navigate_next

Technical Interviews

How To Nail Your Next Technical Interview: The Ultimate Guide 🚀

Dragos Nedelcu

Senior Developer and Founder at theSeniorDev

Could you win a game if you don’t know the rules?

Probably not.

Sadly, most software developers today are trying just that.

Layoffs, recession, and inflation pushed many engineers back into the Technical Interview Game.

They have no choice but to play.

But most don’t even know its rules.

When they get rejected and ignored, they understand they are losing. But, they don’t understand WHY they are losing.

Or what it takes to win.

By winning I mean landing that high-paying developer job you've been looking for ever since you started coding.

I mean not worrying about mortgage payments anymore.

Or the kids' tuition.

At the same time, getting a developer job became a lot harder.

Layoffs, recession, remote work, and AI have flipped the power in the job market, from developers to companies. The days of knowing a bit of React and getting hired are gone.

Every developer job now has hundreds if not thousands of candidates waiting at the door.

You have no other choice but to stand out.

And you have to be very effective at doing technical interviews because the margin for error is small. With fewer opportunities coming by, you better nail the ones you’ve got.

If you are looking or planning to look for a developer job soon, keep on reading.

Today, we will dissect the Technical Interview Process.

You will find out the mistakes to avoid so you minimize rejections. And what it takes for you to succeed at each step of the technical interview process.

So you land that high-paying developer job you’ve been dreaming of.

Let’s go!

We will start by looking at the stages of a typical technical interview process. Sure, different companies have different processes but in most cases, they will look something like this:

the-technica-interview-for-developers — Most Technical Interviews will have the same stages with small variations.

Let's start with the first step.

That is getting technical interviews in the first place…

1. Getting Interviews

The interview process doesn’t start when you get a phone call from a recruiter. It starts the moment you apply for a job or the moment someone sees your CV or LinkedIn profile.

Technical Interview Steps - 1. Applying to jobs — It all starts with a job application.

That first impression of your CV will not only determine if you move on to the technical interview.

But also what kind of offer you will get if you pass the interview. And even then the number of technical interviews you need to go through to get there.

The more red flags in your CV, the more interviews to make sure you are a fit.

On top of that, the developer job market is right now oversaturated with talent. Balme layoffs, recession, and economic conditions. But competition is cut-throat.

You have to do everything you possibly can to stand out.

These days dozens of developers come into calls and tell me they can’t even get invitations to interviews. I always tell them it is probably their CV. Or their LinkedIn profile.

Building a great CV is not the point of this article, but I will give you some hints.

You are allowed to oversell a bit in your CV. The market is tough. You have to stand out. But don’t be like this guy.

Shallow work experience, that only talks about technical skills and doesn’t underline the impact you had over the company will get you rejected.

Employment gaps will get you rejected.

Side projects or experiences that look Junior will get you rejected.

Fancy formatting, cool design, or buzzwords with no real evidence of expertise will also get you rejected. CVs written by ChatGPT with lengthy paragraphs that say nothing will get you rejected.

The good news is that if you stay away from common “red flags” and apply to jobs that match your CV, you will do okay for the most part.

If you want to know more about how to build a top-notch developer CV, watch this YouTube video where I go much more in-depth about everything.

Regarding your LinkedIn profile, it should mostly be a copy-paste from your CV with some additional tweaks (skills, endorsements & recommendations).

Jokes aside, endorsements help you stand out in searches. Is fine to talk to some of your developer friends and endorse each other as long as you work on your skills.

For now, I will assume you have a top-notch CV and LinkedIn profile so a few companies have contacted you willing to proceed.

🚀 Want to find out your technical gaps as a JavaScript Developer? Take this FREE Technical Assessment to find out what you need to focus on to get to Senior and beyond. 🚀

2.1 The Screening Call (First Interview)

developer screening call — The second step of the technical interview for a developer is the screening call.

This is where a recruiter from the company will call you on the phone. They will be asking you a bunch of standard questions about yourself and your CV.

Depending on your answers you will move to the technical interview or not.

What most developers don’t get right here, is that, during the screening call recruiters are not looking for a reason to move you forward.

They are looking for reasons NOT to give you the technical interview.

