Ask HN: How to handle tech interviews?

(About me: I was an early engineer at one of the fastest growing SaaS company on the planet. I had the privilege of contributing to our interview process that took us from 5 to 250 engineers. I'm now trying it from the candidate side: http://InterviewKickstart.com)

tl;dr

You have three choices:

1. Apply with a strong referral and/or

2. Apply to exactly the same kind of jobs/projects that you have had work experience in, and/or

3. Apply to a company that's hiring only one or two people a quarter (slow, careful)

A bit more

Everyone hates the tech interview process. Everyone. Including people on the other side.

Let's understand the process, by taking the most typical case, where a candidate with experience in X type of projects, is applying for a job with Y type of projects.

e.g. If you have worked on say Payment Systems' projects for last 5 years and you are now applying for Deployment Systems' role, then as an interviewer, how do I evaluate you? I don't know enough about Payment Systems to judge your work of 5 years in 45 minutes. And I can't presume you know enough about Deployment Systems that I can ask you questions built on my knowledge of several years.

I hence have the following options:

1. I ask someone about you. That's possible, but not systematic, because I need to find a person that I trust very well. It's much better if that person refers you. Hence your option #1.

2. I can hope that you and I have some project in common in the same domain. That's getting much harder these days, as programming is getting very vast. Hence your second option. Then I can evaluate your work and decide one way or another, quickly.

3. I can look at your work of a different domain and give it a proper evaluation. That's takes time, often hours and days. I can't spend that much time, when my goal is to hire 20 engineers a quarter (and hence interview 5x more). Not to mention that evaluation is also subjective, error-prone and contentious. Everyone has different ideas on design and code-quality. Add that to the fact that I need your work evaluated by everyone in the team, not just me. It just becomes untenable. Hence your third option (apply to a place that's hiring slowly).

Being human, hence, I have to fall back to the path of least resistance. That path is to find the lowest common denominator of our knowledge, which can be evaluated in a short amount of time. Yes, it's not perfect and it's still a bit subjective, but there aren't that many ways of writing quicksort , you know.

I hence ask you that question, begrudgingly, knowing fully well, that I'm myself going to be subjected to the same treatment when I go out interview. But at least now I know why, and I look for the best I can in the current process.

Humans.

As far as I can tell, you are far away from @tptacek's post on hiring. He's saying to ignore the resume, have objectively evaluated work-sample tests. You're saying you want people to look at your resume, and that you're really good at talking about stuff. The problem with coding exercise portions of tech interviews (if I'm repeating him correctly) is that they're not as close a representation of actual work as possible, and that they're subjectively evaluated. The standard "tech interview" sits in between your camp and his.

I ask whiteboard coding questions not because I care if the applicant can do some trivial task, but basically to gauge familiarity. Someone who writes code in a language every day for their current job should not have any trouble expressing a simple algorithm on a whiteboard. It's a screening question, and for someone who knows what they're doing, it shouldn't take more than 5-10 minutes. Once that's out of the way, I talk about their body of work, problems they've solved, etc.

The problem is there are a lot of people who didn't do the work but were around for it. They went to all the meetings, they can tell the war stories, they know the jargon, but they just didn't write the actual code.

As for your question about github profile, the problem is that you can't really tell how much work someone did themselves. I'm sure you wouldn't misrepresent your work on github, but people do. People outright lie. They are probably not even being malicious about it, they just don't have a good sense of their own coding ability and feel like if they just post something that they "could have" written.

One applicant who I really liked really struggled writing code on a whiteboard. He described some projects that he had built himself for university, and that sounded really interesting and reasonably complicated. So I took a look through those, hoping that he was just having a bad whiteboard day. But unfortunately it just confirmed, he was smart, creative but just didn't have a lot of practice writing programs. The code was a mess, it did bizarre and roundabout extra steps to do simple things, and from the timestamps, represented months of work for things that should have taken days. I did admire that he was tenacious and didn't give up, and in the end he build something cool but just didn't have enough practice to write production code without supervision. I would have wanted to hire him for an internship, but that wasn't was we were looking for.

It's a screening question. If you make an ASCII spiral that doesn't mean you're qualified, but if you can't do that then you're certainly not.

The ASCII spiral one was from Triplebyte as well.

The problem with the task is that you can demonstrate decrementing counters, recursive functions, and familiarity with the language, but if you don't solve the specified problem in a constrained timeframe, you fail. (My feedback was basically "You clearly know how to code, but you didn't solve the problem.")

One of the problems with the Tic-Tac-Toe AI scenario is that you have to figure out an algorithm to win at Tic-Tac-Toe. (If I recall correctly, one of the requirements is that it beats you.) I know how to play -- but to win every time? I'd have to formalize an algorithm, then convert it into working code, within a strict time limit with someone watching over my shoulder. I can do it, but probably not in 30 minutes. It'd take me 30 minutes to set up my 2D array and accept input to populate the board.

That's not how my day job works. That's not how any programming job works.

When I get a problem at my day job, I know the entire domain. I know who my customers are, I know the problems they have. If my day job were Tic-Tac-Toe, I'd know everything there is to know about how to play and win, and then it's a formality to convert that into code.

If you really want to go with the coding exercise thing, you can't focus on the "right answer." Whether their tic-tac-toe program wins every time is irrelevant. What's relevant is that they jump straight to the notion of a 2D array, that they know how to do recursion or for-loops. What's relevant is that they can write code without too many syntax errors, that they're comfortable, and that they make progress throughout the time alotted. Whether they actually cross the finish line is irrelevant at best. It's a red herring.

In the end, do you want to know if I can code, or do you want to know if I can write a winning Tic-Tac-Toe algorithm in 30 minutes? Those are two different answers -- just because I can't do the latter doesn't mean I'm not qualified. I just means I didn't pass your test.