Jean-Michel 🕵🏻♂️ FayardMy career-related content is now open-source on GitHub.
I received way lots of cool feedback for my article Keep Calm and Just Say No To Coding Challenges but none was as fun as being live grilled by ThePrimeagen on his YouTube channel.
ThePrimeagen's answer to my article
I was alerted about this video by three different friends, one presenting me ThePrimeagen this way:
Primeagen is an engineer doing impressive stuff at Netflix, he is very active in the Rust community. As you will see in the video, he has a style that some people love and some people hate.
Fair enough. But for my part, I found his video absolutely delightful.
Some people told me to try out making videos, but I declined.
I think I would be a pretty lame YouTuber.
I'm just a dude who write words about stuff.
But ThePrimeagen is brilliant at it.
It was a cool funny experience to see my article come to life in real time on YouTube.
After such an artful build-up, I was hoping he would not just only agree with me.
And indeed:
Ok, just so you know. Hey guess what everybody? This person just gave you the best way to get rejected from many job interviews. Perhaps this person doesn't need a job that much. And therefore can go like this: "What do you do? Oh you are like 93% of tech companies and you have a coding challenge? LOL. Sorry, I don't accept them. It leaves an hash tray in my mind. So no, thank you. To both your job and your interview process".
That started well.
Alas that's mostly a misunderstanding...
So far, without reading anything else, my current take is that it's some of the worst advice I've ever heard.
Real talk: you literally have been told by companies that there is a secret handshake. It involves knowing basic data structures, and how to apply them. So you can go and study for height hours, get good at that, walk in, doing the secret handshake and go right insight the door. Or you can say no to every reasonable job out there.
Is that unreasonable?
My answer will be boring: I agree with all of that.
We have a basic misunderstanding of what coding challenge meant in the context of my article. I didn't mean an algorithmic interview.
And the confusion is my fault.
I assumed it was obvious what I meant by Coding Challenge.
But clearly, at it often happens, what was obvious to the writer is not in fact obvious to all readers.
What happened is that I wrote the article after seeing a friend waste way too many time and morale with a coding challenge of that sort:
We are a music player app company, so we challenge you to do a simplified music player app, with a lying time estimate of four hours, and then we will evaluate the quality of your code according to unknown criteria.
What's a good hiring criteria?
In the comments of previous articles, I have lazily described all kind of challenges as good or bad.
Wait, what does that mean?
There is actually a real definition of a good hiring criteria in the literature, which I would summarise this way.
A good hiring criteria must be relevant, stable, realistic and very clear.
For example, an algorithmic challenge at Netflix is
- ✅ relevant because Netflix does lot of that stuff
- ✅ stable because if you ask different people whether a candidate succeeed at an algorithmic, they would mostly agree
- ✅ realistic because it takes a limited amount of time, and the same for the company and the candidate. Learning data structures and algorithms is a doable task
- ✅ very clear because it's almost like a math problem.
Let see why coding challenges (the ones I had in mind) instead suck
- ✅ Coding challenges are relevant in the sense that the simplified music app has a clear link to the real music app the company is building.
- ❌ Coding challenges are not stable, meaning if you present the same coding challenge to different companies, or even different people inside the companies, you will get "Look Good To Me", "Not Our Level Of Quality (TM)" and everything above and under that. The beauty of your code is in the eye of the beholder.
- ❌ Coding challenges are not realistic for someone outside of the team (that's what the term means). People inside the team, who know everything about building a music player, and who designed this challenge, can criticise your work in 42 different ways. But truth here is that people working there didn't know everything they know today when they started. We developers are learners, don't judge us because we don't know everything at a given time. Find out our potential.
- ❌ Coding challenges are not very clear. One of the reason candidates over-engineer shit with coding challenges is that they the requirements are super vague. Sure they describe the features, but not the criteria. The candidates can't know under which criteria they will be judged.
IMHO companies can do better than cargo cult someone's else bad idea.
Wasting both your time and the company's time
When you say NO to something important to you always say YES to something else.
- You protect your time.
- You protect your morale.
- You protect your self respect.
One thing I didn't mention because I was writing from the candidate point of view is that they also waste time for the company. That's here not relevant for Netflix, because I guess that shitloads of talented candidates apply there.
But many good companies have posts that stay vacant for 3 months, 6 months.
A clear loose loose approach.
You Indeed Have the Right to Say NO
I talked about the company's perspective, but I would warn you against doing that in the interview. There is a reason why I didn't propose you to say:
Your company's hiring practices leaves an hash tray in my mind. So no, thank you. To both your job and your interview process.
Instead I recommended this:
I have to be transparent with you, I had bad experiences in the past with coding challenges and I have decided to stop accepting them.
The difference here is that you not judging them and putting them on the defensive. You are being assertive about your needs.
The companies that will be mad at you for stating your needs
- are the minority
- bullet dodged
So I completely stand by my original thesis.
You Have the Right to Choose When To Say No
Finally I told you the have the right to say NO, I didn't advise you to say NO all the time.
If you apply at your dream company, don't say NO, invest the time.
If you have only 2-3 companies a month that interview you, your next step is to generate more leads, you can procrastinate on saying NO.
On the other hand, if you never use your right to say NO, then that right is pretty useless.
What I did is that I started saying NO when I was interviewed by companies I didn't really wanted to work with anyway. It was awkward at first, but I didn't have the kind of pressure described above. Now I completely feel comfortable with it, and I know that it usually works. And you don't have to worry for me finding a job.
No hard feeling
Now ThePrimeagen, if you read me, I genuinely laughed at your video.
And you even gave me the hope to make a second episode.
Hiring is broken.
Oh man, look at this, there are so many good ones.
Look at this, we have so many pieces here.
Allright, for today let's read "Keep Calm and Just Say No To Coding Challenges"
That would be awesome indeed.
I can recommend my first rant, three years ago already, who started this serie.
