This post was originally published in my blog smartpuffin.com.
I often ask this question on interviews:
"What is the most interesting or challenging task you have ever done?"
The answer tells me a lot.
All developers tell me what they have done. They used Kafka, RabbitMQ and Kubernetes. They sharded, scaled and clustered. They moved the logic from monoliths to microservices. They integrated APIs. They applied all letters from SOLID. They built castles and teared down mountains.
Not all of them tell me why they did it.
Why is "why" important?
As an interviewer, I want to see what problem-solving skills you have and what level of seniority you are as a developer.
In my opinion, the seniority of a developer is not only about the complexity of the system or the code, but also about:
- user-centric thinking;
- making reasonable choices and trade-offs;
- ability to clearly explain all this.
Let's see how we can highlight these qualities when answering the question.
User-centric thinking
Working with users is, I believe, one of the most important (and most underestimated) skills for a developer.
You never write code for the sake of writing code. (Except when you're learning or procrastinating.) You always write code to deploy it to production and let some people use it.
This, actually, is not immediately obvious to everyone right at the start of their careers.
Developers come from schools where they are taught by professors. Professors are not users. Professors look at the code. For several years code is your product.
And the users look at the final product.
If your code is great, but it doesn't solve the user problem - it's useless.
It is not so easy to understand and get used to, but I expect from more senior developers the understanding of this.
So every piece of code is made according to a user requirement, to solve some user problem. And I want to hear about it! I want to know what it was and how your implementation solves it.
Making reasonable choices
You pick technologies for a reason. I am always curious what that reason was.
Mature answers could be:
- we used it for a similar project and it worked well for us;
- we had people in the team who worked with it before;
- we investigated and compared it with others, and it fits us better than them because X, Y and Z.
Not-so-mature answers sometimes look like this:
- it's the most popular technology right now;
- it's cool;
- company X uses it.
I'm not going to argue with you on whether it is really the best or not. But I need to know you didn't pick it on a whim or simply following the fashion. The reason should be based on rational thinking about what's best for your project in your given circumstances. And you should tell me about it.
Making trade-offs
Not always you're able to write perfect code that works ideally. Under the influence of past decisions, changing requirements, and deadlines you may make decisions that could be made differently in retrospective.
I want to hear how you reflect on the previous choices and explain the reasons that were valid back then, even if the circumstances changed now.
Clearly explaining
As a developer, you need to explain stuff very often. You'll find yourself explaining the same project to the users, business analysts, technical writers, QA's, project managers, or new team members.
The skill to explain clearly is valuable in itself, but it is also a proxy to other skills, such as: team player, analytical thinking, and, once again, shows your level of seniority. Great developers shouldn't be above explaining, patiently and thoroughly, their thoughts and ideas.
Answering questions about your previous projects on an interview is a great opportunity to show your skills in this area.
Telling a story
Overall, as a reply to the question, I want to hear a story.
If I were describing my most challenging project, I would start my explanation with describing a task I was solving.
Let's say I implemented our own authorisation without using oAuth.
I'm going to start with why I had to implement authorization for the project? What were the requirements?
And then I'm going to lead my interviewer through the whole process, from defining the requirements to eliminating the possibility of using existing APIs, to implementing, to fixing bugs, to success (or failure and learning).
This way I would:
- make a great cohesive story, easy to follow and understand;
- show how I am involved in all aspects of development, like a senior developer should be;
- show how I apply my problem-solving skills, from beginning to end;
- and leave room to asking questions about every stage of the project.
My own answer
The most challenging and the most interesting project in my career so far was a scalable distributed GIS-system. Check out my set of articles about the architecture and our process: smartpuffin.com/tag/fiji/
Note how I focus on the users, their requirements, and our approach to problem-solving.
Was it a cool project? Absolutely! Was it fun to develop? 100% pure fun. But what I'm focusing on? Reasoning.
For the interviewer it is important to understand your approach. Focus your answer not only on what you did and what technologies you used, but also on reasons and problem-solving, and you'll show yourself in the best light.
Top comments (9)
I wish I had known this before!
But now I do, thanks for sharing :)
I actually had that question today in an interview. This is the kind of interview I prefer over a game of programming language Trivial Pursuit or some unrelated-to-the-job whiteboard programming puzzle.
My answer revolved around a project I worked on a few years ago that involved working with cardiac monitoring data. In that project it was essential that everything worked right because peoples' lives depended on it. If an alert condition was missed or a doctor wasn't informed when necessary, someone could have died. I described how testing was done and how levels of error handling were included to insure accuracy and security.
Wow, Frank. My respect. That's a very challenging project indeed, and I'm sure you've done a great job there.
When I listen to people talk about previous work, I'm not sure if I'm actively listening for the "why". I am definitely listening for an understanding of their work though, which probably includes quite a bit of "why".
It can be difficult for people, especially those not in senior roles. Here are some valid answers you might encounter, but are challenging to formulate and not sound stupid or like a dick:
I reflected on this today, great article. So many things to take in and improve upon!
great post. I had always struggled to answer this question. Now I have a better idea and will spend some time thinking about what I have done in my previous projects.
Something to this effect should be included in the requisite Developer 101 handbook reading for every new member of the community. Well said!
Wow, thank you :)
Important subjet perfectly explained, very helpfull :) Thanks for sharing