Cross post from IRefactor
This week I had interesting discussions regarding hiring and interviewing professional personnel.
The reason it was so interesting, is the fact that the discussions were raised simultaneously by two friends of mine, each from his unique point of view.
David is a R&D Manager who leads successfully a complicated software project written in .NET technologies.
David tries to hire a Software Engineer with specific experience in Smart Clients and Complicated Servers applications but without any success.
David complaints that most of the candidates he meets have a superficial knowledge and don’t meet his expectations.
Daniel is a talented Software Engineer whose major experience is in ASP.NET, willing to change his place of work. Daniel is a very dedicated person; he attends almost each and every summit he can on .NET technologies. He also reads quite a lot of blogs and articles in order to enhance his knowledge.
Daniel had already attended more than dozen interviews, most of which he failed because he was unable to solve some “tricky” (according to his words) questions.
By “tricky”, he gives an example of: “Given a uniformly distributed function between 0 to 1 write a function that generates unique numbers from 1 to N in complexity of O(…) and …” and that’s there he loses his nerve.
“What the hack”, he says to me, “The company even doesn’t deal with any statistical or mathematical computations, all it does is pretty standard enterprise application; retrieve, show and update”.
On the one hand it is ridiculous that Daniel cannot pass interviews, but on the other hand it is also true that we lack good Software Engineers.
But wait, could it be that the problem is within our industry (or us)?
· Understanding that there is a need to hire a new Software Engineer mostly comes too late (in the project’s schedule).
· As a consequence, due to time constraints, there is no time to train the new employee. Therefore the employee must meet very rigorous requirements.
· In order to ensure those requirements (that vary a lot from company to company, based on their line of business), the interviewer tries to infer candidate’s competence using one of the following tools:
o Ask domain specific question, based on the interviewer’s (or his company) experience or immediate needs.
o Ask “quiz” questions, question that can be solved using some tweaking.
The interviewer forgets Peopleware which clarifies: “Major problems of our work are not so much technological as sociological in nature.” Failing to answer a tweaking (“a-ha”) question isn’t a virtue you would like to judge on.
· Finally, candidates that somehow meet the requirements are being hired, which deepens and narrows their experience in the long running term.
A good candidate doesn’t need to know how to tweak a domain specific problem within an hour. Moreover, a good candidate doesn’t need to be a specialist in Smart Clients applications.
Don’t get me wrong, if such a candidate appears during the interviewing process I will gladly hire him (if I need such a skill for long term).
However, if your projects and recourses are planed correctly, you can loosen your requirements a bit.
I have always believed that a Software Engineer should be as versatile as possible and therefore the minimum bare requirement I seek is a very strong software engineering background.
In my opinion, a Software Engineer must understand in different “tools of trade”. He needs to know why it is better to apply this pattern or that pattern, when it is suitable to use Smart Client applications and when it is not, how to build good infrastructure and clean software and etc… etc…
Having good software engineering skills, doesn’t mean you don’t need to specialize vertically in a specific field. With the correct mentoring and coaching, candidate’s experience in several disciplines he chooses, will evolve with years (and this can be a whole another post) and I even expect it to happen.
And that’s how, my conversations with David and Daniel this week ended by discussing how do I find this bare minimum in the candidates, using technology questions and without any tricky (“a-ha”) approaches (of course there are also non technology question that I ask during the interview in order to review candidate’s soft skills).
Here are the virtues that I try to pursue during an interview:
· A candidate must show a strong understanding of Software Engineering principles
· A candidate must be able to learn and evolve with the time.
· A candidate must have a passion for the trade.
The last virtue is extremely important; how many people do you know that work in the hi-tech industry, just because it seems to be “a shiny, nice place”? You probably met such people in the past when they complained to you not to discuss any work issues during the lunch time.
And here is the basic skeleton of the interview:
I ask the candidate to choose an example from his previous work and to explain its design.
I expect the following:
· Problem explanation – clear and concise explanation of the domain problem.
· Solution explanation – short conceptual model or class diagram explaining the solution, including alternatives that were considered, technological pitfalls that were overcome and etc…
It’s amazing to see that many candidates don’t know how to communicate simple technological problems, don’t know what they really tried to solve in the first place and why the solution was chosen the way it was.
I ask a design question from a well known domain.
A well known domain helps to remove obstacles when introducing to the candidate some domain specific logic that might come from the interviewer company’s experience.
An example of such a question will be:
“Please design the MSN Messenger” or “Please design the Linkedin service”
During the interview I add more and more constraints to the question.
I also provide some leads that may (or not) help to solve the question.
I expect the following:
· An ability to adjust the design with each added constraint.
· An ability to learn from my leads and to change the solutions accordingly.
No tricks here, no “a-ha” questions\answers.
I really don’t want the candidate to go back home following an interview with me and suddenly to have the “a-ha” answer for the question I asked.
I just try to reveal how deep the candidate understands the “tools of trade” (based on his experience).
Here are a few examples:
· What is the difference between class and struct?
The question yields in 70% (there are still people that don’t know the difference?) a correct answer that a class is a reference type sitting on the heap and a struct is a value type sitting on the stack.
But, wait, what does it really mean?
How that helps you to build better software in .NET technologies?
(Here is a quick hint: in .NET everything is a struct or a class. Basic int is a struct; why is that?)
· What is the difference between a thread and a process?
The question drives a broad discussion over why and when we need threads, what are the synchronization methods available in .NET framework, what are their pros and cons and etc…
· How do you retrieve a record from a Database?
This question also drives a broad discussion about connected and disconnected modes, dataset\datatable, typed dataset\datatable, XML, ORM, optimistic and pessimistic locks and etc…
By adding more and more constraints on the questions asked I evaluate how deeply the candidate knows his “tools of trade”. He doesn’t need to know all the answers, but you will see; a passionate Software Engineer will know quite a few things under the hood and even if he won’t know, he will try to figure it out, discussing with you all the possibilities and alternatives.