What I Learned from Doing 60 Technical Interviews in 30 Days

In this article, I’ll share my motivation for doing 60+ technical interviews in 30 days. More importantly, I’ll share 13 lessons I learned from my failures and my successes.

I’ve grouped the lessons into three categories to match the phases of a typical recruitment process.

While most of the lessons apply directly to software engineers and technical professionals, the principles behind these lessons can be applied to all careers. I hope you find something useful that you can apply to your professional lives.

How did I get started?

“If you’re going to fail, do it fast.” — Unknown

Like any other software engineer, I’ve had different types of technical interviews - from the dreaded whiteboard coding interview to the unreal 45-minute coding challenge on platforms like HackerRank. While some of my experiences in these interviews were great, others were bad. Really bad.

But I wanted to get really good at interviewing. I wanted to learn to overcome the interviewing phobia and exude confidence at interviews. Like a skilled surfer, I wanted to learn to ride the high pressure waves that came with interviews. I was also looking to change jobs at the time.

So from January through early March 2020, I applied to and was contacted by companies based in the US and Europe. From early-stage startups like Coda to later stage startups like Crunchbase, from mid-size companies like Affirm, to bigger companies like Amazon and even remote companies like Webflow.

109+ applications later, I landed myself more than 60 interviews. These comprised more than 60 introductory phone interviews, 50+ technical phone screen interviews, 18 take-home coding projects, 11 coding challenges and 8 on-site interviews including 3 virtual ones.

What did I learn?

For better appreciation, I have grouped the lessons into three categories to match the different phases of a typical recruitment process.

Pre-Interview Phase

This covers everything from the initial contact with a company to the point where the first interview happens.

1. What I learned about applications

When I started applying to companies, I imagined that the more applications I submitted, the higher my chances of getting an interview would be. Seems logical, huh? So I set a target of 5 applications a day, aiming for 1 interview for every 5 applications.

But my strategy didn’t work as I hoped it would. The number of interview requests I got often fell short of my target. It was almost a 1:12 ratio - 1 interview for every 12 applications.

I was faced with the question: do I need to increase my daily target to, say, 10 companies? Or was there something else I needed to change?

With every unsuccessful application, I saw that something needed to change.

That change came when I took a break from meeting my daily numbers and began to think of my applications differently. I began to see each application as a sales pitch to the hiring manager or whoever was going to be reading my application, but here the product being sold was me.

If a company needed to fill a talent gap and I say I had the skills, I needed to find a way to convince them that I did.

My new task then became to find a way to effectively pitch my unique skills, experience and personality in a way that convinced the hiring manager that I was the right fit for the job.

Here is an example of one of such pitches I came up with:

Backed with my resume, this cover letter had a 95% success rate. The one time this didn’t work, the hiring manager still replied to let me know that the position was no longer available but he would like to connect in the future.

The lesson here is, be very intentional about the application you put forward – quality over quantity. Better still do both. Know your unique competencies and experience and present them in a way that matches the company’s needs without sacrificing your personality.

It is also important to understand the peculiarity of the company you are applying to and its specific needs. A startup or a smaller-sized company may have different needs from a bigger company, thus requiring a different skill-set.

Sell yourself and be sure to back your sales pitch during the interview.

2. What I learned about recruiter in-mails

During this period, I received a number of in-mails from recruiters (mostly unsolicited) for open roles, the majority of which were roles I wasn’t interested in.

Granted, it was sometimes a lot given my busy schedule but I learned to be empathetic, understanding that these recruiters were only trying to do their jobs.

I stopped seeing these in-mails as noise in my inbox and started making the effort to reply to all recruiter in-mails, even for positions I was not interested in. By doing this, I succeeded in building a network of recruiters that have become a rich resource if I have to switch roles in the future.

Now I don’t expect you may want to start replying to every in-mail you receive. But it might interest you to know that some of the interview requests I got were from recruiters I had replied to before for roles I wasn’t interested in. It never hurts to reply.

The Interview Phase

This covers everything about the interview itself, cutting across the different interview types.

3. How to handle introductory phone calls

Yes I get it, you’re busy and many things are competing for your time. But hey, you are also an excellent professional, and that means you never get on a phone call without knowing at least these two things:

• the first name of your interviewer, and
• at least one tangible thing about the company — what they do, where they are located, any recent news, something, anything!

I noticed that for interviews where I put in the effort to make these findings, I always came across as being genuinely interested in the company. That’s something recruiters typically look for in these kinds of interviews.

4. How to handle technical phone screens

The one thing that can almost single-handedly decide how well you do in a technical phone screen interview is your ability to communicate your thoughts clearly.

You may have heard stuff like this before: “The interviewers care about your thought process. Yes they can see your code but importantly, they want to know why you are doing what you’re doing.”

The interviewer isn’t there with you and so does not have the luxury of seeing other non-verbal cues like your hand gestures or nuances. All the interviewer has is your voice as a means of understanding your thought process.

Now you know how you should lead this conversation, the next question is how do you become good at this? Because the truth is, while expressing your thoughts may come naturally to some people, it doesn’t to others – including me.

So – Practice! Practice!! Practice!!!

Practice doing a lot of mock interviews. Doing these mock interviews with friends made me better and more confident in explaining my thought process. But more interestingly, it helped me develop a new mindset about interviews.

I began to see interviews as a conversation with a friend or a team member. I visualized the interviewer on the other end as one of my friends (I sometimes gave the interviewer a name in my head). So what would have been a high-pressure interview I now saw as a friendly ‘chat’ about a technical problem.

