Credit to cover image goes to Christopher Burns on Unsplash
One of the most popular programming interview questions is “describe your latest project”. I guess it will shock no one if I will confess that I (and everyone else I know that interviews) use this question for screening software developers and QA engineers.
For me, I don’t only ask it as one of the questions on the list. About third/half of the interview is dedicated to it.
This post tries to explain WHAT do the interviewers want to get from asking this question, that cannot be achieved by reading the CV, looking at github, etc. In each section I will describe what do they look for, a short tip, and common pitfalls in answering it, all from real life.
We hope that this read can help in preparation for your next interview.
If you found it helpful, please comment, share and spread the word 🙂
Different ways to ask the same thing
Before diving in, we’ll just say that there are several ways to ask this question. They are all the same 🙂
- Tell me about your recent project
- Describe your latest project in detail
- What did you do in your last job?
- Choose any project that you loved and tell me about it
You can guess the last one is my way of asking it. I don’t really care if it’s the recent one. It just needs to be something that was the candidate wants to speak about. However, if they choose a different project than his recent one, it’s also something to discuss. Maybe they get bored easily? Maybe not.
What DO the interviewers want?
As stated above, this post’s goal is to help you understand what the hell an interviewer wants when she asks it and how to answer it like a pro. It is based on my personal experience as a professional interviewer (for hire) and as a programmer that answered this question dozens of times myself.
They are NOT interested in your current workplace’s commercial secrets, patent protected algorithms or office politics.
They are interested in YOU. This question is wide enough that it involves allows them to get a sense of the following areas.
A. Verbal skills, see you can explain complex ideas clearly
A big part of being an engineer in a team (can be 2 people, can be 10) is the ability to explain your ideas to your colleagues, managers, support team perhaps. That’s the reason there is a great significance to the verbal abilities of a candidate. You should not be the Shakespeare of design reviews, but should be able to explain a complex bug in simple words, or the design you made for a new feature in a way your team mates could join.
Common pitfall: Diving to fast into technical details without explaining the big picture. Example: “My biggest project was optimizing the indexing mechanism for the sent email search for users with more than 3 roles that uses multiple IPs at once”. While this sounds fascinating, it’s a very technical way to start your story. And I wouldn’t write it here unless someone said it like that in an interview.
Start with some background. What is the system, who are the users, why is there a problem for users with multiple roles, why did you decide to fix it?
Tip: Practice in describing your project starting from the business/product perspective, explaining the problem it solved (in short), and only then describe the super technical task you had there.
B. See how passionate are you about your job
Because you are going to spend lots of time in your new position, your future employer wants to see that you like what you do, and give positive energy to the team.
Common pitfall: Not showing passion about any part, telling about your project like it was someone else’s work.
Tip: Maybe your recent project didn’t excite you or made you better. But, perhaps the one before did? Before the interview choose the project that you want to talk about, and suggest it to the interviewer. A possible way to say it is: “My recent project was interesting, but I felt I learned more from project XXX. Is it OK if we’ll talk about that one?”.
C. Understand the level of expertise you have in your field.
Hear what are your opinions regarding the technologies, architecture and other technical decisions made in your recent project. By doing so, you are also expressing your knowledge of these technologies (usually by answering some followup questions).
Common pitfall: Not understanding what stands behind the decision to choose a specific technology. For example: the company that you worked for chose to use ReactJS for their frontend application. You might be asked if you think it was a wise choice, what alternatives are there and what were the considerations led to this decision.. and do you agree with them.
Unfortunately, I saw more than once people that simply don’t know why it was chosen and are not familiar with alternatives. Because frontend technology is changing in a super fast pace, the employers are looking for ones who sniff around. Not only a one trick pony.
Tip: Know the technologies you are working on, explore some alternatives (you don’t need to master them, just know a little), and avoid making very bold statements such as: “ReactJS is the best framework, it will suit every application”.
D. Understand your ability to explain technical ideas like your system’s design/schema/components
Expressing your way of thinking of a system with several components, separation of concerns principal and the ability to explain what you have in your head to someone else.
Common pitfall: That’s easy, not being able to draw the component/system design, oversimplifying, or not understanding how the components communicate with each other.
Tip: Practice practice practice practice, and then show it to someone who will ask you what these squares are. Draw on a paper your system’s design – servers, clients, proxies, load balancers, CDNs. Focus on the area that you would like to speak about and draw it in more detail to draw attention there.
Personally I tend to ask about the ways the components communicate with each other, a conversation that touches basic HTTP terminology, usually the term push-notifications/sockets comes up. If you are preparing for an interview, it’s a good idea to polish your HTTP protocol knowledge.
Conclusion:
In this article we covered some of the things interviewers (me) try to achieve by asking candidates about their recent project. I hope that it helped and gave some ideas for how to prepare for this question. Good luck!!
In case you are in a hiring process, you might find these posts interesting:
- How to prepare for an online programming interview
- A through explanation of the hangman interview question
Also, I am soon launching a new service, offering training for both interviewers and interviewees, making their life easier by perfecting their goals and interviewing abilities. Interested? Contact me on Linked 🙂