Interview 101 tips again

Having worked for the IT industry for a quarter of a century, I’ve been on both sides of the interview table a few times. For the team I’m currently building, I’ve interviewed forty to fifty people. For my career, I’ve conducted between four to five hundred interviews. 

While this is not a lot, I believe it still gives me certain credibility. Thus I would like to share a few not-so-unique perspectives from my side. Now, if you are looking for ways to trick the interviewer by pretending to be someone you are not, these insights are unlikely to be helpful. However, they might help you avoid some common mistakes and allow your interviewer to see your real potential. 

I’m not going to tell you anything eye opening. Yet, you’ll be surprised how often I see candidates who’d benefit from learning a few simple things. And even though I’m sharing tips that help with my own interviewing style, I believe my style is similar to many other teams and organizations who look for candidates to hire.

Something simple worth remembering: my goal is to close an open position so my team moves faster. I might have a high bar, but I want you to succeed. I’m looking for excuses to help you pass. It’s not because I like you - though I probably do, as I find a good majority of people likable - but because filling the vacancy helps me solve my task.

And yet, a very good candidate might fail an interviewer like myself.

You might fail not because your skills are bad, but because I couldn’t index them. Recently I had a candidate who just gave up during the interview. That by itself didn’t disqualify that person - we all have hard days - but it didn’t allow me to assess the candidate’s skills. I just didn’t get the data to assess a potentially capable candidate, and I could not take the risk to assume that the level of the candidate was OK, even though another interviewer had given the candidate a pass. For my engineering team, I own that decision. I cannot tell another engineer: look, my team got a bad member because of you.

So let's see what you can do to help yourself show your value to the interviewer.

Be on time for the interview. It is ridiculously simple, isn’t it? Yet, if you are five or more minutes late and you don’t even mention it when you join the call some minutes past the hour, it makes me think you might go easy on your commitments. Now I need to ask you a question about your commitment delivery skills. That takes time from my slot. That gives me less precious time to assess your skills otherwise.

Be concise. Again, I have only 45 minutes. Use them wisely. For your introductory part, which should take 2-3 minutes, please consider skipping “I was on project A doing function B using technology C”. I have already read it from your CV. But also avoid something like “I am an enthusiastic learner, a self-starter and a team player.” It doesn’t give useful data. Instead, give something exciting but relevant to your experience, for example: “A year ago I pushed my first GitOps commit. Today my company has twenty clusters and fifty database servers managed by GitOps - all because I initiated this change”. That will allow me to see how you can contribute to the success of my team right there.

Clarify open questions. It is amazing how many interviewees rush to answer interviewer’s questions without establishing proper context. “How do I reduce the cost of hosting my cluster?” - “Implement autoscaling!” That’s a terrible answer. In the context of my hypothetical question, HPA and node autoscaling are already there. But you didn’t ask me anything. What is the nature of my workload? Is it CPU hungry? Memory hungry? What about network and storage? What kind of node size optimization has the team already done? How is the cluster monitored? Can our cloud of choice use solutions like Karpenter or CAST AI? Can we run some tasks on spot nodes? Does any of that code run on ARM? You get the idea.

Take your time to produce a coherent answer. While zoning out for five minutes before answering is not a good strategy, it’s OK to ask for a minute to think first. Taking a pause to gather your thoughts might improve the quality of your answer dramatically. This is especially true for behavioral questions.

Show your thought process. Aside from foundation skills (you don’t know the difference between L4 and L7? You are not ready to touch cloud infrastructure), I have very few requirements to know anything in particular. Product documentation is your friend. If you don’t know how to create your own Helm chart, but you can build one with the help of Google and ChatGPT within 30 minutes, then I’m happy. But I want to understand how you think. Instead of “I don’t know” go with: “I don’t know, but I can guess and speculate. Give me hints”. This approach does wonders. Not only does it exhibit your reasoning skills, but it also shows me that you have the energy to use them. 

Again, be concise. If you don’t have a short answer to my question, but you push your way through by giving me an irrelevant story about how much you’ve worked with the technology, and how much you love its features - it doesn’t help. It just eats the time I have to ask you more questions and give you more chances. That doesn’t, however, mean that you should skip necessary details. If I ask to outline the difference between the Azure SQL Database and an Azure SQL Managed Instance, and all you tell me is: “Azure SQL Database is fully cloud-native”, not only will you make me ask more questions because I don’t know if you know what “cloud-native” really means - it’ll also make me question your judgment.

