What does a developer's job history shape tell you?

What does a developer's job history shape tell you?

A developer's job history shape is the timeline read as one object: how long each stay lasted, what changed between stays, and what grew across them. The individual lines on a resume describe jobs. The shape describes a career, and it carries evidence none of the lines carry alone.

Earlier lessons in this path built the two tools this one uses. Why developers leave established that moves happen when the work stops paying in learning, scope, or money, and that two-year tenure is close to the software median. The seniority ladder established that seniority measures scope of ownership: tasks, then systems, then direction. This lesson points both tools at the timeline itself. The question a shape answers is "did their scope grow while they were there", and every section below is that question pointed at a different silhouette.

Is a two-year move a warning?

In software, a two-year move is the market working as designed. Median tenure in the industry sits near two years, and the forces behind it are structural. A tech stack ages, and moving is the fastest way to work in a current one. Compensation resets at the market rate on a move and drifts below it during a stay. A new company means new systems to learn, and learning is one of the currencies developers get paid in.

So a resume with four companies in nine years reads differently in this field than it would in law or enterprise sales. The shape worth examining sits one level down: what changed across the moves. A developer who went from building features at company one, to owning a service at company two, to setting technical direction at company three used each move to buy scope. The same four logos with the same title and the same kind of work at each stop describes someone who traded companies without trading up, and the market allowed it because demand for developers has been strong for two decades.

Very short stays cluster differently. One six-month stop in a career is ordinary: startups fold, teams get cut, a role turns out to be different from its posting. Several in a row is a shape worth understanding before the shortlist, and the developer usually has a coherent account of it. Contract work, covered below, produces the same silhouette for a completely different reason.

What does nine years in one seat mean?

Nine years at one company is the widest-variance shape on a resume, because it contains two careers that look identical from the outside. In the first, the developer grew with the company: they joined to build features, came to own a system, and now hold direction over an area other engineers depend on. That person carries something rare, deep knowledge of one large system and the judgment that comes from living with their own decisions for years. Engineers who have watched their five-year-old choices age know things about software that a series of two-year stints teaches slowly.

In the second career, the same nine years contain one year of experience repeated nine times: the same kind of task, at the same scope, in the same corner of the codebase. The company was stable, the work was steady, and nothing pushed the scope outward.

The tenure number is identical in both cases, which is why it decides nothing by itself. The separating evidence is the trajectory inside the stay. Title changes across the years are the visible trace, since a promotion from engineer to senior to staff marks scope the company formally recognized. The verbs do the same work at finer grain: the accountability language from earlier in this module, shipped, owned, migrated, shows whether the things being described got bigger over the stay.

What is the pattern that matters across every shape?

The pattern is growing scope, and it outranks every tenure rule. The seniority ladder runs from owning tasks, to owning features, to owning systems, to owning direction across teams. A strong career climbs that ladder, and the climb is visible in a timeline regardless of how many companies host it.

This is what makes the shape readable across totally different silhouettes. Five companies in ten years with rising scope at each stop is a strong career. One company for ten years with rising scope inside it is a strong career. The silhouettes could hardly look more different, and the underlying pattern is the same line, pointing up.

The pattern also gives a precise meaning to a flat stretch. Three years at the same scope early in a career is ordinary, since the first rungs take time. The same three flat years a decade in are worth understanding, and the explanation is often good: a deliberate stay for family reasons, a move into a harder domain that reset the ladder, a company where the scope grew while the title lagged. Titles inflate and deflate by company, which is why the work itself, what they owned and what depended on it, is the reliable reading and the title is the shortcut.

Are side projects a signal?

A side project is software a developer builds outside work, on their own time, because they want to. As evidence, it answers a specific question: what does this person reach for when nobody assigns them anything. A developer whose evenings produce a game engine cares about graphics and performance. One who maintains an open-source tool with real users has chosen the maintainer's work, support, releases, and other people's bug reports, voluntarily. That is motive evidence, and motive evidence is exactly what a work history struggles to show.

What a side project answers less well is professional skill level. Professional engineering happens under constraints a solo evening project never imposes: other people's code, other people's deadlines, a system that has to stay up while it changes. The evidence for that lives in the work history and its verbs. A modest side project from a strong professional engineer is common. So is the reverse.

The absence of side projects carries close to zero information. Many excellent engineers write code all day, then spend their evenings on their families, their sport, or anything other than more code. Some of the strongest engineers in the industry have empty evenings by design. A profile with no side projects is a profile that has answered no questions yet, and an empty GitHub, covered earlier in this module, works the same way. When side projects do exist, they add. When they are absent, nothing subtracts.

How do you read a contract or agency career?

A contract or agency career is one built on short engagements: a developer joins a project for three to twelve months, delivers, and moves to the next client. Agencies run this as a business model, placing their engineers across many client codebases. Independent contractors run it solo. The resulting resume is a long list of short stops, and read against a tenure rule it looks alarming. Read as its own shape, it is coherent and common.

What the shape certifies is breadth and fast starts. A contractor who has delivered in fifteen codebases has seen fifteen different sets of decisions, met fifteen unfamiliar systems, and become productive in each within weeks. That is a real and specific skill, strongest exactly where a req involves greenfield work, prototypes, or parachuting into an unfamiliar system and delivering.

What the shape leaves unwitnessed is long accountability. A contractor leaves before their own decisions age, so the timeline holds little evidence of living with a system through years of production wear, the territory long-tenured engineers know deeply. Many contractors have that experience from an earlier staff chapter of their career, and the shape by itself has never had the chance to show it.

The scope pattern applies here unchanged, measured in engagements instead of promotions. Early contracts are small builds. Later ones are architecture, rescue work on failing projects, and technical leadership of client teams: clients trusting this person with progressively bigger problems. That is the same upward line every other shape shows, drawn through different paper. Which shape fits a given req, the deep owner, the fast starter, the long climber, is a tradeoff call, and the shortlist station ahead takes those calls head on.