Navigating "senior+" job interviews
I recently did a round of job interviews. I'm on the top end of the Senior Software Engineer band, and I was looking for other "top of senior" or Staff Software Engineer roles. At the end of the interview process I had two job offers, although I believe I could have had more if I was more focussed on interviews after I already had those two offers and if I had more time. The interview process is sometimes difficult to navigate and it definitely took me some time to get right.
Because of this, I wanted to share my experience with people who are curious as to what interviews for Senior Software Engineer (or above) positions look like, or what those roles require from candidates.
A few stipulations/disclaimers before I get to it:
- This is based on my experience in London (UK). Salaries and job titles vary per company and per location.
- I can't promise any particular results in terms of job offers due to reading this blog post.
- This is my opinion, and not the opinion of my employer. This is based on my interview experience and does not necessarily reflect my current role or compensation.
- YMMV.
Pieces of the Puzzle
Ok then, let's get to it!
The job interview process typically consists of several different stages. Some companies will have multiple interviews across multiple days, while some while 'compress' it into a shorter process. Even if the process itself is across fewer days, the actual stages involved have been the same in my experience. These stages are as following (not necessarily in this order):
- CV/Apply to the role
- Initial call with a recruiter
- Introduction with the hiring manager (this part may be skipped or done as part of another call)
- Coding test
- Architecture/Systems design test
- Situational (STAR) interview
- Final stage/Values interview
I will break down these steps in this blog post, and try to explain what kind of skills are desired in those steps from senior engineers.
CV & Application
Writing a CV is probably a whole art on its own, and I'm probably not best placed to say what makes a great CV or not, but I can say what has worked for me. By the way, here is mine if you want some inspiration.
Intro
Put a short paragraph at the top introducing yourself, what you bring to the table, and what you want from your next role. This is mine:
I am a senior software engineer with 8 years of experience. I am skilled in designing reliable and performant systems, integrating with third parties, and building solutions from the ground up. In my next role, I am looking for a role that will allow me to grow into a Staff Engineer or Architect position.
💡Take a look at the "Elevator pitch" section later in this blog post as a lot of the same rules for that apply here.
Experience
Add your experience to your CV. Usually this is in order of recency, but if a past role is more relevant to what you are applying for, you could bend the rules and go order of relevance.
People like to see impact and results for more senior roles. Speak about projects you've led, initiatives you've taken, and the impact you've had to the company. Did your work make some part of the application faster? Did it result in your company passing a pentest? Did it result in 10 new clients signing up? If you're not sure, this is the time to speak to your PM and figure out! They certainly have (or should have) some way of monitoring the impact of the features you're building.
Education history: To include or not?
Don't get too hang up on your education history. After my first couple of jobs, nobody has asked me about it. I've actually completely removed it from my CV to save space and I haven't noticed any adverse effects from doing so. I actually believe that in some circumstances, including it could be more of a disservice, but that's just an opinion and perhaps something for a different blog post
Talks/Contributions
Speak about things outside of work! For example, I include my talks in my CV. I should actually probably make them more prominent.
Talks, open source contributions, blog posts, are all things you can show your prospective employer to show that you know what you're talking about.
Contrary to popular belief, you don't have to be a very active open source contributor or have no other hobbies outside of coding to get a job - but any public work that you can show is a chance to show off your skills. You can't bring them into your workplace and show them how good you are, so this is the next best thing. Give yourself credit for things you've done that are public and you can display - a lot more things than "active React contributor" are valid here.
You definitely don't have to go out of your way to create out-of-work material to show, just think about things you've already done at the course of your career. Even if you don't have an active Github profile (I don't!), don't sell yourself short, there are other things you may be able to display.
Recruiter/Hiring manager introduction
Whether your introduction call is with the recruiter, the hiring manager, or both, the structure is pretty similar. This stage and the final stage are actually the easiest. Some mild preparation is required, but if you have done a good number of job interviews before, you will be able to do this with your eyes closed.
The questions here usually fall into the following categories:
- Who are you?
- What can you offer to the company? Why are you a good fit to this particular role?
- What can the company offer to you?
Do some cursory research on the company here. Good hiring managers and recruiters will explain the company's industry and mission to you in this stage anyway, but it never hurts if you already know something about the company. Be yourself, and show interest. If something catches your eye on the company's website or social media, don't forget to bring it up - this shows you are interested and observant.
I also recommend thinking about why the particular role or company is a good fit based on your previous experience. This may not be asked in much detail at this stage, but it will be a good weapon in your arsenal for the next stages. Remember that as you go into more senior roles, the job is less about your ability to code and finish tickets, and more about the big picture/higher level stuff: systems design, collaboration with other people, making decisions. For example, maybe you don't have experience across the whole of the company's stack, but you have lead projects and mentored engineers in your previous couple of jobs - this is a good thing to talk about when introducing yourself.
Finally, what can the company offer to you? This one goes both ways. They will almost certainly ask about the kind of compensation you are looking for. I recommend asking for their salary range and deciding whether or not that is within your desired salary. Do not give them your current salary and do not give a specific number that you're looking for. Just ask for the range and tell them if that range is appropriate for you. The other part of this question, is actually the questions you ask the company. Write down some questions in advance and ask them when they allow you to (typically towards the end of the interview). These questions should help you decide whether the company would be a good fit and offer what you need - career progression, learning opportunities, company growth/funding stage are all very good questions to ask here.
The elevator pitch
Definitely prepare an "elevator pitch" for yourself before going into the intro call; I can guarantee the first question you are going to be asked at every stage is "tell me about yourself". This is a 60 second question and the beauty of it is that you can recycle it for every stage and sometimes even for different companies. I usually structure mine like this:
- What is my current job title?
- What kind of responsibilities have I had at my job?
- What am I looking for in my next role?
This gives the interviewer a good picture of who you are and why you've applied to this job. Bringing it all together, here's mine:
My name is Erry. I am currently a Senior Software Engineer at Monsters, Inc. As part of my role, I'm leading the identity services team and in particular the Single Sign On project. In my next role, I am looking for a job that will allow me to grow into a Staff Software Engineer or Architect position.
Short, concise, and gets the point across. You really don't have to overthink this one, but you do have to be prepared for it.
Coding test
Congratulations, you've officially got your spot in the pipeline! Now it's all about proving that you can do the job.
The coding test is the hardest to talk about, because every company does it their own way. Some companies do a pair programming exercise, some companies give you a timed task to complete, and some others give you a prompt with a task to return to them.
You may or may not know what the exact exercise will be before that time, so it's hard to know exactly what to prepare.
I recommend using the previous stage(s) of the interview to really understand the company and some of the problems they may have, and try to get an idea of the kind of problem they may face day-to-day. However, the problem in the coding test may not necessarily be connected to the company's actual problems.
I'm not going to go into leetcode or CS algorithm questions because I've not done a CS degree (my degree was called "web development" and had a lot of practical PHP/Javascript projects rather than traditional CS theory) and I don't use these algorithms for my job. If the company you're applying to wants you to solve a CS algorithm problem, then all you can do is study and practice (and ask yourself whether you want to be engaging with companies that have such hiring questions to begin with).
However, most coding tests I've taken have been more practical day-to-day problems that can be solved without memorising algorithms or theory. In that case, this is what you should focus on your test, whether it's a live test or a test you're doing at home:
- Are you following best practices for your job?
- Are there things you would be doing if you had more time (for example better/more tests)?
- What is the performance of your code like? This can be things like "big O notation" but recognising things like how long database queries take
- How would you "scale up" your code? Could it handle 100k users? 1 million users?
- How do you interact with the team if you're doing a pair programming exercise? Are you asking them questions? Are you using them as a resource?
Architecture test
This is similar to the coding test in that you don't know what you're getting until you get there. Usually this is done live, with a person at the other end giving you the prompt and being there to chat you through the idea. In the good old days of in-office interviews, this would probably be done on a whiteboard.
My one recommendation here is: study and practice.
Here are things to focus on while preparing:
- Go back to the questions you hopefully asked in the previous stages about the company. What kind of problems could they be facing? If you can use their product (app/website) this is a great time to use that to your advantage: pick some of the problems they are solving with their product and think about how you would design those features. Even if their product is not public facing, it's worth asking if you can get an account to try the product out - sometimes interviewers can arrange for that, and it gives you bonus gold stars for caring about the product!
- Don't just talk about how you're solving the problem, but also why you're solving it that way. Expect every decision you take to be put under the microscope and have to be justified. Sometimes there is no right or wrong answer, and you just have to be able to explain why you took your decisions.
- Ask your interviewer if there are any limitations or functional requirements for your architecture. Sometimes you have pretty much free rein in your design, and sometimes they will tell you that you have to function within the AWS ecosystem and use a particular database system, for example.
- Communicate things that you would normally do if you had more than one hour to do your design. For example: "this is when I would normally do cost analysis".
- Be ready to go for the simplest solution first, but always keep the question of "how would I improve this" at the back of your mind, because that question will almost certainly be asked.
- Think about the performance and security factors of everything you are designing. Even if you don't work with a very highly scalable system, this is a good time to read up on design principles such as domain driven design, CQRS, and distributed/event driven systems.
My honest view here is that you are most likely going to fail the first few architecture interviews you do. Keep a note for what they ask for, and think about how you can prepare in the future. Maybe spend some time designing diagrams as practice for your next interviews. Think about your current job and how you would re-design the architecture of a particular feature if you were starting over. Keep a list of all the things you could not answer, and don't be afraid to ask for their feedback after the interview. All of this will help you get to a point where you can ace these kind of interviews.
Situational (STAR) interview
The format
Welcome to what is, in my opinion, the hardest part of the interview. Sometimes this is the first step, other times it's the last.
While it may be possible to pass the architecture interview without much prep if you've been doing the job for a long time, this interview absolutely needs preparation up ahead. And much like the architectural interview, you're very unlikely to get this format right from the get-go. It took me several interviews before I was comfortable answering these kind of situational questions without panicking and sweating. It took me even longer before I found it easy and I did a decent or even great job at them.
If you don't know what I mean by Situational questions, those are the kind of questions that can be boiled down to "tell me about a situation when...". Sometimes the interviewers are more subtle about it, but luckily I have found that they are usually pretty straight forward. They will likely tell you in advance that it's going to be a situational interview, and they are not necessarily going to try to ask you trick questions or trip you up.
The trick for those kind of questions is to use the STAR framework. The interviewers may tell you this themselves if they're super nice, but in case they don't, it's good to keep this in mind. STAR stands for:
- Situation
- Task
- Action
- Result
I found this blog post was a great resource on how to answer these questions, but I will try to explain it here as well.
Each question will take you between 3-5 minutes to answer. You essentially have to scan through many years of experience and find the right example for the question and then condense it down to a format that can be answered in a few minutes.
If this sounds extremely difficult, it's because it is, and that's why you should have 2-3 scenarios that you have prepared in advance and can go back to during the interview. You're never going to be able to prepare for every question that they ask, but the more you do these interviews, the more you will find patterns to the questions and you will be able to adjust what you have already prepared in advance to better fit the specific questions you're being asked.
I eventually tackled this by thinking back to my previous 2 roles, and thinking about 2 or 3 projects that I led: what was required, what went well, what went wrong, and what I would change. Then, I wrote down some scenarios in the STAR (or STARL, the L standing for Learning) format.
Example question
Question:
Tell me about a time that you disagreed with a colleague/a superior
Situation
Here you have to give the context and background of why you were doing the particular piece of work. This can be pretty short, one or two sentences.
We had to resolve some vulnerabilities from a pen test. We had very little time to resolve those as the pen test certification was preventing us from signing a new client. In particular, we were storing tokens in local storage, which meant that if any XSS vulnerability was present, the tokens could be stolen by an attacker.
Task
The question to answer here is "what was your role within the project?" Again this can be pretty concise.
My team lead at the time was accountable for the platform security and I was tasked with implementing their suggestions in the best way possible within the time frame as well as breaking down tasks for other team members.
Action
This is the meat and potatoes of your answer. This is where you are giving your answer to the main question. In this case, where was the disagreement, and how did you handle it?
My team lead proposed replacing tokens that were stored in localstorage to tokens stored in cookies. Doing POST requests with cookies would make us vulnerable to CSRF, however, so they also proposed implementing CSRF protection to prevent that.
I instead proposed a solution where we would not be using cookies for POST requests and instead get a token from a GET request + cookie at page load, then store it in memory.
After talking to my lead and getting their understanding and their concerns about this, I wrote down different scenarios and explained why this solution was just as secure, and also saved us time compared to their solution which required implementing CSRF protection.
Result
This is where you show off the impact of your decision!
The team lead agreed to use my solution. Because of this, we finished the project 7 days quicker than the original solution, we implemented something that was less technically complex, and still passed the pen test.
Learning
What went wrong? What have you learned? What would you have done differently?
Not every project is a success, and even those that are, are not done perfectly. Your interviewer will ask you this question, so be prepared for it.
In my case, I should have pushed back more on the particular project. It was a lot of work that was required of us in a short amount of time and it lead to the team working harder than was healthy for us. I have learned from this and now follow a much leaner approach - I have learned to say "no", push back, and negotiate for an MVP rather than trying to make the impossible happen.
Learn the format
That's it! That's the whole format. Now, as I said earlier, I recommend writing down at least 2 or 3 examples of different projects in this format. Then, record yourself answering the question! It sounds weird, but I think that doing this was what eventually helped me to stop panicking about these questions. By playing back a recording, you can see how long you are taking to answer and can learn to pace yourself. You can also get a better idea of where there may be gaps in your explanation. By doing this, I saw that I wasn't taking as long as I thought, and this gave me the breathing room to stop and think about the question for a few seconds before I answered it, which was also gave me a huge advantage in the interview.
Here are some more example questions that I've been asked:
- Tell me about a project you're really proud of
- Tell me about a time that you had to deliver a project within a deadline
- Tell me about a time that you had to make a compromise
- How do you deal with disagreements?
- How do you get buy-in?
- Tell me about a project where you had impact
- What's a mistake you have made in a project?
- What have you learned from cross-team work?
And my favourite one:
What's the biggest technical problem your team faces at the moment?
... And why haven't you addressed it?
These questions can be scary, but just be yourself and remember that they are not looking for people who have done very impressive things or people who have done things perfectly. Rather, they are looking for people who know how to have an impact within their team, and for people who can recognise their own mistakes and talk about what they will do differently next time.
Values interview
Congratulations, take a deep breath of relief. You're past the hardest part of the process, and now you just have to be yourself and show why you're such a great person to work with!
Look up the company and what they value, and see why you relate to it. I recommend being honest, because if you hate everything about what the company does, then you probably don't want to work there. This is where you just show them the person behind the CV. Be authentic, and remember what excites you about the role. Sure, more money is good, but there are plenty of companies that can offer that - so why this particular company? Is it the more flexible environment? What about the people you interviewed with? What did you like about them? What are the cool problems that you're really excited to solve?
Be ready to talk to those things, and the job is almost yours.
The offer
If you've done well in every part of the process, then congratulations, you probably have a job offer!
If the recruiter asks to talk to you on the phone after your final stage, then prepare yourself to be offered a job.
However, the process is not over yet! Have you got other interviews that you are close to finishing? Then feel free to ask for more time before you decide. If you have an offer, you can also use that as leverage to speed up your other processes.
Can you negotiate the offer? You can always ask for a higher salary at offer time. I'm not the best to talk about salary negotiations, but I will defer you to this blog post. Always negotiate. Get ready for them to say no, but don't leave money on the table.
Closing
Wow, that was a lot to write. I hope that this helped someone - the process is quite lengthy and in parts needs special preparation, so I'm hoping to provide the kind of resource I wished I could have while doing my interviews.
Let me know if you have any questions, always happy to answer from my experience. And remember, ask for what you deserve!
Top comments (1)
Thanks for this article, it is really complete and quite helpful!