Skip to content

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

Comments

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.

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.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.