Hacker News Reader

Comment by bit_logic | Hacker News Reader

I think the tide is turning against this type of interview. The industry is starting to notice how ineffective and stupid it is. The big tech companies don't care and will continue doing it because success hides all failures. When there's an endless flood of new college graduate applicants and near-monopoly positions bringing in billions of revenue, nobody cares if the hiring process is bad. They will care someday if those conditions change, but that's in the distant future. Most companies, especially small companies, are not in this position and should have a different process. It's becoming a competitive advantage, especially if a company is looking for senior engineers, to not have this interview process. For example, this list of companies was in a HN story a while ago: https://github.com/poteto/hiring-without-whiteboards The trend is growing and it's a good change for the industry.

View on HN

The tide is definitely turning. The last two interviews I've been to were nice casual affairs where me and another engineer had a technical discussion on how I'd approach various problems they were having (such as deployment woes, wonky network topology etc). The best part is that I feel like I learned something as well, rather than just being shown my failure because I didn't get the interviewer's "trick" to how to solve his convoluted non-practical coding puzzle.

Both of these companies I can gladly say are some of the best places I've ever worked with bright, motivated engineers and a great culture. I think part of it is that if you know your stuff, you'll be easily able to suss out who is bullshitting in a discussion / debate and who isn't. If you just recite problems from Cracking the Coding Interview, you have pretty limited insight into the candidate's abilities.

> If you just recite problems from Cracking the Coding Interview, you have pretty limited insight into the candidate's abilities.

I agree with this. I tell companies to not ask questions from Cracking the Coding Interview. But that doesn't mean those style of interviews are fundamentally broken. It's just stupid to ask questions that candidates are likely to know.

Indeed, I don't write off whiteboard interviewing altogether - if you know exactly what you are hiring for, it can be very helpful to have e.g. a systems engineer write out some C code or go through tree problems. The issue comes in that a lot of people aren't entirely sure what they are hiring for, just that they need a warm body who can code to some arbitrary ability. That's why I always make sure to ask the interviewer what the burning problems are and what kind of action they are looking for on Day One.

> The big tech companies don't care and will continue doing it because success hides all failures.

Cynically, big companies might be selecting for a modicum of technical expertise along with demonstrating capacity to put up with some amount of abusive processes.

I think Hanlon's Razor applies.

They have no impetus to change and think they have found an approach that works reasonable well when given absurd amounts of candidates. The problem is the ridiculous false negative rate.

I struggle to think of a better system. Using experience is unfair and misleading (I worked on awesome stuff... that I can tell you nothing about, I was totally the lead on this software, etc...). Take home stuff is fine with me but a lot of people have problems with it. Come in for a week type things are incredibly applicant hostile.

Sit down with me and lets try and fix this bug seems like a more reasonable solution to me. Dev environment has the most popular ide with their devs, the source for whatever, internet access, and a bug report. Person is there to assist.

They have lots of impetus to change. It's just that they struggle to find a better system.

Talking about prior experience? Flawed for the reasons you mentioned.

Take home stuff? Flawed -- cheating and other issues (I discuss this in another comment).

Work with us for a week? Doesn't scale. Unfair to candidates. Lots of issues here.

Sit down and help me fix this bug? Flawed:

1. Huge bias based on whether they know this particular skill set -- the right tools, etc.

2. Pretty arbitrary as to whether they find that particular bug.

3. It can't be a real bug. It has to be a toy project in order to get a consistent evaluation.

I'd say homeworks are good. In a mix. In fact the process should be a mix. It's hard to get it right.

You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details.

Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything.

Bug fixing is hard to prepare right. If you have a clear cut position, that would eliminate part of bullet one.

I'd argue that they should not be asked to find the bug. Only to fix it.

It does not have to be the same bug. I'd argue for a pool they can pick from.

You should be testing how they approach the problem and how they go about solving it. Heck you can debug and outline a fix for something you can't really code yourself, I know I did.

Pairing with someone from the team they'd work in could also provide some insight into the dynamic.

I agree there is no cookie cutter way for homework and bugs. That's why they need to be in a mix, well prepared and supervised.

> You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details.

That doesn't prove anything. They could've hired a senior developer to help them and explain the concepts in detail.

> Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything.

The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process.

- The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process.

I fail to see how that particular point can ever be a negative for the hiring company. If you need specific skills, you dictate the environment. If you want the candidate to bring his own skills, just tell him to pick his favourite tools.

I can explain the details of Dijkstra's algorithm. Does that mean I invented it?

