The Terrible Technical Interview

If your only goal is to measure the ability to code, then doing a whiteboard interview isn't the best way to do that IMO.

But what about positions where you will be expected to give presentations, do pair-programming, or mentor junior developers? I think whiteboard interviews can be a measure of your ability to take technical concepts and illustrate/explain them clearly to a team.

I used to really hate whiteboards, but as I grew into positions that required more leadership, I realized that I personally needed to develop better presentation skills. If a potential employer were to test me on that, a whiteboard test wouldn't seem unreasonable to me.

So I have mixed feelings on this. Not every hire needs to be capable of being a teacher or delivering a solid keynote speech.. some positions would be best filled by someone with those skills.

In my experience, a lot of companies are combining _all_ these things. So you're expected to do a phone interview, a test project/coding test, a whiteboard test, and the management brown-nosing at the end of it where you get to pitch that you've studied a hard technical skill your whole career just because you're so passionate about getting woken up at 3AM on PagerDuty to build _their_ vision, and definitely not because you expect to be paid for your time and skill. The fact that you realize money exists and can be used to pay for things like housing, education, and healthcare means you're not truly passionate about technology.

The worst is the NYC tech scene where they have the exact same standards (which they cargo-cult from the west coast), but they decided not to bring over that aspect where engineers are respected and valued. Instead they borrowed the west coast interview and combined it with the east-coast finance style where programmers are considered clerical workers and cost centers.

NYC is actually a fun city to interview in because since it combines so many different cultures, you can't even study for an interview because 5 different companies will give you 5 different interviews. Finance companies still love brainteasers and they _love_ mutexes, seriously, if you're interviewing at a finance shop just memorize Java Concurrency in Practice and the producer/consumer wikipedia article, because they are reading questions from there, even though when you show up on your first day you'll have been better off having read Spring in Action and Headfirst Enterprisey Design Patterns or whatever.

In general I love how these companies have elite hiring standards but incredibly mediocre interviews. You get asked the same questions over and over again by these companies. Find the biggest sum in a list, find two items in a list that sum to a given number, sort a list of integers/strings but keep integers where integers were and strings where strings were, copy files with ids to all servers with ids, etc. What's the difference between an abstract base class and an interface (by a Python/Node shop), what is a closure, etc etc. I've heard so many of the same questions repeated over and over. They have "high bars" for their candidates but apparently their interviewers can just use the first link off of Google or re-use whatever Facebook was asking in 2010 when they got rejected by them.

And then at the end we have a "tech talent shortage". Whatever happened to that part where we claimed a false negative wasn't a big deal? (glad the article calls this attitude out).

Tech hiring is totally broken and then they claim there's a shortage. There definitely is a shortage of qualified interviewers, not so much a shortage of qualified candidates. I have a friend who I mentored into the industry, she's very smart but absolutely a junior engineer, and yet she starts a new job and was doing interviews with _no_ training 3 months later. They just threw her into the lion's den and expected her to figure it out.

Coding tests are another great one because the exact same people who talk about the importance and value of data throw all of that out the window when it comes to evaluating them. There is no calibration or standards, generally. One person is offended by a hardcoded file path but doesn't care about whether you have tests, and another person is the direct opposite. Many people expect you to write extensive optimizations for the 100Kb input file you were given, another person sees that as absurd premature optimization. Whether you make it through a code screen is entirely tied to whether your coding style happens to jibe with whoever is reviewing you.

Again, the West Coast is better because at least compensation packages reflect the hoops you have to jump through and the monkey dances you have to have learned on cue. On the East Coast, anybody paying attention is desperately trying to get into management by the time they're 30 because to do otherwise is to be humiliated and infantalized during the interview process _and_ during your tenure working there. My simple solution to all this nonsense is to make sure your CTO and head tech managers are being made to jump through all the same hoops with all the same standards. Drop this whole "Oh, the CTO is a _manager_ role, he shouldn't have to worry about all that." (again, more of an East Coast attitude).

Another incorrect thing tech companies claim that benefits them at the expense of labor that engineers brainlessly parrot: "false positive are expensive because firing is hard". No, it isn't, I've seen many people fired very easily the second they're not up to standards. At worst they're instantly let go because it's at-will employment. At best, their given some absurd Performance Improvement Plan that establishes a paper trail so they can fire them without severance. And if your employer tries to tell you people have come off of those things, I have news for you, people lie, and liars are good at reaching senior management positions.

