On hiring developers and the MBA mindset

Posted by Leo Soto on June 21st, 2012.

As part of my MBA studies I’m reading a paper about agency theory which contains the following paragraph:

“Even when screening is very costly, however, it may still be the most efficient solution to the hidden information problem if the consequences of a hiring mistake would be even more costly to the principal. Such is most likely to be the case when differences in personal characteristics can result in wide variations in performance across agents and when variations in agent performance have a substantial impact on the principal’s ultimate profit”

— Agency Relationships in Marketing; Bergen, Dutta & Walker (1992)

Sounds familiar? Of course! The agent is a developer and the principal is whoever is hiring the developer.

And we know that screening developers is costly. Strategies from companies I have experience with vary from outsourcing the process giving a laundry list of expected qualifications to some recruiter (ouch!) to requiring a week of audition in which the applicant has to work in a real project and see at the end of the week if both sides still think it would be a good idea to move forward.

I have had influence over screening candidates also. I wrote a FizzBuzz-style test (well, a bit more difficult, but same category I would say) that my first employer still used for years after I left. Before that (in the same company) I wrote what was just a knowledge test of Java technologies.

In an objective fashion, the tests I designed were what technically I would describe now as “mostly crap”. But it was useful crap nonetheless! If someone failed the test they were probably lying somewhere in their CV. That usually is a bad sign.

Interestingly, our crappy hiring process based on those tests plus one interview was deemed by management to be too stringent. More than 90% of the applicants were filtered out by the tests, which when you have used a lot of time of your current developers in the interviews, test design and checking answers seems like a lot of time wasted.

I don’t remember the outcome precisely, but I think we (the developers) mostly stuck to our guns and most new hires did actually pass our stringent-in-management’s-view but in-hindsight-crappy process. I sincerely believe that part of the short term success of that organization is owed to the fact that most hires turned out to be good hires.

By the way, I haven’t said why I think the process were mostly crap. I think it was because we never looked for culture fit nor anything beyond technical competence. Ironically, the developers inside that organization recognized that what we most valued of the company (and the reason to stay there regardless of some bad episodes) was the culture. But we did not thought a lot on that when interviewing candidates. Doh

In Continuum we do not use any such test. I don’t think our process is perfect, but is has worked well so far. We hire when there is a direct recommendation of someone already working in our team. When people put their own reputation on the line vetting for both technical and personal skills of others, that is a powerful indicator. When there is not a direct recommended person, or when we have wanted to expand from our core social circles, we have interviewed people, we have tried to schedule auditions (usually not a week long, but pair programming still works well for auditioning over one day) and sometimes we just bet on people.

But the reason we can do that is because we are not growing our team like crazy. If you are growing your team aggressively and you are not one of those big companies in which geeks naturally want to work for (Google, Facebook, etc), you will just make plenty of hiring mistakes.

And I think that the mistakes will be made unconsciously, usually by management that do not get the fact that “differences in personal characteristics across agents developers and variations in agent developer performance have a substantial impact”.

Try to not work for such type of management. They will also undervalue you, thinking that good developers are easy to replace. They will call your team a “software factory”. Good luck explaining to them that if you really want to make such an analogy, the factory is the editor, compiler, debugger, etc., i.e the toolchain we use. Trust me, even when many good things might offset the lack of understanding of the nature of software development by management, the day will come and you will have no energy left to keep working there. I have been there.

Which makes me think that, in a way, this idea of management school I’m attending to is flawed. As if managing was the same challenge regardless of who and what you are managing. It’s not that they say that explicitly. If you talk to any sane person over a beer, they will usually say that sure, not everything is managed in the same way. But I have not heard, in any class, over more than one year, that you should understand what the activity you are managing is about. Or at least try to.

The implicit position that I sense in the business school is that specialization is good, and your specialization is in the management/business area. The whole “leadership” trend is in part fueled by the need to manage teams that do something you can’t possibly understand.

There is something very wrong with that idea.

Originally published at techblog.leosoto.com on June 21, 2012.