The screening call is a disqualification process.

I bet most recruiters are not that evil. Just doing their job. Give them a resume they will actually keep.

If you don’t sound like a match, recruiters will end the call quickly and move on with the next candidate. They have hundreds of them in the pipeline.

Look at it from the company's perspective. If you won’t be a fit, why waste precious time that they could invest in other candidates?

Hiring stats from a famous startup. See how most Developers don’t even get a first interview. From the ones that do, few move on to the technical interview.

So if you went through step 1 correctly and your CV and LinkedIn are solid, you don’t have to worry too much. You will only need to have a solid story to back that up.

Have A Solid Story For Your CV

The second tip here is to prepare and write down the most common screening call questions.

Don’t bet on improvisation and script them. The more you improvise during the call, the higher the chances you will screw up.

“Tell me about yourself” is one of the most asked questions in screening calls and first interviews. Make sure you prepare.

Remember, recruiters here are not looking for a reason to move you forward, they are looking for a reason NOT to do it. Don’t give them one.

To help you out, here are the top 5 questions you should have prepared:

Tell me a bit about yourself.
Why is there a gap in your CV?
Why are you leaving your current job?
Are you currently interviewing with other companies?
What are your salary expectations?

Answer these questions and write them down before your first screening call. You can use ChatGPT but I don’t recommend it. Practice the answers in the mirror a few times until they come off naturally.

Stating Your Salary Expectations

A crucial point you need to prepare for during screening calls is the salary expectations question. It will usually pop up at the end of the call.

Most developers either lack confidence when stating their range. Or they go over the top coming across as greedy and making themselves unhirable.

State your range with full confidence.

But, at the same time keep an open mind and see what they have to offer.

Don’t know what number you should ask for? Do a bit of research.

Most developers undersell themselves here. I would say a good range is usually 10 to 20 thousand on top of what you think you deserve, depending on the market you are in.

I wish stating salary expectations as a developer was that easy.

Also, ignore the old advice about not giving a number first.

Most recruiters know this trick and they will push you until they get a number. If you don’t give one they might end the interview and proceed with other candidates.

The reason why most developers don’t want to give a number is because they think it will limit their ability to negotiate later on. This is not true.

You can give a number and still negotiate when you get to the offer phase.

Once the company realises you fit, they will be a lot more open to talk about money. So don’t obsess about numbers at this point.

Give a range that leaves both you and the company some space for negotiation.

Avoid Getting Ghosted Or Ignored

The best way to make sure they will come back to you after an interview is to check for commitment at the end of the call.

When they ask you “Do you have any questions?” say “Yes” and ask them when they are going to get back to you.

Get people to commit to getting back to you. Without being as mean as Walter White.

If they say, end of the week or something longer than in the next 3 to 4 days, bad news. You might want to check out mentally of this process.

The call most likely didn’t go very well.

You can still probe further.

Simply say “Cool, is there any chance you can get back to me before that?”. This will push them a bit and see where they stand. I leave it up to you how persistent you want to be.

Even if you push them, try to sound as cheerful and friendly as possible. It will disarm any misunderstandings.

The main point is don’t hang up the call and hope they will get back to you.

Because they probably won’t.

Hope is not a strategy. Get them to commit instead.

Senior Dev Tip: Technical questions might appear in the Screening Call. But they are usually high-level or frameworks-specific so don’t worry too much about them. You should be able to navigate them with relative ease.

Senior Dev Tip: If you are speaking on the phone, check your tone, intonation, and pronunciation. You want to sound upbeat and excited, the kind of developer they would love to work with. So if you had a hard day, take 2 minutes before the call to pump yourself up. Listen to your favorite song or take a few deep breaths. It will help you ton.

Senior Dev Tip: Different types of recruiters have different goals. Prioritise internal recruiters, those that work for the company they are hiring for. External ones are consultants looking to place you. They sell developers to the highest bidder. Most times, these recruiters are just shopping around for candidates without a clear opportunity. They will waste your time.

Now that you have passed the screening call, you are ready to move on with the technical part of the interview…

2.2. Optional: Hiring Manager Interview

