Interviews

Interviews are a two-way street. In an ideal world, it doesn’t matter too much about how you perform in the interview. Interviews for the interviewers to see if you would fit in their teams and cultures both skill and personality wise; you also should be doing the same.

I’ve spoken with a lot of HR people and tech directors alike throughout hiring processes,and they all seem to agree: your attitude is more important than how good you are at coding. It’s how you show the process of how you solve the problem, react to adversity, and show your personality in general.

You might get asked things like:

• What is a time when you made a mistake and how did you fix it?

• Let’s say you’re behind on a project. How do you rectify the situation?

• Name one time you were challenged and how you overcame the challenge.

I always hate these questions. It’s hard to think on the spot (maybe I just need to prep more.. guilty!) and for instance, I rarely find myself behind on projects because I try to keep ahead [1]. But the point is: just try to answer these honestly. You should get to the point (STAR method), but I often find these questions as opportunities to get a bit of personality across. Sprinkle in something you found funny or interesting about the project you were challenged on. Tell them what technology you learned from a mistake.

Once you make it through the sea of unappealing questions, it’s your time to shine.

You could ask things like:

• What’s the most challenging thing you’re working on? Do you find the problems you’re working on interesting?

• How do you like your managers? Do they notice your hard work?

• What’s your favorite and least favorite part about the work you do?

I like these questions because they put you in a closer position to what it would actually be like at the job. They help you imagine yourself in that exact role, which is good for you to find out if you want to be there; and it shows good interest to the interviewer.

I would also note that some of these questions could have negative responses. We’re not trying to goad bad answers out of people (and rarely, if ever will you hear any interviewer say anything bad about the company), but you do get honest answers. I’ve heard things like “I don’t like working with technology X or edge case Y,” which is really insightful to know going into the job. …and if you don’t get honest answers, or answers feel forced and practiced in advance, do you really want to work there?

Also, there is a slightly different set of questions I would ask for a non-technical or human resources type interview, but still valuable:

• What’s the culture like?

• What’s the room for career growth like at _____?

• What do successful people in this role look like?

These questions show you’re genuinely interested in working at the company and are trying to imagine what your life would be like there – which are things you should be genuinely interested in.

All in all, you could read a hundred interview books and blog posts, watch a hundred interview prep YouTube videos, do LeetCode problems until you’re insane [2], and it will maybe probably somewhat mostly prepare you, right?

But when it comes down to it, just be yourself. Get your personality across, and interview the company as much as they’re interviewing you.

---

[1]

One time I was super vague and sort of made stuff up as an answer to this question. The big tech senior director interviewing me fully called me out and was like “yeah, it sounds like you didn’t really actually have that experience.” Lesson learned: Be honest! And on a related note, I ended up not choosing that job for a few reasons, but one factor was that I didn’t feel super respected from him nor did I feel a lot of interest.

[2]

In the rare event that a company is reading this: Please stop! LeetCode, HackerRank, CodeSignals, are such a joke. When am I ever going to implement Tetris (true story - there’s a similar question) at my job? When will I ever implement an RB-tree traversal? I think HackerRank and CodeSignal are beginning to do this, but measure me on what I actually will be doing - writing APIs, database queries, designing frontends, etc. There’s a way to show applicants actually know how to code without gamifying it.