Learn how to hire Solidity developers with a CTO’s vetting framework: test EVM depth, security mindset, audits, and on-chain proof.
Hiring a Solidity developer is harder than hiring a backend engineer because a smart contract mistake is public, hard to reverse, and can put user funds at risk within minutes. This guide comes from a CTO who has vetted Solidity developers for production projects, and it focuses on what actually predicts safe shipping: security thinking, EVM depth, and a verifiable on-chain track record.
Mistakes with backend services can be isolated, or even simply be rolled back. Smart contract mistakes however are there for everybody to see in an instant, can put user funds at risk in minutes, and are hard to reverse afterwards. If a contract that is deployed on the mainnet holds permissions (i.e. it controls who can call a function, price of a token, or how funds are to be moved) then bugs in such contracts are not defects, they are also attack surfaces.
Typical interview processes for hiring developers normally test a candidate’s problem solving ability as well as past experience with technology. That being said, when it comes to writing Solidity safely for deployment to mainnet, prior experience building Smart Contracts with the Solidity programming language is not enough. Thus, before interviewing candidates for hiring as a Solidity developer it is very important to test the candidate’s ability to write safe code as well as test their ability to make sound security decisions prior to writing the code.
Engineers working on protocol level contracts typically have a very different skill set to those engineers who work on application layer contracts. The latter group of engineers write lots of contracts that interact with a small number of core contracts. They are typically involved in the work of the frontend, indexer and the corresponding backend. They can use tools such as ethers.js or wagmi to interact with the contracts in the application.
Protocol engineers on the other hand typically write a small number of very complex contracts that store lots of state. They must typically worry about things such as storage layout, upgradeability, token related accounting, reward distribution, trust assumptions and more. Both types of contracts are required for any healthy projects and unfortunately are typically hired as “Solidity developers”.
The product starts out as a thin dApp on top of existing contracts. But within a few months, that dApp is full app with staking, a token and a treasury of funds for the protocol to manage. That means the app-layer Solidity developer you hire for the first month or two of a project is writing code that holds funds. So you really need to test for the role of protocol engineer, which is a very hard thing to do.
After that distinction is clear, this comparison helps:
| Area | Protocol engineer | App-layer developer |
|---|---|---|
| Main focus | Contract logic and state safety | Product integration and user flows |
| Core skills | EVM internals, invariants, upgradeability, testing | ethers.js, frontend integration, APIs, indexing |
| Typical risks | Fund loss, broken accounting, privilege bugs | Bad transaction UX, integration bugs, stale data |
| Best fit | DeFi, staking, token systems, vaults | Wallet flows, dashboards, contract interaction layers |
Verify the candidate’s work on the blockchain before the interview. All work a candidate has done on the blockchain is public and traceable therefore it is very easy to check if a candidate is lying about his past work. Thus if someone says “I Deployed to Ethereum” or worked on “DeFi Products” then ask for specifics such as: contract address, repository URL for the project, whether they were an author of an audited contract and if so what were the specific findings that they owned for and how were those issues fixed in the end.
A large red flag for us is the lack of mainnet addresses (i.e. testnet is not production so not relevant for us).
You should test candidates’ EVM understanding, security judgment, contract review skills and gas awareness. These are the core set of skills required for a contract developer to safely develop and deploy contracts that hold real assets.
It is a good idea to start with a number of questions about storage layout (how mappings are stored in storage, why a particular order of state variables is better than another when deploying an upgradeable contract, etc.). If someone does not know how mappings are stored in storage then they do not have enough experience writing production contracts to be a good hire at your company. Similarly, you should test their knowledge of how delegatecall works and what context is preserved for different proxy patterns.
Security thinking far exceeds the ability to write Solidity code at great speed. For example, do they know that checks-effects-interactions (CEI) helps against reentrancy but is not a panacea? How would the candidate implement access control on a smart contract-based treasury and why would they opt for a role-based approach over simple ownership? The engineers on the team must be able to map attack surfaces. In other words, who can move funds? Who can change parameters on existing contracts? What external calls does the contract make? What are the invariants of the contract (i.e. what must always be true)? The ability to identify these points of failure is the hallmark of a senior engineer.
Evaluating issues related to reentrancy and access control is very difficult for interviewers, because they require people with a lot of experience, i.e. senior engineers that have written and audited contracts for production deployment. If no one on your team has done that before, you essentially are just guessing when trying to vet candidates for issues like these.
Rather than holding candidates through a week long take-home test (which can be hard to judge) hold a 1-hour live review of a small contract (say 100 lines or so) that the candidate has never seen before, with one vulnerability and one design problem, and have the candidate explain his or her thought process along the way. The review can also show how a person communicates under pressure.
The concern here is not whether the engineer could optimize for slightly less gas in a few places (that is a style point and non trivial to fully optimize). But rather that they have written enough production Solidity code that they have an intuition for cost of storage writes, unbounded loops, large calldata vs. memory, expensive events, and bad batch behavior. We strongly suggest engaging with a services firm that already provides smart contract development services to your company. They can do a far better job filtering through false positives and false negatives for you in the hiring process.
Instead of being overly worried about “style” we should pay closer attention to the following red flags: The candidate copies patterns but doesn’t know the risk model behind them.
These are the patterns that deserve extra scrutiny:
Engineering mistakes made when hiring a Solidity developer for a company usually only become apparent on mainnet, when a contract full of money develops a critical bug. It helps to go through a process of review within a team before extending an offer, and have the contract(s) they write reviewed by a team of security auditors as part of a blockchain security audit before launch for all contracts, not just for big protocols.
In-house hiring for security engineers takes more time and more operating discipline than most product teams expect.
There is also concentration risk, i.e. a senior Solidity engineer in charge of the protocol logic for a given protocol could leave the company at the end of a quarter or year (when work loads are typically highest), causing significant problems for the team implementing the protocol (e.g. introducing security-related issues as they are written under extreme time pressure to try to hire an alternative engineer in time).
An agency makes more sense when the work is project-shaped, launch-driven, or uneven across the year.
In-house hiring makes sense for products that have continuous contract development, that have recurring upgrades of already deployed contracts, and have long-term protocol ownership. For projects that have very uneven amounts of work from year to year and which have large amounts of work that are focused around launch (i.e. implementation, test hardening, audit preparation, etc.), an agency makes more sense. The real advantage of working with an agency in this manner is that you get to leverage a working security process that already exists.
Such work is very different from staffing for a project and is instead in line with how most Web3 development work is actually done, i.e. many components are built, and launched together as a single large project (e.g. contract(s) + frontend + other backend services etc).
The framework for hiring Solidity developers is pretty simple and therefore easy to follow but hard to fake.
A short checklist helps keep the process honest:
Our cases page has some examples of our past work with contracts. If you are interested in hearing more about how this could work for your project, we'd love to set up a call with you.
The EVM, storage, external calls, access control, typical developer exploits that can be easily avoided, testing of contracts (unit, fuzz, etc), and for developers who manage user funds, how to reason about invariants, upgradeability of contracts, and how to review changes for issues that an auditor has found.
Have them go through a live contract reading session, and review unfamiliar code as if it were to go into production. Hopefully, they will uncover any flaws in the code including any that you planted as a “test question”.
When you hire Solidity developers, the first question is whether the work is continuous or bursty. Hire in-house for long-term core contract work (e.g. continuous contract development for your product, recurring upgrades to already deployed contracts, long-term protocol ownership). Use agencies for projects with uneven amounts of work from year to year that are focused around launch (i.e. implementation, test hardening, audit preparation, etc.).
This could take weeks to months (yes that’s a rough estimate) and then take couple of weeks to couple of months of onboarding before someone can safely own changes to production contracts.
