Questioning interview questions

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

As an experienced developer, I’ve been in several interviews over the years. Many times, technical questions are a big part of the interview, but in my experience, they start to go wrong when the interviewer expects you to give the answer straight away.
Don’t get me wrong, asking technical questions is fair enough, as long as the questions are about general concepts that a developer of a certain standard ought to know. But when the questions start to go into specifics or ask you to solve specific problems on the fly, at that moment those questions and the whole interview, even, become unfruitful, a waste of time. Let me reason this and explain why I have gotten to this conclusion over the years.

What you want to know about a candidate, e.g. the purpose of a work interview in first place is to figure out:

The personal attitude of the candidate.For me, this is the most important thing. Like a former boss I had several years ago, in Japan once told me: “Technical knowledge can be acquired, but character cannot be changed”. He was right. I have worked with people who had extraordinary technical backgrounds, but a horrible attitude towards work, which made collaborating with them an absolute nightmare. The people with the right attitude, however, are usually eager to learn, easy to work with and, in the end, more productive, as working with these kinds of people brings better results, always making a great job together.

The experience of the candidate. Figuring out the real experience of a candidate is always essential. Of course, if the role they are applying for is junior, you can’t expect them to have good experience, so attitude, point 1, becomes paramount. For a senior role, experience is really important, and the way to identify it is, naturally, by asking questions. However, the questions should be general instead of specific and detailed, in fact, the more general and wide the question is, the better. Experience is what makes you connect the dots over the years, so an experienced candidate can see connections far away one from another and solve a general problem more efficiently and creatively than a less qualified person. This will turn really useful when solving intricate problems or hard to fix bugs on the job.

The candidate’s knowledge and their ability to solve problems and find solutions. Knowledge is a tool that helps the problem solving, solutions finding mind. Knowledge is not the most important thing in a developer, or any employee for that matter, because nowadays all that knowledge is free and accessible everywhere. I would never ask a specific technical question about a particular technical detail and based on that decide the future of the candidate: I want my employees to be able to find the proper solutions, I do not need a walking encyclopaedia of technical terms.

To test their real knowledge, just ask some general questions and terms, and let the candidate explain them in her/his own words. Tests are also a good way to see how good a candidate actually is, but only as long as the test is related to the job. For example, if the candidate has some projects in github, take a look at them instead of making the candidate waste both of your time programming a test app, unless you are looking for a particular set of knowledge.

Asking random tech questions is pointless. The candidate can be nervous, have a bad day, which can make them forget things in that moment. Programming many times is a solitaire task, so some of the best candidates might not do well in the types of interviews we are giving these days. I for one make my own research when I don’t know something, learn, dig, go to forums, I make experiments to find the best solutions. That capacity to get the job done with the requested quality and within the request time is more important than being able to memorize a set of vocabulary.

There is a great chance that you end up in an interview where the interviewer is asking you random technical questions like “what is a DispatchGroup?” or “If you have an array of strings, how do you do this or that… ” This shows that the interviewer, or whoever gave them the questions, has a great technical knowledge but doesn’t necessarily have experience interviewing people, doesn’t have the necessary empathy to understand how emotionally and mentally challenging an interview could be for people, and probably sees the working environment as an extension of the university or high school.