Comment by nulptr | Hacker News Reader

Comment by nulptr | Hacker News Reader

Parent Full thread

I don't think it's just about solving the problem.

It's also about: - how you convinced yourself and the interviewer that your solution was correct (essentially an informal proof of your code)

  - how you test your code after you finish coding

  - what clarifying questions you asked to tease out a concrete question

  - what edge cases you thought of and how you handled them

  - how you handle bugs if they appear in the code

  - what solutions you presented and what their tradeoffs were, and why you decided to use a particular solution

  - whether your code was idiomatic

  - whether you used clean abstractions

  - maybe also comments and variable naming

... and probably others I'm missing.

I don't deny that interviewers have their biases, but I would hope that your interview performance is the major factor in whether you received an offer. There are plenty of people at Google and Facebook who haven't majored in CS at a top school.

From talking to some people who give out these interviews, most of those points really don't matter at all. What matters is A) getting a correct solution and B) being able to explain how you arrived at the solution. Tests, idiomatic code, clean design, etc are not expected and will inevitably waste precious time. Besides, the very nature of the interview (using a walled-off in-browser pseudo-IDE) restricts you from actually writing best-practice code.

As a counter point, I was in an interview loop recently with a candidate that ended up solving the question eventually, but didn't hit a lot of the bullet points in the parent comment (asking clarifying questions, edge cases, abstraction).

After discussing feedback from other interviewers, it was apparent that the same considerations were lacking in multiple interviews, and so the candidate got a no hire decision. For any single interview it probably would have been okay to omit these things, but when there's a negative pattern across multiple interviews, that's when it really hurts your chances.

How do you expect to convince the interviewer that your solution was correct without tests? How can you debug your code properly if you end up with a spaghetti mess instead of using a clean design?

Testing and debugging vary from site to site. Most of the ones I've used run your code against a hidden suite of tests to check all possible edge cases. This would otherwise take up a very non-trivial amount of time in the session. Actual debugging is also not possible on all of the sites -- usually the most you can do is litter your code with logs, which is far from a clean design.

Reply on news.ycombinator.com