11–20 of 121 posts
Here's the strategy we feel is working pretty well for us. First of all, our tech stack looks like this: Java/Spring(MVC)/MyBatis/Hibernate/etc Ruby/Sinatra/ActiveRecord/etc JavaScript/Angular/etc A bit of SQL (MS) We look for candidates of all skill levels who have experience with any "systems" programming language (Java/C/C++/C#) and any scripting language (Ruby/Python/JS). Once we've found a candidate that has any…
Here's a relatively novel idea (I guess): Outline exactly what you need the developer to do, and have them send in proof that they can actually do it. Previous projects, personal github experiments ... Most capable programmers will have something interesting to show. Right?
Talent is a function of experience. It's not that you shouldn't hire for experience - you should. The problem is that the model most people have for quantifying experience is flawed. As it says in the article, 5 years of experience for one person might be the same as 1 year for another. To solve the problem, we need to borrow an idea from RPGs: experience points.
The people who will understand this figured it out long before they were in a position to hire other people. It's just obvious and is repeated so much (don't hire for specific experience) that it is a cliche.
The people who don't get this will never get it, even if you paste stickers that say it on the windshield of their car and whisper it in their ear as they fall asleep each night.
So it's all great to repeat this for the 3 newbs who joined our community in the last 5 minutes and haven't heard this 80 times already this week, but it shouldn't be on HN's homepage.
It looks like I might finally get a job as a Django/Python developer after 3 years of unemployment. Encouraged by my local course for unemployed, I visited the company personally and handed them a dead tree CV and cover letter. I was mildly amused to find they seem to be just 3 guys in small dusty room. I ended up on a job interview of sorts I wasn't prepared for. It ended with a talk about games, Fallout and Counterstrike were mentioned. The best part for me, I got a homework assignment to test my skill.
Obviously, the best case scenario would be for companies to deduce who will have an affinity for certain technologies before they actually use them, but that's too complex and involves the type of decision-making to which HR departments are averse.
Reminds me of one section of the Stripe article on hiring: "Hire People instead of roles". I couldn't agree more with both authors (Stripe and OP). "One thing that's worked well for Stripe is bringing on people who didn’t have an immediately obvious role in the organization. If you can think of one thing this person can do, then there’s probably ten more you're not thinking of that he/she can do two months from now.…
Talent is a function of experience. It's not that you shouldn't hire for experience - you should. The problem is that the model most people have for quantifying experience is flawed. As it says in the article, 5 years of experience for one person might be the same as 1 year for another. To solve the problem, we need to borrow an idea from RPGs: experience points.
Funny, I think it's the other way around. Experience is a function of talent. Talented people gain xp points faster and therefore level up faster. Or rather, they have lower xp requirements for new levels.
Here's the strategy we feel is working pretty well for us. First of all, our tech stack looks like this: Java/Spring(MVC)/MyBatis/Hibernate/etc Ruby/Sinatra/ActiveRecord/etc JavaScript/Angular/etc A bit of SQL (MS) We look for candidates of all skill levels who have experience with any "systems" programming language (Java/C/C++/C#) and any scripting language (Ruby/Python/JS). Once we've found a candidate that has any…
Our dev team is even smaller than yours, and we also spend a lot of time getting to know developer candidates, of course. We've found it helpful to assign a programming project, but usually one that takes around 20-30 hours to complete. We like to pay them market rate for this work because we are busy with our work and personal lives and know they probably are too, plus we often try to give them a module we've been meaning to get started on, so we actually plan to incorporate their work into our codebase. It seems to be a very unique experience for developers applying to our company, and so far it's been very successful.