How to get hired: 10 lessons for doing great in your interview, from a CTO’s perspective
You’re wasting your best opportunity to impress. Here’s how to land the job of your dreams.
Presenting yourself well during an interview is more about social skills than having a well written resumé. That’s not to say the resumé isn’t important — it gets you in the door. But once you’re in, now it’s up to you to impress your interviewer.
Over the past 35 years, I’ve done a lot of interviewing — and I’ve seen just about everything. I still remember the “senior engineer” who had a stellar resumé on paper, presenting as everything we could possibly want in an engineer. We were so enthusiastic! But that enthusiasm rapidly turned to sheer bewilderment. No more than 10 minutes into the interview it was absolutely clear that he had never written a line of code in his life. The simplest, most basic technical questions were completely beyond his ability to answer, and yet he stuck with the fantasy that he was a software engineer!
I felt like I’d stepped into an Alice in Wonderland side-story. The Mad Hatter was in our office, absolutely convinced he could get a job on our team. He couldn’t answer questions like, “What’s the opening tag for a link in HTML?” and “What’s a pointer?” But he talked about it for five minutes, sort of like a used car salesman dodging questions about a car’s history.
If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.
Anytime you'd like to read more, you can upgrade to a paid subscription.
It was a complete waste of time, and we knew it just minutes into the interview. We were floored. We had a candidate who professed to be a programmer, yet couldn’t explain HTML or basic coding concepts. Any time we engaged in conversation, he was confident, engaging, and amiable — and uttered either misdirection or complete nonsense. At the end of the interview, he earnestly offered to come back for another round, and hinted that the offered salary might be a bit too low.
As he walked out the door, our team glanced at each other, alternately perplexed and amazed. Mostly, amazed that someone would try to get a job they clearly were not qualified for. But also amazed this person had managed get past our HR team and schedule an interview!
Having a well-crafted resumé is clearly a door opener. But what happens next is entirely up to you, and it’s all about presenting your true self, being genuine, and being someone people will trust to get the job done.
Most advice emphasizes crafting a technical resume and highlighting skills. I disagree. It’s more important to demonstrate that you’ll be a passionate, effective team member, ready to tackle any problem.
Here are my 10 lessons for having a great interview, and landing the job of your dreams.
1. No more than 1 page
This isn’t an article about how to write a good resumé — there are plenty of those. That said, there’s one very important thing about your resumé where a lot of people miss the mark: Keep it short, preferably to one page, front and back. My own resumé is exactly one page, and that’s after nearly 40 years.
Here’s why: Whenever I get a resumé that’s longer than one page, I immediately think, “this person can’t summarize and communicate concisely.” More importantly, I only read the first page, usually just one side. If you can’t catch my interest and secure an interview on the first page, I’m not going any further. On the other hand, if the first page catches my interest, I’ll flip ahead to check education and a few other things.
One more thing I’m looking for while I’m reading your resumé: Exactly what value your work has brought to your project, your team, or your employer. You need a “results oriented” resumé. That means demonstrating the value you contributed, not your technical tasks. It’s the difference between “worked on event driven architecture using Rust, Kafka, and MongoDB,” versus, “built an event driven architecture that quadrupled processing speed and cut infrastructure cost by 50%.”
Save the list of tools and languages you know for a short “skills” section.
2. Be prepared for a two-way conversation
It may seem obvious, but you’d be surprised how many candidates don’t know who’s interviewing them. They aren’t prepared for a two way conversation.
Don’t go into an interview without having some context. It shows that you don’t take time to prepare and you aren’t actually interested in the work. That’s an instant turnoff.
Know your interviewer. Know something about the job, and the company. Dig deeper than the job description. Where did your interviewer come from? What did he or she bring to the job? What challenges does your prospective employer face in the near future?
I often open my interviews with, “Tell me what excites you about working here?” Or I might try, “Tell me about something you’ve done recently that you think would be a benefit to our team.”
If you just rattle off something that I’ve already seen at the top of your resumé, especially if it has no relevance to me and my team, I’m not going to be impressed. Instead, take half an hour and read the background of everyone who will be interviewing you (LinkedIn is usually a good place to start). Check out the company web page. I like to look up news and analysis on a company if it’s public. That’s usually a great place to learn about challenges the company might face.
Then, engage in a conversation. Can you relate to the team? How are you going to help solve those challenges?
3. Recognize the cues you are inadvertently sending
We’re always broadcasting social signals, every instant we interact with others. Before remote work and Zoom became the day-to-day norm, I think we had a greater awareness of those social signals. Now more than ever, developing your social self-awareness is essential.
It amazes me how poorly many candidates come across. Zoom has made the problem much worse.
The cues you send tell me who you are. Do you make eye contact, or awkwardly look away? Do you listen to my questions, or are you just waiting to talk? Do you take time to converse, or do you lurch ahead without giving me a chance to get a few words in?
Your interview is your chance to convince another human being that you will be a great coworker. I’m quick to terminate an interview if the social cues are off. By that I mean, you aren’t engaging in genuine conversation, you’re distracted, or not making eye contact. We all know where the camera is — look at it.
In part, I’m fed up with interview scams. If you show up with a big microphone blocking your mouth, a horrible quality video, or some third party “agent” or transcription “bot” on the call — I’m just going to hang up. The video interview is merely a screening, a preliminary for me to quickly weed out the people who aren’t going to be great team members. The next step is an in-person interview where you need to show that you are a genuine person with real skills, someone my team will enjoy working with.
4. Your resume should represent who you truly are
Be honest. If your resumé tells me you’re a senior engineer with certain skills, I expect that’s who I’m going to talk to. If your story isn’t consistent with your resumé, that’s a huge red flag.
The Mad Hatter engineer is an extreme example, but subtle inconsistencies will end your interview quickly too. Just last week I had another one of these.
I was interviewing a DevSecOps engineer. Her resumé looked pretty good. About 5 or 6 years experience. All the right words on the first page: AWS, CICD, Github Actions, CICD, Jenkins, penetration testing. A good employment history and experience, including, “using Terraform and CloudFormation for IaC, optimizing scalability and aligning with cost-efficiency goals.”
But the interview revealed a different story: Someone who’s pretty hands-off when it comes to writing code, much more skilled at project management. Her experience running a project to deliver SOC2 compliance for her employer was excellent. But why the inconsistency? Why send me a resumé that looks like it was crafted to present a skilled DSO engineer, when in fact her skills aligned with compliance, program management, and delivery?
It raises questions that concern me. Be sure your story aligns with your resumé, and your skills back up that story. Otherwise, your interviewer is going to feel something is off.
5. Stop regurgitating your resume
In another recent interview I told a candidate, “I’d like to hear about something you did recently that was a big success for you, personally, and also for your team.” He immediately launched into a chronological recap of his resumé — a resumé I had already read. He wasted a great opportunity to tell me something about himself.
After a few minutes, I cut him off and told him I’d already read his resumé. What I didn’t tell him was that I’d also decided he wasn’t great at communicating and prioritizing time.
There’s an art to conveying your value. Your resumé will have a few concise facts, but it won’t tell the story of how you bring that value. Show how you’re different than other candidates who just have a skill set. Highlight your non-technical skills, what kind of team member you will be, how you bring your unique value to the team.
Sometimes it’s hard to know what to say. Recognize that it’s OK to take a breath and think about the question you’ve just been asked. Go ahead and say, “Let me think about that.” Organize your thoughts, or even ask for clarification. Be thoughtful and intentional, because that demonstrates critical thinking.
6. Avoid being a jack of all trades
Pick your strengths. Resumés that list every language and every tool under the sun go right into the bin, simply because I don’t believe anyone can be good at everything.
I’m not saying you can’t show experience with Rust, Go, Swift, Scala, Elixir, Erlang, Kotlin, Smalltalk, Clojure, C, C#, C++, Objective-C, Pascal, Modula-2, Prolog, Java, Javascript, Typescript, React, Svelte, Python, Perl, PHP, Cobol, Visual Basic, HTML, SQL, NoSQL, Bash, Mathematica, and Assembly. I know you can. Those are all the languages I have experience with… but I don’t show all of that on my resumé, except as a footnote.
I have a core set of skills where I’m strong. It’s also where I like to work. Could I modernize a platform using PHP? Yes, probably, but I’d hate the work so I don’t highlight that skill.
Today, my resumé focuses on Elixir, Erlang, and Scala. It also talks about cloud modernization, distributed computing, and team leadership. Those are my strengths and I play to them.
The rest of it is still there, more or less, but it’s mentioned in passing on the back page.
7. Show me that you can grow
I can hear some of you saying, “Ok, but if I don’t list that tool I used once upon a time, I won’t get the job.” That’s nonsense.
When I hire a team member, I’m hiring a smart human with the capacity to learn. Someone who will be an overall benefit to our team.
Just last week I interviewed a candidate for an engineering lead role on our data science platform. It’s entirely written in Rust, with a dash of React for the front end. The fellow I interviewed doesn’t know Rust, yet I’m hiring him anyhow. Why would I do that? Because he’s a good programmer, knows a handful of other languages, and is confident he’ll pick up Rust quickly.
Programming languages are just tools. As a programmer I need you to think like a problem solver, understand how computers work, and know a thing or two about data, algorithms, and architecture. I don’t care what languages you know today, because tomorrow you’ll need to learn a new one.
If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!
8. Follow a storytelling system
One of the most powerful tools for communication is story telling. Prepare your own stories and be ready to tell them. A good story introduces a situation, builds suspense around a problem, and ends with a satisfying conclusion. Or, if you use the STAR method, a Situation, Task, Action and Result.
I can’t tell you how many times I’ve asked a behavioral question and gotten back nothing. “Tell me about a time you had a conflict with your boss and how you resolved it,” “have you ever felt overwhelmed at work?,” or “what’s the biggest challenge you’ve overcome?”
One candidate answered that last one, after a long pause, with, “I had to learn C really quickly.”
Really? That’s it? I hope there’s more to the story! Something about how the company was pinning a launch on some key feature, maybe in a legacy system that needed knowledge of C, and nobody in the company knew it, so you stepped up and mastered a new language, delivered the thing, and saved the day… right?
That would have been more powerful. It would have demonstrated value, commitment, an ability to learn under pressure, and shown me he could deliver.
9. Be curious
I learn more about a candidate from the questions they ask than the ones they answer. Too many people either don’t ask questions or ask mechanical questions that don’t add any value to the interview.
Prepare some questions that demonstrate thoughtfulness about your future role and curiosity about the job and company. Make sure you ask those questions. If you don’t, you’ll leave the impression you don’t really care what job you get, or who you end up working with.
Having insightful questions shows that you want the right job. That you are interested in the work. That you aren’t just jumping ship for the next best salary.
Ask about your responsibilities, what success looks like for your role, and who you’ll be working with. Dig into the technical foundation that you’ll be contributing to. Maybe explore what challenges are facing the team right now, and how those challenges will affect you. Find out what the company’s future plans are, and where it (and you) will be in 2 or 5 years. Ask some challenging questions!
10. Show that you are a problem-solver
When I’m hiring, I’m looking for team contributors, people who will make a difference. It’s about knowing you’ll tackle whatever problem comes your way. You don’t have to have the answer, but you can demonstrate how you think about it. Show that you can tackle tough problems confidently!
I want to hire you because you’re smart, and you’ll get things done.1
I love this post by Laurie Voss, This is why you never end up hiring good developers. I highly recommend you take a few minutes to read it — whether you’re interviewing, or an interviewer… it’s valuable. Laurie points out his two criteria for a successful interview:2
Can they do this job? This is not the same as “can they do this job right now?” but you need to be confident they can learn how to do the job.
Are they going to get better at this job? The answer has to be yes.
I can’t state it any better myself.
If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.
Joel Spolsky, The Guerrilla Guide to Interviewing (version 3.0), October 25, 2016 Joel On Software.
Laurie Voss, This is why you never end up hiring good developers, August 30, 2014, Quartz.