I spoke about the process of hiring my "not-so-newbie" before on my medium blog. But I'm ready to spice it up a bit.

I've not met anyone who likes interviews; maybe it's just the circle of very introverted friends that I keep, or interviews are so stressful, that nobody likes them. Tech interviews are a different matter, especially during the dreaded Rona times. Questions can be overwhelming, expectations can be shattered and everyone can have a bad time.

Which is why we tried to fix it.

Hello stranger... I see you have an eye for things.

Alright, I used two quotes from the merchant in RE4 in the heading, and I have no regrets.

I'm Irina, I work as a Front-end developer for a lovely start-up. We are small, but we are mighty and we needed to expand the front-end team.

Start at the beginning

Before recruiting, before even thinking of questions and the process, ask yourself, what team member do you need and why. Can you invest in a junior and then provide them with support that they deserve? If you can, there is this amazing article about setting juniors for success that deserves a read.

You need to decide:

• how much time, mentoring or otherwise you can dedicate to the newbie,
• how hands-on they are (can they write all the code, tests, CSS and other magic),
• what the heck are they going to be building (tech stack doesn't matter as much as the ability to comprehend concepts, learn new things and be a nice person)
• does it even make sense to hire a single person, or is the role so big that you need to split it into two?

Channel the master planner (not evil ofc)

Now you know who you need, you can jot down appropriate questions that are related to what problems they'll be solving. Do not be mean and start asking about algorithms, if you don't intent for them to be writing them.

The goal for this is figuring out the baseline skill level, for the candidate to interview you and have a jolly old time. NOT INTERROGATE. Don't ask too many questions and break them into thematic sections.

Depending on the broadness of the role, you might have to cram in quite a few questions, so I suggest creating a small list of sections that they need to be familiar with and noting a couple of questions for each.

Our HTML/CSS section included questions like: "Walk me through on how you'd build an accordion. What would you use?" If they said using <details>, fab, they know their supported HTML5. If they said, you'd create a container and have an event listener on a button to hide/show content - also good. If they said, you can hack in a little radio input and use its checked state and CSS the shit out of it - also cool. You get an understanding of how they approach certain problems. You can talk about it and make it less of a "whiteboard coding exercise" and more of a "show me how you think".

And if they're stuck, walk them through a solution. There are chances you'll have to do that with them on the job. Good to test your mentor abilities.

Encourage a dialogue and let them ask you questions. It's important that they know what they'll be dealing with if they're successful.

Just can't get enough of..... technical tasks.

Having a Depeche Mood :P

I'm quite controversial on this. I do not like setting technical tasks for people. All work should be paid (I think?) I like respecting people's time, their schedule and so far, we didn't have to create a proper coding challenge. Maybe as I become wiser, my feelings will change. But.. since the role was very UI/UX based, and the candidates satisfied my box drawing nature during the interview, we decided to test the biggest skill of all: teamwork.

The following was copied from the og article

I work a lot with our wonderful designer James, and it’s important that we communicate well and find UX issues early. So I went digging for our old designs, where we could do things better. We could talk about the things we could improve and we could discuss interesting things that we found.

We compiled a brief that asked the candidate to look at old designs for about 10–15 minutes (designs were included in the brief) and find any glaring issues, things that didn’t look right.

The brief was sent prior to the interview (so the candidates had time to prepare), and the interview was conducted by James and me.

Introduce one another, do some small talk and start completing the task at hand. Let the candidate begin with their findings, and evolve them into conversations, where you can talk about alternative solutions and incremental improvements. If they haven’t found all the “issues” that you and your team have, talk through them too. After all, that’s what teamwork is all about :)

Don’t let this take too long, about 30 mins should be enough to cover 2 screens, and move on. Invite the best judge of character next (Hannah one of the founders and our CTO joined the call, James left). This lets another person who’d be working with them daily get a feel for their personality and even explain what we do and why we do it better.

Interviews resolved..

I tried, but I caught myself throwing bad puns around, finally couldn't take it. So there.

This should hopefully give you enough of stuff to think about. Write lists and talk with other people about who is the most successful candidate :).

Cover photo is from Christina @ wocintechchat.com