One of the many questions you may be asked during a technical interview is: ‘Walk me through a project you worked on.’
While open-ended, this question is surprisingly telling as it allows the hiring manager to look for many qualities in the developer depending on how they answer. It shows how well a developer can present their project and communicate about it technically. It identifies how a developer deals with obstacles, delays, and problems that come up during the project, and how they are overcome to get the project done within the deadline.
No matter what level of developer you are (junior, intermediate or senior), this question has a huge impact on whether or not you’ll get the job.
So here’s how to walk an interviewer through a project
To start, you want to give an overview of your project, the what and the why of it. Were you looking to solve a problem? What does it do? What tech stack did you use and why did you choose those technologies? Was it a group project or a solo one? If so, what parts were you responsible for? What did you build?
Be careful not to spend too much time on CRUD-like features (create, read, update, and delete) without much complexity. You want to focus on what made the project complex and go into depth about that. If it’s a larger project, you also want to be wary about time. Pace yourself and make sure you’re communicating clearly, choosing wisely what you want to emphasize. Just like any presentation, you don’t want to bore your viewers
You’ll likely be asked about what problems and obstacles you faced during your project and how you overcame them. For example, this could either be a feature implementation or a system design problem. This is an important question. As much as you might not want to talk about the bits that stumped you, employers are looking to see how well you are able to problem-solve and what kind of resources you go to in order to resolve the issue.
This gives you a chance to do the classic interview maneuver of taking a negative and turning it into a positive. It’s not about how you spent hours and hours trying to fix the formatting; it’s about your determination, creative thinking, problem solving, and how the experience allowed you to grow as a developer (and doesn’t your formatting look great now? See how it all worked out and what a valuable learning experience it was?)
Similar to behavioural interviews, think ahead of time on this question so you’re not caught off guard. Pick a strong point that can really demonstrate your skills that you believe are your strong suit.
Most projects will have hurdles. In fact it is uncommon for a software developer to not face any problems at all in the making of a project, to the point where not mentioning one raises a red flag to the employer.
If you really didn’t face any obstacles at all in your project, then it might be too simple to use during the interview.
While it can be tempting to walk through everything you’ve ever made, showing off projects that aren’t very complicated is only going to hurt the interviewer's opinions of your capabilities.
A project may be too simple if you can’t expand or upscale any parts of it, if you didn’t have any problems making it, or if it’s too similar to a CRUD-like app. You can mention simple projects, but they shouldn’t be what you’re going to show off.
Employers will try to dig deeper into your project by asking very specific questions. This is a great opportunity to show how knowledgeable you are with this project and how well you can explain it on a technical level.
What makes your project special? This is where the added complexity comes into place. Be careful when answering this question as it’s common to lose track of your thoughts when describing a complex problem, so go in prepared with a strong presentation. Use visuals if handy.
Why did you use this specific tool? If you were to expand or upscale the project, how would you do it? If you were to redo this project again, what would you change? Ex: Gather specs and plan better before starting to code. Again, if you believe you did this perfectly, your project is probably too simple for interview use.
Before the interview, go over your project. Make sure you remember how it all works, what tools you used, and what all you did to get it up and running - and if it’s been a while, make sure it’s still in working condition. You don’t want to be in the middle of showing your project off to an interviewer only to realize something has broken, or that you’ve completely forgotten how it works. Refamiliarize yourself with it. If you built your project with third-party help (for example: Stack Overflow), make sure you also familiarize yourself with that code as well. This is crucial because if an employer asks you specifically about it, you should know what you coded. Give a practice tour to an imaginary interviewer. Make sure you know the ins and outs and can talk about it with confidence.
You worked hard on this project and made something great. It deserves to be shown off in it’s best light and to help you ace your interview and land that job.