I've had this discussion during interviews as a disarming technique. Candidates will sometimes express nervousness at the beginning and say stuff like "I'm terrible at interviews" or "it's been a while since I've had to do this kind of programming," and I try to respond by making it clear that I understand that the whiteboard coding has very little in common with the actual job and that I'm not judging them, so when I dutifully proceed to ask them to invert a linked list, they hopefully don't feel as judged when they approach the problem. Seems to help at least a bit. Mind you, I'd prefer NOT asking those questions, but I'm not empowered to make that change at my workplace and I'm honestly not sure what I'd replace it with if I were.
Interviewing should normally have two results: the candidate was able to demonstrate the appropriate skills, or the candidate was not. Not being able to demonstrate the right skills in the interview does not mean that the candidate is a bad programmer or even a bad fit for the job. It just means that I was not able to verify their bona fides in that hour.
That's the difference between "that interview didn't go well" and "you are a bad programmer." One's a major blow to self confidence, and the other's a bummer. It's also a helpful mindset shift for both the interviewer and the interviewee: both of us are working together to achieve the goal of proving your capabilities. My job is to give you as many opportunities as possible to do so.
Why do you think that whenever we discuss interviews on HN, there's several highly upvoted comments complaining about how many incompetent people show up for interviews and how this basically makes coding interviews necessary?
I think it's because most interviewers consider people that failed their interview bad programmers.
You get classroom training, shadow hours, supervised hours, and certification on a particular type of interview. From that day forward any open slot on your calendar is fair game for Recruiting to schedule, up to 3 per week. You might get away with a "No" RSVP if you have a good excuse, but not in general. It's part of your job.
I think one of the biggest problems we have today is that we use the same word for estimating or evaluating a characteristic or ability of a person, as we do for evaluating the person themselves. I am evaluating your ability to perform this complex task in this situation, and it has nothing to do with my value for you as a person.
You may not care whether I value you as a person, but at that point, that's your problem and not mine.
I'm not even exaggerating, I believe this is a major source of strife in modern societies.
Trying to understand their thought process, is the candidate coachable, can the candidate accept feedback, does the candidate at least understand the underlying ideas, etc.
The more prestigious the employer then the less forgiving they are on your shortcomings.
The word "judging" has multiple variant meanings. It is being used to mean two different things in this subthread.
Judging whether a candidate is coachable, their thought processes relevant to the job, understands the ideas etc is what the interview is for, you're right.
But "I'm not judging" doesn't refer to that. It refers instead to the concept in the word "judgemental". Some definitions of that are "having or displaying an overly critical point of view" and "thinking, speaking, or behaving in a manner that reflects a critical and condemnatory point of view".
Apologies are due, sir. Two things happened. First, I hastily read through the question and rushed my response. Second, just a few minutes prior I finished a workout and was quite exasperated.
The use of the term "not judging" is a bit strange, without further context.
> I'm honestly not sure what I'd replace it with if I were.
Just to theorize: how about having the interviewee write a narrowly scoped toy project that's relevant to the position? (Edit: On site, as a replacement for white boarding.) A JS to-do app for a front-end engineer, for instance. Just a short thing you and the candidate can attack together in a couple hours. The candidate can write "normal" code, google things, clarify requirements, use their own architecture/patterns/style to reach the solution, etc. You could even add/change a requirement midway through the session, too. That would be realistic, and test for brittleness (and maybe be mean).
I don't interview people, so this might be hopelessly naive, or maybe untenable for some types of positions. But that interview process strikes me as a far more representative microcosm of an actual job than regurgitating LeetCode solutions or hardcore algo arcana.
I worked at a company that did this. This company always pair programmed. So the interview took place at a pairing station. We gave the candidate a choice of about 10 toy problems to solve, and then we coded for 2 hours. They could use Google, their preferred IDE, whatever they wanted.
Of all the companies I have worked at, this was by far my favorite interviewing technique. But, I think it works best when you pair with the candidate. So if pairing at your company is not done, it might not be a good fit.
> Just a short thing you and the candidate can attack together in a couple hours
Unless your hiring pipeline is absolutely perfect (you pretty much get great candidates all the time and almost no bad ones) this doesn't scale at all.
Because a candidate can grind leetcode and prepare for a huge number of companies.
On the other hand, something like a homework assignment is typically good for a single company, and if you fail, it's time and effort and emotional energy down the toilet.
Are extremely prestigious or have compensation clearly above market rates.
Candidates only have so much time to dedicate to homework so they will sort companies and work on homework assignments from top to bottom.
Homework are easy to grade (some of that can be automated!) and low commitment from the employer side. But that low commitment sends a signal that the candidate isn't really valued.
Having an on-site with engineers sends a much better signal as it tells the candidate he's worthy of discussing with a real engineer on company time rather than some gradings software.
Of course, if your recruiting pipeline is very poor (low signal to noise ratio, majority of applicants can't code) then sure, weed out with a homework assignment.
Agree 100%. I've decided to just reject any company that requires a homework assignment unless it's a FAANG or nearly FAANG level of prestige and/or comp. Otherwise, it really is a waste of time when there are many, many, companies that do not require homework.
I've done tons of interviews over the past 10 years. It was surprising to me the number of times the experience on a resume didn't line up with what the interviewee showed through conversation and small whiteboard exercises.
I get that it's not very real-world representative, and that's why homework is used instead by some companies.
Maybe the answer is to give the applicant a choice? Either be prepared to convince me you know what you claim, or demonstrate it with a take-home problem.
Personally, I'd prefer a day of in-person-pair programming as part of the interview. I'd get a better feel for the team and their workflows. If it's a total horror show, it's good to know up front :)
I think I misled you. I meant for the toy project idea to be an on-site, swap out replacement for a typical white board session. The time commitment should remain unchanged. Maybe I should edit the original comment. Sorry!
I prefer to have multiple short interviews with different engineers rather than a single multi-hour long one with only one engineer. You get better feedback and it helps against bias.
Not only that but a "toy JS app" implies the candidate knows JS at all. If it's college recruiting, you are better sticking with algorithms since you know that they know it.
To be clear, the goal is to watch the candidate build something using the prerequisite skills expected for the position. I'm not prescribing 3 hour sessions, or JavaScript. Target a 45 minute session. Target whatever tools, languages, etc are expected for the role. Maybe that means being language agnostic. Whatever is appropriate.
Watching folks make something -- for any significant duration -- is perhaps a better estimator of a candidate's genuine job ability than testing how well they approximate an algorithm textbook. Well...that's the assumption, anyway.
