Ask HN: How do you assess Junior Developers before hiring them?
Which extraordinary or new methods do you use for assessing Jr candidates? I've heard about trial hiring, what do you think about it? Perhaps, just tests or only interviewing are enough?
13 comments
[ 2.8 ms ] story [ 37.1 ms ] threadThe thing you have to remember when hiring junior is the burden of making them effective is on you.
The best junior tech people I have ever hired was a intern who was a wedding planner, a veteran who was a pharmacy tech, an early Apple genius, and a professional musician. All are in senior tech or dev roles and two had BAs.
Most interviewing techniques filter the top and bottom of the talent pool. Large organizations are fine with this. It's less risk, more control, and if they wanted a genius, they'd just acquire.
So you don't want to follow thr FAANG style of recruiting. The best ones that do well with that filter have already been snapped up anyway.
One of my favorite tricks is just to ask them to build something. Minesweeper or a roguelike, even if they're a web dev. The idea is not to have them finish it in 4 hours but see their approach.
Do they write specs? Do they write tests? How much do they design for? You probably don't want to hire someone who designs for a week when the target is 2 hours.
What's the balance between planning and development? Usually the bad ones have none of either. It also tests how they deal with huge problems, something that happens all the time in this field.
Test for whatever you're hiring for. If you don't optimize much don't test too much there. If it's a front end job, get them to do some animations. The best ones have some prior experience before the job, see if they'll surprise you.
The best I have seen has been where the company hires them while they are student for a co-op / intern program. You must pay them a decent wage. You must give them real work.
Then you have to establish criteria for hiring. Note if you do not pay them a good wage as an intern, they will look elsewhere for a job.
For criteria I recommend:
1) do they fit / can they get along 2) honesty - this one is tougher than it sounds. When they screw up do they tell you or hide it? When they do not know an answer do they make something up 3) can the learn - listening is different than learning 4) are they inquisitive, do the ask question, do they challenge you "why do we do it this way?" "have you thought of doing it another way" 5) raw talent (notice this is last on the list)
Of course most of this criteria applies to regular job interview.
<begin bitch-fest> When I hear of people having tests or coding projects on an interview it makes me sad. The person doing the interview should be able to read your resume and determine if the interviewee has the skills / talent. They should be able, with a set of well formed questions be able to determine the parts that are not mentioned in the resume and validate your resume.
Myself I have a set of questions I use for all candidates, and a set that I make up for each candidate based on their resume. It takes time, but when you consider the cost / value result, it is time well spent.
Sadly most interviewers do not know what they are doing.
Of course this is where HR should be doing the training, but I have met very few HR people who I thought were capable of their jobs.
Remember hiring someone is not like buying a computer or a car, which are easily disposed of. It is closer to a house or getting married, separation will be painful, and you will spend a lot of emotion with this person.
> "We let candidates do this work on their own time, from their own home, whenever they wanted to"
I'm curious -- how do you control for someone who successfully accomplishes the coding talk, but needed 40 hours to do the work which you expected to take 4 hours?
It becomes less of "Get this thing done by today" and more of "Get these 5 things done by the end of the week".
One developer might just leave it to the last minute or perhaps fail to deliver if they underestimate the scope of work, failing to deliver makes him more unreliable and shows he has a poor grasp on time management and needs day to day focus.
Another Developer may be more conservative with how much time they have available, but may still be working on a different wavelength in terms of day to day expectations, however at the end of the week, they deliver on time. This makes him more reliable and show that he has a good grasp on time management so far, so it shows that less day to day focus is needed on him.