Something else is how you can put in hours and hours of your life, and get _no_ feedback, because telling you how you scored on an interview might expose them to legal liability. Let's be real, the legal liability is when they reject qualified people for things like "culture fit", and if your interview process exposes you to legal liability, maybe it's because it's illegal and unethical.

Another thing tech companies should consider is, instead of paying insane money to recruiters to be pushy sales people who are trying to dupe engineers into their low-paying positions, maybe just redirect that money to the engineer instead, it's 2015, the days that sleazy recruiter types are necessary to try to fast-talk an engineer into a position that's not good for him are over because we have the internet and we can read your terrible Glassdoor reviews.

I'm convinced one huge reason all this happens is to discourage job-hopping, because in this market, liquidity would probably help salaries move up faster.

I know I sound bitter, but again, these are the exact same companies running to the taxpayers to spend hundreds of millions of dollars of middle class Americans money to pay to solve their tech shortage crisis. Yet they absolutely refuse to evaluate their own hiring processes. And a huge chunk of engineers just eat up all this dogma about how hiring is hard and these processes are necessary, and don't think for one second that all these processes are totally designed to please the employer at the expense of engineers being treated well. In a few years, there will be another recession and we're all going to be "rightsized" away, so, demand to get treated well while you still can.

I do almost all of the technical phone screens for my company. The process starts with a "where-do-you-see-yourself-in-5-years" personality screen, with an H.R. drone or outside recruiter. It moves on me, and then on to a brief "homework" coding exercise that we ask people to write and submit. If we like their code sample, then they come in for the panel of "whiteboard-exercise" people who conduct the face to face round. At my stage, I seldom bother with certification style questions about the programming language, or with highly abstract thought exercises, because other people will do those things in the face to face stage.

Typically, I ask questions that give me an idea about the candidate's depth of experience and awareness. For example, "I see that you've spent X years using Subversion for source control. What are your opinions on trunk-first development vs. branch-first development?" I ask questions that speak to practical experience and design ability, without getting into too much depth. For example, "Pretend that you're using an OO language to build an application for . Just off the top of your head, what are some classes that you would expect to see in your class diagram?". Etc.

I find that this level of questioning is a much better screening tool than trick questions about programming language quirks or the minutiae of frameworks, or cliche puzzles about how many golf balls fit on an airplane. However, I groan and roll my eyes when I hear people challenge the need for technical interviews at all. Yes, they are necessary.

Having performed a thousand interviews by now, I am awestruck by how poor the software development talent pool is. I am aware that the Bay Area is overrepresented in HN's readership, and that crowd tends to take for granted the talent level found in the technical equivalent of Mecca. However, I assure you that the rest of the planet is dominated by sleepy line-of-business developers... who have all the passion beaten out of them in the first 5-10 years, and spend the rest of their career just phoning it in and not growing.

I sometimes ask candidates what the letters "MVC" stand for. The successful response rate is around 50/50. I ask candidates to briefly explain the advantages of the Model View Controller pattern, and only 10-20% can field the question. We bring in Java and C# candidates who have been working with their respective language for 10 or 15 years, and they get COMPLETELY EXPOSED during the face to face round when asked a series of basic certification exam style questions. Nothing tricky, just core fundamentals.

People who post here are not the norm. The "norm" is atrocious. So yes, unfortunately we all must endure technical interviews... to filter out people who have enough confidence or personality to excel in the other interview segments, yet are utterly useless.

Let's put it this way: the more experience I've had with interviewing, the more selective I've been in my own job searching, and the more aggressive I've been in my salary negotiations. If you are really good, and are located outside of San Francisco, then you are worth your weight in gold and should value yourself accordingly. You wield tremendous leverage once you make a strong showing in a technical interview.

Interesting report! Did you weight in this - the bad developers are most likely to interview many times, so they appear often to you? Talents either get advised into a new job or stay where they are, because many shops know they are valuable, I'd think.

I'm going to go against the popular opinion here: I don't believe that technical interviews are broken and need fixing. Of course, we know as engineers who deployed code filled with hacks and known bugs to production, everything is broken. The difference is only how broken it is. Let's fix our approach to quality and security, ability to estimate and other things that are much more broken first.