Getting A Senior Backend Software Engineer Job in the AI Era

Disclaimer: None of this is professional advice. I'm not a professional. I'm just loud about my opinions and occasionally employed.

So you got the "we value your contribution" email.

I've worked at three start-ups that started-up, doing the right thing at the right time, but the right time passed, and every other company was also doing the same thing at the same time. Because I don't have million$ lying around to retire early, I had to scramble for new jobs, and in the process I've made a few notes worth sharing.

Before you even start applying

If redundancy is on the table, don't just take it. Ask if they'll do a pay cut or reduced hours instead, like a four-day week, while you look for something else. It beats watching your savings evaporate while doom-scrolling job boards. They might say no. Doesn't matter. Ask anyway.

And when the "here's your severance" conversation happens, don't just nod and sign. Have an actual conversation with a legal advisor about what you're entitled to before you agree to anything. You can't un-sign a thing.

The market has changed, and not in the fun way

There are many people looking for work right now, and companies know it. They can afford to be picky. I did roughly eight final-stage interviews before I got my current job. Eight. Not eight interviews total. I did eight final stages, the ones where you think you've basically got it.

Here's my working theory on why: I wasn't specialised. I bounced between different bits of tech over the years, so I applied for jobs where I wasn't quite the perfect fit, and companies picked the person whose CV matched the spec exactly. Generalists lose to specialists at the CV-screening stage, every time. You need to look like the answer to their exact question, not a good answer to a slightly different question.

There's an interesting quirk of modern job hunting that seems counter-intuitive. It's obvious that companies will reject you for being too junior, but they also reject you for being too senior, on the theory that you'll get bored and leave in six months. What that means is that, if you're desperate, you may apply for junior roles, with salaries below what you're worth. You're not going to get those... there are thousands applying for those. What companies are mostly looking for are people who can complete tasks and look after software by themselves. Aim for the job you're already doing, or perhaps with a bit more responsibility, even nudging your salary range slightly higher. Employers want people who are worth a lot.

And yes, they will ask "what's your AI workflow?" Many do this! Have a real answer ready. "I asked Claude Code to do it" is not a good enough answer, even if, behind the scenes, you're the Lord of the Bots. You need to be able to explain this well, along with the shortcomings of AI.

See my blog post on AI dev for more nonsense on this topic.

Use AI to prep

You can use a Claude project for this. The project has many files, but the most important is a big document of everything you've ever worked on. Markdown is probably best. Then write prompts that tell the AI exactly how you want it to answer the standard interview questions, using your history and the job spec together. The standard questions are always the same:

• "Tell me about yourself." They always ask this. Have a template that adapts per job, including a few lines establishing that you've done this exact job before, somewhere else, and you were good at it.
• 
  "Why do you want to work here?" Not salary, not location. This is about matching your expertise to what they do, and showing you've actually looked at what they do. Somewhere between "obsessed super-fan" and "didn't check the company name" is the target. It's really important to hit the sweet spot here - this was where I was constantly filtered out in the beginning because I was "not enthusiastic enough." When I showed super-fan level enthusiasm, I got the generic "Thank you for your..." When I hit the sweet spot, I started getting interviews. It doesn't actually matter that you're really enthusiastic - you need to explain your enthusiasm in the right way. Their website and job spec can help with that... there is often a careers section where they will tell you why you will love working there.
• Questions for the interviewer. You have to ask something, at both the hiring-manager stage and the final stage... not necessarily the questions that Claude tells you to ask, but something to show you've been listening. Interrupting the interviewer to ask them about something they've said, because you're genuinely interested, might be better than listing generic questions at the end. I got rejected after a 6 stage interview process because I "wasn't dynamic enough". Ask about the interview process itself while you're at it. Interviewers often give you hints about how to do well. This is gold - make notes! Especially for coding tests - you can actually ask what they're looking for, if they don't already tell you.
• Research the company first, before any of the above. What they do, what they claim to value. I once didn't get a job offer after doing well up to the final stage, because they asked a values-based question... "Are you the kind of person that invites people to the pub after work?" Had I known their core value was about being a friend, I could have responded, "No, I organize other socials" rather than just "No." If they do ask weird questions you can always ask them what they're hoping to learn from the answer, and then give a proper answer that actually answers the question.

Get the AI to do mock interviews too, ideally with voice mode. Practising thinking on your feet out loud is a completely different skill from writing good answers, and it's the one that actually gets tested live.

While I was doing all this, I got AI to quiz me in a way that it tracked what I knew, so I didn't have to answer the questions to topics I already knew well. I did this by building a website that does it properly: fullmarks.quest. You give it a topic, like a job spec, React, AWS, whatever's making you nervous, and it builds you a course, quizzes you on it, works out exactly where your gaps are, and then uses spaced repetition to make sure the gaps actually close instead of getting quizzed away and forgotten by Thursday.

Don't wait to be asked the right question. Interviewers work off an arbitrary checklist that may or may not cover the interesting parts of you. If there's something worth knowing that they haven't asked about, just tell them.

Your CV needs one thread, not several

The failure mode is a CV that's trying to be all things, like full stack, but backend-leaning, but a React specialist, but open to lead roles, but also individual contributor. Pick the story. Filename, title, and experience section should all point at the same job.

Some specific notes, on a real CV I was sent:

