Black Lives Matter.

Ace the Interview

Regardless of why you are needing to interview, you want to do your best. You are competing against of pool of other candidates that all want what you want. An offer letter.

Fri Oct 16 2020

It’s 9:59 in the morning.

You’re one minute away.

Your eyes moving back and forth as if you’re watching a tennis match.

For a split second resting on the clock. Then right back to a mirrored view of yourself. Then back on the clock.

30 seconds. The clock is ticking.

You’re waiting to join a video call. On the other side of the wire sits your interrogator.

Palms are sweaty…knees weak… arms are heavy…

You know how the rest of it goes…

And hopefully you don’t have spaghetti on your sweater… because you’re about to sit down for an interview to land a gig as software engineer!

The lead up there, although not as suspenseful in real life, isn’t too far off from reality. At least how I’ve felt in some experiences.

Interviews are stressful, and they all vary in levels of stress depending on your situation. Maybe you’ve just graduated bootcamp, and you’re interviewing for your first job. Maybe you’ve just lost your job and rent is due. Or maybe you’re a rock star engineer who just exited from a hot startup and are just looking to see what’s out there.Regardless of why you are needing to interview, you want to do your best. You are competing against of pool of other candidates that all want what you want.

An offer letter.

Over the past 10 months of working at Hopin, I’ve conducted countless amounts of technical and culture fit interviews. To give you an idea, 10 months ago we were 6 employees and now we’re pushing 200.

Throughout my experience, I’ve seen a lot of uh.. well.. shall I say candidates who were completely unprepared (like not even knowing the company they were applying for), candidates who were so so close, but just didn’t make the cut due to some sort of red flag, to folks who were instant standouts that we couldn’t wait to bring on.

So what makes a good interview? What are those red flags? How can you be one of those “instant approval” type of applicants?

These are all questions I’m going to answer for you today, with hopes that you’ll take away some gems to help see you through to receiving a “We’d love to hire you!” email land in your inbox.

Side note: Before you even get to the interview phase, you need to actually put in an application. There are few things you can do to standout in this process as well. A few months back I interviewed one of recruiters to walk me through things they look for when deciding to move someone on to the actual interview. You can check that out here.

Okay - Let’s begin!

Tip 1) Find a company value you align with personally

This is the obvious one, but you’d be surprised by how doing just a little bit of homework will put you in your interviewers good graces.

One of the first questions I ask in an interview are “Why Hopin?”.

The answer I most commonly hear goes something along the lines of“yada yada I’m looking for a new change of pace… looking for a new challenge… yada yada…”.

… and in my head I’m going “ok.. but why Hopin?”

These answers aren’t red flags per say, but boy are they generic and boring. It shows me that you aren’t really that excited about anything particular in what we are doing or what problems we are trying to solve at the company.

I mean, if you really aren’t eagerly excited about what we are building, but maybe just need a job… then fake it. Do your homework, research the company, read our missions statement and tell me something! Anything that you might personally align with and get excited about.

Again, the generic answer here isn’t a red flag, but you’re definitely not helping yourself out.

Tip 2) “Ya don’t know, what ya don’t know, till ya know it”

I’m a firm believer that most of the levelling up you’ll do in software development happens on the job solving real world problems. I really just want problem solvers on my team. I want people that are ever-curious, will dig deep to find solutions, and have a good attitude. I could care less about the fact you know every single array method in JavaScript.

I still expect you to have a solid level of competency with some parts of our core stack (think big ticket items like JavaScript, React, etc.), but it’s not a no-go if you aren’t familiar with ALL of it. We just want to see that you can onboard quickly.

With that being said, it’s good to come to an interview knowing what you don’t know.

For example, before I interviewed at Weedmaps, I went to the site, opened up Chrome dev tools and went to town in the inspector. I was trying to see if I could find anything that I was unfamiliar with that wasn’t listed in the job req. I dug deep, and ended up finding out they used MobX for state management. At the time, I assumed everyone just used Redux for global state management. I had never used MobX, but was sure happy I took the time to find out that they did. Armed with that knowledge I was able to frame my lack of knowledge here in a better light. I let them know I didn’t know it before they even asked about it.

WM opens up with something like: “So tell us about your general experience on the Frontend. What tools and libraries have you worked with?”

Me: “Well I’ve been heavily focused on React for the last few years and just love it. When it comes to global state management Redux is my jam, however I did some digging and see you all use MobX. I haven’t worked with it much but I understand the core difference is immutability vs mutability”…

Obviously not verbatim, but I remember answering that question along those lines.

What it showed the interviewer was:
- I do my research

- I care enough to spend time digging to find out what I don’t know

- Took time to research what I didn’t know and find out what I would need to know to get off the ground with it, making me an easy onboard.

Tip 3) Anticipate our problems; Come with Ideas

This sort of goes back to the first part about doing your research, but let’s dig a little deeper. Taking Hopin, my current company as an example:

If you do your research on us, you’ll see we are a startup that has grown really fast.

You think it is a smooth ride and we’ve had no problems? Ha. Scaling is freaking hard.

As the interviewer, I love seeing candidates that come through asking about how we are handling challenges faced from scaling so fast. Why? Aside from opening up good dialogue about the company and getting to tell more of the Hopin story, exceptional candidates use this time to talk about ideas they have to help.

I’m not really even looking for unique ideas, I just like to see candidates already having an understanding of our problems. Again, this shows us that this person would onboard and integrate into the team quickly.

Just because you are a code-wiz, doesn’t mean you’re getting hired

Yes you need to know how to code and be a solid developer, but there are so many other things that we look for when interviewing candidates. We want folks that align with what we are doing, have an understanding of the problems we may face, and not be jerks.

We get it though, interviewing is hard and nerve-wracking, but with a little bit of extra prep work you can go in feeling sure of yourself and confident you’ll get the offer.

As always, thanks for tuning into another edition of Stack Yack.



🥞 Extra Stack

To get some other opinions on the interview subject matter, I reached out to two colleagues of mine - Jan Hesters and Matt Clough.

Here's what they had to say:

Thanks for tuning in,

Enjoyed the content?