Skip to content

Commit

Permalink
Add post: As an interviewer
Browse files Browse the repository at this point in the history
  • Loading branch information
amree committed Oct 25, 2024
1 parent c6efda2 commit d328d74
Showing 1 changed file with 362 additions and 0 deletions.
362 changes: 362 additions & 0 deletions content/posts/as-an-interviewer.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,362 @@
---
title: As an interviewer...
date: 2024-10-25
tags: [engineering]
readingTime: true
toc: true
---

I used to just share whatever I learnt, no matter how small it was. However, at
one point, I forgot about the practice due to my work commitments. So, this
time I would like to talk about what it looks like on the other side of the
interview session, which is the Interviewer.

Let’s put the disclaimer out first. I haven’t done it for “years”, ok, maybe
just around two years. So, I’m not what you called a seasoned/expert
interviewer, but I believe there will always be someone out there who can learn
something from this post.

I have also only been an interviewer in my latest company and I never did
before in my previous companies. To this date, I have been involved in 80+
interviews. However, when I mentioned “interviews”, that doesn’t mean all of
them are live interviews where I talked face to face with the candidates. It
could be just me screening or reviewing their assignments. So, this post is
limited to the experience I have from a singular company.

Alright, let’s get right into it. In CoinGecko, we use lever.co as our tool to
manage the candidates. I still remember we used Notion last time with their
Kanban interface and this tool is so much better (and I believe it’s not cheap
too).

Generally, we will use similar processes among the candidates. But, we changed
it from time to time depending on the needs. We are quite flexible. The common
practise is to split them into these stages:

1. Personal Statement
2. Take-home Assignment
3. Virtual Interview
1. With the Engineers
2. With the Founder

There are more steps involved that I didn’t mention as it doesn’t involve us
much as the Engineers. For a start, our colleagues in HR will help with the
“Discovery Call” first before we Engineers start to get involved in the first
stage. Our HR and Engineering Manager also screened most of them first before a
candidate got to us for the first stage. After the third stage, there are also
reference and background checks by HR.

Before we start further, let’s talk about the HR roles in the process.

## HR Roles

I’m not going to dive too much into this as it’s not my place and I also don’t
know the full details other than the updates posted by our HR. However, I want
to make it clear that our HR is involved from the first step until the end.
They played a major role in terms of being the middleman between us and the
candidates. If there’s an update to the candidate from our side, it will be an
email coming from the HR. It’s going to be a full time job for us if we don’t
have them. Thank you Daniel for the hard work from your side 🙏

Regarding the Discovery Call:. It’s actually a phone call our HR made to the
candidate to get more details on these topics:

* Your work experience
* Your interest and understanding of the crypto industry
* Your hobbies/interests
* Goals
* Expectations

You might be wondering, why not just read the CV or the resume? I think having
more information about the candidate will help a lot. There are so many ways to
write those docs and some information that we want might not be there. Our HR
will put a summary and a rating on the candidate’s page on Lever. It does put
more work into our HR, but it's very helpful to us.

Engineering manager may or may not give his input at this point. If all is
good, we as the Engineers will be selected as the panels to review the Stage 1
which is the Personal Statement’s feedback. Normally, the team that asked for
the new hire will be part of the panels. It’s not that unusual for multiple
teams to be involved as there could be more than one team asked for the new
hires. However, the panels will be limited to three persons which includes the
Engineering Manager.

## Stage 1 \- Personal Statement

In this stage, we will review all the information gathered by the HR including
the resume/CV, blog, Github/Gitlab, Twitter, LinkedIn and most importantly, the
answers they put when applying for the job. Those answers are coming from the
custom form that we put on our job’s application page. The questions might be
different, depending on the job and level.

For this stage, we will be splitting our feedbacks into three categories:

* Strength
* Needs improvement
* Red flags

