In my life, I have experienced many interviews. I was interviewed by small companies, by big ones, by popular, and less popular. Sometimes I was doing that because I wanted to get more experience, sometimes I was doing it because I wanted to know what I am capable of doing. Other times, of course, I was looking for a job.
Being a timid person, interviews seemed like a great way to improve the way I communicate with people. Especially since English is not my first language, as you may have noticed, it was essential to have stressful situations (read interviews) where I would have a chance to think on my feet and grow professionally. One day, I told myself that I’ll learn it that well, that I can actually write a book about software engineering.
Finding the right people is tough. I thought if you have money it should not be a big deal, but, in our competing world as my father would say “All that glitters is not gold”, so you have to pick carefully. I found out that only when a friend of mine asked me for assistance in finding a developer without long and boring interviews or test assignments which may scare good thinkers off. Which turned out nearly impossible and prompted an addition of test to the interview process.
Generally, it is common for tasks being copied from somewhere. It is quite unlikely that engineers enjoy doing them because let’s be fair it is disrespectful when people invest zero time but ask you to spend an hour or two. When the interviewer takes a test assignment from somewhere, it shows the skills of working people there and demonstrates the face of the company in a bad light. Besides, most of the time solution already exists on the web.
Fortunately, some companies come up with interesting test assignments like puzzles, hide and seek where you need to get the access to particular resources. Then you have to play a sort of Sherlock Holmes and use your deduction. It may help them to find out more about your intelligence, programming knowledge, creativity and if you are attentive to details enough.
Most test assignments won’t tell if an engineer culturally fit into the company. Or maybe, how good he is as a team player. Also, if the test was randomly picked from the internet it most likely won’t show if a potential candidate is competent enough for the applied position. This is why people invented temporary contracts. It is expensive to hire a candidate that as it turns out creates more issues than he resolves. As for you as a persona, a cultural fit interview was introduced, where they talk with you about life, IQ tests, EQ tests or 50 shades of why. Which sometimes, indeed feels overwhelming, for an interview. Thus, multilevel interviews were created with a variety of mind-boggling questions, steps, and assignments. Unfortunately, not all companies care about what you would think about the process.
-So, what did you do?
I remember a few years ago when I wrote a test assignment for the very same friend. It helped to find a good engineer who was a skillful team player. It also showed me that the assignment is relevant to the work and allows to see a person’s ability to deduct and plan in advance.
So a few weeks ago, when some help finding a right candidate was needed, I’ve created another test for a different project where I tried to minimize the number of dependencies required for implementation, nevertheless, keeping it straightforward and relevant to the real project. Like a tiny bit of token authorization that would show if the developer understands the basic concepts of how it works. I tried to keep it short so the developer wouldn’t need to spend long hours implementing it as well as, supplied it with drawing, description, and recommendations for an overall clearer image of the idea.
If you have encountered a screening of completed test assignments already, you may know, that occasionally people produce something different entirely than what was asked in the task. Sometimes it is better than the original idea, other times they might get away with too many third party libraries that solve a problem for them. So I would suggest eliminating possible misunderstanding between you and the potential candidate and I would advise making an effort in writing a document and implementing the task yourself. That may help to see how long in average the test task would take and would help to reduce the gap between your plan on a paper and actual engineering of it. Which results in a better understanding of the possible outcomes and ways to solve it.
I found a good test assignment to be a benchmark of a great developer. It is a lot easier to hire a wrong person when you subjectively make a decision based on the way the candidate tells you a story. Many times the same friend was hoping to get away from testing by supplying me with candidates’ Github projects. Believe me or not, I saw people displaying opensource projects as their own by removing git history and including loads of uncontributed forks.
To summarize, invest carefully in building a right test assignment keeping in mind what you desire to see in your project but also try to find a balance between a task you ask to do and the time one has to spend on it.