34 Rust CVs, 2 Hires and the Assumption That Cost Us 5 Weeks — My 7-Step Singapore Screen

We opened two Rust backend roles for a Singapore payments platform because a service was missing its latency target. Eleven weeks later we had two good hires. Five of those weeks were pure waste, and the waste happened before we posted the advert.

Nobody had profiled the service. When we finally did — three weeks into a search for a scarce and expensive skill — roughly half the latency we were trying to eliminate turned out to be a query plan problem that had nothing to do with the language. We still hired the Rust engineers, and the decision was still right for the remaining workload. But we had opened a difficult search on an untested assumption, and it showed in the specification we wrote.

Here is the process I run now, starting with the step we skipped.

Step 1 — Decide whether you actually need Rust

This is a hiring step, not an engineering step, because the answer determines who you are looking for and what you will have to pay. Rust engineers are scarce in Singapore and command a premium. Paying it for a workload that did not require the language is a durable cost.

Three justifications hold up in practice:

• Predictable tail latency. No garbage collection pause means the 99th percentile behaves. If your problem is the tail rather than the mean, this is real and hard to get elsewhere.
• Memory safety in a hostile position. Parsers, protocol handling, anything processing untrusted input where a C or C++ implementation would carry genuine risk.
• Compute density at scale. When the compute bill is large enough that a two-to-three-fold efficiency improvement pays several salaries.

Three justifications that do not survive contact:

• “Our service is slow” — profile first. This was our mistake, and it is the common one.
• “It will help us attract strong engineers” — it attracts enthusiasts, which is not the same thing.
• “It is where the industry is going” — possibly, but that is not a workload requirement.

Step 2 — Write a specification that filters

Most Rust adverts describe the language and its ecosystem. That attracts people who want to write Rust, which is a much larger group than people suited to your particular problem.

Describe the workload and the constraint instead:

That last line does more work than any other in the advert. It signals a team that reasons about trade-offs, and it slightly repels the candidate who treats the language as an identity — which is the candidate most likely to over-engineer your services.

Step 3 — Screen for ownership reasoning

The question I open with, always: “tell me about a time the borrow checker forced you to redesign something — what did you change, and was the result better?”

What separates candidates is not whether they satisfied the compiler but what they concluded. Strong answers describe learning something about the problem: that two components had unclear ownership of shared state, that a lifetime was actually a signal the data belonged somewhere else. Weak answers describe a fight, followed by reaching for a workaround with no reflection.

Follow up with the escape-hatch question: “when do you reach for reference counting, interior mutability, or an unsafe block?” A senior engineer answers immediately, with conditions and a note about documenting invariants. A candidate who says they never use them is telling you they have not shipped anything complicated.

Step 4 — Run a code review exercise, not a puzzle

Give candidates 150 to 200 lines of real Rust containing a subtle design problem, and ask what they would change and why. Algorithm puzzles measure something you will never need; review measures the thing they will do every week.

Good material to plant, in rough order of usefulness:

1. Excessive cloning used to escape a lifetime problem — correct, wasteful, and revealing.
2. A mutex held across an await point — the classic production incident, and a strong senior signal if spotted.
3. Errors flattened into a single string type, destroying the caller's ability to handle cases distinctly.
4. A public API leaking internal types, making future change a breaking change.
5. An unsafe block with no documented invariant — do they demand the comment, or shrug?

Score the reasoning. A candidate who spots the clone but explains it may be entirely reasonable at this scale is doing better than one who mechanically flags every allocation.

Step 5 — Test async and concurrency judgement

Nearly every Rust production incident I have seen in backend services traces to the async runtime rather than to ownership. Ownership problems get caught at compile time; async problems get caught at 3 a.m.

Three questions that sort candidates quickly:

• “What happens if you do blocking file or CPU work inside an async task?” — they should reach for a dedicated blocking pool, and explain runtime starvation clearly.
• “How do you cancel an in-flight operation safely?” — cancellation safety is where the genuinely experienced separate themselves.
• “How would you apply backpressure when a downstream service slows down?” — bounded channels and load shedding, not unbounded queues.

If a candidate is strong on ownership and vague here, they have written Rust but probably not operated it under load.

Step 6 — Benchmark SGD bands against genuine scarcity

Financial services and infrastructure employers sit at the top of these ranges; product companies adopting Rust for one service sit lower. Treat the premium as a scarcity tax, and remember that it is only worth paying when step 1 gave you a real answer.

Step 7 — Close within two weeks

Strong Rust engineers in Singapore are almost always employed, rarely actively applying, and typically talking to two or three companies once they start looking. A four-week evaluation loop is not a thorough process; it is a way of losing your first choice.

Set the loop before sourcing begins: screen, review exercise and async discussion inside two weeks, decision within three days, written offer within two more. We lost our preferred candidate in the first search to a company that moved in nine days while we were still scheduling a final conversation.

Hiring versus retraining

The question every team asks at some point. The honest answer is that a strong systems-minded engineer from C++, Go or Java reaches productive Rust in three to five months — faster with an experienced Rust engineer reviewing their work, much slower without.

The failure mode is retraining a whole team with nobody experienced to guide design decisions. The result compiles and fights the ownership model everywhere, which is worse than the language they came from. Hire one or two experienced engineers first, then retrain around them. That sequencing is the entire difference between a successful adoption and an expensive one.

This scarcity pattern is regional. Colleagues at HireDeveloper.ae see the same premium in Dubai, concentrated in fintech, and the team at JapanDev reports a deeper Rust pool in Tokyo constrained mainly by English-language requirements. Widening the search geographically is often more effective than raising the band. If you are standing up a team rather than filling a seat, our guide on how to build a backend engineering team covers the sequencing.

Frequently asked questions

The bottom line

Rust hiring in Singapore is not hard because the engineers do not exist. It is hard because the pool is small, largely passive, and easy to filter on the wrong axis. Test the compiler and everyone passes. Test async judgement and escape-hatch reasoning and the picture resolves in twenty minutes.

The step that saved us most, though, was the one before any of that: establishing that the workload genuinely required the language. One afternoon with a profiler would have saved five weeks of searching for a scarce and expensive skill, and would have found a query plan fix the existing team shipped in two days. Justify the language first. Everything downstream gets easier.