The Job Description Is the First Interview

At 10:40 on a Sunday night, a controls engineer with eight years in battery systems opened a job description for a Senior Controls Engineer at an autonomous trucking company. She read it twice. It asked for experience with model-based design, a list of four simulation tools, familiarity with ISO 26262, and "a passion for the future of transportation." It did not say what the team was building this year, who she would report to, or what problem had made someone open the requisition. She closed the tab and did not apply.

That same Sunday, the hiring manager for that role was wondering why the pipeline was thin. He had approved the description three weeks earlier. In truth, a recruiter had pulled it from a similar requisition opened the year before, he had changed two lines, and both of them had moved on to the part of hiring that felt like real work: screens, panels, and debriefs.

He thought the interview process started with the first phone call. For the engineer, it had already ended. The job description was the first interview, and both of them had been in it without knowing.

From the candidate's chair

A candidate reads a job description the way an interviewer reads a resume: quickly, skeptically, and looking for a reason to move on. A strong engineer in mobility right now is not reading one posting. The board I run carries 27,400+ open roles across 167 companies, and nearly half of them are engineering roles. A good candidate has choices, and the description is where those choices get narrowed.

What candidates read for is not the list of requirements. They read for signals. Does this team know what it needs? Is the work real or aspirational? Will I be the fourth person to hold this seat in two years? A vague description answers all three questions badly, whether or not that is fair to the team behind it.

What candidates usually get wrong is treating the requirements list as a pass or fail test. In my experience across 1,000+ hires, most requirement lists are a wish list written by several people who never met to agree on it. Candidates who match seventy percent of a list and apply anyway get hired regularly. Candidates who match ninety percent and talk themselves out of it never find out.

What candidates cannot see from where they sit is how the description was written. They assume every line was chosen on purpose. Often nobody chose it at all. It was inherited.

From the hiring team's chair

A hiring team experiences the job description as paperwork. It is the form that has to exist before the requisition can be posted, and it competes for attention with launch dates, supplier problems, and the three open seats already slowing the team down. Writing it from scratch feels like a luxury. Copying the closest existing description feels efficient.

The constraints are real. Legal and HR often require standard language. Compensation teams want leveling consistent across the company. In aerospace and defense, export control and clearance requirements have to appear in specific wording. None of that is optional, and none of it is the hiring manager's fault.

What hiring teams usually get wrong is assuming the description is a filter. They write it to keep the wrong people out, so it fills up with requirements. The people it keeps out most reliably are the strong candidates with options, because they are the ones least willing to guess. The candidates who apply to everything apply anyway.

What the hiring team cannot see is the comparison set. The manager reads one description, their own, and it looks fine. The candidate reads it next to a dozen others posted that same week, and in that comparison it reads like every other one.

Where it breaks

The break is that one side treats the description as the opening move of a conversation and the other side treats it as a form that came before the conversation. The candidate is being evaluated by a document the team never evaluated.

The board data makes the problem visible. Roughly one title in five on the board carries the word senior, and about three out of every four roles carry a title that appears nowhere else on the board. Teams are working hard to make their titles specific. The text underneath those titles is a different story. In the descriptions I read every week, including the ones linked from the Mobility Jobs board, the same phrases repeat from company to company: "fast-paced environment," "passion for sustainable transportation," "ability to wear many hats." A unique title sitting on top of a generic description tells a careful reader that the team knew what to call the role and not what to say about it.

The second break is order. Most descriptions open with the company's mission, then list responsibilities, then requirements, then benefits. Candidates scan for the work first. A description that makes them read three paragraphs of mission before learning what they would build has already lost the reader who has the most options.

The third break is honesty about what is hard. Every role in mobility right now has a difficult part: a launch date that cannot move, a program that was restructured last quarter, a manager who is new to the company. Teams leave that out because they think it will scare people. The candidates it scares were going to leave in month four anyway. The candidates it attracts are the ones who read the hard part and think, I have solved that before.

In my own hiring, the descriptions that pulled the strongest candidates were the ones that named a specific problem in the first three sentences. Not the mission. The problem.

What to do differently

If you are the candidate

• Read the description as evidence about the team, not as a test you must pass. A specific description tells you the manager knows what they need. A vague one tells you to ask more questions in the first call, not to skip the role.
• Apply when you match the core of the role, not every line. Find the two or three requirements that describe the actual work. If you have those, the rest is usually negotiable.
• Ask the recruiter what problem opened the requisition. It is the single most useful question in a first screen, and the answer will tell you more than the posting did.
• Write your application to the problem, not to the list. If the description names a challenge, address it directly in your summary or cover note. If it does not, use what you learned in the screen.
• Notice when the description and the interview disagree. If the panel asks about work the posting never mentioned, the role has changed since it was written. Ask how.

If you are the hiring team

• Open with the problem the hire will solve this year. Two or three sentences, in plain language, before the mission statement. That is the paragraph strong candidates read first.
• Cut the requirements list to what you would actually reject someone for. If you would hire a great candidate without a line item, that line item is a preference. Label it as one or remove it.
• Have the hiring manager write the first draft, then let the recruiter edit. A recruiter can fix structure and tone. Only the manager knows what the work is.
• Name the hard part. A fixed launch date, a new team, a program that is being rebuilt. Saying it plainly filters for the people who will stay.
• Read your description next to three competitors' postings for the same role. If you cannot tell yours apart, neither can the candidate.

The controls engineer found a different posting the following Tuesday, at a smaller company, for nearly the same title. Its first paragraph said the team was rebuilding its thermal management controls after a cold-weather validation failure and needed someone who had done that before. She applied that night. The trucking company's requisition was still open six weeks later, and the hiring manager was still wondering where the good candidates had gone. They had read his first interview question, and he had never written it.