The term "cracking the coding interview" became known from the book Cracking the coding interview written by Gayle Laakmann McDowell (software engineer, former Google, Microsoft and Apple).
The book is a collection of coding exercises that are often asked during the technical interviews at a lot of companies, especially at the FAANG (Facebook, Amazon, Apple, Netflix, Google). The aim of the book is to prepare the candidate to answer to these kind on questions.
I really enjoy talking about this topic and I was recently invited at the python milano meetup to talk about this (here is the talk).
Why I read this book
I suck am not so good at these kind of interviews. But I wanted to become better at this. Althought there are a lot of good resources online (hackerrank and leetcode for example), I wanted to use this book to "measure" if I was somewhat improving my skills.
I also was skeptical, because I don't think that you must be bood at this to be a good software engineer.
Surprise
I give it a try and I found something that was unexpected. In the preface of the book, the author says:
- I’ve learned that a lot of interviewers are using this book to learn how to interview. That wasn’t really the book intention
- It’s not for everyone, every company or every situation
- Don’t ask the exact same question in here
This blew my mind. In fact, I always thought that a lot of people keep asking these kind of questions just because they think they should do it. This kind of confirmed my beliefs.
Ok but... what kind of interview?
If you are not familiar to the topic, here is a simple example to understand what I'm talking about:
Write a function that takes a list as an argument and returns the most common element of that list
I know that this looks pretty easy, but when asked during an interview it could be hard to solve.
Here are some quick tips I find really useful:
Don't
- start writing the code: you often need to re-read the question more than once, to understand what you need to do
- be quiet: the interviewer wants to understand if she can work with you and know how you think of a problem. Not thinking out loud is not a good sign
- go for the optimal solution: sometimes it's better to go for a solution, not the solution
Do
- ask clarifing questions: try to deeply understand the problem, it saves you a lot of time (even in real life problems too)
- speak out loud: think about this as a conversation with the interviewer, not as a job interview
- solve first, optimize later: see above
Is it worth?
Even if I don't think that you need to be good at these exercises, I think that practicing on these could help you improving your skills and learn something new (for example some common ways to solve problems). Plus, it's mandatory if you want to work for FAANG like companies.
So my advice is to dedicate some time to work on this and even spend some money (in the book for example or in some course to prepare yourself).
It's like an investment in yourself and in this case you can be sure to have a good return of your investment. The time that you spend on practicing is always well spent.
But then, the epiphany
Why do the companies that ask these questions, ask these questions?
The solution to this dilemma can be found in what the author of the book says: I’ve learned that a lot of interviewers are using this book to learn how to interview. That wasn’t really the book intention. I think the problem here is that most of the time the interviewer is not prepared to do the interview. I'm not saying that this is their fault, or that they are not good in their job. I'm just wondering if they had time to be trained to do this activity.
So, I started "interviewing" the interviewer. Here is an example:
- Interviewer: What are metaclasses in python?
- Me: Have you ever used them in your code?
- Interviewer: No, but I know that somebody else did
My takeaway here is that the interviewer was not focused on what he needs for the job, but just on asking a question.
What I like
Here is a list of what I like to do during an interview, or what the company I'm interviewing for does:
- You actually write or look at the code: this gives you and the interviewer something practical to talk about and it can be useful to understand if you can work together
- You talk about tests: no more words needed
- Public github repo: this helps understanding how the people in the company works
- The interviewer wants you to succeed and not to look smart: sometimes people asks questions just to show how smart they are, without thinking if the question is useful for them. Please don't do that
- Explicit interview process (which is better than implicit): the candidate should know how much time he's been requested for the hiring process to a) organize himself and b) think if it's worth
- Feedbacks (+ and -): feedbacks are always useful and you never know if the candidate will be good the next time. Also, if a company does not give feedbacks, do you really work there?
Another POV
Laszlo Bock, Former SVP of People Operations @Google, wrote a book called Work Rules! where he talks about how Google does People Operations. In the chapter 3 of the book, he talks about the interviews and the hiring process in general:
- Hiring is the single most important activity in any organization
- We found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart. Some of our interviewers still ask them. I’m trying to get them to stop.
What companies should do
I've always thought that hiring is the single most important activity in any organization for a lot of reasons. The most important one is that it is a great opportunity to better understand the company. What are you strengths and weaknesses? What kind of people do you need? What kind of company do you want to be?
To do that, I think that the people involved in any recruitment process should be taught how to do interviews, overcoming bias that could led to bad decisions.
It's not easy to do, but it's worth it.
References
- how programmers overprepare for job interviews
- Coding interview university
- Tips to rock tech interviews
Thanks for reading! I’m always open to receive feedback, recommendations, or questions, feel free to contact me!!
Alessio Izzo, Software Engineer
LinkedIn: https://www.linkedin.com/in/alessio-izzo-06b5398b/
GitHub: https://github.com/aless10
Twitter: https://twitter.com/alessio_izzo86
Top comments (0)