If you were going to give someone a [insert your technology stack] test, what would you have them do?
This was the question someone asked me today in relation to hiring programmers. Given my experience (and the fact that I’m the technical lead), here was my advice…
I rarely give anyone tests. I hate code tests. You have to build them. Some really good people are not good at them and/or don’t perform well when on the spot. I hate taking the tests myself, and I’m not good at them, but I’m a good programmer. We might be better working with something, molding and crafting it while being passionate about the problems we’re solving and products we’re building.
First, I wouldn’t hire so fast. Hire slow, because both hiring and firing is painful and time consuming. Instead, give prospective employees small projects, and increase the project size until you feel comfortable bringing them on full time. This saves you time, money, and effort when they don’t perform. Simply stop working with them. No need for warnings, documentation, or corporate policies and/or governmental regulations to get in the middle of things. Just simply move on.
Second, I simply ask for their github account and a code sample that they were proud of. The combo tells you a ton about them. This is where they get to shine. And if they don’t shine bright enough, that’ll be obvious.
Their github account also tells you what they’re involved in outside work. It will show what they’ve contributed to and what they’ve worked on.
Third, I always looked for people who knew the tech stack already. I like people who learn fast too, but the best option is to find someone who learns fast, but already knows what they need to know to succeed on the first small project given to them.
Here’s a bullet point list of other advice I gave related to the subject of hiring coders:
- Do NOT pick someone who is less than or equally as talented as you. Just don’t.. It’s time consuming to teach people things. If you’re going to pay someone, I’d pay for them to teach me, rather than pay them to learn.
- You want someone you can respect and bounce ideas off of (again, smarter than you). Opinionated is fine and good, but you don’t want someone who’s stubborn. They must be able to listen as much or more than they talk, who can critique the process and/or solution you are proposing, and who brings their own ideas to the table. But when the cards are down, they do it the way you want them to.
- Before you hire anyone, make sure you know why you’d fire them, and make sure you are willing and able to fire them if they meet those conditions. This gives both you and them a similar page to work off of. They’ll know where they are at any point in time based on your feedback, and it won’t be a surprise if things don’t work out. Understand where you are as an employee at any point in time makes for great working conditions, which is one less thing they have to think about, making them more productive.
What advice do you have on the subject? How do you hire coders? Leave a comment and add your advice.