In the last few months, I was looking for a new job as a software developer.

I attended various interviews, talked to a lot of diverse people, had to solve different tasks, answered plenty of questions, and asked at least as many.

In this post, I will share with you what I have learned, and tell you some useful tips for doing well at your interview to get the job of your dreams.

I won’t give you an exhaustive list of technical questions, brainteasers, and riddles. Instead, I’ll tell you how to make the most sense out of them.

Software Today

Software development nowadays is less about technology and more about people. Good communication skills, knowledge sharing, and team spirit are essential qualities of software professionals in modern organizations. Software becomes more and more a people problem.

Good code is driven by simple, easy-to-understand design with human factors in mind. Perfectly working code is no more enough, as far as it is incomprehensible to other teammates. Great programming skills are not sufficient as far as you’re unable to communicate your work clearly.

This fact has been slowly understood by software companies and the interview process has been adapted accordingly. That is, a flawlessly coded quick-sort algorithm is no guarantee for getting a job offer anymore, and it is actually good.

You spend a great piece of life at work. Not only is it no fun to spend this time with asocial, uncommunicative, or even rude, geeks; it is also pretty unproductive at the same time. Software development became too extensive to fit into a single head entirely, and there are no unicorns. Teamwork is a fundamental prerequisite for a successful (software) product. From experience, just one unsuitable person on a team could cause immeasurable damage to the outcome. I bet you know exactly what I'm talking about.

The extra effort at the interview to ensure you’re a good match for the team means the team is a good fit for you, too.

Soft skills became an important part of your professional profile. Some of them are even more significant than the hard skills you put first in your resume. In fact, any technology can be learned, but it’s really difficult to unlearn being a jerk. Deep knowledge of a particular programming language is not as valuable if you can’t use your potential as a team member to create a great product together. Crucial is the ability and will to learn, communicate, and exchange knowledge with others.

Reputable organizations today are not looking for lone wolves or cowboy developers. Rather, team players and excellent communicators are appreciated.

Tell me about yourself

A few honest sentences about yourself, your background, personal values, and what you are looking for, a nice photo, hobbies and interests are more valuable than an overwhelming list of technologies and programming languages you touched since your studies.

Of course, hard skills are still very important, but your professional profile should tell your potential employer who you are. Forget things like UML or XML, no one is interested, strike off all exotic languages you used to be programming in as a kid, you barely remember them, focus on what’s important and relevant to the position you currently apply for.

Structure your profile hierarchically, start with concepts and then go deeper. Have you designed distributed systems or developed machine learning algorithms? Start with telling that. Continue by diving into concrete technologies, languages, methods. Mention them in the list of working experiences, too. Be consistent and integrous. Focus, structure, remove fluff.

Your professional profile is a sample of your work. Being done poorly tells your potential employer you’re probably no good worker. Your professional profile must be professional.

Sometimes an obligatory question comes up:

Characterize yourself using only three words.

Albeit such a question would fit more to an interview for a job in the marketing department, it’s a good idea to be able to characterize yourself with a few significant properties or values. Open, creative and focusing could be a good try. You can explain those in detail afterward, ideally with some practical examples.

I personally characterize myself with the help of three values I identify with: people, quality and learning. People stands for teamwork, knowledge exchange, trust, and intensive transparent communication not only within the team, but also between teams; quality stands for simplicity, maintainability, product-thinking, and focus on purpose; and finally learning stands for continuous improvement, and exploring new things.

Also, it might be nice to have a life motto that drives your personal characteristics on a very abstract level. Like this one by Albert Einstein: “Everything should be made as simple as possible, but no simpler.”

Personal integrity

It’s easy to make things up. There’s mostly no way how the interviewers could possibly check if all that you say is true. Well, there is a way. We can call it an integrity check.

