Ask HN: Can we fix the interview process for engineers?

First, the state of the art of "taking technical interviews" hasn't changed in the last 10yrs at least. This is, when we as an industry are harbingers of "change".

The bottom line is that the interview process is time consuming, expensive and often not the aspect of your job for which you will be held accountable for (i.e. you get fired if you are unable to recruit).

An interviewer in such a case, has no incentive to carefully think about the process. Usually the interview time during his/her day is not the prime task at hand and he/she has to run to "other meetings".

In such an environment and time constraints, We come down to our rote notions of what "intelligence" means.

If you are interested, I would recommend these two very well written articles: 1)http://code.dblock.org/five-ways-to-torture-candidates-in-a-... 2)http://code.dblock.org/how-to-reject-engineering-candidates

Lastly, I wish you luck if you are a so called Front End engineer or worse, a female engineer in this industry. Its really rough out there for them in special.

Now, if you'll excuse me, I have to go and practice my bit manipulations.

Why is it tough for front end engineers?

So are you suggesting that the interviewee goes through something similar to a portfolio? These are some of the projects I have done in the past, I wrote this code here to solve this problem, etc. I agree with something along the lines of "the best predictor of future performance is past behavior," but it could be hard to keep a consistent--dare I say level--playing field that way.

I completely understand where you're coming from, but I'm not sure that a level playing field is necessarily a good thing. Everyone should be given the opportunity to shine at their highest potential and it is my opinion that a level playing field gives candidates the opportunity to shine at their lowest potential.

Find ways to slip your past work into the conversation. If they ask you to solve a particular problem you've solved before, tell them about it. Tell them about the first time you solved it, and what your thought process was, and (if applicable) what better solutions you may have found after your first go at it. Better yet, don't lead with all that; just say something like "Ah, I've actually solved this problem before" and then give them a chance to ask for some detail. If they don't probe on that, you're dealing with an ineffective hiring manager, and are probably wasting your time unless it's a company you really want to work for.

You've brushed up against a key point, I believe. Given a set container all of the problems an interviewer could ask me to solve, there exists a subset of those problems that I've solved previously, but that subset is small.

The problem here is that I don't believe most engineers can effectively explain their thinking when they are still working on solving the problem. Perhaps this is something I could work on, but I prefer everything to be silent while I gather my thoughts. It is my understanding that being quiet when asked by an interviewer to solve a given problem is a bad thing, which ultimately leads to points being docked because I have a process for considering problems that works very well for me.

Conversely, should the interviewee be free to pick a problem they've previously solved and talk with their interviewer about it, they should already have their thoughts gathered. Working under the assumption that the candidate put in a substantial amount of work, they should be able to talk at length about the project. An interesting and useful consequence of this is that, in the event a candidate can't speak about a project they worked on, I believe that says something about their capabilities as an engineer. Should the interviewer be put off by this? Maybe. Maybe not. How far down the rabbit hole do you want to go?

Overall, I think this is a pretty interesting problem that could use some good discussion to generate ideas about what a more effective and efficient process might look like.

From the Other Side of The Table--

Don't approach the interview as an audition, it's not. This conversation should be a two-way exchange of information.

Consider first the interviewer, what's their specific role and background? Are they an influencer in the process or decision-maker?

Just as a physician will perform a patient examination, before prescribing medicine-- can you probe for stated and unstated needs? Can you ascertain what they're trying to accomplish? Any particular areas of pain?

Those insights will help you show-off your talents with the right person at the appropriate time.

Algorithm and coding questions are indeed lacking. They may end up revealing your true ability to do the job, but it's like deciding on an architect by seeing how well they can cut wood and hammer nails.

It's true that discussion of your portfolio and past work, and how it reveals your way of thinking about things and how you can tackle the company's problems, is likely to better convey your ability and value. A smart hiring manager will include topics like this in their interview. A smart candidate might find ways to inject this into the conversation.