Depending on the company, there might be one extra step before you get to the technical interview. The HR interview that can come up after the screening call is optional.

You can think of it as a more in-depth Screening Call.

Here, the hiring manager or the engineering manager will try to break your CV. Be prepared for them to dig even deeper. Be prepared for some technical questions as well.

You might be asked questions about the frameworks you use and how they work. Something like “How do React hooks work?” in the case of a front-end developer.

Or if we are talking about a Senior developer interview, you might face questions about web performance or Microservices.

Again, don’t worry too much as the technical questions here will be high-level, but be prepared.

3. The Technical Interview

technical interview for developers by theSeniorDev

Now that you passed the screening call, comes the technical interview. Different companies have different processes, but they are usually made of the same basic steps.

This is where the real battle will be fought. Expect it to be hard, but not impossible.

‍

Funny because it's true. Image Credit: the Internet.

The order might be different but here are the major types of technical interviews:

The Take-Home Challenge
The Automated Coding Interview
The Live Coding Interview
The System Design Interview

Let’s go through them one by one…

3.1. The Take Home Challenge

One of the most common technical interview types. You will be sent a bunch of requirements and will be required to code something to fulfill them.

In the front end, this will usually be a small front-end application. In the backend, it can be a simple REST API. Different companies have different processes.

Your #1 goal with Take-Home Challenges is to deliver the maximum quality in the minimum amount of time possible.

This is not easy as you don’t want to deliver bad code.

But, at the same time, you don’t want to invest too much time in one company.

When you get a Take Home Challenge don't be like Jime Carey and start coding right away.

Because no matter how good of a take-home challenge you make, there is no guarantee you will get to the next interview stage. Aim to strike the perfect balance between quality and speed.

Follow this checklist to make sure you deliver a great take-home challenge and get invited to the next interview.

3.1.1 Before you start building the take-home challenge

a. Make sure you understand the requirements fully.

If you don’t understand what they ask for, don’t assume something else and go build it. Stop.

Write an email to the recruiter and ask for clarification. This shows you take your time and think before you code.

A Senior Developer trait.

Ask clarifying questions and you will be safe from hearing something like “ohh we wanted something else” after you send your code over.

b. Make sure you get enough time to deliver something good.

The reality of take-home challenges is that a lot of companies will not respect your time. They will send you an assignment and expect the result 3 days later.

If you are employed or interviewing with other companies (which you should) such a tight deadline will put pressure on you and burn you out.

Don’t go ahead and code straight ahead. Negotiate.

Answer back, telling them that you can't deliver something in such a short time. Give an alternative and don’t start coding until they commit to it.

3.1.2 While building the take-home challenge

a. Leverage Boilerplate code strategically.

Don’t shy away from using pre-made repositories to go faster. If it is a React app, use Create React App, if it is a backend there are plenty of ready-made Node.js APIs.

Be careful and don’t pick complex boilerplate code that needs too many modifications to adapt it to the use case you need. You will end up losing more time than if you started from scratch.

b. Use ChatGPT and GitHub Copilot.

Sometimes feeding the requirements straight into ChatGPT and giving it a few instructions will be enough. Use it as it will make you much much faster.

3.1.3 After you built the take-home challenge

Check that you’ve met ALL the basic requirements mentioned in the take home challenge. Do a quality assurance session.

You can use the following checklist:

README
1. Does the project have a clear README?
2. With clear instructions on how to run the project?
3. With further improvements (what would you do if you had more time?)
Testing
1. You should include at least one test at every level
  1. Unit Test
  2. Integration Test
  3. Optional: end-to-end Test
2. Use ChatGPT and Copilot to go much faster here
Deployment
1. Deploy your project to a free provider like Netlify - you will not only stand out by showing the result and detecting possible errors.
Performance
1. Make a quick performance test to show you care more about than just delivering the feature.
2. In the Front End use a tool like Lighthouse.
3. In the backend, you can use something like ApacheBench.
Presentation
1. Despite what you heard, developers don’t lie to read code. Get their attention by showing the end result first. Make a quick video with Loom walking through what you’ve built.
2. Explain how it works, show the main features, and then get into the code. Keep it light but show as much as you can.

