Hacker News new | ask | show | jobs
by soham 4022 days ago
(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 <or insert your favorite question>, 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.

1 comments

Interesting. Someone downvoted this comment. Not sure why. IIUC, this answers OP's question and also gives an explanation. Downvoter care to explain?