Thanks for the write up. Although I don’t agree with everything you say, most of it makes sense to me. Those who haven’t done a lot of interviews don’t know how extremely time consuming and difficult it can be to recruit people. Here’s my perspective on it.

Our recruiters handled most of the work but in the end only an engineer can (try to) judge if the candidate knows how to code. During the peak interview period I had 2–3 interviews a week. Even though the actual interview time only is 2–3 hours, you’ll have to read through the CV, some referenced work, some bureaucracy and a wash up discussion with other interviewers if the candidate should get an offer. All this is at least an hour of extra time. In the ended up working 20%-30% as a recruiter when all i want to do was to crush some code and finish my project.

How do you judge if a candidate can code, in a standardized way across the organization? An easy way is to talk about data structures, personally i hate it but i can understand why it’s used. When i was doing interviews we had a work test (home work) so we had some shared code and problem that we could discuss with the candidate. That makes it even more time consuming since you’ll have to go through the test beforehand but it allows the candidate to demonstrate their skills in a better way.

In the end, it’s all about empathy. It’s gruesome to apply for job after job. As an interviewer, take an extra couple of minutes to talk with the candidate to make them feel a bit more comfortable. It’s also hard to do interviews. If everyone keep asking you for Big O estimates, do a bit of reading before you go to the interview. That way both of you can get the hell out of that room and do some proper coding!