from Hacker News

The Technical Interview Rift

by DonPellegrino on 10/18/16, 5:18 PM with 95 comments

• by kafkaesq on 10/18/16, 6:16 PM

  Some useful advice, but something about the overall tone seems a bit off:

  You are a manager and it’s time to hire a new developer to join your impressive team of A+ players.

  That's where things started to go of course. You're not an "A+ player", and most of your team aren't "A+ players" either. You're just human beings doing the best you can and (hopefully) trying to improve a bit each day -- like anybody else.

  No one wants to work with losers. But any (serious) talk of of "We're all A+ players here!" or "I know how to spot A+ players!" is just motivational kool-aid, and ultimately a distraction from the real work you have to do -- including the task of finding the best people you can hire, and who are willing to throw their lot with your cause.

  Especially when it's quite often the people hired for their seeming "A+" qualities (which they are able to exude in spades) who turn out to be the most toxic, morale-killing members of your (once) impressive team.

• by lisper on 10/18/16, 6:30 PM

  I think Triplebyte has the right idea: essentially a take-home test conducted over a period of a couple of days. It allows a candidate to show off what they can do under realistic conditions, instead of allowing an interviewer to poke at what they can't do under highly unrealistic high-pressure conditions. A typical tech interview is more like a spelling bee than a realistic test of a candidate's abilities: if you happen to get a word/question you know, you look awesome. If you don't, you don't. (Not long ago I screwed up a tech interview because I couldn't remember/figure-out-on-the-spot the iteration condition for estimating square roots by the Newton-Raphson method, and I was not willing to cheat by looking it up on Wikipedia while I was on the phone. Their loss.)

  I just wish Triplebyte would expand their outreach beyond YC companies.

• by blantonl on 10/18/16, 6:07 PM

  I view technical interviews that require algorithm solving and coding on a whiteboard as ridiculous. Primarily, because I am deathly afraid of them.

  And here is why. I own and operate two online businesses in the Radio Communications space that are the de-facto standards for our industry. I've coded both of them from the ground up in PHP/MySQL and manage all the day to day administration of these sites. Our infrastructure is deployed on 20+ servers on AWS, Google Cloud, and some bare metal deployments, for which I manage solely by myself. We have 100's of TB of audio archive storage that is all developed and managed by myself. I've personally tackled the entire stack from the ground up, end to end. I've hired an outside consultant, once, to do graphic design work. I've taught myself titanium accelerator and released a highly successful mobile app for my business for Android and iOS. I've even deployed much of our API using NodeJS! Gasp! I do all security, SEO, sysadmin, scheduling, upgrades, marketing etc.

  But I'm not a computer scientist. If you asked me to outline a best-case sorting algorithm for x use case my response would be "uhhh... " If you asked me to write out a for loop in PHP on a whiteboard I'd say to myself "uh... where do the semicolons go again?" But I can piece together building blocks from AWS, Stack Overflow, open source projects, multiple SAAS providers. I can also write contracts, executive license agreements with third-parties, develop highly successful and consumable APIs, and manage the financials for a multi-million dollar business. I've also deployed multiple APIs in SOAP, XML, and JSON which form the most successful parts of my business

  But get me up in front of a technical interview team where the startup is looking for a computer scientist and I'll have a ton of "yea, but..." and probably wouldn't last too long.

  So when I see these examples of technical interviews in organizations where I know I could add value, but realize their process for evaluating that value could certainly eliminate me very early, that scares the crap out of me. Fortunately, my business has been successful enough that this will never be a scenario I have to face. It still bothers me though.

• by jakewins on 10/18/16, 6:15 PM

  > These are ways to gauge if they know the langue without making them write code. You should never ask a developer to write anything from scratch, or write anything.

  But.. why? You are hiring someone to write code, what better way to gauge their ability to do so than a work sample?

  Obviously you don't drill someone on sorting algorithms, unless that's what you are hiring them for, but make them solve a simple task that is on the level of abstraction and in the domain your company deals with.

  Having sat through interviews where candidates who had made it through screenings and talked the technical talk turned out to be unable to write actual code to solve rudimentary domain problems, there's no way I'm hiring a developer without programming with them first.

• by AvenueIngres on 10/18/16, 6:00 PM

  Here is my take on hiring: an active Git repository with a decent amount of non-trivial code/projects generally gets applicants I have to evaluate to skip the whiteboard interview and instead grab lunch or coffee with me. We then discuss technology/software engineering. I find this approach to have yielded much more conclusive results, though it probably would not "scale" well. You can quickly tell whether someone is passionate and resourceful by talking with them, occasionally erring on research-ish stuff but always focusing on the implementation rather than the theory.

  Plus I sometimes stumble on the occasional gem that is very knowledgeable and from whom I can learn.

  Whiteboard interviews, coding challenges, take-home projects. All of those things are so time-consuming for both the company, the interviewer and, of course, the applicant. And all of that just in the hope that the company will accept them... maybe? Of course when nothing else is available then it is the usual drill: phone, skype, on-site 1, on-site 2. But if other signals are available then to the trash it goes.

• by sssilver on 10/18/16, 9:55 PM

  This is what I don't understand. During technical interviews, why don't we just give the potential employee a laptop and ask them to solve the problem as they would during a regular work day? Why can't they search Stack Overflow, and perhaps reach out to a friend or even a random person on IRC for advice? Isn't this how the real life works? They may not know anything about min heaps, but perhaps a 15 minute research will help them solve the problem better than anyone who actually memorized Cracking the Software Interview by heart? Isn't it better to measure discipline and ability to learn and solve problems instead of measuring existing knowledge?

• by svachalek on 10/18/16, 6:09 PM

  From a Silicon Valley perspective, I didn't even know that this was something that companies considered not doing. 'Round here, a technical interview is guaranteed, it's more a question of if/when there will be anything else involved in the interview. Also, will it be a mundane technical interview, or more like 6+ hours doing Top-Coder style questions on a whiteboard? It used to be only Microsoft and Google were known for that but now it's practically everyone as far as I can tell.

• by arcanus on 10/18/16, 5:22 PM

  > All in all, would do again, except not more than 1 a month because flying across a continent and back for 1.5 days is gruelling.

  This is part of the problem. Aside from college graduates, who has time to fly around the country burning vacation time to maybe get an offer?

• by crispyambulance on 10/18/16, 6:15 PM

  I am glad to see managers that give interviewing the level attention it deserves.

  Many interviewers just assume they know how to interview people to find the so-called "A player" (yeah, we're up to A+ now too). People love the idea of magic gotcha questions the answer of which determines whether a person is or is-not skilled some specific area. But the reality is most orgs are barely sophisticated enough to manage FIZZBUZZ-level screening, let alone screening for "A players." Proven interview techniques that take practice, training and coordination like the Behavioral Interview are often skipped in favor of ad-hoc, unprepared interviews that end up with a go/no-go vote.

• by amorphid on 10/18/16, 6:48 PM

  When I worked as a technical recruiter, I found that a great way to screen candidates was to explain the "box" I was trying to put them in. I described the work I'd done to research the position, why I was screening for certain criteria, and that ultimately I wanted to get their approval on the summary I had written about them. Being non-technical, this worked better for positions I was experienced recruiting for of course.

  For example, when recruiting a web developer, I'd start by asking a hiring manager what they wanted.

  "Get me a full stack Rails developer who knows OO Javascript."

  Then I'd just drill into why they asked for that until I didn' have manh questions. I'd be able to describe roughly what projects needed attention, how the tech stack helped solve that problem, and ask the candidate to help me sell them as someone who can do that. It wasn't perfect, but it worked better than most recruiting attempts I've experienced so far.

  Now as a developer with a few years of experience, I feel I have no idea what I am doing, and am winging it at all times :)

• by pklausler on 10/18/16, 6:55 PM

  OP: "There is a slight proclivity to conduct technical interviews within the companies that comprise the community."

  The companies constitute the community. The community comprises the companies.