Your Hiring Process Needs HTTP Status Codes

Because “we’ll be in touch” is not an observable state.

I submitted a job application recently.

It was one of those applications where you actually put in the effort. I read the job description carefully, tailored the resume, wrote a cover letter specifically for the organization, and answered the optional questions rather than pretending they were optional.

Then I clicked Submit and got… nothing.

No confirmation email. No “we received your application.” No indication that a candidate record had been created. Just a browser page telling me the submission had succeeded and the vague hope that somewhere, deep inside an applicant tracking system, my carefully assembled application had not been written directly to /dev/null.

As a developer, I find this troubling. Not because I expect an interview, or because I think every recruiter owes me personalized feedback. I just want a status code.

And I think that’s a smaller ask than it sounds like, for a reason I’ll come back to at the end: the states already exist. Somewhere in that ATS, my application is in one. The decision not to show me which one is a product decision, not a privacy constraint.

The Web Solved This Problem Decades Ago

When software sends a request to another system, we generally consider it useful for the receiving system to say what happened. Did it work? Is it still processing? Was the request malformed? Is the resource gone? Did something catch fire on the server?

HTTP gives us an entire vocabulary for this.

Hiring systems, meanwhile, have developed their own protocol:

POST /careers/applications

[no observable response]

This is sometimes followed, anywhere from three minutes to six months later, by:

After careful consideration...

Instead of inventing vague candidate statuses like “Under Consideration,” perhaps hiring systems could adopt something developers already understand.

The 2xx Family: Success, Allegedly

200 OK

A human being has reviewed your application.

Nothing else is implied.

Honestly, this alone would be revolutionary.

202 Accepted

Your application has been received and accepted for processing.

This is the most important status code in the entire hiring protocol. The candidate does not need the hiring manager’s notes or a walkthrough of the internal workflow. They need:

202 APPLICATION_ACCEPTED

Now we know the thing exists.

204 No Content

Your application was successfully received.

We have chosen not to acknowledge this in any way.

The 3xx Family: You Have Been Redirected

302 Found

We found an internal candidate.

Thanks for playing.

304 Not Modified

Your application has been “Under Review” for 47 days.

There has been no change since the last time you checked, or the 23 times before that. There will be no change the next time either. Please consider caching this response locally.

410 Gone

The position existed when you applied. It no longer exists. No additional information is available.

At least 410 would be useful. The current discovery mechanism is noticing that your bookmarked job posting has started redirecting to the careers homepage.

The 4xx Family: This One’s On You

401 Unauthorized

You must create an account before applying.

Your password must contain at least 14 characters, uppercase and lowercase letters, a number, a symbol, and one ancient Sumerian glyph. It cannot match any password you have used since 1997.

You will then manually enter every field from the resume you just uploaded.

You will never use this account again.

403 Forbidden

You have the required experience and qualifications.

Unfortunately, you live 37 miles outside the geographic boundary within which we have determined this Zoom meeting can occur.

404 Not Found

Hiring manager not found. Recruiter not found. Job posting not found.

Nobody knows who owns this requisition.

408 Request Timeout

After seven weeks without communication, the candidate has accepted another position.

The hiring team will contact them tomorrow to schedule the second interview.

409 Conflict

The position requires 12 years of production experience with a technology introduced six years ago.

The conflict cannot be resolved.

417 Expectation Failed

You expected the phrase “we’ll be in touch” to imply future communication.

It did not.

422 Unprocessable Content

Your experience is relevant, but your career path does not fit cleanly into the predefined boxes in our applicant tracking system.

Human intervention may be required.

Human intervention is unavailable.

425 Too Early

You applied 14 minutes after the job was posted.

LinkedIn reports 612 applicants.

We have questions too.

451 Unavailable For Legal Reasons

Your qualifications are not the issue.

The issue is a background check vendor, a non-compete of uncertain enforceability, or a sponsorship question nobody wants to be the one to ask about.

The 5xx Family: It Was Never You

500 Internal Server Error

Something has gone wrong internally. Your recruiter left, the headcount was frozen, the hiring manager changed, Finance reconsidered the budget, the organization restructured, or the position was posted by accident.

We will communicate all of these possibilities using the same message:

We have decided to move forward with other candidates.

502 Bad Gateway

The recruiter says they are waiting for the hiring manager.

The hiring manager says recruiting owns the next step.

Your request cannot be routed.

503 Service Unavailable

Your recruiter is no longer with the company.

Their calendar link remains active.

