Software Interviews - Dos & Donts

Intro

I've done more than 200 interviews and interviewed more than 20 people throughout my career. Last year I found myself coaching many people in my network regarding interviews, so I thought I could write a blog post about it. The idea of the blog post is to give you summarized information of what interviews look like in software engineering and what you should and shouldn't do to increase your chance of passing your interviews. Every company does this differently, and the difficulty level also differs based on the position. I will focus on general notes that do apply everywhere unless mentioned otherwise. Although I have some experience on the topic, I am not an expert, so please read this at your own risk.

Behavioural

A behavioral interview focuses on questions that allow candidates to reflect and share their past professional behavior. The interviewer uses this interview technique to determine a professional's skills, personality, and capabilities. They are also known as Value Assessment or Cultural Interview.

The following questions are some behavioral questions that you could be asked

• When was the last time you received constructive feedback?
• Tell me an example of a conflict you had with a colleague, and how did you manage to solve it?
• Give me an example of where your decision influenced the end-user?
• Tell me a challenge you had, where the best way forward was not clear cut. How did you decide what to do?

For more junior people or undergrads, there is a high chance that these questions could be around a hypothetical scenario, for example, What would you do if you identified an issue in the process?. That's not a rule, and it could happen to more senior people, but since more junior people have less experience, the interview will try to extract the information given a context.

Technical

Technical interviews are designed to assess your problem-solving abilities and how you approach the presented problem itself. Those kinds of interviews can vary. Below I listed the most common ones you might face during your interview process.

• Verbal technical questions
• Algorithmics
• Take-home project
• Pair programming
• System design
• A combination of the above mentioned, e.g., Verbal technical questions & algorithmics

These also depend on the seniority level. For example, system design is not appropriate for a junior position. It tends to be common from mid to more senior positions. Now let's dive deeper into those interview types.

Verbal technical questions

In verbal technical interviews, the interviewer asks the candidate to describe a technical concept and tries to measure their fluency in said concept based on the quality of the conversation. You can find several articles for common questions for every technology or domain. For example, questions like below are pretty common:

• What is the difference between NoSQL and SQL?
• Name a couple of design patterns and explain one of your choice.
• What is a stack? What are the two basic operations of a stack?
• What is the difference between coupling and cohesion?

Algorithmics

These interviews are probably the most common ones and can be found in the first stages. They can be formed into an online or an offline coding challenge. They might ask you to solve an algorithmic problem live using your environment or in a coding platform, e.g., Codility, HackerRank. Alternatively, they will provide you with a link to the challenge on one of these platforms, and they will collect the results when you finish it. To ace these interviews, you will need to know data structures, sorting & searching algorithms, dynamic programming, etc. The knowledge depth required to succeed in this kind of interview depends on the barrier the company is setting. If you are applying for a FANK company, you need to know those concepts deeply; if not, a good understanding of each concept with a bit of practice would be fine.

Take-home project

Some companies will ask you to do a home test where they give you a project with some requirements and ask you to implement it offline. After you finish it, they will invite you to an interview to go through your approach. They will ask you a lot of whys and different ways of approaching the problem. The project is typically a CRUD application where you have to integrate with an API, test your solution, and follow software engineering principles like SOLID, simple design, etc.

The problem I am having with this interview is that it takes so much time. If you want to demonstrate your skills, you will probably need to test the code extensively, deploy it somewhere, write some documentation or at least a README file, and build a CI/CD pipeline. There is no definition of done, and if you are competing with other candidates, you have to give a lot of effort to stand out. All these things are time-consuming and require a lot of capacity. Working full-time is hard to invest in such an interview where there is a chance of rejection, so I always try to avoid this kind of interview.

Pair programming

In a pair programming interview, you are asked to solve a software problem by either extending an existing project or by implementing a coding kata. There is a high chance that you will be interviewed by more than one person as well. They will evaluate how you write code, communicate and approach problems. This is probably one of my favorite types, mainly because I love pairing, although it's not that common in the industry. I personally think it's a great way to evaluate a candidate, but it's not cost-efficient for the company. However, to be fair, it's not really pair programming. Your interviewer that acts as a colleague will give you feedback or try to direct you in a certain way, but it's far from how pair programming actually works.

System design

These interviews can be found in more senior positions. They typically give you some functional requirements that require you to build a system at a high level. Many things are going around this interview on how to approach these interviews, what to study, but it is a blog on its own. Long story short, you have to learn about back-of-the-envelope calculation, scalability, availability, fault tolerance, cloud services, data replication, distributed messaging, caching, metrics & logs, data synchronization, and many more. It's a taught interview but personally is the one I enjoy the most.

Some system design interview questions could be the following:

• How would you make a search engine?
• Design Youtube
• How would you design a streaming service?
• Designing a URL shortening service

A Compination

Some companies might invite you for a technical interview where they will ask you some verbal technical questions and then give you an algorithmic problem to solve. Like I said previously, every company evaluates candidates differently; there is no specific formula for interviewing. So the possibility of a combination of the above interview types does exist as well.

Know your value

