Friday, 3 May 2019

Good Help Is Hard To Find - Tips When Hiring Junior Developers

This is the fifth in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.


From a business perspective, hiring Junior developers gives you cheap workers who you can mould into the type of developer you want and need. But what are the pros and cons? Hiring a junior might be compared to adopting a child. It can be very rewarding, but are you really ready? In this article I will outline many of the things you need to expect when hiring a junior. I will suggest some tips on how tackle these issues and hopefully you will become a better teacher.

Why Should You Hire Junior Developers?

From a business perspective, they're cheap and mouldable. They generally have no opinion, and you can teach them the ways of the force. You can give them the trivial work that none of the other devs want to do.

From a non-business perspective it helps everyone grow. For example, having a junior gives your mid-weight developers an opportunity to do some mentoring, and hopefully develop some leadership skills. Also, it should go without saying that teaching is very gratifying.

Will They Slow You Down?

Juniors take time and effort. You need to mentor them, teach them, be their Yoda. All of this is in addition to your daily responsibilities. Be prepared for your other devs to dedicate some time to mentor them. They need to ensure the new dev is meeting coding standards, and actually performing.

If you have never taken on a junior before, then you might notice spending more time with them than anticipated. Keep in mind that they are doing the more trivial work which other devs don't want to do, or don't have time to do. This is the trade-off you need to come to terms with.

They Take Too Long?

Junior developers are not master time keepers (yet). Be aware that will take lot longer than expected. A typical junior is less likely to ask for help, and will sit for hours and days trying to solve a problem. Ideally they should ask for help to solve the problem, then go home and think about why the solution evaded them.

Juniors need to be told explicitly that they should ask for help early. If they can solve a problem in 1hr by asking for help then that is a lot better than trying to solve a problem by themselves in 5hrs. Regularly check in with them to ensure that they are making progress rather than chasing their tail. Reiterate to them to time-box their effort, then ask for help. Set a stopwatch if need-be.

Their Bug Count Is...

Oh boy, juniors have a lot of bugs in their code. They miss a lot of functionality, cause crashes, make your system unstable. Juniors are essentially code gremlins. I should know. I used to be one!

Accept that their output will be pretty bad at first. You need to be supportive. Help them develop habits to double/triple/quadruple check that they have met the acceptance criteria. Get them to sense-check their work with someone to ensure that they have good quality work. It is your job to ensure that they improve. Teach them that it's their responsibility to be better than they were yesterday. Get  them to keep a tally of their bugs each week/fortnight/month.

Their Code Sucks

Let's be honest... We were all juniors in the beginning, and our code was really bad. Code from juniors can have any combination of the following:
  • Excessive verboseness
  • Unreadable
  • Logically flawed
  • Horrible naming
  • Undecipherable dependencies
  • God methods
  • God classes
  • Mega anti-patterns

Be patient with your junior. Obviously if they're doing these things then you need to figure out how to be a good teacher. Give them some reading, send them to a clean code course, get them certified. Show them amazing code. Show them crappy code. Show them YOUR crappy code. Ask them to help you refactor some code you're working on. Ask them to pair program with you. Ask them to summarise a coding article for you. Help them realise that coding is like learning the violin. It takes years of practice, and even when you are good, you still make mistakes. 

They Have No Opinion

This is both pro and con. Juniors generally don't have enough knowledge or experience to have any useful input for some specific problems. On the other had, they don't have years of bias, so they can give you a fresh perspective to a problem.

One thing I find useful is to ask their opinion first. It actually helps me understand my own problem, while also exposing them to real world complex problems. My opinion is that by asking complex problems it will push their thought processes to another level. They will try to solve this complex problem, and be better for it. Remember to thank them for their input. They tried to help, and should be encouraged to keep trying.

Are They A Burden?

By now you have probably realised that you have to explain everything to them. If this is a big problem then perhaps you need to look at your organisation / team and see how it can be more accommodating to mentoring/teaching/coaching etc.

I have been in situations where the development team's reaction was "a junior is too much work, we're too busy to hire a junior". Does this sound familiar? It is a clear signal that people are overworked, and are being pushed to work harder and faster. Too much is being expected, and work is being shoved through your pipeline and pushed onto the dev team. The real burden might actually be up-stream. Fix that problem!

Juniors are not really a burden. You need to figure out how to leverage their current skillset, while also expanding it.

When They Succeed

If you have done your job as a mentor/teacher/coach/leader/Yoda, then your junior will quickly become a mid-weight. They will begin to feel confident, and grow. They will start to shine. One day you will notice a shift in the way they talk an give input. It's like a light-switch suddenly gets flicked.

It's a great feeling when you realise your junior has reached that next level. There are only a few things in the world that can give you this sense of pride. Your entire team will feel this. They all helped!

Tips When Hiring a Junior Developer

  1. Hire people who are hungry to learn
  2. Show them good code, show your own bad code
  3. Remind them that it takes years to learn a profession
  4. Be explicit about the the maximum time you expect them to spend before asking for help
  5. Be explicit about having their code checked before submitting a pull request
  6. Ask them for their help in solving your complex problems
  7. Remember that there are no bad students. Only bad teachers.

Final Thoughts

Juniors are great, and teaching them is extremely gratifying. However, this takes time, effort and patience. When they succeed, you feel like a proud parent. You want them to grow. If you are attentive, you can generally get them productive in a matter of months. If you're really really attentive then you can get them leaping to mid-weight productivity in as little a year or two.

Posts In This Series

  1. Interview Tips for Technical Leaders
  2. Tips To Ensure Quality Delivery When Outsourcing
  3. Tips When Taking On An Intern
  4. Tips When Hiring Senior Developers
  5. Tips When Hiring Junior Developers
  6. Tips When Offshoring Development Teams
  7. Tips When Hiring Digital Producers
  8. Tips When Hiring Remote People
  9. Tips To Improve Developer Retention (coming soon)
  10. Tips When Hiring Lead Developers (coming soon)

No comments:

Post a Comment