You finished the course, passed the exam, and now two job offers are sitting in your inbox. One pays more, one has the better team, and both claim a “modern DevOps culture”. Many newly trained engineers freeze at exactly this point, and the cause is usually not missing data. The trouble is that every factor, from salary and commute to tooling and title, is being weighed on the same scale at the same time. This practical list gives you eight steps for sorting a DevOps job decision into hard requirements and mere preferences, so the choice takes an afternoon rather than a month.

The rules are blunt on purpose. Use them as written, adjust them for your own circumstances, and keep your DevOps career move simple.

1. Write the musts before you read the offers

Do this first, ideally before you have even applied. Take a sheet of paper and finish the sentence “I cannot accept a role that…” with three to five endings. Examples: a role that demands unpaid on-call, a role that requires relocation, a role without written compensation terms. If you write the list after reading the offers, your brain will quietly shape it to fit the one you already like.

2. Keep the musts list short enough to memorise

Five is the practical ceiling. Past that, the items are wishes. A useful check: could you recite the list to a friend in one breath? If not, cut until you can.

3. Convert vague wants into testable statements

“Good work-life balance” cannot be verified. “On-call rotation shared among at least four people, with compensation described in writing” can. Rewrite each must so that an interviewer’s answer would clearly satisfy it or clearly fail it.

A second example: “learning opportunities” is a wish dressed as a must. “A budget line for training that is named in the contract, or at least confirmed by email” is something you can check. If a statement cannot be answered with yes or no, it is not ready to sit on the musts list, and it should either be sharpened or moved down to the tie-breakers where vague hopes are welcome.

4. Put everything else on a ranked tie-breaker list

Preferred tooling, a nicer office, a bigger learning budget, a stronger brand name on your resume: all legitimate, all tie-breakers. Rank them from most to least wanted. They matter, but only after every must is met. This single rule prevents the classic mistake of picking an offer because of an impressive logo while an important condition silently fails.

5. Ask interview questions that probe the musts

Candidates often spend interview time admiring the stack and forget to check the conditions. For each must, prepare one direct question. If “no single-person dependency for releases” is on your list, ask who handled the last release and what would have happened if they were unavailable. Their answer tells you more than a tour of the tooling.

6. Treat silence as information

When an employer dodges a question tied to a must, record that fact. It is not proof of anything sinister, but it means that condition is unconfirmed, and an unconfirmed must is a failed must until proven otherwise. Our own read on how culture shifts actually happen inside a delivery organisation explains why vague answers about practices often signal immature practices.

7. Score only the survivors

Eliminate any offer that fails a confirmed must. Only then compare the remaining offers on tie-breakers. Many people do the reverse, adding up points across fifteen criteria, and let a strong score on wishes mask a failure on something fundamental. Gates first, comparisons second.

If you want a sense of where the field itself is heading while you decide, a forward-looking piece on the direction of DevOps in Japan and elsewhere can inform which tie-breakers, such as exposure to platform work, deserve a higher rank.

8. Sleep on it, then re-read your original list

Before replying, re-read the paper you wrote in step one, not a new list. If you now feel tempted to reword a must so that your favourite offer passes, stop. That temptation is the moment the exercise is most useful. Either the condition truly was a wish, in which case demote it openly, or the offer fails and you should say no politely.

One practical aid: keep the list on your phone as well as on paper, so that a call from a recruiter at an awkward moment does not catch you without it. Reading five lines takes ten seconds and prevents decisions made under social pressure.

9. Record the decision and the reason

Write three lines: what you chose, which musts it met, which tie-breakers tipped the balance. In a year, when a bad week makes you doubt yourself, those three lines remind you that the choice was deliberate and based on conditions you had set while calm.

A note on the pattern beyond tech

You will see this same structure wherever people make a considered, high-stakes choice. International patients exploring heart care, for example, are guided by BestCardiacHospitals, an educational website aimed at international patients and built around weighing care options side by side; it adds that nothing on its pages counts as medical advice. The shared principle is simple: fix the practical conditions first, then compare.

A worked example in five minutes

Suppose Kenji has two offers. His musts are: written compensation terms, a shared on-call rota, a notice period he can honour with his current employer, and no relocation. Offer A is a well-known firm with a famous platform team. Offer B is a smaller company with a plainer stack. In interviews, Offer A’s recruiter would not confirm the on-call arrangement in writing, so that must stays unconfirmed. Offer B answered everything directly, including the rota size and the notice period.

On tie-breakers, Offer A wins on brand and tooling. But the gate comes first, and A has not cleared it. Kenji asks A once more, politely, for the on-call details. When the answer is still vague, he accepts B. His tie-breaker list is not wasted: it tells him what to negotiate for in B, such as a conference budget, and what to look for in his next move.

Common pitfalls when using this list

• Inflating the musts after a charming interview. Charm is a tie-breaker.
• Letting a recruiter’s deadline rewrite your priorities. A short deadline can be a pressure tactic. Your conditions are yours.
• Forgetting to include the unglamorous basics. Notice period, contract type and written terms rarely thrill anyone, yet they are the usual sources of later regret.
• Over-trusting titles. “Site reliability engineer” and “DevOps engineer” mean wildly different things at different companies, so test the duties, not the label.

The quick version

Write the short list of deal-breakers first. Make each one testable. Rank all other wishes. Ask direct questions. Remove any offer that fails a must. Compare survivors on tie-breakers. Sleep on it. Record why. Do these eight things and most job decisions in DevOps stop feeling like a coin toss, and the regret that follows them gets noticeably smaller. Print this page, keep the paper list next to your laptop, and let it do the arguing for you.