3 ms·

Recently read a blog post of Erik Bernhardsson on the interviewing process(he has several other interesting posts that approaches hiring as a machine learning p

Recently read a blog post of Erik Bernhardsson on the interviewing process(he has several other interesting posts that approaches hiring as a machine learning problem). https://erikbern.com/2018/05/02/interviewing-is-a-noisy-prediction-problem.html https://erikbern.com/2018/05/02/interviewing-is-a-noisy-pred... He suggested asking many short questions instead of doing long leetcode problem(as the solution often relies on one single insight, it gives you very little information relative to the work involved). He also suggested using code reading >I print out 10-15 code snippets (not just code, but also UNIX commands, regular expressions, SQL queries and many other things). I then go through and ask: what does this snippet do, how does it work, are there any bugs, etc.? Reading code (as opposed to writing) means I can cover a lot of ground extremely quickly, spending no more than a minute or two on each problem.

adam_arthur 4y ago
Yeah, asking questions with multiple stages/progression, where the early stages are obvious but still provide signal through coding competency are good. Similarly, many small questions is going to give you a more accurate view than a single hard algorithm problem. There tends to be a trick or specific process to solve leetcode style problems, thus sessions are more black/white on whether the person makes that observation. Very unnatural to usual dev work. Interviews should never feel “hard” even if your threshold for success is high. There’s nothing that requires you to ask hard questions to get good candidates. By definition if your problems are perceived as “hard” then they aren’t assessing people on relevant skills, because a problem that is correlated with real world work shouldn’t be hard for anybody who is coding all day/every day. (Though somebody who is unskilled may find pretty much any problem hard, speaking more broadly here)
Yoric 4y ago
I've had an interview during which I was asked to review code. I loved it.

adam_arthur 4y ago

Yeah, asking questions with multiple stages/progression, where the early stages are obvious but still provide signal through coding competency are good. Similarly, many small questions is going to give you a more accurate view than a single hard algorithm problem. There tends to be a trick or specific process to solve leetcode style problems, thus sessions are more black/white on whether the person makes that observation. Very unnatural to usual dev work. Interviews should never feel “hard” even if your threshold for success is high. There’s nothing that requires you to ask hard questions to get good candidates. By definition if your problems are perceived as “hard” then they aren’t assessing people on relevant skills, because a problem that is correlated with real world work shouldn’t be hard for anybody who is coding all day/every day. (Though somebody who is unskilled may find pretty much any problem hard, speaking more broadly here)

Yoric 4y ago

I've had an interview during which I was asked to review code. I loved it.