As you can see this is a lot of work to do in only 10 to 15 hours. And if you are employed full-time, you might have even less time.

And with all this trouble you might still not get the job.

This is why, despite everything you’ve been told, take-home challenges are the worst kind of technical interviews for developers from a power-dynamic point of view.

To find out how to avoid companies ghosting you after sending the code challenge, keep on reading.

You are working for free, and have no power over the outcome which depends entirely on the company. Or worse, on luck.

Bonus: Manage Your Expectations

With take-home challenges, you can still do all the right steps and still fail.

That's why you want to do as many challenges as you can and as fast as you can. So you don’t put all your eggs in one basket.

Follow the shoot-and-forget principle. Once you send your code over, forget about it. Apply to jobs, do other interviews, and get busy.

Bonus: How To Deal With Feedback

You can deliver the cleanest code known to humankind and still get feedback like “You missed optimising for performance and you didn't add Redux for state management”.

When in fact Redux was not mentioned in the requirements and you did add it to the list of “things to do if I had more time” in your README.

But they didn’t look.

Or maybe they didn't care anyway.

They just had to come up with “feedback” so they could defend themselves against negative reviews… Maybe they found someone better and are trying to get rid of you.

Maybe they forgot.

Developers think that because they spent hours building something, the company will reciprocate with the same level of commitment.

In most cases, a random developer will take a few seconds to check your code.

If they see something they don’t understand or feel something is missing, they will discard it without thinking twice.

So when you get feedback after a take home challenge you have two choices:

1. Ignore it and move on - the best way to conserve your energy.

2. Argue against it - this rarely works as companies will most likely entrench in their decision even harder. Most times it will backfire.

My advice?

Don’t argue with them and move on to the next company. Life is too short.

Do your best, yet be willing to walk away to the next opportunity if things don't work.

Senior Dev Tip: Before you commit to a code challenge, demand a review from them. Ask for commitment before you start working. If you are going to commit to delivering, they should at least commit to a fair review.

Senior Dev Tip: Develop a Stoic Mindset when interviewing. Let go of any expectations and attachment to the outcome. Do your best and move on quickly. There are plenty of companies out there willing to hire great developers like you.

Bonus: The truth about Take-Home Challenges

Because of the above reasons, take-home challenges are one of the worst interviews you can invest your time into.

I know you might think they are awesome because you hate live coding. And because you can do them from the comfort of your home at your own pace. With your own VS Code setup.

But, on the other hand, when you do take home challenges, you have absolutely no power.

‍You work for free on a project that can go nowhere.

For starters, your code gets reviewed and you are not in the room to explain your choices. Which is extremely unfair. This would rarely happen at work for example.

On top of that, no matter how much of a good take-home assignment you build, you have no guarantee that the company will come back to you with an answer. Or with feedback.

This is why, at theSeniorDev, we advise the developers we mentor to stay away from take-home challenges and get as good as they can at live coding interviews.

Senior Dev Tip: Depending on the number of interviews you are doing at the moment you might not want to do the take-home challenge at all. Or you might want to negotiate a compromise with the company.

Senior Dev Tip: If you sent a take-home challenge over and got no feedback, make sure you follow up after 3 or 4 days. Send a small email asking for updates. Keep it simple and leave formality at the door. You put a lot of effort into the challenge, you deserve an answer.

3.2 The Automated Coding Interview

The Automated Coding Interview is very similar to the live coding interview.

The difference is no one will be watching you. You will be invited to a platform like HackerRank where you will have access to a time-bounded algorithmic problem.

The good news is these interviews are less stressful as nobody is watching you.

The bad news is that the clock is still ticking. Most tools will also track your mouse, and desktop screen and won't allow you to copy and paste.

So what can you do to pass the automated coding interview?

Spending hours on Leetcode?

It works but getting good through trial and error will take you at least 6 to 12 months. Most developers don’t have that kind of time when it comes to finding a new job.

So, how do you get better?

First, understand that live coding interviews, automated or not, are a game of probability. It is not about passing them or not, it is about how close you get to the solution.

You will never pass every single code interview and if you do it is because you over invested in those skills and neglected others.