This new mindset, aided by the many practice interviews, helped me grow in confidence so much so that I started enjoying interviews, sorry, technical chats. How to get started on a problem

Never start solving a problem without fully understanding the problem statement. You are almost never wrong if you start by asking clarifying questions. It’s also a good sign to your interviewer when you ask those questions rather than run with your assumptions.

5. How to solve the problem

Good candidates know how to solve a problem (e.g. a sorting problem), but the best candidates know multiple solutions to a problem and understand the trade-offs of one solution versus the other.

The interviews where I performed the best (Cruise comes to mind) are the ones where I didn’t just solve the algorithmic challenge – I was also able to provide alternative solutions and discuss the trade-offs.

Aim to provide multiple solutions to a problem, be willing to discuss the trade-offs, and be able to implement at least one of them.

For technical interviews, write clean code. Most interviewers care about your code quality as well as the correctness of your solution. Aim for modular code, separate reusable logic into utility functions, name variables and methods properly, and just be a boss!

6. What to do when you’re stuck on a problem

There will be times when you’re stuck. And this could be caused by a number of reasons: you don’t have the requisite knowledge, incorrect assumptions, missing details, and so on.

I used to think that at such times I was being judged by how fast I could come up with a solution. So I would be quiet, thinking, not communicating with the interviewer, just thinking.

And this is where a lot of us get it wrong. I get it, you need some alone time to think. But sorry to burst your bubble, that alone time is not when you’re being interviewed by a person.

Yes, your interviewer wants to see that you can come up with a solution, but one thing you must not forget is that they also want to see that you can collaborate with other team-mates to come up with a solution. While companies want rock-stars, they also want team-players.

Since your interviewer is a friend, a buddy, a team member who’s on your side and means well for you (Refer to 4), talk to them while you're figuring it out.

Share your thought process up till the point you got stuck and do it confidently, not like some cry for help. By doing so you just may uncover the solution, as was the case during my interview with Coda.

7. How to handle coding challenges

The lessons here apply to interviews that take the form of coding challenges on platforms like Hackerrank, Codility, and so on. Typically these are timed challenges, say 45 minutes or sometimes could be more.

Some of the lessons I shared earlier are useful here, while others like asking clarifying questions don’t apply since there’s no one to ask. So here are some steps I recommend:

• Read through and fully understand the problem.
• Write code that works first, even if it’s a brute-force algorithm. It may not pass all the test cases but get some working code out there first, hopefully within the first 15–20 minutes.
• Test your code with different input types, as this helps you handle edge cases.
• Optimize for efficiency (runtime and space complexity).
• Repeat Steps 4 and 5, till the very last minute.

A good grasp of computer science fundamentals is key here. I’ve added some links to helpful resources in the Resources section below.

8. How to handle take-home projects

Take home projects are an opportunity to really shine because you have more time. This also means they can be time-consuming.

One of the companies I interviewed with provided hourly pay, about $68/hr, for the number of hours you worked on their take-home project — it’s that serious, so you should be serious about it. Be sure you really want to be a part of a company before investing your time in the take-home projects.

Never compromise on code quality for take-home projects. Be very intentional about your design decisions, naming conventions, code structure and so on, and be ready to defend your choices.

During my interview with Course Hero, I used regex to solve a problem I could have solved using a simpler string parsing algorithm. It turned out to be a bad decision as I didn’t pass the interview.

The lesson: only use tools you’re very comfortable with and have a lot of experience with.

10. How to approach on-site interviews

Get a good night's sleep the night before. Arrive early on the day of your interview and smile a lot (it helps portray confidence, but more importantly helps you stay relaxed and be in control).

Confront your fears and accept that even if this doesn’t work out it’s not going to be the end of the world – after all you’re just going to have another technical chat. Then go in and absolutely chat away.

11. How to approach virtual on-site interviews

These can be very different from on-site interviews because everybody’s eyes are on you – literally – and that can be nerve-racking.

I had three virtual on-site interviews and I didn’t pass any of them. Sorry I’m not your guy for this one, but I’ve shared some resources that I think you may find helpful below.

After the Interview

12. How to handle failure

There are many reasons why you didn’t pass an interview. Some of the best engineers I know have failed interviews at some point and still do.

So separate failed interviews from yourself, look for the learning points from each failed interview, and use those to forge ahead. As they say – we move!

13. What about success?

Celebrate your successes, regardless of how small you think they are. I have a few ideas for celebration.

Am I better after doing this?

I’m not going to tell you that I've aced every interview that has come my way since I embarked on this journey. But assuredly, I can tell you I have gotten better at interviewing and my confidence levels have really grown. And yes, I also got multiple offers too 😊.

What should you do next?

• Practice doing a lot of mock interviews with friends. While I don’t totally agree that practice makes perfect (because perfection sounds like a moving target to me) practice helps you quickly identify patterns in interview questions, grow in mastery and ultimately your confidence.

• For technical interviews, nothing beats a very good understanding of the fundamentals of data structures and algorithms. I’ve added links to resources I think you may find helpful.

• Start interviewing and keep interviewing. Even if you have a job, aim to interview every now and then — maybe once every other month or a quarter. Interviewing is a skill, so keep honing it.

I really hope this was helpful to you. And hopefully some of the lessons shared here will make you more confident and better at interviewing – and will ultimately help you land that job you really want.

If you ever need someone to do a mock interview with you, feel free to reach out to me on Twitter @meekg33k.

E go be. ✌️

Helpful Resources

from Hacker News https://ift.tt/2PgalI4