There is a world of difference between "created something" and "can explain it in detail."

What I always prefer is a take-home programming assignment, and then present the results to a group of developers. You need to be able to explain what you did and answer questions about it.

So if whiteboard interviews are stupid and ineffective, what process do you think is better?

I assure that the big tech companies absolutely do care, but they struggle to find something better.

Whiteboard interviews don't have to be ineffective. But empirical evidence suggests that companies greatly overestimate their ability to conduct them properly.

So, what's a properly-conducted whiteboard interview look like?

Mostly talking about previous experience and especially any projects they were persoanally interested in talking about.

I find there is only one thing you need to ensure a new hire can handle to avoid the major fakers. Give them a simple problem that requires a for loop. Usually it takes up like 5 minutes of the interview. I started asking it when I realized that the weakest people on my team would get stuck talking about problems that were simple iterations, they'd spend days trying to avoid a simple 'for foo in bar' coding solution. These were people who could program is the weirdest thing too. Fizzbuzz has become sort of a joke meme over the years but I've found Steve Yegge's core idea to be true, and you can see the deer in headlights with even the simplest code problem. So now it's all I do. Whiteboard coding is unnatural enough as it is, there's no reason to haze when all you care about is will they get hung up on stupid trivial things. Most code is basic CRUD there is no reason to ask about b-trees or tris, let alone implement them.

If I feel the need to raise the bar even higher, I may include a simple pointer based question, since I've come to notice that indirection another concept that weaker coworkers struggle with. But the problem here, is that pointers just aren't relevant to the majority of what devs do these days, and modern languages do well to hide their usage which means fewer candidates will even have worked in a language like C. So you're likely to get a lot more false negatives. And interviews are stupidly expensive so you really want to avoid false negatives.

For reference I work for a company with less than 1000 employees, serving web traffic that needs to handle 2000req/s peak 1000req/s sustained. There is little we do that doesn't fall under basic CRUD. Our biggest tech challenge is cache invalidation, followed by 3rd party API timeouts.

For the most successful jobs I've had, they just looked at my resume and asked some general questions about prior work.

I've also had several positions where I passed whiteboard hazings. Those didn't go as well. My theory is that selecting strongly for code jam types may correlate with not selecting carefully for people who work well together.

> For the most successful jobs I've had, they just looked at my resume and asked some general questions about prior work.

That's great for people who are good at talking. And certainly communication skills are important, but a strong bullshitter with mediocre programming abilities can probably pass such a test with flying colors.

I'm terrible at talking, and certainly at bullshitting. It happened that I was an excellent candidate for the role, but perhaps they might have hired a bullshit artist instead.

But I don't think so. I think I can often smell bullshit just by its sound, and I think a good manager could do even better.

Beyond that, you can be great at the whiteboard and still full of shit.

Yes, the only people/entities who benefit from this type of interview process are the interviewers themselves - They make the interview process needlessly complicated and pointless and then they sell books giving people specific instructions on how to pass those interviews.

They create the problem and then they sell the solution as a book or as an online self-help service.

All the interview questions do is demonstrate that you've bought the right books and spent hundreds of hours practising pointless coding problems because you have nothing better to do with your time.

Maybe big companies are only interested in hiring sheep-like engineers who have no side projects to maintain and no sense of pragmatism... But then why do such companies (e.g. Google) spend hundreds of millions of dollars each year on acquiring startups full of ambitious and pragmatic (wolf-like) people (people who probably would not pass the technical tests).

With that strategy, over time, big companies just end up with a few pragmatic wolves at the top and a large number of sheep at the bottom. It's not natural and they're missing out on more balanced candidates who are neither sheep nor wolf but are excellent engineers nonetheless.

>Maybe big companies are only interested in hiring sheep-like engineers who have no side projects

But the article said that they are interested in people with side projects.

Whiteboard interviews are more complicated? The alternatives that people usually put forward are either "code a homework assignment for a few days", "pair program with a full timer for a few hours", or "look closely at the applicant's open source contributions".

All of those sound complicated as hell. Perhaps they are more effective, but the whiteboard interview is obviously less complex. And the side projects approach is just laughable considering the number of excellent engineers I know who don't have time or interest to code on their off hours.

A good whiteboard question can tell you a bit about the applicant's design sense, knowledge of key data structures and algorithms, and ability to integrate new ideas. It also has the nice benefit of quickly weeding out the huge number of applicants who can't write DFS on a tree.

Reply on news.ycombinator.com