On top of that, I know developers who are top 1% on Leetcode and still can’t get a job. Because they lack the System Design skills or they can’t sell themselves effectively.

Sad but true. No matter how good you are at crunching Algo problems, it won’t get you the job.

As a Senior Developer, you should aim to pass around 80% of the live coding interviews coming your way and forget the 20% left.

So what can you do to get better at passing live coding interviews?

Step-by-step Instructions:

Number 1 - Get insanely good at breaking down logical real-life problems into control flow structures (like for and while loops). You should be a master at writing pseudo code and touch type to at least 60 wpm. If you are not there, start now.

Number 2 - Master fundamental algorithmic patterns. You should understand recursion and how to think recursively. How a queue and a stack work. And how to translate “while” and “for” loops to recursive functions (and back and forth, see number 1).

Number 3 - Get familiar with the Web API. There are certain patterns that we see always in job interviews like using the Promise Constructor, understanding how Timer Functions work (setTimeout), and how they interact with the Call Stack. And knowing certain Array methods (map, reduce, forEach… you must be able to write those on top of your head).

Senior Dev Tip: You should know basic sorting algorithms like Binary Search and Frequency Sort. They will come in very handy in any algorithmic interview.

Senior Dev Tip: You should be able to touch type and write “for” and “while” loops with the speed of light. Just joking, but it helps.

3.3 The Live Coding Interview

This one is very similar to the Automated Coding Interview, with the difference that someone will be in the room looking at you as you code and asking questions.

During live coding, most developers get nervous and mess it up.

Again, funny because it is true. Image Credit Reddit.

The main thing you can do to succeed in live coding interviews is to change your mindset. Aim to have the same attitude as when you are pair programming a close friend.

You are both as chill as possible, collaborating, focused on fixing the problem, and communicating all the time.

Step-by-step Instructions For Live Coding Interviews

Number 1. Think out loud

Make your intentions clear. “So if I get this right, I will try to solve it like this. So I am to implement a nested loop and see where we get from there.”

Be prepared for dismissive, passive-aggressive, competitive, and demotivated interviewees.

Don’t let their emotions mess up with yours. Focus on the problem at hand and stay professional at all times. Expect things to go wrong and stay cool regardless.

Number 2. Performance Talk

Here is where Big O notation comes into play. No need to be an expert but be able to estimate the performance of a recursion call or a pair of nested loops.

Senior Dev Tip: take your time. Don’t jump into the code. Don’t rush to the solution. Breathe and let your brain do the work step by step.

3.4. The System Design Interview

The System Design Interview is one of the hardest interviews because it is a measure of your technical breadth as an engineer but also your technical depth.

But, how can you pass it if you don’t have 20 years of experience writing code?

Simple. Play at home.

You lead the System Design interview to the part of the stack you are most comfortable with. This means you should propose the next step and align it with what you know.

Collaborate with the interviewer but drive the discussion to where you can excel.

For example, if you are talking about Microservices and are good at Database Design, send hints in that direction “So, do you want to talk more about the database now?”

The biggest pitfalls here are:

1. Running out of things to say

2. Being passive, only answering questions, not asking

You can deal with both if you stay focused on the problem at hand and try to relate it with what you know as much as you can, instead of pretending you know things you don’t.

2.4.1 System Design In the Backend

In the backend, it will most likely start with the Fundamentals, which will probably be REST APIS. Then you move on to Authentication and Microservices.

And then depending on how deep you can get, you go into topics like Load Balancing, Caching, Autoscaling, and Service discovery. Here is where they will grade how Senior you are.

Here it is important to always take into account the complete software lifecycle. That means deployment, logging, and monitoring.

A developer that will mention things like SLA and SLI will for sure stand out here. This is very deep. If you want me to write a full article about this, let me know in the comments.

2.4.2 System Design in the Frontend

In the front end, the System Design Interview will most likely focus on a piece of complex UI.

Like a social media newsfeed (for example: build Instagram).

Or a complex form with client-side validation.

The key here is to be able to break down complex requirements into a UI (wire framing) and understand common UI/UX patterns like pagination or infinite scroll. Topics like state management in a huge application, or how client-side routing works will come in handy as well.

