How not to interview

Guide from interviewee to interviewers

So, you gonna be frontend developer in our company

Don’t you really think you learnt %framework_name% and can consider yourself a developer?

Ha-ha, developer, ha-ha-ha

Maybe, you can write a radix sort algorithm on paper right now? No? LOL

Maybe, you can tell me what is the size of array that modern PC can sort per minute? No? So, we will call you back =)))

Wtf are you talkin’ about?

Not so far I had an interview for “Frontend developer (React)” position.

Here is a list of questions that HR gave me before start. I translated it for you:

Do you see frontend here? Here I do not see. But it is

As soon as I saw the questions, I immediately called somebody who’s competent and asked him about this test:

– So, tell me how these questions are relevant for frontend developer position?

– It’s computer science, it’s basics. Even designers pass through it before an interview.

– OK, when UML diagrams are used on your project?

– If you’ve never used UML, you can skip this question

– OK guys, what about SQL? I have some backend development background, but do your frontend devs write SQL?

– No, the don’t. You can skip it too.

– OK guys, what about count bits in numbers? Do you often count bits in numbers? I do it every time I wake up in the morning, don’t you?

– …

Then I had some dumb questions about JavaScript, here is one of them

<sarcasm>Typical situation, I definitely do smth like this everyday</sarcasm>

Of course, I leftand forgot this wasted hour of my life.
During this time I had only one question about real frontend

I’m not so experienced interviewer but I see real problems with this process and I’m not the only one who see that. I often see complaints about that in chats, twitter, also saw some posts here and I think we should work on them.

Before start of tech interview

There are such boring things that you can encounter on interviews.

“Before start” tests

Shitty tests like one from above will only waste the time. Ask it directly on interview within a real interaction, it’s easier to detect potential problems on some subjects.

What do you see yourself in our company after 5 years?

When I hear this question, I don’t see anything anymore. What do you want to hear as the answer? I can’t imagine the answer even while I write this text.

“Tell about yourself”

I’m OK to get this question, but some people (and especially juniors) may be confused by it. Better ask something like “What was you working on”, “What technologies you use in work”

How to do real interview?

Ask only relevant questions

You need a programmer. Not a robot who knows everything.
Ask only questions that are relevant to the position you need.

I won’t deep dive into all questions for specific roles, but…

• If you are looking for OS developer or programmer that will write software for rockets — talk about memory leaks, algorithms, optimizations etc
• If you are looking for game developer — talk about physics, geometry, game engines etc
• If you are looking for backend developer — talk about databases organization, web servers, solving high-load etc
• If you are looking for frontend developer — talk about components organization, UX problems, reactivity mechanics etc

This is not a call not to ask the common questions, but

No fucking questions about SQL for frontend developer

More concrete, less abstractions

1. Abstract questions are harder to explain what you want to hear from candidate. It may not be understood at all. And you’ll consider him/her stupid, but in fact you didn’t recognize anything.
2. Some people may be afraid of interviews. The may be shy. They may have paws. When you ask tons of theoretical questions, it may scare potentially talented people. That candidate may know how to solve the problem but can’t explain it or he/she forgot it.
3. Also, some people (like me) are practitioners and don’t worry about theory. It looks like “I know how it works but don’t remember name of this thing”.

Too much problems that may cause misunderstanding. Better to ask concrete questions, it will be easier for you and for candidates.

I figured out dumbest examples but don’t focus on questions, focus on the difference

DON’T: What is event bubbling?
DO: You have parent and child elements with click event listeners. Which one of the events will be fired first?

DON’T: How to optimize frontend application?
DO: You have a big list. You have some render like list.map(data => <Item data={data} />) but it looks so slow. How to boost it in case we have to render all of items?

Some advices

• Instead of giving a lot of questions, think of several little tasks/problems on various subjects. Important: don’t make candidate write a lot of code and don’t give complex tasks. Just simple problems that need to be solved and may be explained on the fingers. Let candidate to think out loud, see how he/she will come up with a solution. You’ll understand if candidate doesn’t know something.
• Asking questions that can be google’ed in less than 5 minutes will give you nothing. No matter if candidate does or doesn’t know it. Better to check how fast candidate may deal with unknown things. My friend had such a good experience on interview:
  – Have you ever worked with UML?
  – No, I don’t
  – So, you have a task to work with UML, your actions?
  – Firstly, I’ll look for some UML parsers
  – OK, I’ll be back for 5 minutes, and you’ll look for it
  As I said before, it will show you how fast candidate may solve problems even when he/she have not experience on some subject.
• (JavaScript-related) Show your project’s package.json and let candidate comment it. Which of packages are nice? Which aren’t — and why? What alternatives you can propose? (This trick is also useful for candidates — ask them about package.json and you can give the impression of an expert)

Of course, it’s not all advices I can give, I’m not a recruiter, and here is what the first things that came to my mind when I started to write this post.

Hope it will help you to interview more effectively :)