Intimate Developer Interviews
According to approximate estimates, for 10+ years of work at Miro, he conducted about 500 interviews. It’s time to share the sacred experience “how to check in an hour what people are fumbling, and at the same time not turn the interview into a stuffy interrogation.”
Everything written below is a personal opinion and in no way reflects the existing interview process at Miro.
Digging deep
No hypothetical or abstract questions like:
— what would you do if…
What does the perfect one look like…
– Name the 5 best qualities of the team
– and others “Where do you see yourself in 5 years”
The only thing we learn from here is how realistic answers people can generate on the go. ChatGPT can do that too.
There is only one way to reliably check what a candidate can do – ask what and how he has already done. Therefore, we build most of the interview from digging into past experience.
Entry options.
— In a nutshell, tell us about your most interesting (most difficult) project? What is the essence of the project? Team size? What is your role? What is your main contribution? Project term? Etc…
In 3 minutes we learn the general context, and then we fall into the details, clinging to the roughness.
People willingly share stories about the projects they are most proud of. You can immediately understand the seniority of the candidate by the structure of the answer and how he defines the problem.
Junior:
— We moved from custom bike to react
– For what?
React is popular / easier to write / faster
Middle:
— Our custom bike was terribly slow and did not support typing, which is why we spent a lot of time fixing bugs. As a result, we decided to move to react. The application began to load faster and the number of bugs decreased.
Signor:
— To improve time to market… blah blah blah 😉
We make sure that the candidate clearly understands what task he was solving, he knows in what parrots success was measured. The more clearly the problem is formulated in business terms, the better. Red flag if the candidate gives a porridge instead of a staging.
We ask what went wrong and what to do differently now. Self-reflection is a useful skill.
The candidate must remember everything even if the project was 5 years ago. In the end, that’s why we ask about the “most-most” project.
And if he doesn’t remember the details, then there was no dedication or “I just followed the order.” Here, in any case, there is no depth here – for us, the red flag.
If a person fumbles, it is immediately felt and the conversation turns out to be lively. It is especially cool if you do not understand the domain area or the technologies used – you can learn something new. Because a great candidate is able to quickly and easily explain the essence to those who do not fumble.
Subtotal:
Ask about the past, not the future
– Digging deep, not wide
Check hard in 15 minutes
Let’s say you liked everything at the previous stage:
— Relevant experience is;
– Common sense is present;
– Thoughts are expressed clearly;
— And most importantly, we understood the grade of the candidate and what role he would be best suited for;
In theory, already on the basis of how the candidate spoke about his experience, social security can be rounded off. But, unfortunately, there are guys with a suspended tongue and useless technical skills.
Therefore, it is necessary to check that a person knows how to do his job efficiently and quickly.
And then the programmers unanimously agreed to arrange a total hell for each other at social security in order to amuse their CSV in the most expensive way for the company.
To do this, go to battle:
– Abstract algorithmic tasks, when we are looking for a chela who should quickly rivet molds on the react;
– Designing high-load systems that you do not have;
– Multi-stage selection from hourly livecoding, then hourly system design with two or three interviewers at each stage for the ordinary position of middle or junior;
– And other ways to burn the loot without finding out whether the candidate knows how to work;
It is necessary not to show off, but to give a typical task that you really have to face, but solved in 5-15 minutes.
If we hire an ordinary front-end developer, then we ask for the usual form. Then tie the validation and accessibility. Let’s see how reusable everything is designed.
And, if the candidate does it, ask a couple of questions in depth about understanding the tool (language, framework). Because without depth there is no point in expecting speed or quality. Any problem will make it slip in place for hours.
And if a person fumbles, then it is immediately obvious, and 15 minutes to check the equipment is more than enough. And if you don’t fumble, then 2 hours are not needed.
Which parrots to evaluate
As a result, we get the following structure of the interview:
— 10 minutes for an intro about yourself and selling the team;
— 30 minutes talking about the experience of the candidate;
— 15 minutes about technique;
– 5 minutes for the candidate’s questions, or longer if the candidate is interesting;
It remains to consider how to compare candidates with each other.
Immediately make a reservation that I do not fill out a real summary in the parrots indicated below. But, if you analyze on the basis of what the summary is formed, then I evaluate candidates on three main skills.
Hards and availability relevant experience (well, if the person has seen some shit).
Communication. Ability to communicate, quickly and structured to explain the essence of the issue.
Proactive in learning and passion for work.
For each skill we give up to three points:
0 – everything is bad
1 – will drive with beer
2 – good
3 – great
There is at least one zero – just goodbye.
If there are units everywhere, the candidate is weak on all fronts – it’s also not interesting. (We start from the fact that each next player should strengthen, not dilute the team)
And then, depending on the proportions, you can decide which role suits the person best.
Hards: 2
Communication: 1-2
Learnability: 1-2
An ordinary developer who can just work a job. We take.
Hards: 1-2
Communication: 1
Trainability: 3
Perfect June. We take if we are ready to invest.
Hards: 1
Communication: 3
Learnability: 1-2
Manager, take.
Hards: 3
Communication: 2-3
Talkability: 1-2
Techlead. We take.
At the same time, following any formal system blindly when working with people is not the best choice. Formally, a person can score a lot of points, but also a few poorly formalized alarm bells.
In this case, it’s better to trust the gatfiling and say no than risk hiring. Or ask someone else to conduct additional. interview to make sure it didn’t seem. We are not hiring a faceless machine, but a living person with whom we will interact every day.
In fairness, the described approach is suitable for those who conduct interviews regularly, you need a full hand to make decisions on the go. If you interview once a month, it will be difficult to calibrate, and then it is better to call more people for an interview or do more stages to collect more opinions. More expensive, but also works.
Of course, it is impossible to write an article on Habr without leaving a link to your tg-channel. Subscribe, I irregularly unload various nonsense from my head there – very interesting 😅
