For me personally the process gives me a lot of anxiety/fear to the point where I won't do them even when I know I want to. I suspect a lot of the negative sentiment around interviews or talk about their 'ineffectiveness' is just this fear being poorly interpreted.

I think the technical interview process is also just a separate skill to master that has some overlap with programming, but is mostly getting good at leetcode style problems. It reminds me of things like the SAT for college.

There's a lot of failure necessary most of the time to succeed that I think scares people away because they do one and fail and then think they're not good or smart enough. I think I did ten different phone screens and three or four on sites before getting hired by a famous company. Some of those I totally bombed and others went really well - there's a randomness to it depending on the question you get and the specific interviewer.

I wish this wasn't the case and things were better because it'd be really fun to work on interesting projects with different people at different companies, but the barrier to changing is so tedious it's often better to stay put at a local maximum.

The technical competence check is all retrospective, hearing them talk about prior projects and what the design and implementation process was like, how decisions were made, what the challenges were and how they were handled, any regrets/learnings. And most of that is just digging in far enough to confirm that the person was actually a first-class participant in it with a deep understanding, and not a bystander. Any whiteboard stuff would be "show us how the system worked" as a last-ditch check on basic communication skills.

The "audition project" is a trend story with, from what I can see, very little empirical evidence to back it up. When the most notable example of a company routinely employing audition is Treehouse --- all due respect to Treehouse, but still --- that's a red flag.

The bigger red flag is that the paid audition project method has obvious flaws. The top 20% of software developers are almost uniformly employed. Prospective new employers for these people court them actively; in fact, the problem of companies luring top developers out of other companies is so challenging that large SFBA tech companies have entered into illegal compacts to stifle the practice. Companies are so hard-up for talent that they'll "buy" startups just to get access to their teams.

In this environment, why would a top developer, who has their choice among tens of different high-paying interesting jobs, moonlight for a prospective new employer just so they can make sure the relationship's going to work?

Most technical interviews are terribly flawed. They aren't standardized and they aren't rigorous so you can't compare candidates on any apples-apples basis and you can't correlate them to job performance to make them more predictive. Most of the developers tasked with conducting them suck at interviewing; many use interviews as a sort of hazing ritual, and most use them as opportunity to project their own subjective views about how software should be built onto candidates. Many technical interviews are trivia games punctuated by awkward attempts at working through code on a whiteboard or a piece of paper in a high-pressure environment.

The solution to this problem is to improve technical interviews. It's not to pretend that the whole market for devs has suddenly embraced temp- to- perm hiring. It hasn't. It's getting harder to find good developers, not easier, and the notion that companies have the luxury of inflicting "audition projects" on candidates is counter to reality.

Recruitment for tech companies is near constant at a certain level of talent. While there are smaller or profitable but stable niche companies that aren't looking to add engineers, most companies would always hire an engineer with a skill level that exceeds a certain threshold. In other words, if you're really good at coding, have a really strong understanding of software design, and you aren't a hard person to get along with, they'll have something for you.

This leads to the technical "interview", which is really better described as a technical exam. The most infamous incarnation of it goes like this: you arrive in a room, a very strong software developer arrives you are asked a variant on a data structures/algorithms question that you must solve at the whiteboard. It will be difficult to get it exactly right in the time allotted, but you will now demonstrate that you are able to write tight, good, efficient code that largely solves the problem. You will also demonstrate that you can clearly explain difficult technical concepts in clear human language (usually English), without getting angry or excessively flustered. If you're really, really good at this, they have something for you. Exactly what that is we can all work out later.

This leads to a constant state of "filtering". These companies are continuously scooping up silt, sifting through, to see if there are any good bits of gold in there. If they accidentally throw out a bit of gold, that's fine, they just keep sifting and sifting.