Basically, it’s about our first impression regarding this candidate. We are not
supposed to take too much time on this stage, but it can take me more than one
hour if there is more information about the candidate. I even browsed some of
their projects on Github just to see how they code. It helped me to put a
picture on this candidate so that I can have better understanding which in
result helped me to build better questions tailored to him in the live
interview stage.

This is also the place where we will highlight their strong points and
potential problems based on the resources that we have. As mentioned before,
the “Discovery Call” notes helped us a lot in making sure we understand the
candidate better. So, our answers will be based on multiple sources, not just
the the questions that we posted in the application page.

Once we have worked on the first impressions, we also need to fill in two more
points which are:

* Whether this candidate raise the bar
* Feedbacks for Stage 2

What does it mean to raise the bar? This is quite subjective, but for me, it’s
about whether the candidate is someone who could offer something new/better
compared to the other candidates. It’s just a Yes or No option.

For Stage 2 feedback, we will put a summary for all of the points. Sometimes,
I’ll put a note on how this candidate compares to the others. It’s a free text
field, so we can put anything we want there. We will also leave some notes on
what we want to know in detail which we may or may not be asking during the
live interview. It’s possible that we will change the panels after that, so,
the notes that we put may help others too. This is also where we will suggest
which assignment is suitable for the candidate.

Then, we will put a Rating (we can’t skip this part):

1. Strong No Hire
2. No Hire
3. Hire
4. Strong Hire

If you noticed, you can’t choose something like 50-50. You have to pick a hire
or no hire. The rating system is quite simple, but it forced us to really think
it through. Kudos to the Engineering Manager who thought of this preventing me
from being on the fence LOL. The same rating system will be used throughout the
Oh, it’s possible for a candidate to be rejected on this stage.

Once the candidate passes Stage 1, HR will contact the candidate with the
assignment that needs to be delivered within a certain time period. Our EM will
help to answer if there’s any question regarding the assignment. At this point,
we’ll just wait for the assignment to be delivered.

## Stage 2 \- Take-home Assignment

This is the stage where we will review the assignments. Yes, there can be two
of them,, but normally, the other one is just a small task that doesn’t require
the candidate to code. Once the HR receives the email from the candidate about
the complete status of the assignment, he will block two hours of our calendar
based on our free time to review it. HR did more work here as he needs to
ensure we don’t review two assignments at the same time. He also knows that we
still have to code and do other tasks 😅 It’s not that uncommon to have a
combination of Stage 1, 2 and 3 happening in the same week. Again, I’m so
thankful to our HR. Yes, I’m just going to keep on thanking him in this post.

So, what do we do at this stage? This is where we will look into the code
submitted which is normally done through Github. During my early years, I
downloaded them and made sure they were working locally. But, these days, it’s
very rare for me to do so unless I have a good reason. Besides, one of our
requirements is to have the application running on the Internet, either through
free or paid hostings. So, I don’t exactly have to ensure it is actually
working locally.

I believe this is where I’ll spend the most of my time compared to the other
stages. We also allowed candidates to use different programming languages
before. It’s going to take more time for me to review whenever I get a stack
that I’m not familiar with. Recently, we asked candidates to do it in Ruby on
Rails. They can use React as the front-end if they want to. Other than
reviewing the code, we will also prepare the questions that will be asked
during the live interview. For some people, they can make up the questions on
the fly, but for me, I need to prepare the basic questions first and then I can
improvise from there.

You might be wondering what kind of questions we would ask? It depends on the
assignment and the candidate. We will use our knowledge from previous stages to
construct a good question to test their knowledge. For example, we won’t be
asking basic Ruby questions even though the assignment was built using Ruby on
Rails if the candidate is not a Ruby developer. Most of the questions are about
the assignment itself, why did you choose to go with this approach and not the
others, etc. Most of our questions are open ended, which means there might be
more than one correct answer. The main thing that I want to see is if they can
justify why they chose that kind of answer.

