I am both a recruiter and a highly experienced developer and software designer.<p>I once sent one of the very best programmers I know for a job interview.<p>I have met a small handful of outstanding programmers in my > 30 years in IT and this guy was in the top five, near the top.<p>I had personally worked directly with him for 5 years and he was unquestionably one of the most talented programmers there is, and a nice guy, easy to get along with and great to work with. Incredibly productive, and capable of the most incredible feats of software development.<p>The client interviewed him and said ....... no thanks.<p>There you go - I have just explained everything you need to know about technical recruiting. Give it some thought - the more you think about it, the more it reveals the deepest truth about YOU and your software hiring processes.<p>NO-ONE - no-one ever thinks they make the wrong call when they reject a candidate - including you.<p>If you want to know what happened after that - I called the CEO who I knew quite well and essentially said to him "What the fuck are you doing? I sent you one of the best programmers there is - and I know this from first hand personal experience over five years - and your interviewers rejected him?". They employed him because of that and he became their chief technical architect pretty quickly.
Post author here:<p>My new company helps companies fill contract software positions. We're a lot like a recruiting or staffing agency, but trying to do it in a new, less spammy way. It's been REALLY frustrating working with hiring managers. I used to be one of these frustrating hiring managers so I guess I had it coming.<p>I had a hiring manager tell me that he can tell in the first 15 min of an interview if someone is a great engineer or not. I remember thinking the same thing. I felt like I had this special intuition that I had developed over the years. That's just total BS. There is NO WAY you can know that and you don't have a "special gift".<p>I don't have a great solution yet, but for senior engineers I've come to trust previous work experience the candidate has much more than my gut, my culture fit questions and my stupid coding questions. We had a hiring manager that was looking for a strong back end engineer turn down the engineer that built the search backend for yelp because he didn't like his answer to "how would you program the code in an elevator."<p>So my new company Facet (www.facetdev.com) is basically built around helping senior engineers, with strong experience building products at scale, find contract work.
Obviously interviewing isn't 100% accurate. Almost nothing is. You definitely can't tell in 60 minutes whether someone will be a success at your company.<p>But you often can tell, with very very nearly 100% confidence if someone will <i>not</i> be a success. And that is the purpose of the interview. To filter out the "definitely not"s — the programmers who can't write fizzbuzz. And yes, I have seen plenty of these.<p>And interview is not the be-all and end-all of recruiting: of course it isn't. But I'm seeing a pendulum swinging a long way in the other direction now, and a lot of people talking as though interviews are worthless. They're really not.
I conduct the technical part of interview in my company. There are many candidates which charm our director and HR. They recite the buzzwords flawlessly and their resumes are top notch. When they come to technical part of interview, they charm us as well. Until they start coding. We ask two easy coding tasks (one programming, one data science) and so many candidates have issue with transfering algorithm they conjured on the spot into code; or are unable to solve problem on abstract level (and not hard-code the values for problem given to them). It is not uncommon that we identify sweet talkers which would have negative productivity for the company (meaning we would spend more time/money into fixing their code than they would bring value). I am firm believer that software developers must pass technical part of the interview.
Still relevant: <a href="http://www.aaronsw.com/weblog/hiring" rel="nofollow">http://www.aaronsw.com/weblog/hiring</a>
One of the biggest issues is the industry as a whole operates on a completely different hubris level. I don't think any of my professional references has ever been contacted with the purposes of gaining significant insight into my prior accomplishments or to get information about what it was like to work with me. Nope, all we need is some fancy data structure and algorithm knowledge and a white board to find that great candidate.<p>And those that do care about past accomplishments seem to be more interested in public Github repos.<p>However, it's my guess there's some sort of inflection point because I doubt Pike or van Rossum did any white board problems when they were hired at Google. My guess is their interviews were much closer to the way the rest of the world, the world outside software development, conducts interviews.
It's better to let good/great people slip away then to get a bad apple onto the team. Or worse, a mediocre one who never does anything <i>wrong</i> but also isn't contributing positively either.
Daniel Kahneman, a Nobel laureate noted for his work in judgment and decision making, stated in an interview earlier this year that interviews are terrible at choosing the best candidates. Unfortunately, he didn’t articulate alternatives.
Maybe making the 'extended interview' process more formal would be a good thing.<p>Formally have an internal 'contract' worker process where anyone they might want can be hired in to a trial pool, and projects can bring in the trial worker for small things quickly (maybe writing unit tests, or a fresh set of eyes, etc).<p>Every month review performance, make a decision to offer job as X, keep on for another month, or let go.<p>As a different part of this, alternating weekends might also be a more focused part of this, let someone that ALREADY has a job have a similar trial process on just some weekends, maybe with a more remote-work focus.
It's more accurate to say that the current format of asking algorithm questions is not the best way to judge programmers ability. All it tests is how much has the programmer memorized for the interview and not really how he codes in the real world.<p>But i dont see this changing as most interviewers have been through the system and are likely average programmers themselves.
I am approaching 1.5 decades as an employed software engineer. Interviewing culture seems to change a little over the years, but usually in other wacky directions that leave me feeling entirely disengaged from the industry. I also very much love my vocation, though it alone is not enough to keep me enduring through the insanity of technical interviews , "cultural fit" assessments, and the violence of linear reductionism.<p>Articles and discussion threads like this are pretty much the only reason Im willing to interview at all (and thus remain in the industry). So thanks for sharing, Im glad to know other people are aware of how bonkers this is.<p>The long version takes years of explaining.<p>The short version is: I am highly allergic to cognitive dissonance.
I'm interested in where the break-even point is. With some interview processes now stretching over 15-20 hours or even more, it seems at some point the process is not helping make a better decision and just demanding extra resources from both the hiring company and the interviewees.
The underlying assumption is that Daniel would have been a great fit. Can this be assumed? Even as a good engineer, his claim to fame is founding the Prime Air team. Would there have been a "What started as an idea over coffee with Gur..." moment at Netflix? Would he have just become a random developer instead? Worth nothing that Daniel actually went from Microsoft to Amazon after not being hired at Netflix, so perhaps he would have similarly churned at Netflix.<p>This really isn't your typical "but whiteboard interviews suck!" situation. (not to say that they don't ....)
I feel that the best we can do is "does this person look good on reference and/or paper? Then if so, in the phone screen and then interview: is there any reason to believe the stuff on paper might not be true?" (that latter happens a surprising amount).<p>Also: "is this person a jerk?" though you have to account for the awkward things someone might accidentally say when they feel they're in a high-pressure situation.
It's interesting that some people find that many so-called "programmers" cannot write FizzBuzz (see links in post, apart from a fun FizzBuzz version in Python):<p>FizzBuzz in Python with nested conditional expressions and a generator expression:<p><a href="https://jugad2.blogspot.com/2018/12/fizzbuzz-in-python-with-nested.html" rel="nofollow">https://jugad2.blogspot.com/2018/12/fizzbuzz-in-python-with-...</a>
Sometimes I think we would be better off hiring people on the spot at random.<p>In France we have a legal maximal 4 months trial period for employees so... This gives enough time I think.<p><a href="https://www.service-public.fr/particuliers/vosdroits/F1643" rel="nofollow">https://www.service-public.fr/particuliers/vosdroits/F1643</a>
It really depends. When you are hiring senior programmers, don’t set the bar very high, then you can filter out majority of bad applications in a 60mins interview. For both hard skills and soft skills.<p>Then you need to spend more time for the remaining ones to find the right people.
What's interesting is that most thoughtful people in the industry agree that our conventions around interviewing make for an almost hilariously arbitrary hiring process, but very few large software orgs have actually changed the way they hire.
Portfolio, portfolio, portfolio.<p>I could talk to someone for hours and still misjudge whether I would enjoy coding on the same project with them.<p>Show me reams of code that they wrote, and I will know immediately.<p>It's too bad that usually isn't possible.
We can’t. But we also can’t interview people for weeks. So we do one hour and we go with our gut feeling. It’s a terrible way to hire, possibly the worst, except for all the other ones.
No worries. There's always that probationary period in which either party can recognise it's not a match and either do something about it, or just give it up. How long will it take you to decide? A week? Two weeks? A month?
You can judge programmer's ability in 60 minutes. Can someone program? 60 minutes is way more than enough. How great of a programmer are they? You're going to need more than 60 minutes, unless already had a chance to look at their prior code base.<p>What's difficult to judge is, are they organized? are they hard working? how do they handle stress? how's their communication and attitude? do they write great documentation? do they test their code? are they a great team player? how creative are they?<p>Due to time constraint of an interview, someone might be more sloppy than usual. Their might be the interview stress which is different from regular work stress, interview stress can impact their communication, etc. But if we focus plainly on technical skills, you can flush that out in 60 minutes.<p>I'm a hiring manager, and I have never failed in hiring someone who didn't have the required tech skills. Technical ability I can always hit spot on, the tough one is determination and soft skills. Some of the folks I took chance on, who displayed terrible soft skills during interview turned out to be champs, communicate great, work hard, etc. A few that were very eloquent during interviews were a disappointment, sloppy in development, poor communication in practice, etc.<p>People also grow, so someone that was a bad fit/interview for you, could in a few years grow and become great. Potential is also difficult to spot.