Two titles I really loathe right now due to misuse and horrifyingly broad expectations are DevOps Specialist/Engineer/Architect and Full Stack Developer. While "specialization is for insects," the expectation that every technical resource is a polymath is unrealistic. In job interviews now (both as interviewer and interviewee) I like to ask people what they're bad at. It is not meant to be a condescending question, but rather a way to understand what parts of work people will struggle with.

Too often in the current technical job landscape, hiring managers and recruiters are looking for a genius level polymath, someone good at everything thrown at them, even if they have little or no experience at it - and it is seen as failure during the interview process if someone admits that they do not check one of the thirty boxes on the job description.

Several years ago I was working with a client who was trying to fill a position, and candidate after candidate was getting shot down. The client was sourcing these positions from everywhere: internal recruiters, external recruiters, referrals, and staff augmentation shops, but they simply could not seem to find the person that would fit the role. As someone who had done a technical screening for several candidates and who was intimately familiar with the role that was being hired for, frustration was mounting for me as well.

I finally asked to sit through the interview process for the role which could be summarized as "Senior Administrator for Enterprise Content Management System." The day-to-day responsibilities were the operational management of the CMS and the long term responsibilities were configuration improvement, capacity planning, expansion and deployment of additional nodes, and working with development teams to improve development pipelines for the CMS.

That was the entire expectation of the job. The title for the job was DevOps Engineer. I could not tell you then, nor now, why the title had only one tie-in to the responsibilities.

So after one particularly successful tech screen where I recommended the candidate for a full interview, I sat as a fly on the wall (or the phone, in this case) for the interview process. The interview with the team that candidate would work hand-in-hand with went well; she demonstrated knowledge above and beyond what was being asked for, the interpersonal skills were as solid as can be for a phone interview, and really I felt the candidate was working to her strengths. It all went downhill after that.

The development team was the next group for the interview and began asking about her coding experience, specific java-related language questions, questions about development life cycles, her personal experience with other languages, and what she would do about certain bugs if encountered. I was gobsmacked. The questions had nothing to do with the job role, and certainly was nothing that I had screened for. Still, at the end of their time, the interview rolled on.

The next team was the systems team. Much like the development team, the questions that were asked had nothing to do with the job role. How do you identify performance issues on servers? How do you configure sendmail (an email distribution application common to the UNIX/Linux world)? How would you create exceptions for permissions on certain directories and files? The candidate gracefully acknowledged that these questions and the rest of the questions asked were out of her area of expertise, and she felt uncomfortable with attempting to answer them.

The interview wrapped and while the candidate surely felt horrible from the sheer lack of knowledge she was able to exercise, I was livid. The second and third groups of interviewers had nothing to do with the role, and it had become clear that the problem lay within the hiring process.

I circled back with my point of contact at the client and she immediately let me know that the developers and systems team did not feel like she was a good fit and that they would likely pass on this candidate too. I, at that point, asked why they were involved when they were asking questions unrelated to the job role.

The response: "All DevOps engineers are interviewed by the same three groups." I took some time to process that and finally had to explain that the title given to this person was not the job they would be doing, and asked if the job description had been circulated to the people doing the interviews. Of course it had not - the interviewers were asking questions they always asked.

Not every person is good at everything, and even if the role had been a true DevOps something-something or a Full Stack Developer, there are going to be gaps in knowledge. I'm not going to expect someone to know every specific configuration management tool, container optimization, be a product SME, know SQL, know NoSQL, program in four different dialects of assembly language, be able to educate new hires on the pros and cons of different cloud providers, and play basketball, baseball, and hockey at a professional level.

There are few Bo Jacksons in this world - people who have the capability to operate at an extremely high level for multiple sports (American football and baseball, respectively), and the expectation that technology professionals do not just two things exceptionally well, but everything exceptionally well is ridiculous.

After circling back with the client about the job role they were trying to fill, they decided that yes, the process was overkill, and yes, they did want to make an offer to the candidate that I sat through the interview with, three weeks later. I called the candidate to feel them out and was told in a straightforward manner that they would not accept the offer even if one was made because she did not feel that the company understood what it was trying to accomplish. I wished her good luck and passed that information back to the client.

Expecting a candidate, any candidate, to not only check all of your "must haves," "nice to haves," and "wishes" but excel at every single one of them is unrealistic. Any candidate that can demonstrate, not just say, that they meet every single criteria should likely be hired on the spot. Expecting the later is a set-up for failure, as is expecting a candidate to even meet all of your "nice to haves" and "wish list" items.

My "what are you bad at?" question is usually followed up with "what are you great at?" because I want to know where to expect a candidate to shine, not just what to coach someone on.

Hiring for failure, to me, means that I expect that the candidate will be good at every single item on a job description - and penalize them either during the hiring process, or worse, post-hire, for not being that genius that is wanted. Hiring for success means understanding the core requirements for a role, finding the candidates that meet those core requirements, and being able to coach or mentor them on the rest.