First, there’s no point in lying. Don’t do that, I mean it. If you make a different person from yourself, that person would be expected to remain as such afterward. But one can’t lie forever. Soon or later, the truth comes up and the consequences are drastic. Losing the job and all the opportunities that you had to cancel due to this one and that could’ve matched your dreams much better. Broken trust, shame, and a black hole in your resume. Definitely not worth it. What’s more, telling the truth is much easier as you don’t have to memorize anything.

Even if everything you say is true, you have to be ready to prove it. You have to watch the integrity of your words. For each and every statement there must be a concrete example from your experience.

You say, you’re creative? Tell me about your best ideas in your previous work. You say, you’re a leader? Tell me a story where you take over a control. Are you good at conflicts resolving? Tell me about a conflict in your team and how you managed to resolve it. You like learning new things? Tell me about a piece of technology you read about recently.

Questions about resolving conflicts and disagreements in the team or on the organization level are very popular among interviewers. They help them to test your integrity as a team player. A true team player welcomes diversity and disagreements. Different opinions are opportunities for exchange, to learn something new, or to refine your own thoughts. Conflicts should never become purely emotional and must be resolved rationally through discourse with the whole team.

As the ability and will to learn is one of the most important characteristics of a good developer, you may expect a lot of questions touching on this aspect:

How do you learn new things? What was the last lecture you attended and what did you learn? How would you explain a particular technology to a younger coworker?

Another interesting sort of questions focuses on legacy software. While, as the old joke says, a new JavaScript framework is born every day, a successful software product could live over ten years. This means most stable companies deal with legacy systems of some kind. A question about how you get on with this is definitely about to come.

While it is good to be keen on shiny new stuff, it’s necessary not to forget about the purpose. You should not adopt a new technology just because of the technology itself, but because it solves a problem you actually have. Microservices or machine learning are cool, but not a silver bullet. You should aim to use good and appropriate technology that fits your context, and communicate it so towards your interviewers.

Be honest with your weaknesses as well. Don’t be afraid to admit that you don’t know everything. It’s perfectly fine to be aware of room for improvements and way better than being caught lying. Much more important is to show the will to learn and to get continuously better.

What, how and why

What and how questions are familiar to every developer. There are plenty of interview questions over the Internet everyone can just print and learn at bedtime as a poem:

How does merge-sort work? What transaction isolation levels do you know? How to check two strings for equality? What does SOLID mean?

I bet you have already been asked all of those questions and you definitely know the correct answers by heart. As this is good, it’s not enough.

Good companies will test your understanding and solving skills rather than encyclopedic knowledge of definitions and algorithms. That is, you should also expect why questions, such as:

Why is bubble sort ineffective and why is it not possible to fix it? In which cases could bubble-sort do make sense? Why is the Repeatable reads isolation level not sufficient to avoid phantom reads? Why do we not use the Serializable level everywhere? Why is the == operator not adequate for checking strings equality in Java? Why does the Dependency inversion principle lead to loosely decoupled code?

Knowing what and how is necessary, but a good engineer must know why, too.

Analyze, be creative

A lot of questions are not meant to be answered directly or even correctly. Many of them have an open ending or no solution at all. Interviewers are interested more in your thought process and solving skills than in a precise answer.

There is no shame in taking some time to think. Nobody expects you to come up with a brilliant solution instantly. Take a deep breath, analyze the question, be creative, and share your thoughts.

What profession would you do if you were not a developer? What is your favorite phone app? What color would you be?

There is no correct answer to the above questions. They all test your creativity and ability to think out of the box. Analyze the hypothetical situation first:

Maybe you always wanted to be a musician and now you have an opportunity to sell your dream. But if you always wanted to be a programmer it’s unlikely that you have a list of alternative professions in mind. Why would you be someone else? Maybe because there is no such job whatsoever! So, what would you likely be in medieval years? Or in a parallel universe where physical laws are not constant and humans communicate via music. Show that you’re not boring. Nobody wants to work with a tedious person.

Some questions are put unclearly on purpose and interviewers expect you to ask additional questions to make the problem clear. Take the interviewers into account as equal partners, try to work it out together, collaborate:

