4 ms·
I do both. The problem with asking only about experience is - as surprising as it may seem - people are often not prepared for this question. This often means t
by lhorie 5y ago
I do both. The problem with asking only about experience is - as surprising as it may seem - people are often not prepared for this question. This often means they just talk about a highly specific mundane technical task they're currently working on (for example, I've had answers like "implement redux reducers for my project") and when pressed about challenges, they can't come up with anything and just wing it with some generic canned response (e.g. "the challenge was using APIs from backend team to make the product work" or some other mundane aspect that one typically would expect to be present in every such job). Another variation is that they can't organize their thoughts quickly enough to summarize effectively, so they ramble semi-incoherently for 10 minutes about the specifics of their tech debt.
Mind you, while answers can be highly uninspiring, they often help contextualize where a candidate is in the spectrum. It's easy to spot ticket-closers with this question for example, and conversely you can quickly spot highly opinionated individuals. But like in scientific studies, there's different value in self-reported data vs data you collect from your own observation. There's plenty of "talk-the-talk" people that can articulate prose extremely well, but struggle with the most basic of technical tasks when it comes to actually writing some code. This is surprisingly common with people pivoting from startup jack-of-all-trade roles to highly specialized roles in bigcos.
- karmakaze 5y agoDefinitely both. This is the part of the interview that I get the strongest signal from. If they can still remember a problem, failed and working solution with great detail some time after the situation then they must have understood it at a level more than lookup trial and error fixes. It's great when you can riff off each other thinking about various avenues of discovery, potential causes and fixes.
- shalmanese 5y agoI don't understand why we collectively treat interview questions as this big gotcha trade secret we have to spring on interviewees in real time. It feels like a masochistic hazing ritual. I've taken to pre-emailing the general structure of questions I expect to ask ~48 hours before the interview and I've found that a) the interviewees are enormously thankful (which helps with closing candidates) and b) the quality of signal I get is much higher.
- wobbly_bush 5y agoWhat exactly do you mean by the general structure of questions? How much details do you send out before the interview?
- lhorie 5y agoI think there are two answers: the bad answer is that people think of interviews as school finals, with all the same connotations about potential for cheating, cramming, memorization-without-retention, etc. The good answer (IMHO) is that the format allows the interviewer to evaluate how a candidate deals with prioritizing conflicts of interest (i.e. the desire to write clean code vs desire to just get something out due time constraints pressure). It also opens up opportunities to explore refactoring, whereas a primed candidate might just bang out "perfect" code the first time around, and not leave much room for evaluating their iterative process.