This article has some interesting tips and useful encouragement but the system it outlines has a glaring hole: there is no objective feedback loop based upon <i>outcomes</i> back to the interviewer. The author appears to encourage that interviewers seek feedback, but the message is not to look for data but <i>sentiment</i>:<p>“One way you can tell you’re proficient is that recruiters and hiring managers try to find ways to include you in their interview loops because they know you’ll both get the candidate excited and be able to assess their work fairly, even if they take an unusual approach.”<p>If recruiters and hiring managers want you on a panel, it signals that you’re unlikely to disrupt their pipelines by rejecting candidates. This is especially true for high-growth companies (e.g. Twitter where ICs would do 8 onsites a week; I did 5 per week for years). They like you not because you’re proficient but because you’re aligned.<p>Is it possible to be aligned and “wrong” ? Of course! Invariably, gluttonous hiring practices result in the need for “bar raisers” to restore consistency, entire teams with no real focus, and an explosion of communication channels. Hypergrowth is cancerous. And if everybody is in it together, nobody will be hold another accountable.<p>This article outlines very little about proficiency and a lot about how to brainwash new grads into believing alignment itself with a recruiting process is a very special skill. Seek evidence about real outcomes instead. Do your own critical thinking.
I don't think "assessing talent" during interviewing is a skill you can learn. The skill you're learning is assessing how well the candidate performed during the interviewing process. The interviewing process itself is what is assessing the talent.<p>Put another way, I would rather have a novice interviewer use a good process than have an experienced interviewer use a bad or mediocre process.<p>In my experience, FAANG-style whiteboard interviews are a bad process. They don't work for assessing developers, and the skill of the interviewer can't compensate for that. The only thing I have found that works consistently is some form of work-sample interview, where the candidate produces working code in their preferred development environment.
Can anyone recommend a good book on becoming a better technical interviewer? I’ve found plenty of books on being a better interview candidate, and a few for hiring ceos or sales people, but I haven’t been able to find anything with useful suggestions for the hiring side of the table in a tech interview.
Engineer / engineering manager here.<p>Nicely articulated article. There is one observation that I respectfully disagree with - the one that says interviews are monotonous and boring.<p>I have done hundreds of interviews in my career and never found them to be boring. Perhaps one the reasons is I don't do scripted interviews. It is always an exploration for me. I will start with simple questions and if I get good answers I will go deeper and deeper into the subject matter or into the adjacent area. If I don't get good answers I will retract and probe another direction. This is sort of a depth-first traversal of candidate's skills with a heuristic to stop traversing a particular branch if I see it is not a promising direction.<p>My goal is to discover the area where the candidate is the strongest (obviously within the areas I am interested in for the particular role I am hiring for). It is very fun and almost never boring. The experience is always different because people are never the same. Yes, some candidates are just not good, but even bad ones are bad in different ways.<p>I know common wisdom for using scripts is to have repeatable and comparable evaluations so that you can choose the best candidate. I understand the desire but I prefer to find the best in each candidate and if it means I have to use a lot of gut feeling and intuition to make the final decision then so be it, I believe it still results in better overall results. The idea to choose the person I want to hire based on how many answers to my standard questionnaire they got right was never appealing to me.<p>I can totally see how if you do scripted interviews it can become boring, so don't. Interviews can be fun and it can be a creative process.<p>Another way interviews can be fun is if you find someone who has stronger skills than you do in a particular area. I love it when a candidate teaches me something new. Find where their strength is and let them shine.
My reaction to this article - we've utterly failed when it comes to training effective mid-level software engineering leaders. It feel like we are substituting rule by committee for what should ultimately be a leadership decision. If you cannot select engineers, you should not be leading them.<p>Employee Input is certainly welcome. We don't want to hire jerks or idiots. But the manager is responsible and accountable for the quality of hires and employee performance.<p>The other half of my life is in manufacturing / distribution. We have engineers too, managing great big piles of machinery. We RUN on engineers and mechanics. Generally led by engineers. Hell, my last CEO was a former engineer and my current COO (who runs the plants) is an engineer himself. It's engineers, all the way up.<p>They don't need to shop candidates all over the building to figure out if they can handle the job. They know. And can make an appropriate decision.<p>It starts with setting the expectation that engineering centered functions are to be led by engineers. And the price of leading those functions is knowing your stuff...<p>No Excuses.
The article names "making the candidate want to work with you" as the first of the two critical skillsets, and goes on to reinforce that this is important.<p>I've thought for a while that this might be one reason why some large dotcoms (which reportedly study their interview efficacy) put even very experienced candidates through one-way leetcode whiteboard batteries. It seems similar to "negging"[1]. If there's an attraction intent behind it, that would explain a lot.<p>If so, then perhaps we have countless other companies mimicing the big dotcoms, or at least being influenced by the practice, without being in on the dark pattern side to it.<p>[1] <a href="https://xkcd.com/1027/" rel="nofollow">https://xkcd.com/1027/</a>
I noticed that the people who interview a lot don’t really get anything in return; in our quarterly engineering org meetings or whatever there’s a slide thanking the people who interviewed most. I’ve never gotten a thanks when I interviewed more than other times, nor any other indication that this is something my manager values. (And what your manager values is kind of everything, in my experience.)<p>So I almost never volunteer when they need someone to cover, don’t try to put more effort into it than necessary, and have blocks in my calendar so they don’t try to schedule when I don’t want them. It may be crucial for the company (and ethically, you owe it to candidates to treat them fairly) but it’s not treated like something they value.<p>For what it’s worth, I somehow slipped through the cracks and didn’t have to interview for quite a long time after I started. No one complained or made a note of it at all.