How Web3 is different from classical architecture
You probably already know that Web3 stands for decentralized applications. When recruiting blockchain developers you'll need to understand the main differences between Web3 and classical architecture.
Front-end and back-end
As for Web2, in Web3 you still have front-end and back-end developers. Front-end applications basically provide a gateway between browsers and your application user interface and blockchain. In the Web2 world, you would have ReactJS / AngularJS developers building an application that connects through a REST or GraphQL API to a back-end application.
In Web3 the back end is a distributed application that runs on smart contracts. Smart contracts are small programs that are executed on a distributed network of nodes. Each execution of a smart contract costs you fees (gas). Web3 back-end developers usually will have to master Solidity a decentralized language to build smart contracts. It's a complex language that cannot be mastered quickly, at least 1 year of experience is necessary to become a somehow efficient Web3 developer.
To interact with the blockchain a Web3 developer will have to use HTTP Gateways (for example Infura, Alchemy, and Quicknode), but that interaction will be read-only. If you want to write data on the blockchain, you'll need to connect a Wallet (like Metamask) and use a browser extension, which will inject some javascript in each page you show to your users, therefore authenticating them on the blockchain and offering a way to put data there.
Hire Web3 developers
Web3 stack to master
Web3 stack is very different from classical web2 applications, don't be surprised with absolutely unknown libraries and languages!
First, you need to understand that there are multiple blockchain technologies split between the ones running on Ethereum Virtual Machines (EVMs) and the others (non-EVMs)
EVM Blockchain Examples
- Ethereum - Original EVM smart contract platform
- Polygon - Ethereum sidechain
- Arbitrum - Layer 2 blockchain using Optimistic rollups and multi-round fraud proofs
- Optimism - Layer 2 blockchain using Optimistic rollups and single-round fraud proofs
- Hermez - ZK rollup Ethereum Layer 2 network managed by Polygon
- ZKSync - ZK rollup Ethereum Layer 2 network using SNARKs
- Starknet - ZK rollup Ethereum Layer 2 network using STARKs
- Avalanche - EVM-compatible Layer 1
- Cronos - EVM-compatible Layer 1
Building on EVM blockchain will require your back-end web3 developer to master one of the following development environments:
- Hardhat
- Truffle (actually 3 developer tools: Truffle for developing and testing, Ganache to create local blockchains, and Drizzle for front-end)
- Brownie for those who prefer python
Non-EVM Blockchain Examples
- Flow - Layer 1 using Cadence, Flow's native resource-oriented programming language
- NEAR - Layer 1 using Rust or Assemblyscript for smart contracts
- Solana - Layer 1 using Rust C, C for smart contracts
- Terra - Layer 1 using Rust for smart contracts
Other technologies that might be mandatory for a Web3 candidate
- Back-end Web3, building smart contracts: Solidity
- Quickly experiment with Solidity : Scafold ETH
- React Webhooks on the blockchain: Wagmi
- HTTP Gateways: Infura, Alchemy, Quicknode
- Wallet connection: Wagmi or Rainbowkit
- Connect Ethereum: Ethers.js, Web3.js
- Decentralized storage: IPFS or Swarm
Web3 CI/CD and testing
Unlike standard web applications, which can easily simulate a user workflow for full-scale testing, web3 applications suffer from a number of challenges. One major challenge is that they work within a constantly evolving environment, where each transaction must go through multiple layers of approval before being finalized. Another issue is that web3 apps require a user to download a separate client application, which often requires a third party to verify transactions.
Ethereum blockchain ecosystem, you can test smart contracts with Foundry, Dapptools, or Hardhat, which usually also provide an Ethereum Virtual Machine (EVM) runtime for you to interact with the smart contracts locally. In a similar fashion, Jest and Mocha are commonly used to test web applications.
To test Web3 applications your developer will need to adopt 3 potential strategies:
- Mimic the user
- Mimic the stack
- Mimic the workflow
Mimic the user
We can use a Burner provider within the Ethereum world. Originally introduced by Austin Griffith, a burner provider is an Ethereum wallet powered by a private key stored in the browser storage. By having the provider stored locally, one can quickly sign transactions as a “live” user, which even though is not at all ideal for real digital assets, is great for local development and yes, end-to-end testing.
Mimic the stack
Depending on the blockchain in question, this can be a daunting task. As mentioned before, within Ethereum, there are extensive tools to make this happen, thanks to the vibrant community around the project. For our example, we’ll be using Hardhat, which is able to spin an EVM-compatible node, exposing a series of RPC calls** that can help us fake even an existing user. Additionally, we’ll spin up a TheGraph subgraph, used by our demo application to expose a GraphQL server for us to query.
Mimic the workflow
The last step is then to mimic the workflow of your app. You can do so by interacting with your smart contract through your front-facing user interface (UI). Any errors in your UI should be detected by your integration tests. In case you skip your own UI, you render the entire test useless, as the connection between your smart contract and your UI is what we're trying to test.
There are a few end-to-end test runners like Cypress, but I’ve enjoyed using Playwright. To mimic your user’s workflow, a Playwright test would look something like this (the entire code available here).
Web3 interview questions
What are the common smart contracts standards?
- ERC-20: Token Standard
- ERC-165: A standard to publish and detect what interfaces a smart contract implements.
- ERC-721: Non-fungible token standard
- ERC-1155: Multi-token standard
How much gas does a simple Ethereum transaction cost?
- A simple transfer of value requires 21'000 gas
What is an ABI?
- ABI is an acronym for Application Binary Interface
- The ABI is the interface to interact with our smart contract
- The ABI can be generated from your smart contract source code (you have to compile it)
Why is is hard to generate random numbers in a smart contract?
- Solidity contracts are deterministic. Anyone who figures out how your contract produces randomness can anticipate its results and use this information to exploit your application
In which two scenarios a fallback function (defined as payable) gets called in Solidity?
- A contract receives only ether and no data (msg.data)
- No function name matches the called function
What is the difference between ERC & EIP?
- Ethereum Request for comments (ERC) define standards for the usage of Ethereum
- Ethereum Improvement Proposals (EIP) improve the Ethereum protocol itself
List and explain the parts of EVM memory.The memory of an EVM is divided into three types:
Storage:
- Storage values are stored permanently on the Blockchain network
- It is extremely expensive
Memory:
- Memory is a temporary modifiable storage
- It can be accessed only during contract execution. Once the execution is finished, its data is lost
Stack:
- A stack is temporary and non-modifiable storage.
- Here, when the execution completes, the content is lost.
In which circumstances would you use the new CREATE2 opcode to deploy a contract?
- When you need to know the address that the future contract with a certain bytecode will use before actually deploying it.
If you want to use delegateCall to call an interface function; how do you calculate the function signature?
- It’s the first 4 bytes of the keccak256 hash of its canonical signature, or theInstance.theFunction.selector.
How can you send Ether to a contract that doesn’t accept Ether (i.e. there is no fallback function or the fallback function always reverts)?
- Use selfdestruct, because it doesn’t execute the fallback function.
Where to find the best Web3 developers?
Eastern Europe countries (Georgia, Ukraine, Poland, Armenia, ...) have the largest pool of experienced front-end and back-end developers. Most of the developers will ask to work remotely and it's a good thing when you build a decentralized application!
code.store has developed unique expertise in hunting, hiring, and paying remote Web3 developers. Our unique assessment tests include more than 50 questions. We conduct an extensive analysis of each candidate's previous experiences, their individual contribution to those projects, and reference checks.
