The Rational Software Engineer: How to Find a Dream Job

I am a software engineer who geeks on learning, using a scientific approach to solve problems, and optimizing my performance. During my work as a software engineer, I tried to understand what can make the process of finding a new job more smooth and less error-prone. I feel like I’ve gained some insights into this topic, which may be useful for others as well. In this article, I will share a few recommendations that help me to go through the job search process and identify whether a company is a good place to work.

Searching for a New Job is a Thrilling Experience... or Not

And here we are - you decided that you are not satisfied with your current position.

Maybe you found yourself at a place where you don’t see your future growth as a software engineer, or your company’s values don’t match yours anymore, or your project is disappointing, and you cannot do much to change it (here I wrote what you typically could do to deal with “bad” projects); or the main things that bring job satisfaction like good work-life balance, pleasant relationships with colleagues, and a reasonable salary are missing.

Regardless of how you ended up here, now is the time to start searching for a new position. This is always a tremendously exciting journey. So many possibilities are open that can bring new knowledge, experience, and a lot of joy. On the other hand, the job search process can get lengthy and even frustrating, and it’s fairly easy to make the wrong choice with a company. So is there something I can do to make the job hunt as pleasant as possible and to find a great new place? Yes, and there are quite a few useful tips.

Before we start, one assumption I make is that you are in such a place of your experience and market-state that you are “hunted” by companies, and you can get a dozen invitations for an interview without much hassle.

It’s a typical situation for most software engineers with a couple of years of experience when the market is “optimistic”. However, it can be very different if you are looking for your first job or the market is in a “crisis” state, like, during the beginning of Covid. In such a case, it may be more pragmatic to be agreeable and less demanding instead.

So let’s start with the “preparation” phase.

Brush Up Your CV

If you have abandoned your CV since you started working for your last company, it’s time to make it up-to-date again. It is a good practice to do it constantly, even when you are not looking for a job. I try to update my  CV each month or so because, otherwise, I simply forget specifics that can be worth mentioning, like challenges I encountered.

What is the best structure of a CV? The answer will vary from person to person but I prefer to do it this way: I keep all of the essential things on the first page - my contact data, my mindset as a software engineer, technologies I have experience with, and future expectations; and on the other pages, I list all projects I have worked on and the specifics - technologies, responsibilities, achievements, interesting challenges I met. In such a way, a person who looks at my CV can get most of the relevant information from the first page but also have all the technical details if they decide to read further. Here is what my CV looks like:

CV First Page: General Info About Me

CV First Page: Technical Skills

CV: Listing of the Projects for the Rest of the Pages

As now you are all set up, let's move to the position searching step

Define What You Are Looking For

Here I tend to start with the criteria for an “ideal” position I’d like to find before starting the search. It can help me to quickly narrow down the filters and navigate accordingly later on. Here is the list of criteria for the position I try to define for myself before I start.

1. Minimum salary
2. Remote work fine and team collocation, relocation
3. Branch of development (Backend, DevOps, Machine Learning)
4. Technologies (Java, Kafka, Azure)
5. Role in the team (Developer, Lead)
6. Type of the company (start-up, product, consultancy, or outsource)
7. Social plan and perks (vacation days, insurance, shares)
8. Size of the team
9. Structure of the team
10. Company daily communication language
11. The sector of the company (finance, healthcare, real estate)

Let’s say that I’m a Java developer with 10 years of experience living in Oslo, Norway, and I want to transition to functional languages, as well as I only want to work in fintech as I believe that this is how I can bring more value to the world. Also, I am an immigrant, and using Norwegian as my primary language at work will help me to learn it. Then, the criteria list can look something like this:

1. 100 000$/year
2. Collocated with the team in Oslo
3. Backend + some DevOps
4. Scala
5. Lead role
6. Product company
7. Insurance, pension plan, shares
8. 5-10 people in the team
9. Dedicated Product Manager, UX, and QA
10. Norwegian
11. Fintech

One useful step that I do next is to prioritize the criteria so that I know what is non-negotiable and what doesn’t matter that much

