Many of you know one of my passions is entrepreneurship. This is part of the reason I became a web developer and one of the reasons I love building Buink.
Part of entrepreneurship is hiring the right people. Hiring is hard and it can make or break your project and company. Hiring developers is even harder because of the lack of supply, the difficulty in assessing skills, and the long-term consequences the wrong hire can have.
This is why I enjoyed reading Fletcher’s recent post this morning, “The hacker’s guide to hiring software engineers.” He included tons of great resources and ideas. It is definitely worth a read.
Inspired by his post I thought I’d add two additions, from my point of view, relating to hiring contractors vs employees and testing potential developer hires.
Contractor vs. Employee
I agree with his section on contractors vs. employees in many instances, but being that I’m a contractor and not interested in being an employee (and probably never will again) I’ve put a lot of thought into the question and summarized several good reasons startups and other companies may want to consider contractors as part of their technical strategy.
Testing Potential Developers
Fletcher has some great recommendations on testing potential developers and in many instances, a test can be helpful. However, I’ve never seen this done well and I have been asked to take these kinds of tests many times. I’m not saying it can’t be done, but I would love to see it improved in the following ways:
- Only send people a test if you’re serious about moving forward with that person. Vet them quickly over the phone first.
- I see companies all the time that ask 10 or 15 developers to take an hour test (unpaid) when they’re only planning on hiring one. I think everyone could agree that is a waste and, some might say, even disrespectful to other people’s time.
- Make the test relevant to the type of work you’ll be asking of the developer. This seems obvious, but trust me, it is not.
- Decide on the first task you’d ask the developer to do and make that the test question. If it is database work you need, ask them to setup a model. If it is css work, ask them to create a list of items that is responsive. If it is Angular work, ask them to create a directive that has an api.
- Too many times people get these questions that have nothing to do with day-to-day coding but have too much to do with nuances of a language that are rarely used in practice.
- So, they end up hiring book smart developers that sometimes have little experience in practice. The questions you choose should be geared to the types of coders you want to hire, street smart, or book smart.
- That is not to say that some theoretical questions aren’t good, but in my experience, the biggest driver of projects coming in under budget and on time is street smarts.
- This leads me to my #1 recommendation for hiring developers. It is related to Fletcher’s tip on a contract-to-hire relationship but a little more specific. Send them a small paid task, maybe 8 hours of work. Have them track their time and see the quality they send back. If they do well, send them more work. If they keep doing well, make them an offer. I’ve had ton’s of success with this strategy.
