We’re Bad at Interviewing Developers – Interview with Kerri Miller

> I don't understand what she's talking about here. Every time I see a job opening, the software hiring manager and the team peers know there's a pain point that needs to be solved. E.g. "We need to an embedded C programmer to make this firmware talk to our USB protocol". "We need a developer to port the Java code to Go." "We need to expose our mainframe transactions as a REST API", etc.

Not necessarily here, but there are also a lot of buzzword soup and horribly vague reqs floating around out there. Just browse Dice or Indeed.

> I'm not sure where her experience with whiteboarding comes from. In my experience, companies use whiteboarding to sketch out algorithmic thinking. Whiteboarding is the opposite of reciting trivia such as the "3rd parameter to an obscure library function" Interviewers don't care about perfect syntax or missing semicolons.

My experience has been that significant numbers of interviewers want working code on the whiteboard, Amazon in particular. If whiteboard interviews were what you describe, I and large numbers of other people would not hate them so much.

It isn't just whiteboard interviews, either. I have had phone screens where my Linux programming skills were judged based on how well I had memorized POSIX manpages. Maybe I have just had bad luck in drawing interviews, but then maybe you have had good luck. I don't know. I can dig up anecdotes from around the web to support both our experiences.

I like the spirit of this, in that I personally enjoy working some in other areas. Plus, I think dividing out work like "analyst" and "architect" can be super dangerous: it shifts individual focus from project success to looking like an awesome producer of architecture documents or analysis documents.

On the other hand, I think the model you suggest would also be problematic because on a project of any size you need to glue back together a lot of very thin slices. It adds the problem that no one person is going to be amazing at all those things, so a fair bit of important work will get done poorly.

I think the best model is instead cross-functional, closely collaborating teams where the decision about who does what is extremely fluid. That gets the benefit of lots of people doing (and understanding) different sorts of work. But it lets key work be done by people with strong expertise.

Real-world examples of this include IDEO's pursuit of "T-shaped" people:

http://chiefexecutive.net/ideo-ceo-tim-brown-t-shaped-stars-...

And Atomic Object's use of "poly-skilled, co-located teams of generalists":

http://spin.atomicobject.com/2011/09/16/poly-skilled-teams-d...

I wish you could see how a potential employee acted in a Slack room and in pull requests for a week or two before hiring them. (It's doable, but fairly rare in the industry right now.)

As we move more and more towards working in a distributed fashion, using tools that don't require us to even meet someone in person for months at a time, it's a little strange that there's so much emphasis placed on in-person interviews (which is inherently a fairly stressful process). How someone communicates in person is fine, but that's sometimes only part of the picture.

On top of that, some people are much more comfortable communicating over the internet, and weighing in-person interviews so heavily ends up discounting their real talents. Ideally you find people have skills with both asynchronous and synchronous communication... but you need to be keeping an eye out for both qualities for that.

Also if the company ends up being a bad fit, then it looks less bad on the person's CV than if they join as a perm and then leave after a few months.

Depends on the individual's preferences and life situation. I was offered a contract-to-hire position earlier this year, and turned it down because the contract term happened to coincide with the expected birthdate of our third child. Even though I was confident that I would succeed in the position, I didn't want to deal with any uncertainty around that date. Also, in the United States, health insurance is usually tied with employment; while the ACA (Obamacare) has made it significantly better with the introduction of the exchanges, it's still a hassle to switch insurance providers, especially around a major life event such as the birth of a child.

In my particular case, the company I did opt for ended up being a bust, to the point that I resigned without having another offer in place. It ended up working well—I'm in a job now with tons of job security, good pay, a good work environment, and interesting work—but I ended up in the exact situation I was hoping to avoid when I rejected the CtH position.