How To Discuss A Software Project In An Interview

I'm Adam, an experienced software engineer and a professional interviewer. For over two years, I have been working with candidates in the software industry and other industries to improve their chances of landing a great offer (see adamdangoor.com ). This article provides a few tips and tricks which I have used with candidates to help them to ace the interviews focused on discussing their software projects.

Discussing a software project which you have done in the past is a common interview topic. The starting question might be "Tell me about a project you worked on in the past" or "Tell me about a time you solved a complex problem". Without proper preparation, it can be difficult to demonstrate your skills to an interviewer.

Performing well in this part of the interview can make the difference between being hired or not, or getting an offer at the level you desire or not.

Typically, the interviewer is looking for you to demonstrate that:

• You have worked on a complex project in the past,
• You have a good understanding of how the project fits together,
• Your approach involved some degree of rigour,
• You can communicate technical concepts clearly.

Therefore, you should be as explicit as possible in getting these things across. Another important tip to keep in mind is that in any discussion of your past work, you can greatly benefit by showing that you have a positive attitude and that you would go above and beyond to reach the successful conclusion of any given project.

Now, let’s dive into these points one by one.

1. Revealing the project’s complexity

The question an interviewer may have in mind when assessing the complexity of your project is "If I had this goal, how much technical knowledge would it require to be achieved?".

Given that you are unlikely to have enough time to discuss every detail of the project, you can get this across best by calling out what your biggest technical challenge was. You can explain which solutions you considered, what the trade-offs were between those solutions and finally which one you chose and why. To be more explicit in getting this across you could say "This was difficult because...".

2. Understanding how the project fits together

In order to show that you have a great understanding of how the project fits together, you can explain exactly what happens when a certain input is given. For example:

“When the user clicks ‘Translate’, my code sends the user’s input to the translation service. My code then polls the service until it says that the translation is complete. I then use the Amazon API to save the translation to our S3 bucket. My code then queues an operation in RabbitMQ to send the user an email.”

Beyond the project itself, you can dive into details to demonstrate that you understand the technical domain, whether that is web applications, machine learning, game development, or something else. You can also touch on the business context of the project - you might briefly discuss the stakeholders, their needs, and the way you communicated with them.

3. Demonstrating the degree of rigour involved

One way to demonstrate that you take a rigorous approach when dealing with work is to answer the question “How did you know that this worked?” well.

This involves describing the user’s needs and how you knew those needs were met. An ideal discussion may describe which automated tests you chose to add - e.g. unit tests and integration tests. You could also describe other ways you knew that the specification was met, such as manual testing, using a staging environment, or a beta release.

In some cases, it is useful to point out your pragmatism and application of the right testing technique for the situation. For example, if you were creating a prototype, perhaps a thorough unit testing suite was not sensible. If you used monitoring tools, logging tools, or anything else - that can show your understanding of keeping software working in production.

4. Communicating technical concepts clearly

If performance was a goal of your software, you can demonstrate a strong understanding of how to make software performant by explaining how you measured performance and simulated real environments before shipping and maybe how you monitored performance in production after shipping. Using numbers here (such as load times, or memory impact) can show a depth of understanding of the technical concepts and a thorough approach which will definitely impress the interviewer.

When I work with candidates who are preparing for interviews, we make sure to consider a number of projects in advance. We write down detailed bullet points of what happened and key decisions, and then we arrange them into a coherent narrative, making sure we have a part which discusses a decision and the trade-offs involved. We also make sure that the architecture of the solution is clear and make a point to discuss the testing or measurement side of the project.

Most importantly, when it comes to an interview, you do not need to have a memorised script - having the key points clear in your mind will help the conversation flow smoothly and avoid those “I wish I’d said…” moments.