Coding Interviews: What Works, What Doesn't, and Why It Matters

https://gist.github.com/jonocodes/be053c8bda6a4fd11e26486528e44b16

by jonotime • 2 years ago

11 6 2 years ago

gist.github.com

jonotime2• 2 years ago

I dont do well on coding interviews. If I get rejected from a company but I think I would have been a great fit, I often sent them a note with some comments as to why these types of interviews are bad. I recently decided to formalize my thoughts into this open letter that I can share as a link instead.

Hacker Newsies - you are a smart bunch. I know we have discussed these issues at length over the years, but I would love your feedback on this letter as I send it to employers and recruiters.

Or any other general thoughts you may have. Heck, maybe you want to fork or write your own version that fits your situation. This is certainly a trend I could get behind!

Note: I wanted to do this in notion since thats where my public site is, but getting footnotes to work there is too hacky. Pure markdown worked much better so for now it will live as a gist.

aharris6• 2 years ago

I find myself not even wanting to apply for jobs where I think this kind of live coding question might come up, since I assume I will do terribly a job otherwise seeming to be a great fit.

policharizard• 2 years ago

Super interesting, I have super strong opinions here having been through the gamut. I cannot code when someone is watching me. I freeze up, can't remember basic syntax. I also think I code in a very sporadic way that would be confusing to watch.

In my last big search I did 3 major take home projects, and got paid for my time for 2 of them. Each project took about 10 hours and I was rejected without feedback. One of the jobs I'm pretty sure used my code from a react app that made a menu system for a restaurant.

My current job, a non technical recruiter reached out to me, we did a 30 minute interview, then I did a 30 minute interview with the team, and another 30 minute interview with the CTO and director. It doubled my pay and it's been the best job I've ever had. I'm a perfect fit for it and there was no technical aspect to it whatsoever.

Ultimately, I think the problem is inverted. Companies are worried about hiring, when they should really be putting way more energy on firing. Hiring should be: do I want to work with this person? And firing should be this person is not capable of doing the job. I think technical checks for new hires are largely useless.

jonotime2• 2 years ago

Yeah. But there is the old adage that its harder to fire then it is to hire - used as an excuse for rigorous testing.

Most of what we do day to day does not take a genius. Maybe companies just want to think they are special and need the smartest.

In terms of firing, I dont think I know anyone who was close to getting fired for their work. Its usually behavior related.

davely• 2 years ago

I’m in the fortunate position of not needing to interview (I have a pretty solid thing going on right now), but I’m not opposed to going through the interview process if an interesting opportunity comes up.

So, I’ve done it a few times now (and ultimately been rejected every time, doh).

I tend to agree to OP's suggested alternatives.

For example, take home assignments:

Personally, I enjoy the take home assignments. It gives me time to work on something without pressure. I generally find them kind of interesting to do as well. The time estimates are just completely ridiculous though (e.g., "it should only take you 2 hours") and trying to work on them around normal work schedule, family obligations, and what not can be such a chore.

One company I interviewed with based one of the in-person technical interview panels on this take home assignment. We walked through the code, and even talked about things that could have been done better, given the constraints. Had a few other standard panels with them: system design, culture questions, etc.

Rejected. Doh.

Another company I interviewed with had a few pair programming exercises (these were virtual, in lieu of an in-person interview at the time) -- though they threw me for a loop. I've sat on interview panels myself, so, similar to OP, I feel like I have a good sense of what we should be looking for when we hire a candidate.

Oh, man. That does not translate well through the interview process. In my previous example, this company called me back for a follow up technical interview, because I "spent too much time communicating my development strategies and plan, and not enough time actually solving the problem." So, they called me back for an additional interview step. This time, I solved the problem without trouble and even had some good, engaging conversations as we went along.

Rejected. Doh.

The Leet Code stuff is just atrocious though. It's rote, it's not helpful, it often relies on stupid tricks and gotchas, and if you don't solve it in the most optimal way, you're pretty much done.

(Side note: Advent of Code is coming up in about a month or so and I am so looking forward to it. I'm serious when I say that those are FUN programming questions!)

Ultimately, I don't know what the solution is. We as engineers universally hate this process, yet we keep putting each other through it, finding the most minor things to ding a potential candidate for.

eedeebee• 2 years ago

your alternatives are all good

Coding Interviews: What Works, What Doesn't, and Why It Matters

Related Stories