Similar to the previous stage, we will put a rating on 10 criterias for the
assignment submission. Six of them are compulsory and the other four are extra
credits. No, I’m not going to reveal what are the points 🤣. Suffice to say,
the good ones won’t have a problem. Then, we’ll also give a rating as the
overall, same system as the previous stage. That rating will be the final score
for us to decide whether we should move forward with the candidate or not.
Again, we also have a free text field where we will put some notes that will
help us the reviewer in the next stage.

Sometimes, we asked the candidate to rework on their submission. It really
depends on the candidate and the submission. We can also just reject the
candidate at this stage if we want to, same as other stages.

Then, our HR will take over and communicate with the candidate in order to
ensure all parties, engineers and the candidate will be available for two hours
on a certain day for the live interview. This requires our HR to look into our
calendars (the panels) and the candidate too.

## Stage 3 \- Virtual Interview with the Engineers

Virtual interview is where everyone will be in the same video call for the
interview. Normally, there will be four people involved: 1\) EM 2\) The team
lead 3\) The engineering from the team that is hiring 4\) The candidate. It is
not always the same though, for example, it’s quite normal to see two team
leads and the EM sits together in the call. It happens when there is more than
one team hiring. It is also possible for a candidate to be offered a position
in the Web team even though he applied for a job in the API team. We will
decide based on the outcome of the interviews.

For me, this is the most challenging stage between the processes even though
I’m not the candidate. Before experiencing it on my own, I assumed only the
candidate will be challenged, apparently the interviewer does too.

Normally, we will set the session to two hours which split them into:

* 5 to 10 minutes for introduction
* 50 minutes to discuss about the previous assignment
* 50 minutes about the candidate’s working experience
* 10 minutes for the candidate to ask us any questions

As usual, we’ll change it depending on the candidate. If we don’t think we got
enough information about the coding skills, we’ll just extend the discussion on
the assignment a little bit more by taking the time from other sessions.
However, we will limit the total time to two hours. It’s very rare for us to go
beyond that.

Let’s talk about the preparation. In order to have a fruitful conversation, we
will prepare the questions before the call. For the panels, one of them will
create a doc to summarize all the feedback from earlier stages. Then, we will
create a new section to talk about the assignment and the work experience. The
doc will be shared among us so that everyone can edit the file and add their
questions. Normally, it’ll be done on the same day or the day before.

For the assignment questions, we will split the questions based on the
functionality. We try to make the flow as smooth as possible so that we don’t
have to jump back and forth between code unless it’s unavoidable. So, if there
are different questions about some of the code, we’ll just keep on adding them
in the doc. Imagine a tree from the big to small branches. Sometimes, we will
combine the questions together when needed. Everything will be done
asynchronously as we don’t need everyone to be online to build the questions.
Basically, everyone doesn’t have to be in the same room to work on the doc.

What would we ask? It depends on the candidate. Other than the time taken to
review the questions, this is the stage where it took most of my time. The
questions will be tailored to the submitted assignment and the candidate. We
won’t be asking basic questions on Ruby if they haven’t done Ruby before.
However, we will be asking generic programming questions to verify their
understanding. For example, I’d look into the code patterns, testing, etc. and
see whether the candidate understands what he was doing in the first place.

Then, we have the work experience questions. Depending on the level of the
candidates, we would most likely ask about their past projects. Basically the
details from the planning until the post-deployment. This is the most
“wildcard” section as we don’t have the full details other than what the
candidates put in their resume/CV. So, for the preparations, we’ll just outline
the very basic questions and we will adapt from here.

Now, let’s jump to what is happening during the interview. Normally, the EM
will start by introducing the panels and explain what is going to happen in the
next two hours. Then, we’ll ask the candidates to make an introduction. Yes, we
have the basic details, but we are going to ask them to do it anyway. It will
help the candidate to be at ease for a little bit before we go into the more
challenging sessions.

