Signup to the waiting list!
I have to say I hate programming interview questions. Why they are so difficult?
If you ever used a tool like HackerRank or read a coding interview questions book, you’ll probably agree with me. Yes, there’s a whole industry around coding interview and preparation for them.
I hate those. Not everyone agrees with me, on the Internet. Seems that many want to continue this “tradition”.
A couple years ago I decided I had enough with contracting / freelancing and I went through the hiring process of many different companies.
This was before I realized that I am basically unemployable, but this is another story. And by unemployable I mean I just cannot work for anyone else except for me, to build my own products and assets rather than building someone else’s.
About half of the companies I applied to had an initial screening with a practical “take-home” project.
No one asked me to implement FizzBuzz, or other algorithms that are often described as “required knowledge”.
We might get tricked into thinking that every hiring process is like the one you’d experience at Google. I read about people spending one year just to prepare for the Google interview, only to be rejected when they applied. Sad.
There are countless small and medium companies that never hire using a rigorous and sterile technical interview on topics like algorithms and data structures. At a whiteboard. Without Google and (gasp!) Stack Overflow.
Sure, it’s great to know those topics inside out, and I think you really should.
And I get the underlying thinking: the problems are basically all the same, with 10-20 variations. Implement bubble sort. Ok, I can do that. They just want to listen your reasoning on the subject. How you approach it. But in reality, it’s explaining what you remember of a problem you memorized. If the candidate is a fresh graduate, they might even remember it well. If the candidate is a person with 5 years of real work experience, they might not remember that.
FizzBuzz would be more reasonable. It’s not taught in school, the problem can be explained in 3 minutes, and you can reason about it.
But if I was to organize the hiring for my company, perhaps as a CTO, I would never ever put the person in front of a white board, and ask them to implement FizzBuzz. Why? First, it’s completely useless - you will never have to implement that in the real world.
Second, there’s so much stress on the applicant. A lot of people underperform under those conditions. Me included. I could show off perhaps 10% of my value, just because I can’t function well in such an environment alien to me.
DHH (David Heinemeier Hansson, creator of the super popular Ruby on Rails framework) once said: “I would fail to write bubble sort on a whiteboard”
It’s awful and perhaps only good at stress-testing the nerves of an applicant. Which is a completely different thing than testing the abilities to provide value to the company, like programming if I’m hiring a programmer.
No problem you can solve in a traditional whiteboard interview has any correlation with the actual job of a programmer.
I must think about when was the last time I spent some time deciding which algorithms to use, let alone implement a brand new algorithm. So why people are continuously asked about those things?
This is a tweet pointing that also big companies are moving in a better direction:
We’ve updated the wording we send to the Front End Engineer candidates to better reflect the Facebook interview process for that role. I hope this helps folks prepare for their interviews! pic.twitter.com/EvTyKbugYT— Dan Abramov (@dan_abramov) February 12, 2019
Practical knowledge. Ask us for this.
I remember one cool question I got at an interview: describe me what happens when you do a Google search. It was open ended, and was the start of a conversation on network protocols and the little things that happen. This was an intelligent question.
There was no whiteboard because it was a remote Zoom call.
Another interview was based off a coding challenge I implemented using React, offline. I had 7 days of time (not that the actual coding took 7 days, 3 hours was enough). The rest of the hiring process was based on the work I did on this code.
So, my answer the question “why interview questions for programming jobs are so difficult?” is probably “because the company hiring process is broken” and you should perhaps think “do I really want to work there?”.
Wouldn’t it be better to skip the interview altogether? The best thing to do would be to have a company contact you to work for them. You can do this in various ways: networking being one of the classic. In person at conferences, on Twitter, on GitHub.. there are many ways. Once you know and stay in touch with one or more employees of a company, the next time there’s an opening you can definitely be on the list for the position. Especially if they know and appreciate your value.
All, as usual, in my humble opinion.
More lab tutorials:
- The stack I use to run this blog
- 8 good reasons to become a software developer
- SEO for developers writing blogs
- Review of the book The 4-Hour Work Week
- Build a lifestyle business
- Build your own platform
- As an indie maker, what kind of product should you build?
- Create your own job security
- Developers, learn marketing
- The freedom of a product business
- Generating value
- Have a purpose for your business
- The idea is nothing
- The niche
- Remote working for software developers
- Product / market fit
- The best podcasts for frontend developers
- Why should I create an email list?
- Disconnect time from money
- The scarcity principle applied to software products
- The social proof principle
- How I added Dark Mode to my website
- My notes on the Deep Work book
- The pros of using a boring stack
- How to estimate programming time
- On going independent as a developer
- How to learn how to learn
- Why interview questions for programming jobs are so difficult?
- Do I need a degree to be a programmer?
- Everyone can learn programming
- How to be productive
- How to get the real number of pageviews of a static site
- Have you filled a developer bucket today?
- How I record my videos
- All the software projects I made in the past
- Tutorial purgatory from the perspective of a tutorial maker
- Every developer should have a blog. Here’s why, and how to stick with it
- Having a business mindset for developers
- How to write Unmaintainable Code
- What is Imposter Syndrome
- How to work from home without going crazy
- How I prototype a Web Page
- You should be the worst developer in your team
- How to start a blog using Hugo
- Write what you don't know
- How to block distractions using uBlock Origin
- Coding is an art
- I wrote 1 blog post every day for 2 years. Here's 5 things I learned about SEO
- Dealing with the fire
- On being a generalist
- The Developer’s Dilemma
- My plan for being hired as a Go developer. In 2017
- Productivity gains of using a Mac and an iOS device
- How to go from tutorials to your own project
- This is my little Digital Garden
- How to start freelancing as a developer
- Sharing the Journey Towards Building a Software Product Business
- Subfolder vs subdomain
- How I use text expanding to save time
- Software is a superpower
- I love books
- How I decided to create a new projects management app
- On using IndexedDB as the main database
- How to automatically cut silence in videos