Hire talent, not five years with Java

Why did it make sense then?

>Hugely over-architected solution? Eliminated

For a code interview I can see myself over-engineering a solution even though my day-to-day coding style is all about flexibility and readability. In my mind being able to over-engineer shows an ability to code.

Perhaps the better approach to solving this problem is to stop repeating it on tech blogs, and start moving to publishing and discussing it in HR blogs and similarly appropriate, targeted mediums. As stated elsewhere[1], this is undoubtedly the existing mentality of the audience to whom this article is written. Those who actually need this advice are the existing and future HR managers and departments who are in charge of hiring.

I spent some time about a year-and-a-half ago building up and managing a small internal development department at a mid-size corporation. I was involved in finding talent to fill development roles in the company twice. The first time, I sat in on an existing search and interviews for a role in a different department. The process could not have been more broken--the position had been open for roughly one year, and the interviews yielded no hirable candidate (as judged by the individuals making the hiring decision). The second time, I led a search for positions freshly opened for my department. The process could not have been more smooth--three strong candidates were hired within three weeks. The only significant difference between the two hiring pushes was the approach--the first was focused entirely on a candidate who had n years of experience on platform X; the second focused on candidates who showed the greatest talent and aptitude in previous professional and personal projects, and gave the greatest indications they were a great fit for the personality of the team.

After we completed our hirings, the VP of HR pulled me aside to mention she'd never seen anyone conduct interviews like we did (she sat in on a couple after hearing about how we'd done the first candidate interview), and was impressed by the way the candidates responded in the interviews. She could "feel" which candidates were going to be hired, even though she had no knowledge of software development. We discussed the differing approaches between hiring for talent and hiring for n years of X experience. She intuitively understood the difference, but had not ever seen it in practice as intentionally as we pulled off.

Programmers understand this. Small businesses who are predominantly programmer-driven or -dependent understand this, too. Even big businesses who are primarily technology-focused show signs of getting this as well (a recent round of interviewing with an Oracle company surprised me with how much they were focused on the right things).

The proverbial dragon to slay here is the HR departments, managers, students, and training programs lacking this advice as fundamental practice. Perhaps we need to see more process-oriented and manager-level technologists joining up with HR professionals to advance the point. Maybe HR departments and educational efforts could start creating Developer Advocates to assist in crafting better approaches and more finely tailored practices to support development/engineering talent. These might be the vanguard of producing better job descriptions and interview processes to hire talent that is more competent, productive, dependable, and retainable.

The most important lesson I learned when I worked with a formal HR department to hire new people is that they care. They really do. They don't want to hire terrible candidates who are going to be miserable, hate their jobs, and drag down a team. They want to empower people to improve professionally while taking care of a company's needs. We need to start working with and spreading this advice among the HR professionals who will increase their value to both companies and personnel by including it in their standard procedures.

[1]: https://news.ycombinator.com/item?id=5441337

[edit: forgot link & punctuation error]

If this were true, then you would never see a problem with startups too small to have HR departments. But you do. It might differ subtly from the big companies, but it's absolutely there.

Everyone doing hiring thinks they are the smart exception and everyone else is stupid.

I would agree with OP, until when I has become a hiring manager myself. I do understand years of experience may not equal to competency in certain skill sets. But if you are going to run a hiring post, what kind of metrics could you use, on top of years of experience?

Putting something too generic (e.g. intermediate programmer, mid-level, etc.), you tend to attract a lot of non-relevant, hello-world sort of people.

Putting a laundry list of language features? You are afraid you could unwittingly weed out people you want, let alone the first person to complain would be the recruiter in HR.

Most hiring managers, myself included, just use years of experience as a guidance so that the candidate can get a feel of the expectations. I did hire candidates with lesser experience but with good technical competencies. Therefore there is no harm to try if you are confident you are a good fit. In fact, I will be really impressed if someone can sell and market oneself intelligently. Surprise me!