Tell Me About a Technical Project
Breaking down a quintessential PM interview question
As an APM interviewer, one of the datapoints I'm looking for is the level of technical understanding a candidate has. The simplest approach, and one that I use regularly, is just to ask "Tell me about a technical project you've done and the biggest challenge you faced."
In this article, I'll go over what an interviewer is looking for in an answer, and what you can do to improve yours.
What the Interviewer Is Looking For
This question and its purpose is straightforward: a quick way to judge technical knowledge. It's not as in-depth as a system design question, and gives the interviewee the advantage of familiarity with the subject matter. Sometimes, the project will be the interviewee's choice while other times, the interviewer will ask about a specific project on the resume. Regardless, the goals are still the same.
Confidence and Reputability
Because this is your "home turf", an interviewer will expect you to project confidence and quickly establish reputability. This is crucial because while an interviewer may not be familiar with the specifics of your project, they can still tell if you have a strong grasp on the material.
The implied requirement is that you need to be confident and well-versed in the project you're presenting. Select a project where you:
Wrote the code yourself
Relied minimally on 3rd-party libraries / solutions
Had to make decisions by yourself
Tried different solutions, and therefore can very concretely explain why you made a particular choice
If possible, pick a project that you built outside of school rather than a class assignment. Many technical PMs and SWEs will have taken similar courses in school, and are familiar with the complexity of the project and the amount of support given by friends/professors/TAs. There's nothing inherently wrong with that, but mastery of class material is expected. To the interviewer, the interesting part of the question is the "challenge you faced and how you overcame it" portion. This is where critical thinking, problem solving, grit, and adaptability are showcased.
If you do talk about a class project, ensure that there was a challenge you can talk about, and that the way you overcame it was through your own attempts, not by getting the answer from friends or a TA.
The Right Level of Detail
The standard failure mode for this question is not being able to answer the interviewer's probing questions in depth, but it is possible to be too detailed.
Remember that the job of the PM is to communicate effectively, meaning at the right level of abstraction for the audience. Including unnecessary details could needlessly confuse the interviewer. They'll convey that you don't know where the gist of the project ends and the minutia begins, and worst of all, they'll eat up valuable minutes from your interview time that would be better spent on the product-focused questions.
What is the right level of detail? Start with the knowledge you want the interviewer to take away. This can include:
Your level of technical competence (e.g. beginner vs. advanced)
Your ambition
Your problem solving skills
Your ability to pivot a project in light of a roadblock
Then ask yourself if a given detail advances the points you're trying to make. If not, cut it! You can always leave openings for the interviewer to ask for more. For example:
"We ended up choosing Bootstrap because of some compatibility issues we ran into earlier. I can describe those issues in more detail if you want, but before that I also wanted to explain our backend stack. ..."
What You Should Do In Your Answer
There are a few broad questions that the interviewer is always considering:
How much work did you actually do?
How much work was original vs. guided/copied?
How much of what you were doing did you understand?
Do
Only put projects on your resume that you can fully explain. A simpler project that you know in-and-out comes across a lot better than a complex-sounding project that you barely cobbled together using a tutorial.
Examine your understanding of every single aspect of the project. For example, which problems were difficult to solve? Generally difficult problems will be obvious to an experienced interviewer, and expect them to ask how you approached them.
Practice your answer. This is your home turf. Rehearse your initial explanation, and leave no stone unturned when anticipating followup questions.
Don't
Make things up. If you don't know how something worked, or why you made a certain decision, just say so. Engineers say "I don't know" all the time, and a truthful answer is far better than a paper-thin excuse.
Pass off blame. It can be tempting to blame team-members / external dependencies / etc. when describing a challenge you encountered. Resist the temptation. Not only is it a bad look, it's poor PMing in general. Good PMs take responsibility for failure and use it as an opportunity to understand what went wrong and think about how to prevent it next time.
Have generic challenges. "It was a new programming language" is not a unique challenge, and doesn't show anything specific about you as a problem solver. The question is heavily biased towards showing your problem solving abilities. Find a problem where you can explain:
Why it happened
What effects it had
What you did to work through it
What you learned and will/won't do in the future as a result
Bonus: A later project where you applied the aforementioned learnings
The "describe a technical project" question isn't out to get you. It's just as straightforward as it seems, so long as you know what the interviewer is looking for and prepare your thinking ahead-of-time.
Good luck!