Tell HN: Stop Accepting Shitty Interviews

There was a long discussion on HN the other day regarding why companies are having trouble hiring engineers:

https://news.ycombinator.com/item?id=29892437

One of the recurring themes is the "leet code" interviews. I will go further and say that any interview that doesn't mimic the job is a guaranteed way for me to turn the company down.

Stop accepting shitty interviews

When I was talking to trading firms about coming back to the finance industry, about half of them admitted they already use my open-source software. And yet, only one firm bothered to ask me about how some of my stuff was implemented. That's the firm I'm working at now.

Instead, I got plenty of firms that still insisted on asking me questions that are not remotely related to the job. Tons of Hacker Rank and Codility, even though I've never had a time limit when building something in real life. Tons of intern-level questions as if I was a college freshman. And tons of detailed questions about how a specific programming language works, as if we're going to build a compiler for that language.

And to reiterate, those were the firms that already admitted to using my software!

Stop accepting shitty interviews

The stupid assessment practices won't change unless employers suffer the consequences for this nonsense. I have always made it my mission to reject any firm that asks me syntax questions or brain teasers. (Seriously, the New York Times doesn't assess journalists by having them conjugate verbs; it's just weird to ask this.)

Yes, people get mad when I terminate the interview on the spot. I'm sure I've been blacklisted from a few places because of my stubbornness. But damn if I'm going to allow stupid shit like this.

Stop accepting shitty interviews

While I agree in principle, the average developer is not going to have released and maintained an open source project. Let alone one that is used. Let alone one that is widely used. People in your position should rightfully do that, you have all the leverage. Other people not so much, especially new graduates. I agree that having tasks that simulate the real environment is the goal but we also work in an industry that it is common place for productivity to only really start after 6 months. Thus, any interview is going to be some simulacrum of the real thing. Personally, I would like to see something like "Make 10 commits to X open source project and we'll talk". Make the world a better place while actually evaluating the candidate for job readiness. Both technically and behaviorally as you see how they behave in the community.

I myself am not pro-leetcode, but I see the advantages of leetcode from both the interviewer and the interviewee side.

From the interviewee side: It gives you a known set of material to prepare for (ofc there may be newer questions). But this alone helps a lot. With the explosion of frameworks, libraries, languages it is very hard to prepare for everything.

From the interviewer side: Again it will give you a standardized set of questions which can be asked and you can compare across candidate due to this.

>> about half of them admitted they already use my open-source software

Similar to how people don't have time to prepare for leetcode, there may also be people who don't have github repos with open source code etc. Take my case, I work for a company where I have to get permissions if i am gonna start a open source project, even though it may not be related at all to my current work.

Yup, there are countless employers looking to hire coders. If your spidey senses tingle, end the interview and move on to the next one.

I've got a little anecdote on an interview that I should have ended, but I was a junior so I didn't really know better at the time.

At this interview, one of the things they wanted me to do was to do a series of one minute coding challenges. They weren't leet code or anything, but just difficult enough that they required a lot of knowledge, and I wasn't allowed to look up documentation. This one guy stood behind me and looked over my shoulder with a stop watch. After a minute was up, I had to put down the code I was writing and move on to the next one, and the process would repeat. I think I did about 12 of those. It was some of the most ridiculous bullshit I ever did in an interview. If you didn't remember the exact array method off the top of your head then you were just screwed. Mind you, they were hiring for a junior position. These days there's a possibility I'd survive it, but I wouldn't even bother at this point.

I accept very few interviews at all, so sniffing out shitty ones ahead of time isn’t particularly intuitive for me. But I can say of the two worst ones, I very nearly walked out on one, and did walk out on the other. I regretted not walking on the first one and didn’t regret walking the next one. The first was a FAANG, the second … should be in the acronym.