What does “favorite” actually mean? Most beloved or mostly used? What would be the app I would keep if I could keep only one? You can talk about the newest game you had really fun playing, or be practical saying that your favorite app is the internet browser because you can do practically everything with it.

There is no need to study psychology and emotional values hidden under different colors. Your interviewers did certainly not. If you want, say you would like to be blue as it is your favorite color remaining you of the sky. Or maybe yellow like the dress of your child on its first school day. You may also say that you’d like to be white because white is used only little and by only true artists, which means you would participate in as many great paintings as possible. Options are infinite.

You’re supposed to be happy too

The task of an interviewer is to find out if you’re a good fit for the team and the organization she represents. Your task is to figure out if the team and the organization is a good fit for you.

This aspect of the interview is often underrated which can easily lead to disappointment, or even anxiety and burnout. You spend at work way too much time to be unhappy there. If nothing else, please, remember this.

Make sure that the job fits your expectations and there is consistency in what the interviewer offers. Ask questions. A lot of them. Show your interest in the organization, the team, and the product. Ask about company values and check if they match yours. Ask about challenges and how they solve them. Check answers for openness and consistency. I used to ask this very same question to every interviewer:

What is the worst thing about working for the company?

Some companies would promise the earth but the reality turns out to be very different. Do they have concrete examples to share with you? How does the organization support your ambitions and needs? Do they offer lectures and training? Will you have time to experiment and try new things out?

Interviewers often over-use buzzwords they barely understand. Try to address this as well:

What do you understand under Agile? What does DevOps mean to you? How do you do Scrum?

It’s always a good idea to ask about your potential role and organizational structure. An unclear and inconsistent understanding of the role responsibilities, high and opaque hierarchy, or cumbersome processes are signs of a dysfunctional organization.

To show interest brings points for you as well.

How to do your homework

Last but not least is a technical task, usually given as homework with limited time in the first phases of the interview process.

This kind of examination became very popular the last time and replaced typical multiple-choice tests almost completely.

The point is not only to see your skills in action, it’s also a good check of your thinking in an unusual situation.

What is so different about such homework? The conditions are pretty unnatural. It’s no real problem you have to solve. You’re missing context and typically a lot of other information. You might ask additional questions, but you’re also supposed to make assumptions by yourself.

There are several rules I’d recommend:

First, if you’ve got some code to extend, study it. Never do any changes, except you have found a bug or been told otherwise.

Don’t over-engineer. This is time to shine, but it doesn’t mean you should use every piece of technology you know. Rather, make your solution extensible, so it’s open for further improvements. You don’t have to use each design pattern from the GoF catalog, it’s much better to use only one, but properly. Use best practices, but keep it simple. Think in terms of MVP (Minimal Viable Product): What’s the minimal solution it could possibly work?

Always write tests. Not only tests increase your assurance that the code is doing well, but they will also make you more productive and help you get things done quickly. Every change, every requirement and condition must be found in the test suite.

Use static code analysis tools. In this case, the tool that comes along with your IDE will be sufficient. This will be probably the first thing your reviewers will do. Don’t let them find any code smells. It’s easy money.

Consider options, make notes. Your solution will be discussed later, so it’s important to know why you did as you did. There could be more than one right solution, but it’s important to explain why you have chosen this over that. Everything is about trade-offs, you should understand the benefits of your solution and be aware of its drawbacks.

Summary

Let’s summarize the most important points to be aware of when preparing for an interview as a software developer:

• Software today is less about technology and more about people.
• Working code is no more enough, you have to communicate your work.
• Teamwork is a fundamental prerequisite for success.
• Ability and will to learn is crucial.
• Your personal profile is at least as important as your hard skills.
• Be honest, consistent and integrous. Don’t lie.
• A good engineer must know why and understand trade-offs.
• Analyze, be creative, and share your thoughts.
• Ask questions, show interest.
• When working on a task, use best practices, but keep it simple.
• The job must fit you.

I wish you good luck with the interview, getting your dream job, and having a lot of fun developing software!