5 ms·
This is a pretty good manifesto. Something that I rarely (never) see mentioned is that the ability to quickly evaluate a technical hire is a skill managers can
by malvosenior 7y ago
This is a pretty good manifesto. Something that I rarely (never) see mentioned is that the ability to quickly evaluate a technical hire is a skill managers can and should cultivate. I never give coding tests. I sit down with a candidate and within 20 minutes of verbally discussing their prior projects I know if I want to hire them or not. This does mean that the manager has to be technical and have the ability to deep dive in these conversations. It's by far the most efficient and candidate friendly (and interviewer friendly!) method I've seen. I've never had a bad hire doing this and I've hired dozens of people
- 52-6F-62 7y agoI was hired with a very similar process. I was asked several technical questions that applied to the role and about my own history, etc. Three years later I'm still here and have survived several rounds of layoffs and a sale of the division of the company I work for. I still work with that manager. Most interviews with tech screens that I've done have been fine, though. A couple of them have been bad where I've recognized the engineer testing me has been wrong but that never fares well for the person being interviewed. Most calls I take are often an introduction before we even go to a tech screen, though, and I appreciate that chance usually. It's saved interviewers and myself a lot of time in the past.
- mucle6 7y agoYour story about surviving layoffs implies that you survived because the interview thoroughly vetted you. Wouldn't that be true of people that were laid off?
- 52-6F-62 7y agoIt doesn't imply anything except that I'm still working with that manager and we've worked well together. At the time I was the only technical hire under a technical manager. Much of the business isn't technical and weren't part of the same interview process. I understand what you're trying to ask, but no—it doesn't apply in this case.
- tracer4201 7y agoWhat kinds of things do you ask? I’ve interviewed and worked at FAANGs. I’ve done mostly coding and design interviews. I don’t doubt your ability but help me understand your model. Is it more open ended (tell me about your previous projects... candidate can speak to the problem domain, design, implementation choices, trade offs, or dive deeper into “Oh yeah we had to instrument events to feed into data processing pipelines for personalization...and XYZ failed so I had to do ABC.”) or is there something more critical?
- malvosenior 7y agoI start pretty open ended, then ask specific questions about their choices. I almost always ask them to describe some of the schema of the db or how pieces of their project were communicating with each other... I also ask them what they like about their language of choice and why. I keep the questions specific to their projects and experience though. I should add that I strongly favor candidate with open source experience, so most of the time I'll have also looked at their code myself and may have some questions about it. The number one thing I look for is: can this person ship software? I'll ask a lot about the project lifecycle, what they did to get it across the finish line, how they supported and enhanced it... I try to do this in a non-leading way.
- soneca 7y ago> "I should add that I strongly favor candidate with open source experience, so most of the time I'll have also looked at their code myself and may have some questions about it." So, that's the most important part missing from your original comment. From that, I would assume that you never hired a developer without looking at their code before/after an interview. Is that right to assume? Basically open sourced code (and not the interview) act as a substitute for coding tests in your process
- malvosenior 7y agoNo, I've hired plenty of people who haven't had open source contributions. It just makes the conversation easier when I can see their code beforehand. I also find that the really good people tend to do open source or personal projects, so there's a high overlap there.
- crdoconnor 7y agoI've often been surprised by what has come out in a coding test that hasn't emerged in a conversation. People who seemed dull and uninspired in conversation ended up being brilliant and vice versa. There's no substitute I think.
- malvosenior 7y agoThe trick is to get good at having those conversations so you can get to the bottom of someone's skills even if they're not outgoing, good at speaking... It's totally doable but it's on the manager to develop those skills. There are a lot of excellent developers who do not code well in an interview context. Nerves, artificial restraints... coding is something that happens once you're in the flow. That's a state few can achieve in an interview.
- crdoconnor 7y agoIt's rather like saying that you can interview a musician without asking them to play. Yes, nerves play a part. That's why it's good to start easy and ramp up difficulty gradually, giving the interviewee a few easy wins to build up their confidence before getting them in to the harder stuff. Frankly I find the most unnerving interviews (coding and questions) to be the ones where you have to second guess what the interviewer wants to hear. Where the question/task is difficult, but the desired outcome straightforward it's much less stressful.
- ScottFree 7y agoIt's closer to saying you can hire a songwriter without asking them to write a song in front of you. A musician gets paid to perform in front of people. Asking them to do that in the interview is exactly the skill they're looking for.
- cableshaft 7y agoSpot on! Or take the Funnyman scene from Boondock Saints where a criminal boss tells a guy, "They tell me you're a Funny Guy. Tell me a funny joke." "Now? A joke? Uh... um, uh... A joke. Yeah, alright. Um... <awkwardly starts an offensive joke>... I'm not funny today. I-I know. I'm havin' a hard day. I-I-I- This joke sucks. It's-it's-it's a stupid joke." That's kind of like how I code when sitting down for an interview, whereas I have no problem otherwise. My coding looks like an awkwardly told joke (oftentimes). If all I had to do was pick some code I had memorized and practiced and "perform it", i.e. type it out, then yeah, sure, no problem. But I get asked to come up with the answer to something on the spot, something I usually take a little time to settle into, maybe do some Googling, etc, and always seems to be something I missed when spending several days to a week refreshing my memory on what I think I'm going to be asked ahead of the interview.
- bradleyjg 7y agoEven if we take your word that you have a zero false positive rate how would you even know what your false negative rate is? I don’t understand why so many seemingly otherwise scientifically minded people swear by anecdotes when it comes to hiring.
- tmn 7y agoWhat does false negative matter for? As you said, you cannot know it, so why bring it up as a missing metric? What matters is if they hired for their demand, and their hires met or exceeded expectations
- bradleyjg 7y agoWe cannot know it by anecdote. We can know it using a well designed longitudinal study. Why settle for the former? Why do so many proudly refuse to read the literature? The only other thing I can compare to the anti-intellectualism around hiring is a similar phenomenon around nutrition and dieting.
- tmn 7y agoI mean, I think you're planting your flag in some intellectual what aboutism. The confidence in the strategy of the process here is only as anti-intellectual as it is simultaneously conducive to that actual work trying to be accomplished. Say a man marries a high caliber lady. Beautiful, smart, great personality. If he says, 'I did great here'. Does anyone say to him, 'Well what was your false negative rate?'. I guess you might
- deleted 7y ago[deleted]