Where I work, we needed to add some capacity to our product development team. It was a short term need that could have turned into a long-term need if things go well. We were looking for a contract developer for a three to six month contract. Sounds easy enough, but there were some complicating factors:
- In order to help with the short term need, we had to get the person in pretty quickly.
- We’re didn’t have a lot of time to devote to recruit someone.
- Our current team is very effective.
The first two items are typical of any team needing to increase capacity. Item number three is where it gets interesting.
When I say that the current team is effective, I mean that we get a lot done, we enjoy the work, and we enjoy working together. We believe that the product and the codebase is getting better with each sprint.
I attribute this to core values we have as software developers:
agile: We believe in deferring decisions to the last responsible moment to keep our options open and to be able to adapt.
object oriented/domain driven: We start with the domain concepts and the object model and not the database. We’ve leveraged NHibernate on the server and object serialization on the device to eliminate buggy hand-coded SQL.
software craftsmanship: We view software as a craft to be mastered, not by learning a new technology like WCF or WPF, but by developing sound judgment and applying the basics like those expressed in the SOLID principles.
XP/Scrum: We embrace the engineering practices expressed in eXtreme Programming: collective code ownership, continuous integration, pair programming, and automated testing.
The developer we add to the team must already value these things or must adopt these values to work effectively. A developer arguing to implement a stored procedure on the next feature because it would be more efficient (whether right or wrong) would be counterproductive. Someone opposed to pairing on tasks would reduce the team’s energy and be a distraction.
The first problem is that it is difficult to communicate the values that make our team effective to a recruiter that doesn’t have the context.
Recruiters tend to fall back on what they know… more experience and greater sense of leadership is better. This leads to a paradoxical problem: the more experience a developer has and the more leadership he has shown, the more important it is that he (or she) be a fit for the team. Less experienced developers are 1) more moldable and 2) less responsible for their experience.
The Advantage of Inexperience
Less experienced developers tend to be more open to learning new skills and adopting new values. The good ones recognize that they have a lot to learn—both in techniques and what fundamental values lead to better software.
Less experienced developers also tend to have less control over the the technology and methods they use on the job. They often don’t know what to look for in accepting their first job or two and don’t have the influence to change the direction once they get there. So, I hold less experienced developers less responsible for their lack of experience with object oriented, domain driven technologies and insistence on agile methods.
The Burden of Experience
Developers with many years of experience tend to be the leaders within their teams and organizations. They are the ones who drive the technical decisions and shape the values of their organizations. Because of this, we have a higher expectation that these developers are experienced in the techniques we use and hold the values that we hold. If they don’t, it is mostly likely that their convictions are more settled and they are much less likely to change.
Communicating to Recruiters
Evidently, I was ineffective in communicating this idea to the recruiters who were helping us. Recruiters continued to send people to us touting ten years of SQL Server stored procedure experience or any combination of Microsoft technology TLAs. I don’t think they understood what I meant when I would said that a particular person had too much experience (of the wrong kind).
So, I brainstormed with the team and tried to spell it out with a diagram that looked like this:
I thought maybe the picture would do what the thousand words hadn’t. No such luck… I had to explain the chart to guys on the team; so, there was no way this would help the recruiters. Undaunted, I made one more attempt, this time with a simpler drawing:
I thought maybe this “magic quadrant” style graphic would work better, but consensus was that it still didn’t make it simple enough.
So, I gave up on the conceptual approach, and boiled it down to some questions, based on the years of programming experience the person has.
For developers with 1 to 4 years of experience, only one question:
Would you like to work on a agile team?
I went on to explain that we think a less experienced developer will adapt to our style of working if he/she is interested in learning the way we do things. We also think it will be very valuable and marketable experience.
For developers with 5+ years of experience:
What are the SOLID principles and why are they important?
What are three principles of Domain-Driven Design?
What does CQRS stand for?
What is your favorite ORM and why?
What CI tools have you used?
The candidate should be able to answer at least 3 of the 5 questions without hesitation. Someone without the experience we are looking for will probably not recognize the terms and won’t be able to answer them.
The idea was that an experienced developer who does not embrace the agile/DDD approach would not be familiar enough these terms that are peculiar to that world to answer the questions. The answers themselves are not that important (anyone does not use them won’t be able to interpret those answers, anyway), but familiarity with the terms indicates that we should talk to the person.
Because of some short-term issues, we put off the hire. I am hopeful to give this approach a try soon, though.