Knowing your value is a taught one, mainly because many people have a hard time evaluating themselves. Most people tend to underestimate their skills. You will probably get asked about your salary expectation in your first interview with the recruiter to see if you match their budget. There are companies that have an extensive range of budgets, and depending on your performance, they will adjust the offer. You can better understand your value from talking to people in the industry or even getting another offer from another company. Getting an offer will give you some indication of what your value is. Please don't take it for granted, though; some companies have different budgets, your performance and negotiating skills are playing a leading part. To get more insights, you can always check glassdoor as well. Generally, their job is to get you hired with the minimum amount that will satisfy you, and your job is to get the maximum amount of money that will benefit both you and the company. I am not a negotiation expert, but you should always try to negotiate from what I know.

Great vs Good Interviewers

Interviewing someone is not an easy task, and it's not always done right. If you have a lot of interviews throughout your career, you will learn that there are more professional interviewers than others. One of the most important tasks an interviewer has is to build a comfortable environment for the candidate to be more of themselves. Also, good interviewers are conversationalists. Instead of going through the questions and answers directly, they try to make it feel more like a conversation and extract the answers they are looking for. They might, for example, comment on some of your answers, saying that they would agree or disagree so that you can take a breath and feel more like chatting. This way, it feels more natural and definitely more enjoyable.

In general, that's not always the case. I've had interviewers that asked silly old-school programming questions, they made it feel like an exam, and generally, they didn't have good vibes. All those mentioned above apply to both behavioral and technical interviews. So, in general you have to be aware that the results of your interview depend on the interviewer as well.

Dos & Donts

Good vibes

Interviews are not only about you. Try to make their time joyful. I mean, they are already investing time to interview you, and leaving a good taste when the interview finishes is really important.

Ask!

Always ask questions! These are free points and shows interest in the employer. You can do some research about the company before your interview. There are different kinds of questions you can ask

1. Genuine Questions - That you actually want to know the answer
   • What are the roles within the team?
2. Insightful Questions - Demonstrate your knowledge or understanding of technology
   • Why for product A you choose to use the X protocol over the Y protocol?
3. Passion Questions - Demonstrate your passion for technology
   • I'm not familiar with technology X, but sounds interesting. Can you please tell me a bit more?

Use STAR/PAR technique

The STAR technique is a common system used to answer behavioral interview questions. It provides a structure for you to remember to include the correct data in your answers.

• S – Situation - background info
• T – Task - what you had to do
• A – Activity - what you did - this should be the longest part of the answer
• R – Results - positive; quantifiable; what you learned; what you would do differently next time

If you get asked a behavioral question, answer by going through the letters in order. The PAR technique is the same as STAR but combines the S and the T steps.

"We" vs "I"

When answering questions about your experience, you should try balancing your answers by using both we and I. Using the we in an answer shows that you are a team player and you are an active member of the team. On the other hand, using I will show that you are taking more initiatives and will show off your leadership skills. Answering with only one of those subject pronouns will not have good results because you are either not self-independent or are not a team player. It's pretty essential to give both perspectives to the interviewer.

It's ok to say "I don't know"

Don't lie in things that you cannot support. If you get asked about a specific technology that you don't know or never heard of, don't lie! Professional interviewers will eventually find out, and you will possibly get rejected. It's totally fine not to know some stuff; honesty is not harmful. One suggestion is to show some interest in things you don't know and ask for more details about the subject if there is time.

Prepare your stories

Prepare some examples of challenges, conflicts, failures, leadership in your work experience or projects so that you can have something to talk about. It's challenging to improvise in the interview in real-time. This is a table I think I've taken from the Cracking the Coding Interview book where it can be helpful.

Questions	Project 1	Project 2
Challenges	...	...
Mistakes/Failures	...	...
Enjoyed	...	...
Leadership	...	...
What you'd do differently	...	...

Take notes

After finishing the interview, write down everything that happened. This is helping me with my self-assessment to have a better understanding of my performance. It is also helpful in your next or upcoming interviews. Of course, you can always ask for feedback, but not all companies take the time to give you any.

Mock interviews

Mock interviews are an ideal way to practice for real job interviews because you are in a situation that mirrors an actual interview with a company. When you review your interview with the interviewer, you'll be able to modify your responses and interview behavior, if necessary. Practice interviews familiarize you with the interview process and allow you to practice answering common interview questions with confidence. Some platforms offer this as a service, but you can always find a friend to help you out.

Perseverance

There would be times when the problem you asked to solve might be complex, or there is no straightforward solution. You always have to demonstrate perseverance! Perseverance is determining to keep on going in the face of setbacks and challenges. When you are stuck, don't give up. Keep trying to solve the problem, and that will show off your grit and independence.

Enjoy it!

I find interviews really challenging, and it's fascinating to me. It's almost like having exams within your career. I know that it can get frustrating and stressful, but I think it will certainly pay off if you put in the effort.

Wrap up

In this blog, I discussed different types of interviews and dived a bit deeper into each type. I also shared some of my learnings after so many interviews and some techniques and tips that I use to help me perform better. Initially, I thought of sharing my knowledge on this domain, but as I was writing this blog, I realized that I could write for hours. So if you liked the blog, please do let me know, and I might write another blog on how to prepare for each interview.