The biggest difference between a Senior and a Mid/Junior Engineer here will be the Scalability and Web Performance discussion.

A Senior Developer will be able to dive deep into topics like lazy loading, code splitting, optimistic UI, and scalability strategies like using a CDN, caching, or server-side rendering.

Seniors understand topics like polyfilling, tree shaking, and content negotiation and they can put them all together into a coherent story about how the System will look like.

As side topics, make sure you look into “How to Build a Design System '', managing CSS as scale, think BEM or CSS in JS. Now that you are there, take a look at Monorepos as well.

Does it look like a lot?

It is.

Keep in mind this article is about how to nail the Technical Interview up to the Senior level. The interviews you will do in real life might be as hard or a bit harder than this if you are lucky. Either way, preparation is key.

A Senior Developer I worked with used to say, only the paranoid survive. True during layoffs and true during a job interview (I would replace paranoid by well prepared though).

Senior Dev Tip: Even if it is a Senior-level interview, you can expect interview questions about fundamental JavaScript, such as “How does the Event Loop work under the hood?” or, “Can you tell me what happens to TypeScript code when it is transpiled? What gets shipped to the browser?” Make sure you prepare them.

Senior Dev Tip (Frontend): Do understand the basics and best practices when it comes to accessibility. It is one of the most underlooked topics by developers but you should expect a question in at least 70% of the interview.

Also, make sure you check out Semantic HTML, how to include Accessibility in your dev tools (ESLint Plugins), and what things like “area-label” are. These are the kind of details that will make you stand out from the mass of coders.

Congratulations!

If you made it this far, you passed the hardest part of the technical interview and you are ahead of 99% of your competition.

Let’s make sure you don’t screw it up before the finish like like this fella:

4. Optional: Another HR Interview

Image description — The Hiring Manager Interview is usually a chat with an Engineering Manager or Tech Lead.

This is simply an extension of the Hiring Manager Interview but with a strong focus on behavioural questions. To put it simply, they want to know that you can work well in a team.

That you can face and solve conflicts productively (more on that later) and that you can prove and demonstrate a go-getter attitude.

Companies are biased toward hiring people with the right attitude.

That is a mix of positivity, professionalism, and proactivity. They will ask you questions like “Tell me about a time when you had a conflict in your dev team and how did you go about it?” or “Tell me about a project that you are most proud of?”.

Or, my favourite, “Tell me about one of your biggest failures or a project that failed.”

It is important here that you stay positive and professional, but at the same time tell real stories that people can relate to. If you have no stories or you improvise you will come across as inexperienced, or worse, unprepared.

If you sugarcoat it too much it will sound fake.

If you script them too much you will sound like a robot and there is already ChatGPT for that. So try to do your best with the storytelling but keep it real.

5. The Culture Fit Interview

If you get here, you are doing great. The company is confident in your technical skills. Now they want to make sure you will fit into the company and the team.

To nail this interview you need to show 2 things:

Overall Professionalism
Excitement about the company

This interview might feel cheesy and unnecessary, but is part of the process.

Jokes aside, let’s dive deep into these two traits and how you can display them during the interview:

1. Professionalism

You want to show that you have good conduct and can handle difficult situations. Trust me, there will be many as building software is a very messy process.

How do you handle conflict? How do you take feedback? Are you a good team player? If so, what’s the last thing you did for your team to help them achieve their goals?

In this interview, words are worth nothing.

As always, it is all about proof.

To nail the culture fit interview, use stories from your past experiences. Talk about the situation, the action you took, and the result. Use the STAR format. Feel free to Google it if you don’t know what it is.

Don’t memorise but do write down the answers before the interview.

This is one place where you can use ChatGPT to help you out. Don’t worry if the answer sounds a bit cheesy or robotic, as long as you can make a point is okay.

Remember, you are a software engineer, not a literature major.

Here are the top 3 questions for you to prepare:

How do you handle disagreements? For example in a code review.
Tell me about a time when you identified a critical bug in the codebase... How did you go about it?
Give me an example of when you missed an important deadline… What have you done about it and how did it go?

2. Interest and excitement

This means you are enthusiastic about joining the company. You should be. If you have to fake it, go find another company that will get you excited. Life is too short.