1. Scala
2. Fintech
3. Norwegian
4. 100 000$/year
5. Backend + some DevOps
6. Collocated with the team in Oslo
7. Lead role
8. 5-10 people in the team
9. Product company
10. Dedicated Product Manager, UX, and QA
11. Insurance, pension plan, shares

Great, now I have priorities that I can search according to and filter out many irrelevant results. Some of them can be applied in the search already, like preferred technologies and the role in the team, while others are the things you will mostly be able to find out as you go during the hiring process itself, like the structure of the team and whether the team is collocated.

Search and Apply

Even after using the filters upon the priority list, there are typically a lot of open positions to apply to. If not, then it makes sense to give up on some less essential requirements for the position. I try to find around 10-20 positions that I can apply to. Some of the companies may seem like a precise match, while others will be more of a spare choice.

I’d typically write a motivation letter to the positions that got me the most interested. There is a good reason I would like to work for them, and it can be beneficial for you to state that.

Let’s imagine that you are looking for positions in a neuroscience-related company. Then, it can be relevant if you include why you are passionate about the field and what related knowledge you have (this one may be worth to be added to the CV instead). Now, let’s discuss how to have some background checks of a company.

The Reference Check is for Your Benefit

Candidates are typically asked to provide some references so that the new employee can understand your track record and see how you behaved at your previous workplace - I find it essential. I also find it useful to use the same approach for the company you are going to work in.

A good way to understand the internal workings of the new company is to ask its employees or your new teammates directly. If it’s possible, find some people that you are going to be in the team with and some people from the company in general, and ask them what they like and dislike in the company.

Also, you will probably have somebody in your network who has either worked or heard about the company. So ask around, and typically you will get some feedback about the company or at least a reference to somebody who can provide you with such feedback.

As well as that, there are some resources like Glassdoor where you can find reviews about the company, salary ranges, and insights. Don’t forget to check it out before you apply; it can give a really precise picture of some aspects of a company. 

Now, you have applied to dozens of positions, and the first steps of the hiring process start: figuring out missing details about the position and the pre-screening calls. These steps can be time-consuming and somewhat repetitive, so let’s discuss how to navigate through them effectively.

Asynchronous Communication

You got contacted back by a hiring person, and they offered you a call to go into details. At this point, instead of having a call, I prefer to chat/email for the necessary information that I need to understand whether I want to invest the time in the hiring process at all. If you set salary as your main requirement and it is not stated on the vacancy, why would you go to a call and spend 1 hour of your and the company’s time just to figure out that the salary is simply below your minimum requirement?

Typically, the vacancy will lack some information about the list of criteria you set, so it’s important to clarify all of the missing bits. For example, whether the team is collocated and what the company’s daily language is. 

As I have collected all the needed info and now I am asked to have a pre-screening call. This is another point that almost always gives me a feeling “this could have been an email” kind of feeling. I have had dozens of such calls, and almost all of them were alike. I was given an overview of the company, the basic information about the project, and how the hiring process will look like.

Also, I needed to describe my experience, what I am looking for and when I can start. All of the information fits into 1 message. In terms of the information, there was no need at all to have a call instead of chatting. So why would anyone even want to have such calls that are time-draining, hard to fit into one’s calendar, as they happen during work hours, and don’t provide any new data?

The reason is not that they couldn’t collect the information asynchronously, but that the company wants to understand whether I am an adequate person at all. A good solution I found is to ask for the list of questions they want me to answer and send back a video recording answering all of them. I find it much easier to fit into the schedule, and it takes much less time in general as well. 

Also, some companies like to give “The Big 5 Personality Test” at this step, so you can do it once and reuse it as well.

If you are asked to have the pre-screening eventually, as the company doesn’t want to answer your questions on chat, or they don’t want to accept your video recording, then it’s a useful piece of information for you to judge upon. If their hiring process is so rigid, maybe, it’s good not a place for tech innovation as well.

Also, there are a few more questions that you can take at this step (if you have a prescreening call) or ask them at the appropriate step later.

