a short rant on recruitment processes

I haven’t rant on recruitment processes yet; but, here we go.

Here’s a list of questions I would like to go through silently during an interview.

• what value he can bring to the team? what other competences the candidate possesses, which can help my team
• can he work on complex problems?
• how much mentoring does he need to start the job?
• can he communicate freely? will he ask for help and guidance when needed?
• does he understand the business domain he is working in?
• how does he value quality?
• can he work under pressure?
• can he take over ownership?
• can he delegate?
• can he mentor and help others?

How do the above questions fit into a formalized recruitment process? The most interviews I was invited to were divided in two steps rooted in two separate worlds: HR (“where do I picture myself in 5y”) and technical (“how can you walk the graph to find…” with a whiteboard, or even worse spelling programming language expressions over the phone, or quoting memorized API spec, which is always available to everyone online).

I have lots of doubts where it comes to programming-quiz-like questions. While I like thinking about algorithms, data structures, and “code golf”, this is nowhere near what I do for the most of the time on projects: planning releases, speaking to the client, solving complex problems, mentoring, simplifying business requirements (I’d call that negotiations), chasing people for missing tools and infrastructure. The actual coding takes at most 30% of my time, yet I still consider myself a programmer, and I like it.

I can’t see ABC tests being any good help. Thinking is a valuable process. Solution is just the outcome. Measuring the results from a test will never be enough to verify if the candidate fits.