504 Gateway Timeout

“We expect to have a decision by Friday.”

Friday has passed. The specification does not define which Friday was intended.

Candidates Don’t Need Distributed Tracing

There’s a serious point hiding under all of this. Hiring has an observability problem, and it’s usually mistaken for a communication problem.

Companies understandably cannot expose everything happening inside a recruiting process. Candidate evaluations are private. Interview feedback may be sensitive. Hiring managers need room to compare people and make decisions.

That’s fine. Nobody is asking for:

GET /hiring-manager/private-thoughts/about-me

But there is an enormous amount of territory between exposing confidential deliberations and providing no information at all.

A hiring pipeline already has states. An application was received. It entered review. Someone reviewed it. An interview was requested. The requisition was paused. The position was filled. The position was canceled. The candidate was declined.

Those state transitions already exist in the system. They are already recorded, timestamped, and reportable, because that’s how recruiting teams measure their own funnel. The candidate is the one participant in the process who cannot see the record they’re in.

Give Us the Boring Version

Imagine an applicant portal that reported nothing more than this:

202  APPLICATION_RECEIVED     Mar 04
200  REVIEWED                 Mar 19
304  NO_CHANGE                Apr 02
304  NO_CHANGE                Apr 30
410  POSITION_CLOSED          May 12

That’s not radical transparency. It’s barely transparency at all. But it tells you the system is functioning.

It removes the need to wonder whether an application disappeared. It reduces pointless portal refreshing. And it prevents candidates from reading silence as information, when silence might mean anything from “the hiring manager is on vacation” to “the requisition was canceled two weeks ago.”

Mostly, it treats applicants like participants in a process rather than packets transmitted into an undocumented endpoint.

200 OK

I don’t expect every application to result in an interview. I’ve submitted enough of them to have considerable empirical evidence supporting that position.

I don’t expect detailed rejection feedback either. I understand why companies are reluctant to provide it. I don’t even particularly mind 403 REQUIREMENTS_NOT_MET or 410 POSITION_FILLED. Those are answers.

What makes modern hiring uniquely frustrating isn’t rejection. It’s uncertainty about whether anything is happening at all.

Software engineers have spent decades building systems around a simple principle: when one system asks another to do something, the response should carry enough information to understand what happened.

Candidates aren’t asking for distributed tracing of your recruiting infrastructure.

We’d settle for a status code.

Facebooktwitterredditlinkedinmail

The Kitchen Doesn’t Care About Your Excuses

There is a moment in every high-stakes environment when something goes completely, objectively wrong, and the only viable response is to keep working.

In my case, it was a pantry clerk who walked into the dry storage room carrying a stack of boxes, clipped a fire sprinkler head, and discharged what I can only describe as an impressive quantity of initially greasy water across an active commercial kitchen. We were told to continue service. It took four hours for the sprinkler system technicians to arrive and resolve the situation. We dried our shoes afterward.

I have thought about that shift many times since leaving commercial kitchens for the technology industry. Not because it was the strangest thing I witnessed. It wasn’t. Not by a significant margin. However, because the response to it was so instinctively correct. Nobody called an all-hands. Nobody convened a retrospective on the water. We just kept swimming.

It turns out that lesson travels extremely well.

A few weeks ago I wrote about how a non-linear career isn’t actually non-linear, that the industries change but the underlying questions stay remarkably consistent. I want to make that argument concrete. Here’s what commercial kitchens specifically taught me about performing under pressure, and why none of it required translation when I showed up in technology.


The Kitchen Never Lies

I spent years in commercial kitchens before I spent years in technology. Western Culinary Institute. Private golf clubs. A Lebanese restaurant. Bulk production facilities turning out ten thousand pounds of macaroni and cheese a day, five days a week. Country clubs. A casino. Catering. Culinary competitions.

The environments were different. The underlying dynamics were identical.

High pressure. Constrained timelines. Mismatched team experience levels. Leadership of wildly variable quality and sobriety. Outcomes that mattered regardless of what had happened behind the scenes to produce them. Customers who neither knew nor cared about any of it.

I did not know I was learning transferable skills at the time. I thought I was learning how to cook. It turns out those were the same thing.


Same Kitchen, Different Ingredients

The technology industry has a vocabulary problem. It generates terminology at a pace that would impress a culinary school graduate. Culinary schools name everything too, usually in French. But underneath the terminology, the operational reality of a software team and a commercial kitchen are structurally almost identical.

