There are two types of hires. The one based on potential and the other based on experience.
Juniors you hire based on potential, seniors you hire based on knowledge and experience.
Evaluating Juniors
Juniors do not have much experience or no experience.
To evaluate them fairly, you can create a code challenge as a proxy to understand how fast they can learn.
A pretty good Junior will excel in the code challenge and they will probably code to impress. They will surprise you somehow.
Training Juniors
The best way to learn about the product and the codebase is to work on customer success by attending to customers.
Customers will ask as many questions as they can about any feature or part of the system.
They will also bring bugs, improvements, incidents, and feature requests.
The only way a developer can keep up with all these customer requests is to learn faster about the product and the codebase.
A simple bug can make them learn how the backend and frontend work, how we store some data in the database, how we receive and process webhooks, and our event-driven architecture running in our Kubernetes.
As they progress, you can assign them to harder and more complex issues and features. While solving this problem have a more senior engineer pairing with them to accelerate the learning.
In Summary
The job market is very competitive right now.
Only hiring Seniors is not very cost-effective. You need juniors for easier tasks.
Try to focus on these ideas to hire and train juniors, so they can catch up faster.
Great summary, Sibelius!
Additionally, I’ve seen two things work pretty well when training juniors:
- Bring them into design and architecture sessions. Even if they don’t contribute a lot, they’ll understand more about why the decisions are being made and the trade-offs;
- Give honest and robust feedback. Not only on knowledge gaps, but especially on what they’re doing well. This will keep people motivated and allow them to double down on their strengths.