I love learning all about coding. I guess if you’re here, you do too. But there comes a time when you need to convert that hard-earned knowledge into hard-earned cash. That means going through an interview process. What is the best way to navigate those troubled waters?
Now, I’ve been on both sides of the fence. I’ve interviewed more candidates than I can remember. I’ve built tech teams that I’m proud of. The first time I interviewed a candidate for a tech job was .. goodness! over twenty years ago. And I’ve gone through interview processes and gotten the jobs I wanted.
Here are my five tips, my dos and don’ts, for preparing for a job interview in the tech world. The things that have worked for me in my experience auditioning for tech jobs. The things that have convinced me when I’ve interviewed candidates. And I’ll share the absolute show-stoppers in interviews. Those that make me look at my watch and wonder if I can tell the candidate the interview is over.
Before I dive in, here’s my first tip. Remember that an interview is a two-way street. They are also about finding out if the company is a good fit for you. Incidentally, having that attitude also shows strength and confidence, not neediness.
Step 1: Research the company
Your first step is to research the company and answer the question: “What is this company about?”. This hallows you to show that you’re interested in this company specifically, not just in any job, and gives you materials and context for the next steps.
A good source of information here is the company’s annual report, which expresses where the company is at and where it wants to go.
Some questions worth trying to find the answers to are:
- What is the company doing?
- What tech problems or challenges could they be facing?
- What are the company’s values and what is the company proud of?
- What direction could it make sense for the company to head in (and have tech needs for)?
And above all, make sure you spend time ** looking through the company’s website**.
Let me tell you the story of one guy I interviewed. Because I have UX designers in my team, I often ask people what they think could be improved on our website. It’s not even a trick question; it’s just that we’d like to make what we do even better. This one guy gave a vague and evasive answer. Because of that, I started pressing him a little about what he liked about what we were doing. I realised he hadn’t been bothered to open our website. He hadn’t taken five minutes to find out what we were doing. He wasn’t interested in us, only in getting a salary.
Don’t get me wrong, getting a salary is important. But if you’re not interested in what a company does or why they do it, you can’t expect them to be interested in you.
Which brings me to my next point.
Step 2: Find your whys,
The next question you need to answer, at least for yourself, is: Why? There are, in fact, two whys: Why do you want to work for this specific company, and why should they hire you, specifically? The questions you can ask yourself are:
- How are your values and the company’s values aligned?
- How can you bring something specific to the challenges (technical or otherwise) the company is facing?
- What are the difficulties you’ve faced and the challenges you’ve solved that might come in useful for this company?
When I’m interviewing, this is what I’m trying to understand if I ask: “What are your interests outside of work?” Because I’m trying to determine two things. First, I’m trying to understand who you are and what makes you tick. And second, I’m interested in understanding if you’re able to invest your time in something, even if it’s not work.
But if you’re ever sitting across from me, and I ask you that question, make sure you have something specific to say. I once had a woman answer that she was interested in music. So I asked: what kind of music? And she answered: “any kind of music”. As there wasn’t much to grasp on, I asked her if she had any other interests. She answered: “cooking.” But when I asked her what kind of cooking, you guessed it, she answered: “Every kind of cooking.”
That’s not a passion, it’s a vague interest. It doesn’t open any doors to conversation. And it doesn’t tell me anything about you or your story, which brings me to my next point.
Step 3: Build stories to tell
One of the first questions you will be asked will be something along the lines of “Tell me about yourself?” And since you know the question is coming, you might as well prepare for it. And the human brain is made for stories, not raw data. In fact, instead of asking people to tell me about them, I usually ask them to “tell me the story that has brought you here.
So think about how you can explain your experience and your training as a story. And for each experience, try to think of a story you can tell that helps illustrate what you bring to the table. How you overcame a specific difficulty, or how it taught you something about yourself.
And make sure to make it specific and memorable. I once asked a guy to tell me about the project he had just worked on and the difficulties he had faced. He answered. “Oh it was a difficult project. Because it was big. And complex.” I pressed him for specifics, I asked him what features he had worked on. And he was unable to provide any. This guy was memorable. Just not for the right reasons.
I understand that Interviews can be stressful and make your brain freeze up. But that is precisely why it’s worth preparing the stories you want to tell ahead of time. And that brings me to my next point.
Step 4: Know your answers (Don’t cheat)
You see, the next step is to go through everything you’ve said of written, and make sure you can back it up and explain it.
Clearly, the guy who was unable to say anything about what he had done is a good example of what not to do. But the same holds for technical questions.
For instance, if you use ChatGPT (or a friend’s help, for that matter) to answer technical questions, make sure you understand what you have written.
Let me tell you a story to illustrate. I tend to give Code Reviews as technical tests because… well, they’re real-world problems, and they show if you understand the code. And .. let’s be perfectly honest… I slip one or two subtle issues in among some more blatant ones. And one day, I got excited because one person pointed out the subtle mistakes in a React Code Review.
Now, this was an interview for a French company, but the code review was in English. We always check that people have at least a basic level of English because we have colleagues who don’t speak French. And this guy didn’t just pick up the mistakes, he did so in good English.
I had the guy come in for an interview. And at some point, we switched to English. I asked him an innocuous question about what kind of TV he liked to consume. But.. he had trouble understanding even the simplest of questions.
So I switched tracks and started talking about the line with the subtle error. I asked him how he thought we could solve the issue he had found. To my surprise, he had no idea what I was talking about. So I took it back a notch and talked about a less subtle error he had picked up in the test. And again, he had no idea. Finally, I went to the most stupid error there was. And yeah, you guessed it, he still had no clue. That was the day my colleague and I decided on a codeword to let the other know there was no point in continuing the interview.
My guess is he used ChatGPT. If you’re using artificial intelligence to augment your intelligence, that’s fine. But if you’re using it instead of your intelligence… Well… don’t.
What do I mean by augmenting your intelligence? Well, that brings me to the fifth point, the one that is your chance to leave a lasting impression.
Step 5: Prepare your questions
If the interviewer is competent, they will keep the most important question of the whole interview for last. And that question is: “Do you have any questions?”
Now it’s fine, at some point, to ask about stuff like working hours and benefits. However, you need to be strategic about those and ask them right at them end, almost as an afterthought. Do not lead with that kind of question.
Instead, the “Do you have any questions?” opening is the perfect time to show that you’ve taken the time to think about the challenges the company is facing.
However, first, before I cover those, I prefer to lead with questions that change the balance of power. These questions are always relevant. And they show you have high standards. Implicitly, you’re asking the company if they are up to your standards. Those are questions about the development process and how it favours quality. Questions like:
- What level of automated tests do you have?
- What is your test coverage like?
- What kind of CI/CD do you have?
- How do you ensure code quality?
If you haven’t had the opportunity to do so before, and if the subject has not been covered in the interview, you should also ask questions about the fundamental environment:
- How is the work organised? How long are the sprints?
- What is the tooling?
- What is the structure of the team, and how is it organised?
- What is the hosting environment?
- And, of course, what is the tech stack? Although, to be honest, the interviewer should have covered these points in the intro or the job posting, and it makes sense to ask these sooner if you can.
Finally, you need to ask questions specific to the company’s business model or to the challenges they’re facing. Questions like: “Have you thought about implementing this strategy?”, “How have you solved this technical issue?” Or “How does this challenge or change affect you?” You get extra points for thinking outside the box, about challenges that don’t just affect the tech team but the company as a whole.
And now it’s my turn to ask you: do you have any questions? Let me know in the comments, and in any case.. I’ll see you in the next video.