How to scare away good Unity Developer

Let’s talk about the interviewing process. Through my career, I’ve been on both sides of the table. Some of the following “mistakes” I made myself, others were collected through many interviews as a potential contractor/employee.

• Ask questions about API of the Engine/Framework — We are not testing the memory of a candidate. There are thousands of functions, and even for often used methods, I usually just open the Doc or use IntelliSense.
• Have a tough time pressure quiz — That one is quite often, however not always in the extreme form. It could be okay to give some entry-level questions quiz to filter out an intern or junior developer, but it doesn’t make sense for middle/senior positions. The chance of false negatives is high. Once I’ve faced the quiz with such tight time constraints that I barely was able to read a question in a given time.
• Mandatory request code samples — Many have their code under NDA. Not all devs able to write pet project: family, overtimes, or they could be very dedicated to their main project.
• Exhaust developer with endless interviews — Searching for a job is a stressful task by itself, don’t make it even worse. Developers are often going through several interviewing processes in parallel. Most of the HR questions could be asked via email. It’s usually enough 1.5–2 hours technical interview to understand if you need this person onsite or even hire right away. Try to keep it under two calls.
• Don’t study profile — Twitter, Blog, GitHub is an excellent source of information; some hires could be made solely on these resources. If you don’t have time for this and expect a candidate to tell you everything during the interview, it’s disappointing and unprofessional.
• Reject job hoppers — People don’t leave when they are happy. People don’t leave their friends. Finding new ones is always stressful, and usually, nobody wants this experience. There are so many factors like bad conditions/treatment, small compensation, overtimes, studio closure, lack of growth, uninspiring project… So it’s more a question to an employer, can you give this person fulfillment, fair compensation, and proper treatment? If yes, then you don’t need to worry.
• Ignoring pet projects because of low quality — That was once a big mistake of mine. I’ve discarded pet projects of candidate because they were entirely technically not challenging. Eventually, we hired him, and he turned out to be very motivated and self-driven. The intention and efforts are what matters. If a person dedicated his time to create something — he already has done more than 80% of others.
• Irresponsible behavior — A long first reply, slow communication, forget about an interview. Good devs don’t sit for a long time without work. If you want to hire a professional, be a professional. If I’m told that the interviewer didn’t appear because of some urgent situation, it tells me a lot about the company.
• Write a TLDR position description — Many devs with an imposter syndrome will be scared away; they are usually good devs and hard workers. Check some of the positions from Amazon and Google; they are often a couple of paragraphs long, sort of “write and maintain software…”. The number one skill for any developer is to learn and use new technologies. Don’t write anything which will be used occasionally.
• Look for the exact skillset you need — As I mentioned above, the number one skill for any developer is to learn and use new technologies. That’s what you should be checking during the interview. The only exception is you need somebody for a short-term (1–3 months) contract to do a specific job.
• Ask puzzles and riddles — In my experience, it doesn’t correlate with good developers. It seems big companies ditching them as well.
• Over-rely on algorithms(Unless you work for FAAMG company 😂) — There is no doubt that a candidate should possess a basic knowledge of data structures. But not all coders use complex algorithms in day to day life. There are areas where performance is not as critical as maintainability. Developers should understand the techniques and limitations of algorithms, not remembering a concrete implementation of “Merge Sort.”
• Try to hire a higher-level engineer than you have in a company — It’s tough to evaluate senior developer if you are at the middle level. A good imposter can often deceive the interviewer of the same level. If you are hiring a Technical Director or CTO without having one currently, better to outsource this task.

All discussed above is my personal preference and experience. There are always edge cases when my advices don’t apply.