DEV Community

Discussion on: A tech interview that doesn't suck

Collapse
kallmanation profile image
Nathan Kallman

It's interesting that this is basically exactly what my current employer does for interviews (though a different problem more derived from our domain instead of a generic todo) and has done since I was hired.

Judging by the quality of engineers hired over the almost 4 years I've been there I'd say it's a good strategy:

  1. Small starting code problem
  2. Modification requests in a live coding session

Does an excellent job of testing their coding abilities as it most closely matches actual workload without a lot of the false signals from trivia style coding problems (you studied this particular problem, you had someone else write your submission, etc.) It's the follow up that's important; it exposes why it's bad they wrote it all in one function, or didn't test it, or used regex for everything. Have a small enough follow up change so even the most junior can make progress and show their current skill level, but have enough follow ups that the most senior won't run out/can flex their thought process a bit.

Great article!