Having been researching different hiring practices, it seems that most companies converge on a few different techniques (e.g. algorithms on a whiteboard, take-home challenge, pairing, and technical interview questions). This leads me to ask:<p>How does your team hire?<p>Do you believe in the efficacy of your process?<p>How do you think your hiring process can be improved?
My current company does a pretty traditional "algorithms on a whiteboard" type interview segment or two, an "object/app modelling" segment, and a "chat with the CTO" segment.<p>It seems to be effective in the sense that I don't recall anyone getting hired and then quickly fired, and my coworkers are all very smart, capable people.<p>OTOH, it's ineffective in the sense that we probably need to hire at twice the rate we actually are.<p>I'm not sure what I'd do to improve the process, honestly. Every approach I've ever seen or thought about has significant disadvantages.
I was wondering if any company in the US or outside ask for the candidate's preference about whiteboard vs. takehome project? It seems to be a highly debated sticking point for both camps: some feel they would rather have an easy (generic) way to prep by refreshing their CS101 and save time, while others want it to resemble actual work-like environment + problem.<p>What stops a company preparing 2 tracks and letting the person choose? Yes, it must make HR's, hiring managers' and interviewing engineers' lives a bit less planned and convenient, but it should increase the overall happiness levels for each candidate regardless of the result, which should result in referrals and a filled position (which is what the company really cares about).<p>What am I missing or is someone already doing this?
This has been an area of interest for me as well. I have spoken to a lot of engineers and hiring managers on this subject, and my takeaway is that no two engineers seem to agree on what's the best way to hire people.<p>Some think that code-while-on-the-phone interviews are bad (too much pressure for some candidates), while others think that take-home interviews bring all kinds of issues (e.g. candidates copy pasting code from Stackoverflow).<p>Some think that white-boarding is important (insights into the thinking process versus syntactic correctness), while others think that it's not a true evaluation of what the candidate will actually be doing at work.<p>Some think that asking pure algorithmic questions are bad (does anybody even implement their own hashmaps at work?) while others think that it's a reflection of how much a candidate explores the depth of a subject.<p>Some swear by HackerRank/Codility based automated tests to "filter" unqualified candidates, while others think that looking at Github for their code samples would be a better evaluation.<p>Some want generalists, while others want specialists.<p>Some people reject candidates on arbitrary "culture-fit" reasons.<p>Personally, here's my ideal interview process based on all these conversations and my own 100+ interviews in various places I have worked:<p>* Minimum reliance on resume - some people are just bad at writing about their achievements<p>* Have an initial 30-min call to learn about the projects that the candidate has worked on (especially if you are hiring a specialist). This should not be a filtering round unless you see something totally off target.<p>* Send the candidate a take-at-home coding assignment. This should ideally take only 2-3 hours and should be <i>directly related</i> to the kind of work she will be doing at work.<p>* Have another 30-60 min follow-up call to ask the candidate about the approach taken, alternate options, and possible extensions. This will help one ensure that the candidate had not merely copy pasted the code from the Internet.<p>* If everything looks good, bring the candidate onsite for face-to-face interviews.<p>* I prefer 2 rounds of face-to-face - the first round asking questions around the candidate's areas of strengths, and projects previously worked on by her. On the second round, I prefer asking questions that are from the domain I am working on. This will allow me to find out how the person attempts to understand a new domain, and whether the person listens/asks questions etc.<p>At the end of the day, interviews are subjective, and I have made peace with the fact that you're always going to miss out on people who might have just had a bad day.