Finding the right job is a difficult search problem. You typically do not have the resources to search until you find the perfect position. Fortunately employers also do not have the resources to look for the perfect candidate.
However it makes sense to at least invest some time into the search and pick the best of the available options. There are multiple dimensions to consider when evaluating a position. Here are some dimensions that I find useful to look at.
- Experience level. The experience level is typically denoted by terms such as junior, medior, senior, principal and so on. Experience is valuable because if you learn from your past mistakes you can avoid making them again. Instead of counting years to determine your experience, I suggest to reflect on the problems you have solved and the mistakes you have made. You can also take a look at how other companies define the levels, e.g. the Kickstarter ladder.
- Values / culture. Culture is made of and by people. In my opinion the company culture plays a huge role in providing you with an environment where you can grow. How does the company deal with failures? Is there a sabbatical model? Are people expected to work unpaid overtime? Do employees share knowledge? How transparent are management decisions and strategy? Those are questions you might want to get answered at some point.
- Potential to grow and learn. I already mentioned this as part of the company culture but I want emphasize it a bit. A good company will help you to move out of your comfort zone. It provides a safe space to make mistakes and learn from them. You should have enough time to reflect on your work and receive training or support as needed.
- Compensation. Compensation includes salary, bonuses, paid overtime / evening / week end work, benefits, stock grants or options, insurance, retirement plan, time off, company equipment (bike, car, phone, ...).
- Location. Where are you going to work? Do you have to relocate? Is there travel involved? Can you work from home? Is the position 100% remote?
- Career development. Does the company have a career development plan? Is it clear to you what you need to do in order to progress? Be sure to check out both expert and management career paths in case you want to have flexibility to switch at some point.
- Business impact. Are you working on something where you can see direct impact? Or are you just a small cog in the machine? I'm not saying that either one is bad but it makes sense to reflect on that.
- Can you identify with the service / product? If you want to use the product you are building yourself, that typically leads to passion and motivation in your daily work, which might translate to happiness and high quality output.
Now you can try to assess each position based on the dimensions that are important to you. Unfortunately there is an information asymmetry. While you might be aware of your experience, values, and salary expectations, your potential employer is most likely not. On the other hand it is very unlikely that you will find all the information you need on the companies career page.
This is why across the stages of your job search the goal should be to remove that asymmetry as much as possible. When you start looking for jobs, you typically have a public job posting and/or a career page of the company. I recommend to review as many postings and companies as possible and put them in a list. I personally like to use my to do app but you can use any format you like.
Next you can prioritize that list based on the information you have. You should not remove any items unless there is a complete mismatch. Keep in mind however, that most things are negotiable. If your salary expectations are not matched or you feel that you are not experienced enough do not worry. There is no perfect candidate and I recommend to apply nevertheless.
Note that you might have to read between the lines when looking at job descriptions. For me personally there are some red flags that I'm looking for, e.g.:
- missing description of what you will be doing
- phrases like "hard work will be rewarded" or talking about deadlines
- service / product does not match your values (e.g. working for a military company if you are a pacifist)
- poor reviews on Glassdoor, Kununu, etc.
- focus on specific frameworks / programming languages rather than concepts
After you have at least a couple of positions on the list your goal should be to gain more intel, especially on the topics that are not covered by the publicly available sources. The usual way to do that is to apply. Another way is to look at company reviews or find someone who works there and start networking.
As soon as you apply there are different stages you need to go through (depending on the hiring process) until you receive an offer. It usually starts with you expressing interest in the position by sending your CV and some form of cover letter or questionnaire. If you know someone in the company who can refer you, this will make it a lot easier to take the first hurdle. After that there can be one or many interviews, home work assignments, assessment centers, and so on.
The next sections are going to focus on those different formats and how to prepare for them.
Your cover letter and CV contain the first pieces of information that recruiters are going to look at. So you should put at least some effort in making it appealing.
The cover letter is a good place to express your interest in the position. You can emphasize your relevant background and describe why you want to work in this position.
The CV should contain contact information, professional experience, education, awards and certifications, and references such as blog posts, portfolios, open source contributions, publications. If you have the time, it makes sense to adjust the CV for each position, highlighting relevant experiences.
When stating your professional experience, focus on key achievements and describe what you accomplished rather than describing the project in general. Feel free to give prominence to key technologies and methodologies in each stage rather than a generic, disconnected, long list somewhere in your CV.
Software Engineer at Producto Inc.
2017 - 2020
I was part of the team that was responsible for the payment processing components, handling 10M requests per day. During that time I developed Spring Boot microservices using Kotlin and deployed them in AWS Fargate. I also architected and implemented a data pipeline using AWS S3, SQS, SNS, and Lambda.
Even if your CV is exceptional there is still a chance that your application will fall through the grid. Referrals are a good way to get past the first hurdle and they give you extra credit in the application process.
To get referred however, you have to know someone in the company. The more people you know, the higher the chances that you know someone at the company you want to apply to. Additionally you might get access to job listings before they are made public.
So how can you build your network? Unfortunately, it's not as easy as accepting LinkedIn requests from strangers. You will have to talk to people. Where do you find people to talk to? Well, you can start at your current job (if you have one). Talk to different people across the organization and build a relationship that lasts beyond your employment. You can also go to meetups, conferences, or engage in online communities.
There's one last advice I want to give before we are going to discuss the interview process. Apply anyway!
Even if you do not fulfil all the criteria, apply anyway! There is no perfect candidate so your goal should be to be the best option rather than the perfect option for the company. Even if it is not your dream job, apply anyway! You will get interviewing experience, get to know different companies, and maybe even have multiple offers which can be a good basis for your contract negotiation later on.
Interviews with hiring managers or recruiters focus on your personality and cultural addition to the company. Your potential employer probably wants to understand if you will fit into the team, how you approach conflicts, what motivates you, and so on.
It makes sense to prepare for those type of interviews by reading up on the company culture and strategy, maybe reading blog posts by the leadership team, listen to podcasts or checking out the YouTube channel.
Talking to your hiring manager is often the first opportunity to ask deeper questions: How do you measure success of the company / the team / individual team members? What are my future career options inside the company? If I want to work on something else within the company after three years, is that possible? What is the strategy to deal with competitor X?
If you passed this interview stage, you typically move to more technical interviews such as coding interviews, system design interviews, on-site interviews or assessment centers.
Coding interviews are an opportunity to demonstrate your analytical thinking and the ability to express your thoughts both in verbal language as well as code. These are important skills for any software engineer.
The best way to prepare for coding interviews is to practice. I recommend to pick a website like LeetCode where you can solve algorithmic and data structure problems of different skill levels using your preferred language.
You should pick a language that you are comfortable with and that you plan to use during the interviews and stick to it. When selecting problems, focus on the high quality ones. LeetCode has community ratings for each problem and you should only attempt the ones that have a high ratio of thumbs up votes.
Start with easy problems and solve them until you feel comfortable. Then move to medium problems and keep practicing until you are able to solve medium problems within 30 minutes. Feel free to attempt difficult problems as well, if you get bored by medium problems.
For each problem I recommend to submit the simplest solution you can come up with first. Do not try to make your code efficient in the beginning but aim for a working solution instead. This has two advantages during the interview. Firstly, you have a higher chance of getting a working submission within the time limit. Secondly, it opens up potential for discussion where you can show your understanding of trade-offs when it comes to algorithm design and code. I also recommend checking out my series on the RUM conjecture.
If you struggle with even arriving to a simple solution, try to divide the problem into smaller and smaller problems until each of them becomes trivial to solve. Or start by adding assumptions and removing them step by step. Take the FizzBuzz game for example. The goal is to count from 1 upwards but everytime a number is a multiple of 3, you say "Fizz" instead. If the number is a multiple of 5, you say "Buzz" instead. If the number is a multiple of 3 and 5, you say "FizzBuzz".
If you wanted to put that in code, you can start with a simple loop that prints all numbers. Then you figure out how to handle the "Fizz" case. Then you add the "Buzz" case. Then you take care of "FizzBuzz". While this may sound trivial to you for this simple problem, adopting this strategy for every problem you solve enables you to tackle even the hardest problems. That's actually how all hard problems are solved. Step by step.
During the interview it is important to engage with the interviewer. Make sure you understand the problem statement, asking for clarification if something is unclear to you. Think and express your thoughts, before you start writing code. Remember that the interviewer wants to understand how you think so being quiet for 20 minutes and then submitting a perfect solution does not necessarily get you far.
If you, as I suggested earlier, start with a simple solution, feel free to check in with the interviewer if what you are doing is sufficient. It might be useful to ask for quality requirements (performance, extensibility, security, etc.). This way you can discuss the trade-offs of your solution with respect to certain quality attributes that might be relevant.
- Interviewer (I): Design an algorithm to sort an array.
- Applicant (A): What are the requirements with respect to time and space? Do I have to sort in-place or can I use additional memory? Should the array be sorted descending or ascending?
- I: Try to use as few additional memory as possible. Please sort the numbers ascending.
- A: A naive implementation would be to repeatedly go through the array, comparing adjacent elements and swapping them accordingly, such that the smaller elements iteratively move to the front. This solution requires O(1) additional memory and has O(n²) time complexity. Should I implement that solution or would you like me to discuss alternative approaches first?
- I: That would work. Please go ahead and implement that and then we can discuss how we can improve.
If you completed your coding interview successfully, the next step might be an architecture / system design interview.
While the coding interview focuses more on writing a piece of code and reasoning about algorithms and data structures, the goal of the system design interview is to assess your ability to build software systems.
This includes but is of course not limited to
- understanding functional requirements and quality attributes,
- knowing the roles of different software components (front ends, back ends, data stores, etc.), protocols (DNS, TCP/IP, HTTP, etc.), and infrastructure (compute, storage, network) and how they play together,
- being aware of what service level indicators and service level objectives mean and what role they play when designing software systems and building a software organization,
- having techniques at your disposal to achieve certain quality attributes (availability, consistency, scalability, extensibility, etc.), such as sharding, fail-over, replication, load balancing, caching, synchronous vs asynchronous communication, encryption, API design, and so on.
It is certainly helpful to have some experience in designing, building, and operating software systems yourself. A good resource to get started or refresh your knowledge in the area is The System Design Primer by Donne Martin.
During the system design interview you can apply similar principles as in the coding interview. Engage with your interviewer, start with simple solutions and discuss trade-offs. You should be aware that there are no silver bullets and every architecture decision needs to be taken and viewed in context of the current environment and situation.
And just as in the coding interview it makes sense to understand the functional and quality requirements because they will have big influence on the optimal architecture. I am also a big fan of evolutionary architecture. Try not to think in terms of target architectures that are designed upfront on paper because the world is changing and your design should be able to evolve as well.
Here is a list of questions that you might encounter in your interview:
- Design a distributed key-value store.
- Design an image hosting service.
- Design a web crawler.
- Design a chat application.
If you are stuck, think about what those systems are supposed to do and what components you will need. Draw some boxes and connect them with lines and you are good to go! ;)
Assessment centers are sometimes used if there is a large group of applicants and the company wants to save time. Personally, I am not a fan of assessment centers as they can be very stressful and you feel watched and judged all the time even during the breaks.
They typically last one or two days and consist of different weighted exercises and breaks. However, the breaks are also part of the exercise as interviewers might engage with you on a personal level, which is why I find it so stressful. In order to prepare for an assessment center you can practice the following skills:
- Communication. Applicants will usually be asked to introduce themselves. If you can, come up with an introduction that is interesting to listen to and at the same time highlights your strengths. It is also common to give presentations, so be sure to practice your presentation skills.
- Ability to work under pressure. There are different exercises to test your stress resistance. You are typically asked to perform a set of tasks with a tight time constraint. You are forced to prioritize the tasks and also react to disruptions introduced by the interviewers. Feel free to ask if your daily job is going to look like this because it is, this might be a red flag.
- Teamwork. Group exercises are very common to test your ability to work in a team. There are different roles in each team and not everyone can be a leader. Be prepared to take on the work that nobody wants to do / is most important for the project success. This might mean doing dirty work or taking the lead of the group. Listen to your teammates and facilitate the discussion such that everyones opinion is being heard, resolving conflicts as they appear.
- Analytical thinking. This can be tested in many different ways ranging from individual exercises such as IQ tests all the way to group exercises. I personally find it not easy to practice though.
Of course those skills are important for many jobs and it makes sense to practice them even if you do not expect an assessment center. I recommend to practice in front of real people, e.g. family or friends, and record yourself. Then you can analyze the video later and improve based on that.
If you can, find some information about your interview partners. Is the person conducting the coding interview a big fan of TDD? You might want to write some tests or at least discuss how you would do it. Did the system design interview partner work on distributed databases? You might want to chat about that distributed systems research paper you recently read.
Keep calm. It's easier said than done but the more you practice, the calmer you will be. Apply to positions you are not so much interested in first so you can get some practice.
If you managed to pass all the interviews, the only thing left to do is to negotiate the contract. This typically includes your starting date, your compensation, location, restrictions around having a second job or not being allowed to switch to competitors, and so on.
The one topic that is probably most discussed is compensation. I could write a lot here about my successes and failures in contract negotation but I would not be able to give as good advice as How Not to Bomb Your Offer Negotiation by Haseeb Qureshi. I heavily recommend reading it.
When it comes to contracts and you are in doubt, you should consult a lawyer. Especially because what is legal or not heavily depends on the country you are working in.
As soon as you received one or multiple offers and decided to take one of them, you are done! Congratulations to your new job! If you have any advice or stories you would like to share, please leave a comment :)