Then, we will start the technical questions with the assignments. The panels
will ask based on the document that was prepared earlier and make the
adjustments as they go. Normally, there will be one lead and others will add
more if needed. The questions can get quite challenging. We will relate the
questions to the challenges that we have in the current work environment. The
key is to challenge the candidate out of his comfort zone and see how he would
adapt and react. Most of our questions are based on real problems. We do make
some imaginary problems, but they are not too far fetched from the reality (our
existing work).

Due to the limited time that we have, we would try to control the flow as much
as possible. It’s pretty normal for the candidates to randomly go out of the
context when they couldn’t answer the question properly. We will just cut them
off even though it feels a little bit rude. One thing that I realized when I
started to take over this session is that I started to talk faster than normal.
We also can’t give too much time to the candidate to answer the questions.
However, we will take a pause here and there when the candidates are asked to
give them a little bit more time to answer the questions. It’s kinda expected
since we have limited time to ask questions. The main advantage is that we can
cover more questions, but, at the same time, it would put more stress on the
candidate.

These would be my top tips if I have to give tips based on what I have gone
through before:

* Review the assignment again and prepare. You don’t want to forget about what
you did in your assignment and also the WHY.
* Ask for time if needed in between questions.
* Use online drawing board and screen sharing to make your point clearer.
* Don’t be afraid to ask for clarification. It will make you look like someone
who can communicate and not just work without questions when given tasks.
* Minimize the interruptions. Try your best to ensure your Internet, speaker,
MIC and everything else is working properly before the call. Of course, don’t
be late.
* Have some water ready. You are going to need it, a lot. It is also a good
trick to get some extra time in between questions. It will force your
interviewers to take a pause too.
* Look at the camera. Personally, I think it is kind of rude if someone doesn’t
look at the camera when someone is talking to you. Try talking to someone on
the street while looking somewhere else.
* Relate the question with your past experience. Do not just answer the
question. Think about the time where the answer was something that you
implemented before. It will show you have the experience and not just taking
some points from a random blog.
* Be aware of the timing. Do not go out of the context too much. Ask if it is
ok if you want to elaborate further since you think it will help your interview
session.

Asking about work experience is probably the most challenging part of the
session for me. Yes, asking non technical questions is more challenging for me.
As mentioned, I can’t prepare much about it. I need to understand the
candidate's project based on what their resumes or discovery calls. What helped
is to have some basic questions as your guidance. Having objectives like what
you are looking for from a candidate is good as well. Work backwards from
there. Additionally, writing the summaries on what the candidate said while
adapting my questions to their answer is quite challenging.

I think this part of the interview is more relaxing for the candidate as they
only need to talk about what they have done. It is also important that a
candidate can reflect on their past projects so that they are able to mention
what they can do better if they have to do it again. A good engineer always
reflects so that they can learn and grow. Actually, that applies to everyone.

These are my top tips when it comes to work experience:

* Pick the most impactful project that you have worked on instead of talking
about all of them. Remember, there is a time limit.
* Depending on the position you are applying for, take the most suitable to
show your skills: leadership, technical skills, etc. It doesn’t make sense to
talk about managerial skills when applying for individual contributor
positions.
* Be concise on your answers. We are developers as well, don’t put too many
buzzwords. Again, time is limited for us.
* Ensure you can back up your decisions from your past projects. Why did you
choose that method? Why not this method?
* Oh, be respectful to your interviewer, please. I have interviewed a candidate
who laughed back at us thinking that we asked stupid questions even though it
is not.

I think that’s pretty much it. Towards the end of the interview, we will give
the chance for the candidates to ask questions about our work and it can be
anything. Best to prepare the questions even before the interview so that you
would not waste the time to think about what to ask.

## Summary

Phew, I think this post is too long already. I guess for the summary, I would
like to say that it is not just the candidates who have to spend time to do
the preparation and even the interviewer can be nervous too. We take our
interview sessions very seriously. I hope that the next person who will
interview me will do the same. Good luck everyone.

0 comments on commit d328d74

Please sign in to comment.