1. Why is this position open?
2. What are the company’s values?
3. Who are the company’s customers?
4. What is the company’s attitude to overtime?
5. What HR processes do you have?
6. What are the perks you have?
7. How do you help your employees to grow and educate themselves?
8. What are the activities a developer can do in the company apart from the project-related ones?
9. What is your mentoring culture?
10. What will my Career Path look like?
11. What does the company expect from me in the first half a year?

Great, now, luckily, you have managed to have had the whole “introduction” step using only emails, and you are invited to the technical round.

Technical Round

I try to keep in my head that the technical step, as the interview process in general, is not only for the company to understand whether I am good but for me to understand whether I like the team as well. Therefore, I don’t hesitate to ask questions that will help me figure out important things about the team, tech processes, tech expertise, and such. Here is a list of some useful ones that I typically ask the tech person.

1. Who are the developers on the team, and what is their expertise?
2. What processes exist in the team?
3. How much is the tech involved in the product decisions?
4. How is your deployment configured?
5. What is the architecture of the project?
6. What is your approach to testing, code review, refactoring?
7. What external integrations do you have?
8. What are the technical challenges that you face?
9. What is the technical plan for the project for the next couple of months
10. These should give you a good picture of the project and the team.

Test Assignment

At some point, it’s common to give some kind of proof that you can write code well. Typically, it is a form of a home test assignment. If I am asked to do an assignment, I respond with a couple of options sorted by preference.

1. I can show PRs I did
2. I can show you some of the projects I wrote
3. I can show some test assignments I have from the past
4. I can write the test assignment if it’s paid for

Let’s discuss the list a little. Assignment tasks can vary in length, but some companies would send you a test task that can take up to 10 hours and expect you to do it for free. I find it irrational. First of all, typical test tasks show very little of how a person codes in real life. PRs show it much better, for example. Secondly, 10 hours of a developer's time are not free, so it’s strange to expect it to be done for free. Therefore, I prefer to give a couple of alternatives that are more preferable and show my expertise much better to the tech person who interviews me.

How to Get a Better Understanding of a Team

Alright, so the position fits the requirements you set greatly, and you enjoy the technical side of the project as well. However, as we all know, a lot of things seem nice and shiny in the beginning. However, when you start working, a lot of small nuances appear that you didn’t think of.

Maybe, after a week you notice that the team does overtime often, or the developers are demotivated and hostile, or that there is a very strict hierarchy and your ideas and initiatives are not heard. You start thinking “I wish I could have had a chance to see how my work would feel like when I was accepting the offer”. And the good news, there is a technique that can provide such an opportunity.

Once, when I was interviewed for Volkswagen, It was explained that the last step of the interview process would be to work in a team for 1 day, where I would meet the team and work with them during this time on a given task. I would be involved in their meeting, be able to see the office, get the vibes of the team and other employees in the company, and get familiar with the office.

Unfortunately, I decided not to proceed with them, but the process sounds greatly beneficial to both parties. It can help to understand the company’s “inner kitchen” and whether it is not a good fit much earlier. Even though it can be a hassle to organize, it brings tremendous value, and I will ask for such an opportunity next time I get an offer to understand my future workplace earlier and have the ability to make a more sensible choice.

Use the Test Period

Hooray, everything has gone smoothly, and now you get an offer. I would stress to agree on some reasonable test period where you and the company can decide not to proceed with each other on short notice. This gives a really good opportunity to stop working there if after a few weeks you determine that you don’t enjoy the workplace.

Conclusion

I believe that it’s much easier to find a great job if I identify what is useful for me and try to figure out as much relevant information about the company, project, processes, and the team during the interview. I try not to give a second thought to bombard the interviewer with questions, as the interview is a two-way process. I hope that the recommendations from this article will help you to find a job that you will truly enjoy.

This article is a part of the "The Rational Software Engineer" series on Hacker Noon. It covers topics related to optimizing personal processes, education, career development, and being passionate in a software engineering context:

• The Rational Software Engineer: A Guide to Work Time Organization 
• The Rational Software Engineer: There is No Perfect Project
• The Rational Software Engineer: How To Be Passionate About Your Work [Part 1]
• The Rational Software Engineer: How To Be Passionate About Your Work [Part 2]
• The Rational Software Engineer: How To Find a Dream Job