Ask HN: How to handle tech interviews?

Thanks for interviewing with us. We know interviews are stressful and we try and account for that by offering a selection of different problems. Also, if we think someone is freezing from nerves, we’ll offer them a problem to do on their own time after the interview before making a decision. We know we can continue doing more and want to run more experiments around this for our next batch of applicants.

What's interesting to us in this specific case is that you actually did great during the interview. We've done hundreds of them in the past few weeks and we're really excited to talk with you again for the second round.

Hey, another Triplebyte founder here. This is something we've talked a lot about. To set a balance, we talk to people about a project that they've worked on in the past, and also have them pick a problem from a list, and work on it with us over screenshare. I'm sorry this did not go well for you (I'm curious to look at our notes from your interview, but I don't know who you are).

We're focusing on being consistent and fair. I understand (and am sorry) that we mess up and miss good people. But looking exclusively at experience creates other opportunities for errors (I believe more opportunities). We don't require perfection on any of the problems. We're looking for process, and try to help people (for example, on both of the problems mentioned, we generally talk about good approaches before the person starts coding). But again, we definitely mess up. Sorry about that. We're trying to do it less as we improve the process.

JFWIW: I'm @tqbf on Twitter, and 'tptacek here. @tptacek is someone else. :)

It's frustrating, isn't it?

I've said a few times here on HN that it's a career goal of mine to get to the point where I don't have to do technical interviews. I'm not particularly offended by tech tests[1], I just wanted to get to the point in my career where I didn't have to take them anymore. Unfortunately, I'm not sure this is realistic anymore, at least not without severely limiting my opportunities.

Overall, I'd say that if you really don't want to take another tech interview test, your options are:

1) Consult to hire. This is unappealing for a number of reasons, and many companies will still ask you to take a technical test to work as tech consultant anyway. But they may be more willing to take a chance on you as a consultant without the tech test[1], so you might be able to prove your technical ability on the job and get an offer that way. I'd say this is an option if you are unemployed, failing at the tech test part of the interview, and would like to try something new.

2) Work on open source projects that span multiple institutions, and get hired by one of those institutions. This is different from having a generally impressive github profile or history of open source contributions - it is more about having worked directly on an open source project with developers or other staff specifically at the company or institution where you are interviewing. Why ask you to find a cycle in a linked list if you've already developed and tested features directly with the devs at the institution where are interviewing? This is similar to the "consult to hire" - there are people who have worked directly with you already and know you can do the job.

3) Become a luminary. This isn't an option for me, but the people who created Python, Ruby, Rails, that sort of thing, they can don't have to find the longest path of non-negative integers in a binary tree at the whiteboard to get a job. Of course these folks don't exactly need advice from me, and I doubt they "get a job" in any sense that resembles the way I "get a job".

I'd say that for your good but not famous dev, the second option can be effective, though you do need to make an effort to keep branching out and looking for the right kind of project (they aren't necessarily easy to come by). Personally, I've reached the conclusion that I'm limiting my options too much by avoiding technical interview exams. Studying those data structures and algorithms books, getting razor sharp with solving medium to difficult problems at a whiteboard in 45 minutes, it's probably just part of the profession, at least for now. You really do lose a lot by refusing to participate.

[1] by "tech test", I mean the sort of questions you'd find in "cracking the coding interview" or questions you'd typical find in an algorithms and data structures exam (variants on trees, hashes, graphs, sorting, run time), along with some OS stuff involving threads, deadlock, and so forth).

First, let me say, that I view take home coding exercises as a fundamental basis for a good hiring process, as such, I do those with no reservations.

That said, when I encounter one of the oodles of bad technical questions that exist out there, I will frequently ask the interviewer what precisely they are trying to judge and how this particular question judges that. I ask that, because I am unquestionably interested in developer hiring pipelines and I am actively trying to learn about them. Usually, this leads to a discussion that acts as a proxy for what they really want to know, but I make it a point to say how much I do not like these kinds of questions.

The thing is, you can't change someone else's hiring practice. But chances are, if they are engaged in asking questions like that, they have not designed or standardized the pipeline (if they had, it becomes obvious how stupid those questions are). If you are working with a non-standardized, ad hoc process, expressing yourself clearly and professionally is usually enough to get through it (this isn't a good thing).