Senior Software Engineer Interview
How to prepare for a successful interview in 2021
As a senior software engineer and tech lead, I’ve been involved in conducting many interviews over the years. My goal here is to share the senior software engineer interview questions and format that I use and have found to be the most valuable in finding good candidates in the hope that it will be useful for both interviewers and candidates alike.
To those preparing to be interviewed, I want to be upfront in saying that each company, and even team in a company, will likely have their own interview questions. Because of this, you usually won’t be able to prepare for the exact questions that will be given. But, you can be sure that you’ll be asked at least some of the questions in the categories listed in this article and will be much better prepared if you are ready for similar questions.
To the interviewer, it’s critically important that you too prepare for the interview. Choosing the wrong candidate can be hard on your company in addition to making your life more difficult; especially if you are responsible for taking the new hire under your wing. This is your chance to get the information you need in a relatively short amount of time to make a good decision.
That said, let’s go over the different categories starting with questions about the hiring company.
Know About the Hiring Company
I can’t tell you how many times the candidate I’m interviewing has obviously done very little if any research into the company. In addition to being a red flag, it’s also such a big disappointment. It indicates the reason the developer is looking at the company is not because of what the company does but solely because of what it offers to them: location, benefits, salary, etc.
Now, there’s nothing wrong with a candidate looking for a new job partly due to the previously mentioned reasons – they just shouldn’t be the only reasons. As an interviewer, I want the candidate to demonstrate interest in what the company does and how he or she can contribute to its success.
How do you as the candidate do this? Simple, research. Look up the company’s website, see if they have a blog, look at press releases, and so on. Be prepared to ask meaningful questions to the interviewer(s) based on this information.
For example, I’ll generally ask a question like, “why did you decide to apply here”. As a response, I’m looking for something like, “I saw on your website that your company is currently working on a, b, and c. That sounds like a real challenge and I’d love to help you tackle it. I think that my experience doing such and such would help to make it a success”.
Or, I may ask something like, “what kind of questions do you have about what we do?”. A good answer can be something like, “your company builds products one, two, and three. These all sound very interesting. Can you tell me a little more about them?”.
Questions that I don’t want to hear from candidates are things like, “do you have a good 401K plan?”, “how much vacation time will I get?”, and “what kind of raises can I expect?”.
As a candidate, you can in many cases find most of this information online. Or, if not, then you can ask about it later on in the hiring process. Trust me, it will come up. If you ask about it during the interview, again, that says that you’re not so interested in what you can do for the company but more in what it can do for you, which is not a good first impression.
Be Prepared to Discuss Projects You’ve Worked
Some software engineers believe that the number of years one’s been a developer directly translates into being a good senior software engineer candidate. Now, this is somewhat true in some companies. For other companies though, years worked is not really that big of a factor.
To show that you as a candidate are truly at the senior level in these companies, be prepared to demonstrate to the interviewer, in detail, that you have a proven track record of helping to move projects, big and small, from start to finish.
An effective means I’ve found as an interviewer to help the candidate to do this is to go through their resume and to dive into the details of the positions listed. For example, I’ll ask a question like, “it says in your resume that you worked at such and such company. Tell me about what you did there”. I’ll initially let the candidate give an overview of their position. From there, I’ll dive in and ask questions like:
- You said that you worked on such and such at this company. How big was the team at what was your role in it?
- For the given project, did you design the solution and if so, what did it look like?
- How many projects have you been a lead on?
A number of times when I've gone past the surface of what’s listed in the resume, the candidate has been caught almost completely off guard. If it’s listed in the resume though, then it’s fair game for the interviewer and you as a candidate should be ready to discuss it. It’s not particularly useful to the interviewer to get a response like, “I worked on that project five years ago. So, I really don’t remember much about it”. Yes, candidates have responded like this more than once in interviews I’ve given.
If a candidate cannot go into detail on the projects listed in their resume, then it says to the interviewer that either what’s listed was a project the candidate was minimally involved with or not involved with at all. Either way, it’s a red flag to the interviewer.
An example question and good response could be as follows.
Interviewer: I see that you worked on such and such project. Can you tell me about it?
Candidate: Yes, that was a difficult but rewarding project to work on. I worked with a product owner to build out the full requirements using such and such methods. From there, I considered several possible solutions but ended up choosing this one because of conditions a, b, and c. I then worked with a team to go over the architecture, split out the work via user stories, ….
If you as a candidate have experience with projects like the one above, then plan out how you can go over them and really sell them to the interviewer. It will go a long way to proving that you’d be a good candidate for the business.
Object-Oriented Design Questions
Some see this as more of a junior or even entry level category of questions. After all, it’s assumed that a senior software engineer candidate who’s been working in the field for a significant amount of time will know the ins and outs of object-oriented design (OOD), right? In all actuality, I’ve found it surprisingly common that candidates are not all that familiar with OOD or are very rusty.
Now, this may be somewhat forgivable for those who have primarily been working in the frontend for years; especially if the position is more or solely frontend oriented. But, if the position is backend heavy, then not being able to answer questions in this category is an immediate disqualification to me.
Candidates should be familiar with and should be able to succinctly discuss the following:
In addition, candidates should be familiar with SOLID:
- Single responsibility principle
- Open-closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
In my experience, the three main reasons candidates are rusty with the above are: they’ve been frontend focused, have only really been doing CRUD-style development, or are working on old systems with procedural languages.
If you as a candidate fall into one of the categories listed, then be sure to brush up on these items before heading into the interview. You should also pay particular attention to the first, fourth, and fifth items in SOLID as they tend to be discussed in a little more detail than the second and third items in my experience.
Design Patterns Questions
Along with the fundamentals of OOD, a candidate should be able to demonstrate that he or she knows more than just the basics. To show this, I generally spend a bit of time on design patterns. Again, this seems to be another area that many candidates are not prepared for but really should be quite familiar with when interviewing for a senior-level position.
One of the first questions I’ll usually ask is something along the lines of, “what is a design pattern?”. From there, I’ll ask about GoF. For the GoF, you as a candidate will want to know what the three main categories are: creational, structural, and behavioral. You’ll additionally want to know at least one pattern in each category while being able to discuss all is recommended.
It’s also important to point out that while all design patterns in the GoF can be useful in certain scenarios, some are more commonly discussed than others from what I've seen. These being singleton, factory, adapter, and observer. It might be wise to spend a little more time studying these.
And, if you can bring up and discuss an example of a design pattern that you’ve successfully used in your own projects, it doesn’t have to be a GoF pattern, then that will really help demonstrate to the interviewer that you have more than surface-level knowledge of OOD.
Domain-Driven Design Questions
I’ve personally been a big proponent of domain-driven design (DDD) for years - Having architected several applications using its principles, giving a number of presentations, to changing how I work with our Product groups. Basically, I’ve found it to be incredibly useful in building enterprise applications.
That said, even a few years ago I still wouldn’t have expected a candidate to know that much about DDD. But, with the increased industry-wide interest in microservices, DDD is here to stay and is widely known and used to various degrees in the industry. I now expect that backend candidates will know at least the fundamentals of DDD like:
- Ubiquitous language
- Bounded contexts
- Value objects
- Infrastructure, application, and domain services
Now, I still wouldn’t consider it to be prudent as an interviewer to disqualify a candidate because he or she doesn’t know DDD in depth; especially a more frontend-leaning candidate. But, I think it does show a significant gap in the candidates’ knowledge and abilities if they aren’t familiar with it.
Speaking of microservices, if a candidate says that he or she has experience with microservices, then this doesn’t necessarily mean that the he or she has used or is even are aware of DDD. In my opinion, those building out microservices should be well aware of bounded contexts. If not, then this indicates a lack of interest in good microservice design and overall interest in software design in general in my mind.
On the other hand, a candidate that knows about and has used DDD in a significant way almost always rises to the top of the candidate list in the interviews I give. It generally shows that the candidate is serious about development, is more up to date with best practices and methodologies, and really indicates that the candidate has moved past the basics of OOD in a big way.
SQL is a common language used for relational database management and is used by many companies. It is likely that you as a candidate will be asked some questions around this topic and should be prepared to discuss it.
As an interviewer, I’m not looking for exact knowledge on syntax as I think that’s a waste of time (a developer can look up syntax in seconds on the job). What I do want to know is the candidate’s true depth of understanding of good relational database design.
For example, if you as a candidate say that you have SQL experience, then I’m going to ask you questions like:
- How do you determine when to create a new table?
- How do you determine how to name tables and columns?
- What’s the purpose of foreign keys?
- How do you appropriately index tables?
- How do you analyze query execution plans and optimize queries using that information?
- What is database normalization?
- What is a stored procedure?
- Is it good practice to have business logic in stored procedures?
As a candidate, you can also expect the interviewer to ask questions about your real-world experience with DB design like how you’ve handled certain issues that have come up such as deadlocks or if you’ve ever had to deal with data-loss scenarios. If you can show that you’ve handled difficult situations well, then that will be a big plus to the interviewer.
REST API Questions
REST APIs are incredibly common in modern development. Because of this, it’s likely that it will be brought up in the interview to some degree.
Some questions I’ll generally ask in an interview are:
- What is a REST API?
- What is a resource and how do you decide what the resources should be?
- What is a route?
- What is an endpoint?
- When should you use POST, GET, PUT, PATCH, and DELETE?
- What are some methods to secure an API?
- Are you familiar with the OpenAPI specification and have you used Swagger?
- Have you worked to integrate with third-party REST APIs? If so, what kind of challenges did you run into and how did you resolve them?
As a candidate, you should be prepared to discuss specifics around REST APIs that you've helped to create, maintain, and integrate to if you do have expereince in this area.
Frontend Technologies Questions
If the interview is more backend oriented, then not much time may be spent here. If more frontend oriented, then a significant amount of time could be spent in this category.
Generally though, the questions are going to be around the technologies the candidates have used and if they’ve heard about and/or worked with the technologies the company uses. For example, you as a candidate may get questions like:
- Have you worked with jQuery?
- Explain the MVC and/or MVVM design patterns.
- Are you familiar with frameworks like React, Angular, Vue, etc?
- Have you used SASS?
- What is micro-frontend architecture?
- How do you ensure accessibility?
- What is responsive design?
- What are some of the challenges with developing for mobile devices?
- Have you used Gulp?
- Have you used Webpack?
For more backend-oriented positions, I may only care that the candidate has a basic understanding of the fundamentals of frontend development.
For full stack candidates, I usually like to see that they have used more modern frameworks and have a good understanding of proper frontend architecture.
For senior frontend developers, I want to see that the candidate has used modern frameworks and has experience creating frontends using best practices and is both knowledgeable in and has utilized some kind of defined frontend architecture.
What Kind of Development Do You Enjoy Most?
Some developers that I have interviewed have been full stack. Others frontend or backend. What’s important with this question for the interviewer is to learn where the candidate feels most comfortable and if he or she wants to switch from one area to another.
It’s important to ask this question as an interviewer because if you’re looking for a frontend developer and the candidate seems to be a good fit but doesn’t really want to continue doing frontend and instead wants to move to the backend or vice versa, then the candidate might not stick around too long. That is unless you can make that happen for them, which may or may not be a possibility.
As a candidate, you should also be honest with yourself and the interviewer with this question. It’s unfair to everyone involved if you’re not.
Will You Fit in With the Team?
As an interviewer, you want to make sure that the candidate it not only a good fit on the tech side but also will be able to integrate and work well with your team.
For example, let’s say that you work on a team that uses Kanban. Additionally, user stories are generated by your product group with which your development team closely works with. Now let’s say that the candidate has always worked solo not following any real development framework in the past. It could be real shock for the candidate to move from a loose to a more structured form of development.
Along with a more structured form of development, there may be different types of demands on the developer’s time moving to a team environment such as being able to design and split out work for others, mentor entry level and junior developers, help to foster a good DevOps atmosphere, and so on.
A candidate like this could still be a very good fit – I’ve personally seen in my own career some top developers come from environments like this and they have transitioned very well into a team environment. So, it’s definitely not a disqualifying factor. It’s just something that you want to make sure the candidate understands and is comfortable with.
What Do I As an Interviewer Take Away From the Interview?
Using these different categories of questions and how the candidate responded to them, I’ll generally come up with a list of their different strengths and weaknesses and how that correlates to the open position(s).
From there, I’ll discuss these strengths and weaknesses with others and we’ll come up with a decision on who is the best fit.
We may also decide that the candidate is a better fit for another position in the company as well. As a candidate, this is an important item to realize – if you really like a company, then go ahead and interview even if your qualifications aren’t necessarily a perfect match as you never know what positions will open up in the near future that you may get a call back for or if a position will be opened up just for you because of the interview.
I hope this information helps to give interviewers some ideas around the format of an interview and questions they can ask. I also hope this information gives candidates ideas for their senior software engineer interview preparation.
As an interviewer, remember that there isn’t one “right” way to give an interview. You will need to tailor the interview to the given position and even to the given candidate. But, many of the questions you can ask can still be pulled from the categories discussed in this article.
To the candidates, I believe you will be much better prepared if you understand and are prepared for questions in the categories above. And, if you don’t fully understand them, then this may be a good opportunity to build up your skills, which will make you more competitive in the field.