Ask HN: What should an ideal developer interview process look like?

I wish I'd had "a real plan" in jobs past as an individual interviewer in a series, instead of a vague goal like "talk about his technical chops" or "see if she can work across teams". I turned out not to be very good or consistent at either freestyling questions completely OR reporting reliably whether a candidate was "successful" in my area without planning and consistency.

I'm a former developer, turned hiring manager for a very technical support team and employ several things I feel are fair and useful and I believe would also have been in that past life.

0. repeatable interview process. When comparing candidates, the comparison should be apples:apples. "check for culture fit" isn't; "ask questions 1,2,3 of each candidate, with goals of finding out x,y,z and help to N degree if requested" is. Leave room for the candidate to demonstrate personality and style of course, as well as (short) tangential conversations that come up during the Q&A process. The goal isn't to make it robotic/automatable.

1. There is a take home exercise. It has a clear scope:

- accomplish goal X (create a website)

- with tools like Y (your choice of static site generator)

- in Z fashion (public github repo)

- in less than 4 hours.

Encourage questions before candidates begin the exercise, so that people work on the right problem rather than guessing wrong. Don't force a timeline ("you have until the job closes which won't be sooner than a week from now"), and use an objective grading rubric for each section of the task.

Here's an example of the objective rubric: 1 point for grammar, 1 point for each of two distinct points of content, and 1 point for providing the context as to why those are important points. Few of the questions have only one correct answer and it is not always obvious to candidates what we're looking for in an answer; but it is known in advance to the grading committee what is being sought, e.g. "perspective over plot".

2. interviews are in slack. We're a remote team who communicate 95% via writing, and it doesn't matter if you stutter or what you look like or how you present. Get comfortable in your PJ's with a cup of tea, or use your standing desk if that helps you feel sharper. It only matters how you communicate in writing.

Once again, the interviews are structured - "interviewer 2 will ask these 5 questions" and the criteria for success aren't "this woman was well spoken" but instead "she showed ability to think on the fly about something unexpected, demonstrated empathy in communication, and made a compelling argument for her proposed solution". Not quite as objective as the take home test, but still "gradeable". And, in case of a hard choice between two candidates, other stakeholders in the hiring process can review the transcript of the chat, providing their grade considering the pre-specified criteria, to help decide.

It's not ideal, but it is practical, allows for cooperative interviewing (anyone can help a candidate start the well-documented interview process; anyone can do any stage of the interview and know that we cover all the questions we want asked before the end), and encourages consistent judgment.

It's worked well for us so far and people have appreciated it; it also lets us give concrete answers to "what could I have done better?" to candidates we reject who ask for a follow-up. I feel pretty strongly that you spent your time working with us (particularly on the take home exercise) so I can spend time explaining how you could improve (often it is useful to other applications for other jobs: "your code should have comments to explain confusing things or highlight clever things", "consider using git for revision control rather than only committing your completed project", "you'd benefit from using a grammar checker"). We've had many repeat applicants who answer better with each iteration.

Yeah, that’s how I understood it, but there’s often opposition on HN to that process.

I hate doing take home projects.

* It's way too easy to set a project that takes too long. I was given one the other day that would have taken about two to three full days. That simply doesn't happen if you do the test sitting in front of them - the time spent (and potentially wasted) is always capped because the test setter doesn't want to waste too much of their own time.

* Take home projects inevitably have issues ("bugs", if you will). You can't just "resolve" those problems if the person who set it isn't sitting in front of you.

* Take home projects take employer skin out of the game. It's way too easy to give out twenty tests and ignore ten of them. I was actually half way through a homework test the other day when I was told that surprise they had an open offer and the candidate had just taken the job. I doubt they'd have wasted their own time testing me IRL knowing what they knew.

From the employer's perspective:

* In the last case I also realized after googling that the answers were online and I could just have copied someone else's.

* You lose a valuable source of feedback which allows you to iteratively improve the test if you're not watching the candidate while they do the test. I suspect this is partly why the take home tests I've been given are generally of a lower quality than the in person.

* It's valuable to talk through the solution with the candidate while they do it (describing trade offs they made, pitfalls they're cognizant may crop up, potential downsides to their approach).

After the initial phone screening for a full stack engineer, we send a take home questionnaire that doesn't require any coding - but rather presents a set of questions that span across different domains (development process, databases, product, infrastructure).

The candidate selects 3 questions to answer from the set of questions. We expect them to take ~15 minutes to answer each question using the English language.

I guess if you're hiring junior people to stick in a standardized box, it's mostly just a numbers game. Way back when I got a job offer out of school strictly based on my resume (took another job).

But even when the interview process was mostly a formality because I knew many of the people and they knew my work, I still had some on-site interviews.

I'm pretty sure on-site interviews are the norm for the vast majority of professional jobs. Including, or perhaps especially, for the most senior positions.