Being excited doesn't mean you are their biggest fan. It means that you understand their mission, vision, and values. And you want to help them make that vision a reality.

Before the culture fit interview:

Check the company’s mission and vision statement
Think about how you could help them advance that

Now that you have your STAR format questions prepared and you know the values and the mission of the company you are more prepared than 99% of developers out there.

One last thing, before jumping into the call, make sure you are in a good mood.

Play some funny videos on YouTube or listen to your favourite song. Emotions are contagious. And people gravitate towards good emotions. So get yourself in a great mood before you jump into the interview.

Senior Dev Tip: Listen more than you talk. Remember, it is about them, not about you. Ask questions about the vision and mission. Ask them what’s their biggest challenge right now. Ask why. Simply show you care and the job will be yours in no time.

Senior Dev Tip: You might think, what a bunch of corporate BS this is. Why do I have to “fake” all this stuff? I just want to open my editor and write some code. Well, it is what it is and you have to deal with it. And yes, some of these interviews will sound like plain corporate politics and propaganda. Is not good, is not bad, it is what it is. You need the job, so just do it.

6. Offer Negotiation

Okay, so you passed all the previous stages and you’ve got a magic email from the company saying that they would like to extend you an offer.

They might invite you to a Zoom or a telephone call to tell you about it.

If you jump on a call, always opt for a phone call. Or a Zoom call without video.

Okay, you might not want to be that direct, but you’ve got the message.

Audio-only calls put a lot less pressure on you. You can also make longer pauses to think and take notes. (if they push you, just say you are on the go and can’t do video at the moment).

Two Objectives During Offer Negotiation

Listen to what they have to offer - Take notes. Ask questions if something is not clear.
See if what they offer you is the best they can do - Say something like: “Hey, great offer. Is this the best you can do on the base compensation side? Or is there some margin?”

Policy: Never commit during a call

Even if you love the offer, the best is not to commit right now. No matter how hard they push. Just say you took notes of everything and need to think about it and come back to them.

They might try to push you and see if this is good enough.

Tell the truth.

If you like the offer and find it attractive, tell them, yes it is a very solid offer.

If not, tell them it is a solid offer, but you feel like [insert your number] would be a bit more competitive in the current market.

Work with the recruiter, state your wishes and see if they can do anything about it.

Things to negotiate for as a developer ranked by importance:

Total Cash Compensation - push up on this one as much as you can. .
Bonus - signup bonus, yearly bonus, whatever. It is free cash.
Remote Work - go for fully remote or as many remote days as you can..
Vacation Days - paid time off, highly valuable as well.
Learning Budget - make sure you get a commitment on this one, written if possible.
Equity and Stock options - can’t pay mortgage with these ones, but they help.

Senior Dev Tip: they might try to talk about benefits, tangible or intangible. Like a learning budget or the chance to work with new technologies. Take note, but don’t get distracted. Move the conversation back to the cash compensation which is the most important.

This is not a deep dive into developer salaries and compensation, but let’s say the most valuable things are things you turn into cash quickly.

Like cash itself, bonuses, or a learning budget. Holidays are great as well as they have a direct impact on your health and time with your loved ones.

You can’t pay your mortgage with stock options. The likelihood of those options becoming real cash is low, and you always have the vesting period.

Games companies play at the offer stage:

Giving you “feedback” before they make the offer
Mentioning other very strong candidates
Talking about “budget” limits

The truth is, no matter what they say, if you get here, the power is in your hands.

If you have another company extending you an offer, that is even more true. So don’t give in. Try to push them. Don’t be mean, but don’t be nice either.

This is it.

Now that you understand the rules of the technical interview game, you can adjust your strategy and actions and have the best chance to win. To get the kind of offer you deserve.

One last word…

I know you might be thinking this is too much work.

I agree.

Technical Interviews are a lot of work. However, being able to pass technical interviews is a highly paid skill.

It will give you access to a lifetime of financial stability, allow you to switch jobs freely without the fear of not finding something better, and get you a job you love.

Getting good at passing technical interviews is hard. But it is worth it.

I wish you the best of success in your next interview.

Take care,

Dragos

arrow_back

Back to blog