The odd thing about this (having been on a few of these interviews myself) is that it turns the "interview" process into a technical exam. I've been shuttled from room to room for six hour of whiteboard exams, all about tree traversal, complex sql, some math, and at the end of the day, I honestly have no idea what this company does or what they'd want me for (aside from what I'd read about in preparation for the "interview", none of which was discussed at all). But I do get it from the point of view of the company - if I can do certain branches of math, write tight code, and do sql really really well, and I clearly have the verbal and presentation skills to explain it all, then yeah, they will be able to make good use of me at their company (for the record: no offer ;) )

The filtering is irritating for candidates, of course, since it means that in our field we sit for exams constantly. The saving grace is that these companies must devote the valuable time of their strong engineers to conduct the interviews, which means they don't do it unless there's a good chance you're a good candidate.

The more insidious side of this is the rise of automated testing and/or "projects". You spend 30 minutes talking with a recruiter, and then you get a link to an on-line exam or project that can take from 2-8 hours. This allows the company to cast a wide net without wasting time. Well, wasting their time. The process allows them to push the inefficiencies of the process out onto the candidates. The amount of time spent by developers on these exams, only to be dismissed in 5 minutes, is staggering. This is one reason I won't take these exams (if they occur very early in the process - if it happened much later, when it was clear both sides were serious, I would reconsider), even though I will spend an equivalent amount of time on in-person exam/interviews.

Technical interviews where you look at some code and review it, or is asked to broadly describe how to design a system etc isn't unreasonable, and as you say it's better than judging only on poise...

There were three "rounds":

1. Phone screen with actual lead developer. There were some quiz-y questions here, which I'd previously thought of as a silly outdated approach, but it honestly was a low stress filter for basic technical knowledge.

2. 90 minute pairing exercise with the same lead developer. We built a small example app together. Resources were sent over ahead of time so my environment was good to go, and the expectation was set from the start that the goal was to assess how I thought and approached code, not to see how far I could get in 90 minutes.

3. 4 hour "on site" where I talked to each developer on the team I'd be joining. No technical exercises. Each person came with their own questions, and expected me to ask mine.

What I took away from the experience was that companies are seriously overthinking and over-engineering the process. There isn't a magic heuristic you're going to discover that will identify "10x engineers." You can vet if someone is technically competent enough for the role, approaches software in a way that gels with your org, and if they have any red flags in fairly straightforward fashion that doesn't require enormous amounts of prep for them or your team.

It's the technical interviewing portion that's a pain to have to re-do over and over again. Especially if it involves travelling across the country to do. Engineers are ultimately looking at company and engineering culture to choose between.

The other thing is that for some engineers, they might perform well in one on-site versus another for many reasons such as the questions asked, interviewer rating, or something as trivial as mood. Seems like Triplebyte giving people one-chance makes this difficult.

Ultimately, I feel the main crux of hiring/interviews/finding the right talent is training. If the industry is over-fitting on people who can pass whiteboarding, then why aren't there more startups focused on this aspect? Not just passing interviews (e.g. outco.io), but actually focused on training systems design and algorithms. Universities don't do that in undergrad or grad school.

I've been to interviews which were more or less well designed quizzes that could be administered by non technical people, with the answers evaluated by technical people later. That seemed better than the alternative. I do know one interviewer who always uses "what do you think are the three best books on software development?" You get some interesting answers to that one.

Just to clarify, at least for the SRE hiring process, you first have a single technical phone screening with a technical recruiter (not an engineer) which is literally on the phone. At least it was for me, no webcam or anything. It's a pretty short and back-to-back question/answer type of conversation similar to what is told by the article (although the article strikes me as odd and does not match my experience). After that you have a couple (or more if need) of "phone" (read: hangouts with webcam and shared doc) interviews with actual engineers and those are more technical and require you to write code as well. Then you'll be moved to on-site interviews.

(This is for Europe at least, I imagine it'd be similar in other areas but can't know 100%).

Maybe the whole time, people should have considered what adds value to the company instead of treating it as an entrance examination. A coding problem is appropriate if they're right out of school and you can't get a good feel for them, but usually, holding a conversation for an hour or so is enough to get a feel for whether or not this person can do the job you have in find, or think of a job they could do.

If having the disposition of a golden retriever is good for a particular role, then that's what you look for. A better soft skill, in my opinion, is knowing where to pick your battles and not arguing endlessly about everything else.

For my money, I'd expect that most interviews in any field are technical to some degree. If you're hiring an HR person at any level of seniority at all, presumably you'll be asking questions that bear on employment/tax law, dispute resolution and so forth - in short, questions that bear on a body of specialised knowledge: technical questions. The problem is execution.

Having never been asked to do code on a whiteboard, I can't comment on whether that's any use. (I think I'd be OK provided it was acceptable to drop into pseudocode: surely we're not testing for encyclopaedic knowledge of every method in X language's standard library.) 'Homework' challenges have the advantage, if they're executed right, that whoever you're hiring won't be going in completely cold to whatever tech you're using - may as well get some of that newbie-googling done in advance. (Just did one for a job using Mongo/Mongoid - what I knew about that beforehand would have fit on the back of a cigarette packet.)

How much time do you spend preparing for non-technical phone screens & behavioral interviews?

Quite likely, there's no one-size-fits-all solution for assessing candidates.

The way I approach this is by looking at the candidate's background and trying to make connections to the product the company or team is working on.

Then I have an open conversation with the candidate about these connecting points and possibly related subjects. It usually becomes obvious quite quickly if the candidate knows what he or she is talking about. It also gives you an idea about how the candidate communicates, which often is more important than technical skill.

Technically, that's still a technical interview but it's much more free-form than the rigid white-board interview format. It's more of a conversation between equals rather than a test setting, where one side is being questioned.

While far from perfect, I think these types of systems do have some advantages. Keep in mind, I think they are best used as a tool for pre-screening candidates for graduate positions (where we have a LOT of applicants), or candidates we may otherwise pass on due to a lack of well known engineering school or well known companies on their resume (and I'm sensitive to this given that I moved to SF with neither of these). Also, my company is in a very technical problem space, so we do actually use algorithms + data structures on a daily basis.

* I don't buy the "I have 5 years of experience, I should be exempt from coding in HackerRank / phone screens / on-site technical questions" argument. I've done interviews with many people with years of experience and Senior Engineer on their resume, who are unable to solve trivial problems like finding simple patterns in an array. This might not be the majority, but it's enough to create a lot of noise in resume screening.

* As a hiring manager, my job is to make sure that engineers on our team are not getting pulled from their day to day work to do phone or on-site interviews with sub-par candidates. While lots of people on HN tend to complain about interview processes, the reality is that once you start at a job, most of the time you want to focus on writing code and solving technical problems, not performing multiple phone screens per day. Designing a good interview process involves BOTH creating a good experience for the candidate, and not overwhelming your existing team.

* Certainly a strictly better alternative is take-home challenges (which we used to use, and still do for some candidates). However, to get any valuable information from these (and give justice to candidates who spent a couple hours building something), an engineer on our team has to spend time unzipping, running and looking through them, and writing up their thoughts. This might take 30 minutes of their time, and probably an hour or more out of their flow. To do this with more than a couple candidates per week is not possible (not to mention the fact that understandably engineers might not get around to reviewing it for a few days, which is not fair to candidates). For this reason, I think simpler HackerRank type challenges are a better way of pre-screening candidates.

* As a candidate, HackerRank is one of the easiest possible steps for you to pass. Almost all of the problems are up on their website! They may not be exactly the same as the ones given to you by specific companies, but there is a lot of overlap in these types of questions. If you spend a few hours practicing you will be able to ace almost any HackerRank challenge given to you.

That said, HackerRank is a tool, and I think there are a few implementation details needed to make it work well:

* Many of the suggested questions for candidates are terrible (e.g. "will this code compile", or really unclear problem descriptions). For our quiz, I chose all the questions and answered them myself before ever giving them to candidates. If a company lets their recruiters set up a default quiz, it will be really bad for candidates.

* As I mentioned, we usually use this for grads, or candidates who we are not sure about based on resume alone. If you come in through a referral, cold outreach, or TripleByte (who only work with really high quality candidates) you usually get to skip this step.

* I don't think these systems can every tell you how good a candidate is. They can and should only be used as a method of filtering out candidates who don't meet a minimum standard. As others have mentioned, writing algorithms is only part of the job of a good engineer, and they do nothing to test your architectural skills, teamwork skills, motivation level etc. For this reason we only use it as part of our hiring process, as a minimum bar for entry into further interviews.

I'm also constantly looking for ways to improve our hiring process, so open to suggestions to any of the above.