Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

About 10 years ago, I was show a piece of code (directly from their codebase) which was about 50 lines long and we had a technical conversation around it in which the interviewer asked me the following questions:

- What does this code appear to do (both technically and more importantly in the context of the business domain of the company)

- Are there are any red flags, edge cases, etc. that this code might not cover?

- If I were to rewrite it in the using modern libraries/tooling/best practices, what might I have done differently? High-level - we're not looking for you to physically write syntactically correct code here.

This is the same interview process that I now use on prospective applicants. In a single 30-60 minute dialogue it helps me answer questions such as:

- Can they size up and summarize existing unfamiliar code bases? In enterprise the ability to deal with legacy code is often more common than writing new code

- Can they re-interpret old code using a modern lens? For example if we're discussing JS/TS (requires vs imports, callback hell vs async await, XMLHttpRequest vs fetch). For python (nested lists vs dataframes, simple numpy regression vs pytorch, etc)

- Are they able to communicate and convey their thoughts in a coherent and logical manner?



I like this idea a lot, its a different form of technical interview that relies on interpretation rather than getting them to write something that may be suboptimal and not the quality of what they would do on the job. It tests knowledge rather effectively


I've had a similar one and find it extremely helpful for both parties. It should get more common!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: