Seeing The Big Picture: One Important Aspect Of Being A Senior Developer

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.