Don’t cheat. Once I gave a candidate who didn't belong to the team my benefit of the doubt and recommended to hire. That was a painful mistake. The cost of a false positive resulting in a bad hire is much higher than the cost of passing on a good candidate. If I - or anyone else on the interview board - have a slight suspicion that your performance is not genuine, I will not let you join my team. Besides, how much sense does it make to join the team only for a few weeks and then to be fired for gross underperformance?

Understand the intent. I’m not giving you a code exercise to complete while I watch. It’s super stressful (ask me how I know). My goal is to understand your value to contribute to the project, which is different from assessing your ability to withstand the pressure of a whiteboard coding exercise. Likewise, I want you to know that it’s not my intent to assert that I’m smarter than you (I probably am not), I have more experience (perhaps, but so what), or that I work for a cool company (that’s true, but irrelevant). As long as we agree on what I want to take away from our talk, it’s helpful to both of us.

Be transparent. Say, you have had a brief, tangential experience with a technology, and you mention it on your resume. I, on the other hand, have little understanding about the depth of this experience, so I can ask you something beyond the area of your exposure. It’s OK to say something like: “I touched X only for a few months when I was fixing a Terraform config that managed X, so my experience with X is limited to that”. It’s not OK to say: “I forgot” (unless you really did), or to go on silent mode.

And now a few tips for the behavioral questions.

Remember: I hire you, not your last team. When I dive into your experience, use the “we” only when necessary. Focus on the “I”. While it is an obvious flaw, most candidates abuse “my team”, “we did”, “it allowed us to” etc. Team spirit is great. If you join the team, you are going to be a part of the collective success (or collective failure). But today my job is to assess your personal input to the story of your last project.

Use the STAR format. Again, I’m going to ask you to tell me a story. Unless you know a better way, use the following structure: SITUATION-TASK-ACTION-RESULT. Please click the link and read the article if you are not familiar with it. When you miss any of the four pillars of the STAR, it makes it hard for me to understand the meaning of your story.

Avoid hypothetical answers. I am asking you to show your experience. If I ask you to tell me about a time where you had to work with vague requirements, an answer like “If I have vague requirements I am going to reach out to the product manager and understand how I can mitigate…” gives me no data. I need a real story, with you being the lead actor of that story. 

Provide details and specifics. I need to understand the measurable impact of the story you just gave me. You have improved the performance of your service? Reduced cost? Improved agility? Great. But please substantiate your claim with numbers and details. Compare: “We reduced the hosting cost” to “Because of my initiative to migrate the production from VMs to the Lambda functions the monthly hosting cost went down 30%, which paid for the scope of this migration in 6 months”.

Identify the questioned leadership principle. I admit, this one is a bit hard, but it can help you a lot. When I ask you a question, it’s going to map to one of the Amazon Leadership Principles. Now, I don’t work for Amazon (not any longer, anyway). But I would like to suggest that whatever company you work for, familiarizing yourself with Amazon Leadership Principles is a fantastic investment that’s going to work for you throughout your career - both during interviews and in your daily job. For the context of my tip, try to identify which particular principle the question is indexing. That also will allow you to do the following trick: if I ask you to tell me, say, how you were able to unblock your team while your team leader was on vacation, and you don’t recall a suitable story, you can pivot: “I don’t have a story like that, but I understand that you are asking about my Bias for Action. Let me tell you how I took a calculated risk…” This will be a fantastic opportunity on your side to (1) show that you are familiar with the Leadership Skills (2) demonstrate how you understand their meaning and (3) give a good story from your experience which demonstrates your value.

At the end of the interview, I’ll give you five minutes to ask questions. The worst strategy is to have none. That tells me you are not interested, and that’ll go to my red flag list. But don’t ask questions just because you have to. For example, one person asked me: “what kind of laptop will I get?” (Windows? MacBook? I don’t know. I’m hiring you as a contractor through a consulting company. It’s their choice.) Ask something that matters to both of us. Our team composition. Our technology stack. Tools. Methodologies. Ideally, ask a question relevant to something you heard during the introduction I gave you at the beginning of the interview. This will allow me to see that you have listened to it and you have remembered something. This will give you extra points.

One last tip: I might fail, and have failed, candidates because of a questionable attitude. If you are passive-aggressive, show no interest, or otherwise are not nice, it’s not helping. Be friendly. My team and I are not just assessing your technical skills. Bringing an otherwise smart and productive contributor who is demoralizing the team might have a negative net value. My team must understand if we want to work with you. 

And finally, if you don’t pass the interview, please remember that your interviewers are humans. I am sure that throughout my career I’ve rejected more than one candidate that would be a great team member. Likewise, I had more than one or two interviews as a job candidate where I thought I had done an outstanding job - just to be rejected. Things happen. Don’t get discouraged. If you are good, you’ll find your next job soon.

Good luck!