For most engineering roles, a candidate repository is a reasonable starting signal. For smart contract roles it is close to noise, and I stopped relying on it some time ago. The reason is structural rather than a comment on anyone’s honesty: this ecosystem is built on forking. Protocols are forked deliberately, templates are the recommended starting point, and tutorial code is everywhere. A repository containing several thousand lines of Solidity is entirely compatible with having authored almost none of the decisions in it. Here is what I use instead, in the order I use it.
Step 1. Decide Whether You Need a Solidity Engineer At All
This is the step that saves the most money and it is skipped almost every time.
Take any product described as a blockchain product and inventory what it actually consists of. There is a contract layer. Then there is an indexer, an API, a queue, a reconciliation process, a database that mirrors on-chain state because querying a chain directly is impractical, a web application, an administrative console, monitoring and an operations runbook. In most products I see, the on-chain portion is a small minority of the total system.
If you write one specification covering all of it, you will go looking for a scarce and expensive profile to do work that a strong backend engineer does better and faster. Draw the boundary explicitly: what runs on chain in one bucket, what reads from or writes to it in the other. Teams that do this almost always discover the first bucket is a focused piece of work for one specialist over a defined period, while the second is the team they actually need to build.
Step 2. Establish the Regulatory Context Before the Specification
In Singapore this matters more than it does in most markets, and it changes the profile rather than the technology.
MAS regulates digital payment token services under the Payment Services Act 2019 as amended, and licensing guidance for digital token service providers sits within the Financial Services and Markets Act 2022 framework. Published expectations include adequate independent audit arrangements proportionate to the scale and complexity of operations, and for new payment service licence applicants, independent external assessment of technology and cybersecurity controls. The current position is on the MAS payments regulation pages, and you should confirm your own obligations there rather than from any summary, this one included.
The hiring consequence is specific: an engineer working inside a licensed environment has to produce code that survives external review and has to document decisions while making them rather than reconstructing them afterwards. Some genuinely excellent smart contract developers have never worked that way, and a few actively dislike it. That is not a character flaw, but it is a fit question, and it is much cheaper to ask about at screening than to discover during an audit.
Our expert take #1
Ask one question early: tell me about a time your code was audited externally — what did they find, and what did you disagree with? The answer sorts candidates immediately. Engineers who have been through it describe specific findings, explain which ones they pushed back on and why, and talk about the documentation burden without resentment. Engineers who have not been through it either have no answer or treat the question as an accusation. In a regulated Singapore context the second group is a real risk, regardless of how good their Solidity is.
Step 3. Verify Authored Work On Chain, Not Activity on GitHub
This is the replacement for the repository review, and it is the core of the method.
Ask for deployed contract addresses with verified source rather than repository links. Then do three things:
- Check the deployment matches the story. Who deployed it, when, on which network, and is the source verified. A candidate claiming authorship of a production system should be able to point at it.
- Ask about one specific decision in the code. Pick an access control pattern or an upgrade mechanism and ask why that choice rather than the obvious alternative. Authors answer with trade-offs and constraints. Non-authors answer with definitions.
- Ask what they deliberately kept off chain. This is my favourite question in the whole process. Everyone who has shipped real on-chain systems has a strong, specific opinion about what does not belong on chain, usually formed painfully. People who have only written contracts in isolation have no view at all.
Testnet deployments are acceptable evidence for less experienced candidates, provided everyone is clear about what they are. What is not acceptable is a repository link offered in place of a deployment, because that is precisely the signal that forking makes meaningless.
Step 4. Replace the Take-Home With a Review Task
Take-home exercises are a poor instrument here. They take candidates a long time, strong candidates increasingly decline them, and what they measure is whether someone can write a small correct contract — which is the easy part of the job.
Instead, hand over a short contract containing deliberate flaws, give them twenty minutes, and ask one question: what would you refuse to ship here, and why?
Include a mix: an access control gap, a state change ordered after an external call, an upgrade mechanism with unclear ownership, and at least one thing that looks alarming but is actually fine. That last inclusion matters, because the failure mode you most want to detect is the candidate who flags everything indiscriminately. An engineer who cannot distinguish a real finding from a cosmetic one will generate enormous noise in review and will not be trusted by the rest of the team within a month.
Reviewing exposes judgement much faster than writing does, it respects the candidate’s time, and it closely resembles the actual job. Our broader guide to hiring application security engineers in Singapore uses the same principle for a different profile.
Need this profile without running the search yourself?
We source smart contract engineers for Singapore employers and screen them on verified deployments, review judgement and audit experience before they reach your calendar.
Lance-toi — brief our Singapore teamStep 5. Screen Testing Discipline Explicitly
Ask what their invariants were on the last system they shipped, and how they tested them.
This question is unusually effective because it is hard to answer convincingly without having done it. An invariant is a property that must hold no matter what sequence of operations occurs — total supply equals the sum of balances, no user can withdraw more than they deposited, the contract never ends up in a state with no valid next action. Engineers who have shipped value-bearing code think in these terms by necessity and will name three or four without hesitation.
Follow up on tooling: fuzz testing, invariant testing, fork testing against mainnet state, and what their coverage actually meant. The specific framework matters far less than whether they can explain what a passing test suite does and does not prove. The strongest answer I regularly hear is some version of: the tests proved the cases we thought of, and the audit found the one we did not.
Step 6. Probe Upgrade and Key Management Judgement
Most expensive incidents in this space are not clever Solidity exploits. They are governance and key management failures — an upgrade executed by a key that should not have been able to execute it, an admin function nobody realised was reachable, a multisig with a threshold that made sense at founding and not afterwards.
So ask directly:
- Who can upgrade this contract, and what stops them doing it at 3am?
- Where do the keys live, and who has them today versus who had them at launch?
- What is the procedure when something goes wrong in production? For immutable contracts, the honest answer is often that there is very little you can do, which is exactly why the previous two questions matter.
A candidate who treats these as operational details rather than design decisions is telling you something important. In a regulated Singapore environment they are also the questions an external reviewer will ask, so you may as well ask them first. Our note on building a cybersecurity engineering team in Singapore covers how this responsibility is usually shared.
Our expert take #2
The single most predictive trait I have found is comfort with saying no. On-chain code is expensive to change and sometimes impossible to change, so the engineer’s most valuable contribution is often refusing to put something on chain that does not need to be there. Candidates who describe talking a product team out of an on-chain feature — and explain the reasoning — are consistently the ones whose systems I see still running without incident two years later.
Step 7. Match the Engagement Shape to a Spiky Workload
On-chain work has an unusual rhythm. It is intense during design, specification and deployment, and then comparatively quiet, because deployed contracts are deliberately hard to change. A permanent specialist hired for a three-month problem spends months four through twelve underemployed, which is bad for them and expensive for you.
Three sensible shapes, depending on your situation:
- Permanent hire — correct when you will keep shipping on-chain functionality, and when the person is also willing and able to contribute to the surrounding backend between releases. Ask about that willingness explicitly at offer stage rather than assuming it.
- Contract engagement — correct for a defined build with a clear end. Structure it so that knowledge transfer to your permanent team is a deliverable, not an afterthought.
- External audit — necessary in a regulated context, but not a substitute for either of the above. An audit reviews what you built; it does not help you decide what to build.
Most teams end up with a contract engagement for the initial build plus a permanent backend team around it, which is also the cheapest configuration that works. If you are weighing engagement models, engaging developers as independent contractors in Singapore covers the classification side, and scoping backend development work covers the larger bucket from Step 1.
Where These People Actually Are
A note on sourcing, because the screening method only helps once you have a pipeline.
Singapore has a genuine concentration of this talent relative to its size, driven by the regional digital asset sector and the research and infrastructure work that has grown around it. The practical difficulty is that the strongest people are rarely on job boards and are frequently engaged on protocol work rather than looking for employment. They are reachable, but through their work rather than through a listing: the verified deployments you asked about in Step 3 are themselves a sourcing surface, as are audit reports with named reviewers and the contributor lists of infrastructure projects your own stack depends on.
Be realistic about competing offers. A capable smart contract engineer in this market usually has alternatives, including non-employment ones. The specification that wins is rarely the one with the highest number; it is the one with the most interesting unsolved problem and the clearest statement of what the system must guarantee.
For the regional view, our colleagues cover the Gulf side of the same search — screening blockchain security engineers for a Dubai crypto team uses a comparable method in a different regulatory setting, and free zone versus mainland hiring in the UAE is worth reading if the same team is being planned across both markets.
Our expert take #3
If you take only one thing from this: you do not need to read Solidity to run this process well. Every check above is answerable by a non-specialist hiring manager, because each one tests reasoning you can evaluate rather than syntax you cannot. The most common reason companies hire badly for these roles is not a lack of technical depth on the panel. It is deferring entirely to the only person in the room who claims to understand the technology — who is frequently the candidate.
What I Would Do This Week
- Split the specification in two before posting anything. On-chain in one bucket, everything else in the other. Most of your hiring is in the second bucket.
- Replace the take-home with a twenty-minute review task. Include one thing that looks wrong but is fine.
- Ask for deployment addresses, not repository links, in the very first message. It changes who replies.
- Add the audit question to the first call. What did they find, and what did you disagree with.
- Decide the engagement shape before you interview, not after someone good says yes.
Hiring one specialist and a backend team around them?
We source both in Singapore, screen on verified on-chain work and review judgement, and will tell you plainly when the role you have written is really two roles.
Lance-toi — talk to our Singapore teamFrequently Asked Questions
Do I actually need a Solidity developer, or a backend engineer?
In most products described as blockchain products, the on-chain surface is a small fraction of the system and the rest is ordinary backend engineering: indexing, APIs, queues, reconciliation, a web application and an operations console. If you write one job specification for the whole thing you will search for a rare and expensive profile to do work that a strong backend engineer does better. The useful exercise is to draw the boundary explicitly. Everything that runs on chain goes in one bucket, everything that reads from or writes to it goes in another. Once the buckets exist, most teams find the on-chain bucket is a focused piece of work for one specialist over a defined period, while the second bucket is the actual team you need to build.
Why is a GitHub profile a weak screening signal for smart contract work?
Because the ecosystem runs on forking, and a repository full of contract code tells you almost nothing about who authored the parts that matter. Template projects, forked protocols and tutorial code all produce impressive-looking repositories. The signal that cannot be borrowed is a deployed contract with verified source that the candidate can discuss in detail: why a particular access control pattern was chosen, what the upgrade path was, what the team decided not to put on chain and why. Ask for deployment addresses rather than repository links, then check that the deployer and verification line up with the story you are being told.
Does MAS regulation change who I should hire?
It changes the profile rather than the technology. MAS regulates digital payment token services under the Payment Services Act 2019 as amended, and licensing guidance for digital token service providers sits under the Financial Services and Markets Act 2022 framework, with expectations around adequate independent audit arrangements and, for new payment service licence applicants, independent external assessment of technology and cybersecurity controls. The practical consequence for hiring is that an engineer in a licensed environment has to produce work that survives external review and has to document decisions as they go. Some strong smart contract developers have never worked that way and find it genuinely uncomfortable. Screen for the experience of being audited, not only for the ability to write correct code, and confirm your own obligations with MAS rather than relying on a summary.
Should the role be permanent, contract, or handled by an external audit firm?
Usually some combination, and the shape of the workload should decide. On-chain work tends to be spiky: intense during design and deployment, then comparatively quiet because deployed contracts are, by design, hard to change. A permanent hire makes sense when you will keep shipping on-chain functionality and when the person can also contribute to the surrounding backend between releases. A contract engagement fits a defined build with a clear end. An external audit is not a substitute for either, because audits review what you built rather than helping you decide what to build. The common and expensive mistake is hiring a permanent specialist for a three-month problem, then watching them become disengaged when the interesting work ends.
William
Talent Sourcing Expert at HireDeveloper.sg. Builds screening processes and candidate pipelines for specialist engineering roles across Singapore and the wider region.