Software Engineer

Your resume is not the bottleneck you think it is

Software engineers spend more time on their resumes than the process rewards. For most engineering roles the document has one job: get you past a recruiter screen that lasts under a minute and is mostly pattern matching against the stack in the posting.

After that, nothing on the page matters much. You will be judged on a technical screen, then a set of interviews that test problem solving and system design and, at senior levels, how you make decisions with other people. Nobody rereads your bullet points afterwards.

That has two consequences. Spend less time polishing prose and more on making the match obvious. Then spend the time you saved on the parts that actually decide the outcome.

Make the stack match visible in five seconds

Recruiters screening engineering applications are matching a shortlist of technologies. If the posting says Go, Kubernetes and Postgres, they are scanning for those three words.

Put a technologies line near the top, grouped rather than listed as one long string. Languages, then infrastructure, then data. Order it to lead with what the posting asked for.

Then make sure the same technologies appear inside your experience, attached to something you built. A skills list that mentions Kafka with no Kafka anywhere in your history reads as aspiration, and an interviewer who spots the gap will start there.

Leave off things you would not want to be asked about. Every technology on the page is an invitation to a question, and there is no benefit to a longer list you cannot defend.

Write what the system did, not what you were assigned

The weakest engineering bullets describe tasks. Developed features. Wrote unit tests. Participated in code reviews. Every engineer does these, so they carry no information.

The strongest describe a system, a constraint, and an outcome. What did you build, what made it hard, and what changed as a result.

"Rewrote the order ingestion path from synchronous HTTP to a queue-backed consumer, which took peak-hour p99 latency from 4 seconds to 300 milliseconds and stopped the checkout timeouts we saw every Friday."

An engineer reading that learns your scale, your judgment and roughly your level. They can also ask you three good questions about it, which is what you want. A bullet nobody can interrogate is a bullet nobody is impressed by.

Numbers help, but use the ones you actually know. Invented percentages are obvious to people who have measured things for a living.

Referrals move more than any resume edit

The uncomfortable arithmetic of engineering hiring is that a referred candidate and a cold applicant are treated very differently, and the gap is larger than any improvement you can make to a document.

This is not about knowing important people. Most referrals come from ordinary former colleagues. Go through everyone you have worked with, find where they are now, and ask the ones at places you would want to work whether they would refer you. Most will say yes, because at many companies they get paid for it.

If you have no network to draw on, build the smallest useful version. Contribute a real fix to a library the company maintains. Answer questions where their engineers hang out. Write about something you built with the same technology they use. None of this is fast, but it compounds and a resume rewrite does not.

Reading an engineering posting

Postings are written by committee and the requirements section is the least reliable part. Three things elsewhere tell you more.

The team size and structure. A posting that mentions the team you would join, its size, and what it owns has been written by the hiring manager. A posting that describes the company for four paragraphs and the work for one was written by a recruiter working from a template, and the interview will be less organised too.

The seniority language against the requirements. Ten years of experience demanded for a role described entirely in terms of implementing features is a company that has not thought about what it needs. Three to five years alongside ownership of a system is a company that has.

Whether they mention on-call, testing practice, or how they deploy. Companies that talk about how they work have usually thought about it. Silence on all three, combined with enthusiasm about pace and impact, is worth asking about directly in the first call.

The requirements list itself can be ignored more than most candidates believe. Applying at seventy percent of the stated list is normal and expected, and the people who wrote it know it is a wish list.

Level is a claim you have to support

Titles do not travel. A Senior Engineer at a 20-person startup and a Senior Engineer at a large technology company are frequently two or three levels apart in scope, and every experienced interviewer knows it.

Rather than arguing about the title, describe the scope that supports it. Senior usually means you own a system end to end, break work down for others, and are trusted to make design decisions without supervision. Staff usually means influence across teams and responsibility for technical direction beyond your own.

If your evidence is thin for the level you want, the interview will find it, and being downlevelled after four rounds is a worse outcome than applying one level lower and being strong. If your evidence is strong but your title was junior, say what you owned and let the scope make the argument.

The technical screen is a rehearsable skill

Most engineers who fail interviews are competent at their jobs. They fail because the interview format is a distinct skill they have not practised, and competence at work does not transfer automatically to solving a problem out loud, on a clock, while someone watches.

Practise the format, not just the problems. Say what you are thinking. Ask about constraints before writing code. State your approach before typing, so the interviewer can redirect you early rather than watching you spend twenty minutes going the wrong way. Talk about the trade-off you are making when you choose a data structure.

Silence is what sinks people. An interviewer cannot give credit for reasoning they cannot hear, and a candidate who arrives at a working solution without narrating often scores below one who reasoned out loud and did not finish.

System design rewards specifics from your own work

At mid level and above there will be a design round. Design a URL shortener, a notification system, a feed.

Generic answers assembled from study material are recognisable, because they describe an architecture with no history. The ones that land draw on something you have actually operated. What broke, what you had to change, what you would do differently.

Prepare by writing down three systems you have worked on and, for each, the constraint that shaped the design, the failure you did not anticipate, and the thing you would change. That preparation is reusable across every interview and it is far more valuable than memorising a reference architecture.

Ask about scale before designing. A candidate who designs for millions of users when the interviewer had thousands in mind has demonstrated something unhelpful about how they would work.

Gaps, layoffs and short stints

Engineering hiring is more relaxed about these than most fields, particularly after several years of large-scale layoffs across the industry. What matters is that the account is straightforward.

Put the reason inline. A role that ended in a company-wide layoff should say so. A gap you spent on something specific should say what. Interviewers are checking for a coherent story, not an unblemished record, and the discomfort candidates project about a gap does more damage than the gap.

Short stints are the one thing worth pre-empting. Two or three roles under a year, back to back, will get asked about. Have the honest reason ready and keep it brief.

Levelling is the pay conversation

We do not print salary figures, because a number from the Bay Area means nothing in Toronto, Bangalore or Nairobi.

The structural point that holds everywhere is that pay in this field is set by level far more than by title, years, or how well you negotiate. The single largest change available to most engineers is being hired one level higher, which is decided by the scope you can evidence in interviews rather than by anything on the resume.

After level, the biggest factors are company type and how the company makes money. An engineer building the product a company sells is usually paid more than one maintaining internal tools at a company in another industry, in the same city at the same level. Moving from a local company to a multinational, or from a traditional industry into software, reprices you against a different band entirely.

For what the role pays where you live, our salary calculator takes your city and your years of experience.

The most useful thing you can do today

List the five people you have most enjoyed working with, find out where they are now, and message two of them. That will move your search further this month than any amount of resume editing.

When you do apply, our job search builder points one Google search at every board you trust, and the ATS scanner shows what a filter reads before a person does.