You have a head chef and a CTO. You have line cooks and engineers. You have front of house and you have marketing. You have the person who is technically in a support role but is actually holding the entire operation together through sheer competence and quiet heroism, and that person exists in every kitchen and every engineering org I have ever encountered.

The hierarchy is real. The hierarchy is also frequently ignored when things get busy, because when things get busy everyone does what needs doing. The title matters less than the skill and the willingness to move.

The product has to ship. In a kitchen, that means service ends at a specific time regardless of what happened during prep. In software, the deadline is usually softer, and I would argue that softness causes more problems than it solves. A kitchen cannot negotiate with a hungry dining room. The discipline that creates is not optional. It is the whole job.


Expertise Is Flexibility, Not Rigidity

There is a format in culinary competition called black box. You arrive at the competition, you are handed a box of ingredients you have not seen before, and you have a defined window of time to produce something coherent and excellent from whatever is inside. No advance preparation. No recipe. Just skill and whatever is in the box.

The competitors who do well are not the ones with the most elaborate plans. They are the ones who know their fundamentals deeply enough that an unknown input doesn’t produce paralysis. It produces curiosity.

The harder version of this is what happened in some competitions when judges would walk in midway through cooking and announce a required addition. Not a gentle one. Sometimes it was Durian, a fruit so aggressively aromatic that its presence reorganizes every other decision you have made. And the timeline did not move.

The competitors who handled this gracefully shared a specific characteristic: they understood what they were already working with deeply enough to see how the new element could integrate. They were operating from understanding, not from recipe-following. Mastery, it turns out, produces adaptability rather than rigidity. The more you know, the more options you can see.

I have watched senior engineers navigate a surprise architectural requirement three days before launch with exactly the same quality. The ones who handled it well weren’t attached to their original design. They were attached to the outcome. The design was just the current best path to get there.

The ones who struggled, in the kitchen and in the codebase, were the ones who had confused knowing a recipe with knowing how to cook.


The Demo Is Not the Product

Culinary competitions sometimes include a format called hot food displayed cold. You cook an elaborate multi-course meal, seven courses, classical technique, genuine craft, and then you coat everything in aspic, a clear gelatin, to preserve its appearance for judging. The food looks extraordinary. It is presented on mirrored platters with architectural garnishes. Judges evaluate it with great seriousness.

Then it gets scraped into the garbage.

Nobody eats it. The entire exercise is about the appearance of the thing, assessed by people who will never consume it, after which it is discarded.

I have sat in enterprise software demonstrations that felt identical. A beautiful thing, carefully prepared, evaluated on appearance by people who will not use it daily, followed by a procurement process that has increasingly little to do with whether the thing actually works in a real kitchen at volume on a Saturday night.

The aspic looks great. Ship the thing that survives the sprinkler.


The Judges Don’t Care

This is the part that took me longest to fully internalize, and I think it is the most important.

In those culinary competitions where the judges walked in mid-execution and added a surprise requirement with no time extension, there was no sympathy in the scoring. None. If the Durian addition made the dish worse, you did not receive credit for the degree of difficulty. You did not get points for the fact that the constraint was late and unfair. The dish either worked or it did not.

End users operate the same way. They do not know about the sprinkler. They do not know about the scope change that arrived on Wednesday. They do not know that the original timeline was unrealistic or that the requirements shifted twice or that a key engineer was out sick during the final week.

They know if the dish works.

This is not a counsel of despair. It is a counsel of clarity. The customer’s indifference to your constraints is actually useful information, because it means the only variable worth optimizing is the outcome. Not the process narrative. Not the effort invested. The thing that lands on the plate.

Kitchens are honest environments in this way. The food either satisfies or it doesn’t. That directness, uncomfortable as it sometimes is, produces better cooks. I think it produces better engineers too, when the culture is willing to apply it.


From Soup to Python

I did not plan a career that would move from commercial kitchens to developer relations and technical writing. It happened the way most interesting careers happen. Through a sequence of decisions that made sense at the time, producing a trajectory that only looks coherent in retrospect.

But the through-line, looking back, is consistent: helping people understand difficult things under pressure, with incomplete information, against a deadline, in an environment that will not pause to accommodate the difficulty.

That is the job in a kitchen. That is the job in DevRel. That is the job in most places worth working, regardless of what you are serving.

The ingredients change. The kitchen doesn’t.

If you are standing in ankle-deep water right now wondering whether to keep going. Yes. Keep going. Dry your shoes after.

The dining room is waiting.

Facebooktwitterredditlinkedinmail