• If the file's called "Full Stack" but the title says "Backend," that's a fight your CV is having with itself before anyone's even opened it.
• Titles matter less than you'd think, honestly. I got hired as "senior backend" and my contract says Staff Software Engineer. Nobody's checking.
• Drop weakening words. "Strong React specialist". "Strong" undercuts "specialist." Either you're a specialist or you're not.
• Skip "15+ years." Just say the number. The plus is doing something I can't quite name, and I don't trust it.
• Bold your tech stack in the experience bullets. If someone's skimming, and they are always skimming, they should be able to see "TypeScript, three jobs" at a glance.
• Find your numbers. Cost cut, time saved, incidents reduced, anything. If you genuinely don't have a number, work backwards and make a reasonable estimate rather than leaving it blank.
• If your job history has a run of short stints, have a real answer ready for why, because they will ask, and "it just didn't work out" three times in a row is not an answer, it's a red flag wearing a trench coat.

If you're going for lead, prepare differently

Titles are mostly noise, like I said, call yourself senior, lead, staff, principal, whatever fits the spec, nobody's checking your payslip. But the interview for a lead role is a very different interview, and treating it like a slightly-more-senior version of the IC one is how you get caught out.

Almost regardless of the exact title, expect mentorship questions in senior roles. That one's universal. But for anything explicitly "Lead," get ready for a run of questions about how you actually work with other roles and steer a team:

"How did you work with the product owner?" "What's your leadership style?"

These aren't technical questions and you can't wing them on the day. I found them genuinely hard, and needed proper prep time before I was comfortable answering, not because the questions are clever, but because "leadership style" is the kind of thing you've never had to articulate out loud before, even if you've been doing it for years.

As a tech lead I used an approach I called, "The Definition of Awesome". That landed well. Maybe I'll do a blog about it one day.

The stuff you're expected to know cold, backend edition

If you're going for anything backend-leaning, here's the syllabus, apparently:

• 
  Observability. Name real tools your company used, like Sentry, Prometheus, Kibana, the ELK stack. Know when to log info versus warning versus error, and have an opinion on structured logging. For AWS specifically: X-Ray for tracing, CloudWatch for logs/metrics/alerts. For GCP: Cloud Trace. Know what RED stands for. If someone asks how you'd handle logging, don't say "with a logger". Say whether you use structured logging and what fields you included.
• REST status codes. All the ones that come up in real arguments: 200, 201, 401, 403, 404, 429, 500. Know when to retry or fail.
• Microservices, and specifically when you'd reach for a synchronous API call versus an async message-broker-and-handler setup. This comes up constantly.
• ACID and isolation levels. Fintechs in particular love to test you on "how do you make a safe payment or withdrawal," which is really just a transactions question.
• System design. This is the one that scared me most. Watch walkthroughs. This playlist got me through it. Practise a handful of designs until you're not improvising from zero, and make sure your DB / SQL choices are solid. You probably won't be asked to write SQL that actually works. Pseudocode is usually good enough, as long as you include your isolation levels and locking.

Or, you know, build a course on it in fullmarks.quest and let it figure out which bits you actually need to drill. It doesn't care that system design terrifies you. It just keeps asking until it stops terrifying you.

Cloud specifically, like AWS or GCP, is mostly a concepts test, not a "write me some Terraform live" test. Nobody's ever asked me low-level infra questions. Have at least one real story about something you actually deployed, and understand the concepts well enough that they transfer between providers, because they mostly do.

One more thing that took me too long to figure out: you don't need to remember the deep details of everything you built. "I don't remember the exact details, but if I were doing it today, here's how I'd approach it" is a completely fine answer. Seniority doesn't mean total recall. It means you know what a good approach looks like even when the specifics have faded.

Where to look

LinkedIn will happily let you apply to hundreds of jobs and reject you from all of them, usually with a template email that manages to say nothing at all. It's possible that you'll get an occasional interview, but it's a low-yield, thick-skin-required strategy, and writing a tailored cover letter for each one, then editing it so it doesn't read like Claude wrote it, gets old fast. After many depressing, "Thank you for your application..." emails, I stopped applying on LinkedIn.

Turning on "open to work" seems to get recruiters coming to you instead, often in a weekly rhythm. Tuesdays, in my experience, for whatever reason. Recruiters who reach out have effectively pre-filtered you against a real role, which is worth something.

My highest probability of success was via people I knew - either former colleagues or recruiters who had great experiences with me in the past. With former colleagues, you can get valuable information, like exactly what they're looking for in the coding test. Better to delay the interview and prepare properly than give up the rare opportunity by handing in a coding test that focused on robustness, when they just wanted performance.

A few other places that produced better results than LinkedIn, for what it's worth:

• TotalJobs - for regular email alerts on new postings
• CV-Library - I suspect recruiters source a lot of CVs from here
• The Work From Home Hub - for remote-specific roles
• Wellfound - startups (it probably helps to be the first to apply for a job that's just been posted)
• Cord and Welcome to the Jungle - companies reaching out to you directly
• Experis, ContractorUK, Jobsite - if you're going contract

Pace yourself with the applying, by the way. Blast out fifty in a weekend because you're anxious about the silence, and you'll have fifty responses to prepare for the following week, which is its own kind of overwhelming.

If you take one thing from this: figure out the two or three gaps that are actually costing you interviews. Use a spreadsheet, and track where things are going wrong and right, so you get a vague idea of how things are progressing. Solve any gaps properly instead of vaguely re-reading the same AWS docs page for the fourth time. The tool for that is fullmarks.quest. You get free credits, and if you burn through the credits, tell it I sent you.