A guide to hiring a Solidity developer
Solidity is a programming language for contracts that run on the Ethereum Virtual Machine. Its own documentation calls it statically typed, with a curly-bracket style that will feel familiar to people who know JavaScript or C++. It supports inheritance, libraries and user-defined types. This page is about the language and the daily work in it. If you want help choosing a network or building a full app, see the pages for Ethereum, blockchain and web3 developers.
What the work looks like
A Solidity developer usually starts with a short description of what the contract must do and who may do it. Then they write the contract, a set of tests, and a script that deploys it to a test network. They run the tests again after every change. They look at what each function costs to call, and they keep notes so another person can pick up the code. Most of the day is spent reading code and tests, not typing new lines.
Why the language needs care
Contract code is public, and once it is deployed it is hard to change. Every function that moves value is a place where a small mistake can cost a lot. The language also has its own quirks. Data can live in storage, in memory or in call data, and each one behaves differently and costs a different amount. The compiler changes between versions, so a developer must know which version the project uses and why. Newer versions check arithmetic for overflow by default, and an unchecked block turns that off for a reason that should be written down.
The jobs people hire for
The first job is a new set of contracts for a product, with tests from the start. The second is a take-over. Code exists, the original developer has gone and someone must understand it, test it and extend it. The third is a clean-up before an outside review, so that the reviewers spend their time on real risks and not on messy code. The fourth is cost. Users complain about fees and a developer is asked to cut what each call costs.
How a Solidity developer differs from other roles
A smart contract developer is the wider title and may also work in other contract languages. An Ethereum developer adds the network, wallets and layer 2 choices. A web3 developer or blockchain developer looks at the full product. A Solidity developer is the person who lives in the contract code. If that is your main need, you are hiring for the right thing.
When a Solidity developer makes sense
- You have a clear idea of what the contracts must do and need them written and tested.
- You already have contract code and need someone to take it over or extend it.
- Users find your contracts too costly to use and you want the gas use looked at.
- You plan an outside review and want the code and tests ready for it.
- You want a long-term engineer on your contracts, not a single short job.
If you are still deciding whether you need contracts at all, talk to us first. Many products work better with a plain database, and a developer who says so is saving you money.
Reading a Solidity developer’s background
Ask for contracts they wrote that are live and can be read by anyone. Look at how the code is laid out, how the tests are written and how they dealt with feedback from reviewers. Be careful with a profile that lists many networks and no code. Ask what they would write differently today. Good answers are specific and admit past mistakes.
Interview questions to try
- When do you use storage, memory or calldata, and what does each cost?
- How do you decide which functions can be called by whom?
- What would you test for a function that sends value to another address?
- How do you decide between a fixed contract and an upgradeable one?
- Which compiler version would you choose for a new project, and why?
Strong replies come with reasons and a real example. Take care with anyone who talks only about speed and never about checks.
Run a small paid exercise
Set the same short job for each finalist. Options include writing a small contract with tests from a one-page spec, reading a short contract and listing the risks, or cutting the gas use of a contract you already have. Pay for their time. Compare the code, the tests, the questions they ask and how they explain their choices.
Agree how the code is handed over
Agree on one repository in your name, a review step for every change and a rule that nothing goes to a live network without your approval. Keep the deployment keys and admin wallets with you, not with the developer. Ask for short notes on each contract and a list of the commands that run the tests. That way the project survives a change of team.
Preparing for an outside review
Independent security firms are separate businesses that you hire yourself. A good developer helps by freezing the code, writing a short spec, cleaning up comments and handing over a test report. Leave time for the findings and the fixes that follow. Treat the developer as one part of your safety plan, never the only part.
Mistakes to avoid
- Hiring for the number of networks on a profile and not for readable code.
- Letting the developer hold the only copy of the admin keys.
- Skipping tests on the odd cases because the normal case works.
- Changing the compiler version late in the project without a full test run.
Need a wider skill set? You can also browse our Ethereum developers for the network and the app around the contracts, or our smart contract developers for work in other contract languages too.