james@kartar : ~ / 2026 / 6 / engineering-jobs-i-might-apply-for
Overview

Engineering Jobs I Might Apply For

8 min read

Engineering Jobs I Might Apply For

I read job descriptions for fun now, which probably needs some explaining. I am not looking for a job. I am, comfortably, not. I read them the way some people read real estate listings or go to open houses: no intention of buying, purely for the pleasure of watching language do work it isn’t up for.

Because the modern engineering job ad has converged. Somewhere in the last few years the whole genre drifted into a kind of mid-Atlantic marketing register, the same nine phrases shuffled into a slightly different order each time. “You’ll join a team of high-performers in a collaborative environment.” “Series B, growing fast.” “We move quickly and value ownership.” “We use AI to accelerate our engineers.” Every one of those is true of every company that has ever existed at some point, so none of them actually tell you anything.

So let me flip it around. After twenty-five years of being, variously, an engineer, an engineering manager, a VPE, a CTO, and then an engineer again when I missed it, what would a job ad have to say to make me read it twice? Not apply, just read it twice (and maybe go find out who wrote it).

I should say up front that almost none of what follows will ever appear in a real posting, and I know exactly why, because I have written postings, and I committed most of these sins while doing it. Sometimes there’s a board, or a legal team, or a head of talent who won’t let me write the true thing. Sometimes I just can’t break the habit. Let the one among you who has never typed “fast-paced environment” cast the first stone.

What stage are you, actually?

Most postings dance around this. “Series B, growing fast” is meant to sound like momentum, but it tells me nothing about whether you have product-market fit, three months of runway, or a CFO who described last quarter to the board as “lumpy.” What I’d love, on the first page, is three plain sentences: we are at stage X; our biggest risks for the next year are Y and Z; we are hiring this role because of A. That would be the most useful paragraph in the whole posting, and I have never once seen it.

It matters because the job is a different job depending on the answer. An engineer at a pre-product startup spends most of the week building things to throw away on the road to working out what to actually build. An engineer at a scaling company spends it threading new features through systems that are already load-bearing. An engineer at a mature company spends it keeping trust in things that already work. All three are good jobs, they’re just not the same job, and you could save us both a round of interviews by saying which one you’re advertising.

If you genuinely can’t write that down, at least drop a hint about which kind of engineer you need. I like building, I like chaos, and I like fixing broken things. I am almost certainly not the person you want for the very stable, very sensible platform that just needs a steady hand on the tiller and, in fairness to us both, I shouldn’t take that job either.

How much of the week is mine?

Before I apply, I’d like to know how much of my week I’ll point and how much will be pointed for me. That version reads something like: “Expect roughly N hours of meetings a week; the rest is yours, for whatever’s on the team’s roadmap.” Note the qualifier, the team’s roadmap, not yours. Almost no engineering job, at any level, is “you decide what to work on.” Anyone telling you otherwise is running the most relaxed business in the world or is about to disappoint you, and the odds do not favor relaxing.

There are wonderful jobs at every point between “you will be in seven meetings a day and the meetings are the work” and “you’ll see your manager once every other week, if the light is good.” I just want to know which end I’m applying to before I find out the hard way, in month two.

The state of the code

I want a paragraph about the actual code, and I want it to be unflattering. Not “modern” or “well-architected,” because those are things you assert, and nobody puts the true version in a job ad. I want specifics. How old is the oldest service you still depend on? What’s it written in? How many people understand it today? And what does it cost you if it falls over tomorrow morning?

The strongest possible signal in a posting would be a sentence like: “Our oldest production service is eleven years old, written in a language two of us can still read, understood deeply by exactly those two engineers, neither of whom will be on your team, and we are hiring partly to make that number larger than two.”

Where AI actually fits

There’s a line in roughly every other posting now: some flavor of “we use AI tools to accelerate our engineers.” It carries no information whatsoever. Of course you do. The café down the road uses AI tools to accelerate its engineers, and it doesn’t have any engineers. The interesting question is what your team has actually changed because of it.

So be specific about how you use AI. Do your engineers write the tests by hand and let the agent draft the production code, or the other way around? Does code review still start with a human, or has the agent’s pass quietly become the real first reviewer and your colleagues the rubber stamp? Is there a written-down list of things the agent isn’t allowed near, and does anyone honor it? The person you want is the one who reads those answers and either nods or picks a fight.

The people who you’ll work with

Most postings describe the team in the manner of a horoscope. “You’ll join a team of high-performers in a collaborative environment” is said about every team that has ever existed, including the ones currently not speaking to each other.

The team I’d apply to join is the one whose posting writes about itself like an actual group of people, with histories, with strengths, and, somewhere in the fine print, with weaknesses. “We’re five. Three of us have worked together before. One is the best problem solver I’ve ever sat next to. One joined six weeks ago and still needs a map. Collectively we’re thin on operational experience, which is the real reason this role exists.” I have never seen a job ad describe its team like that. If one did, I’d believe an actual person had sat down and written it that week, and that alone would make me read the rest.

Things that do not impress me

I am not impressed by a salary band three multiples wide, which usually means you haven’t decided what the job is. I am not impressed by the perks. I am not impressed by an interview process that wants more than one take-home, more than four rounds, or a conversation with someone whose job I can’t deduce from their title. I am not impressed by a posting that goes out of its way to tell me how flat the org is, how high the bar is, or how much it prizes “ownership,” a word I now distrust in direct proportion to how often it appears.

I am also not impressed by the conspicuous absence of seniority levels. Some companies, fashionably, have done away with them. A few of those are genuinely great places to work. The rest are using the missing ladder to avoid ever saying out loud whose call is whose, and you can’t tell the two apart from a job ad, which is exactly the point.

What I’d actually settle for

None of that is going in a real job ad, and I know it. No company is going to print that its oldest service is held together by two people who’d both quietly like to leave, or that the team is “short on operational experience, which is why we need you.” That’s not how anyone writes about themselves to strangers, otherwise dating apps would be a lot more useful.

But the ridiculous version always points at a reasonable one. You don’t have to confess your runway to admit you’re pre-product-market-fit and that’s the whole shape of the job. You don’t have to publish anyone’s failings to write “we’re five people, two of us are new, and we need someone who’s run things at scale.” You don’t have to grade your own code to say it’s ten years old and only two people really understand it. None of those are confessions, they’re just specific, and one specific sentence does more work than nine generic ones.

To me, the ad is the cheapest sample of how a company writes everything else. If the posting is nine stock phrases, so are the planning docs, the incident reviews, and the strategy memo. If the posting bothered to be a little specific, there’s at least a chance the rest of the place did too. It’s not much to go on, but it’s not nothing.

So I don’t need the perks, or the mission statement, or the promise that you move fast. Just swap “a team of high-performers in a collaborative environment” for one true sentence about who’s on the team and what you need them to do. Even a cautious, legal-approved version of the truth would stand out, because almost nobody else bothers.

I’m not looking. But if an ad like that landed in my inbox tomorrow, I’d read it twice, work out who wrote it, and probably try to hire them, which is more than I’ve done for a job ad in years.