Sep 4, 2013

Filtering out a PITA developer in an interview

In the last couple of years I had been unlucky to work with a developer that I really hated. He wasn't a bad developer. In fact, he made some decent input into the codebase and had come up with some very good ideas. However, he also had some traits that were absolute roadblocks for me.
  • he was chatty: he loved to turn to me and distract me whenever a ghost of a question started to form in his head (I had to attend the birth pains of this question being phrased);
  • he didn't know to hold personal distance: he preferred to grab attention by touching you on the shoulder while sitting behind -- not something I like, especially when I'm concentrated on something and not expecting this shit;
  • he was slow: he talked slowly, he understood slowly, he browsed through the code fucking eternally, typing with one finger per hand and constantly slowly switching between mouse and keyboard; this slowness wasn't something you would notice instantly, but noticed very well after a 15-minute discussion if you wanted to get rid of him ASAP;
  • he loved to argue for the sake of the argument: on the one hand this and on the other hand that and fuck it's all so dialectic that we should probably not do anything;
  • he talked through every fucking smallest detail as if he was a novice instead of just discussing the main bigger parts and starting coding and then it will work out of course;
  • in the process of these eternal (initially that was *days* until we figured out what a pain it was) discussions he would forget things from 10 minutes ago and you would need to revisit them;
  • he loved to bitch about what a mess the existing (not written by him) code was; it's not that he wanted to offend, just I think because in his world there was smart him and dumb others, just as a principle, not you or me, but oh my god what a shitty method this is!..
  •  it was normal for him to ask a colleague of mine to give him a lift and during the ride to comment that the car was too small or the speed too low and how he could've done that faster if just walked; again: not because he wanted to offend, but rather because he did not care and (this is my subjective opinion) was a smoking stinking piece of shit;
  • he had salary larger than any of us, and at the same time he had no passion or enthusiasm for the project as well as no self-dependence, and the only times he e.g. overworked was when he figured out he would get yet more money this way.
I could continue this list eternally. Just to depict the level of my frustration from working with him I'll say that his presence made an otherwise perfect and thrilling startup project almost intolerable for me, and that working with him was the worst experience of 2012 for me, and that was a year when we e.g. split up with my girlfriend, so that should put it into some perspective.

Lyrics aside, I was often thinking if it could've been different -- if he could've somehow be filtered out by the interviews. I'm probably selfish here, but on the other hand what had his presence done if not destroyed the atmosphere in the group? Also, I saw him constantly doing things slower than they could've been, and when we later went to different projects in the same company, he failed to deliver on time by a factor of 10 maybe (weeks instead of days and none was ready when he left for a vacation) -- so overall I'd say that I would pretty much insist on not having such an expensive while at the same time useless and toxic developer in my group.

At the same time, I think to the interviewers he must have looked pretty cool: aged 40-something -- but we have some very good developers of this age in our company, some of the interviewers included; with 5+ experience in Java and 5+ more in C++ and so on; intelligently looking, calm (as a turtle), communicative... 

First, if there was a real task to be done (at home, on the scale of a day e.g.), he would certainly have failed it. Second, a possible test for him would be to give him some well-enough-written code and make sure he would 1) understand what it does, 2) reasonably fast, 3) mostly on his own and without constantly demanding clarifications from interviewers. Then to ask him to do a change -- ensuring the specification is really clear -- and make sure he 1) does it, 2) doesn't drag interviewers into helping him or constantly reassuring him he's doing ok, 3) doesn't pretend his own block is caused by others (bad specification, insufficient tooling etc). Another option would be to give some ok code and ask how bad he thought it was, ask to improve (in reasonable time), then ask how good he thought his code was. Another option: give a complicated task and a tool (library e.g.) sufficient to solve it, then see how fast he would do the task and how much he would blame the tool for delays. Or maybe a not so hard task and a not so sophisticated tool with a bug or two -- and check if he will fix the bugs or blame the tool.

And then -- then there should be some mechanisms to not have people stuck in teams they are unhappy with for years. And for me the lesson is: trying to play nicely is not worth the effort while there are so many tasks ready to solve and developers ready to help. Sometimes a coworker is a pain in the ass because he really is, not because your attitude is wrong.