What I Learned from Doing 60+ Technical Interviews in 30 Days

Subscribe to my newsletter and never miss my upcoming articles

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:

body image.png

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.

9. What tools should you use?

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

Tapas Adhikary's photo

Uduak Obong-Eren, This is so motivating man! Great Tips to follow.. Thanks for sharing..

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

Tapas Adhikary, Glad to know this was worth your time and you found this motivating.

Lisa L Gruman's photo

Hi, Uduak Obong-Eren: This article is great for anyone - even non-software engineers - looking to become great at interviewing . . . and life! Excellently detailed, yet easy-to-understand, you graciously and generously shared all your research to help others. In sharing your intellect, you also revealed your kindness. With thanks. +Lisa G.

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

Thanks for your kind words Lisa L Gruman, I'm really glad to hear that you found the article insightful.

Bolaji Ayodeji's photo

This is really amazing, thanks for sharing!

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

Thanks man, glad you found it useful!

Bolaji Ayodeji's photo

Developer Advocate at Hashnode

I can't wait to read more from you :) Uduak Obong-Eren

Vesk's photo

I'm sorry to say it but am I the only one who thinks that the last bullet point in your pitch, about being adding diversity is just kinda weird? At the risk of sounding politically incorrect, even if such studies exist, that doesn't mean that candidates should be given an advantage/disadvantage based on something like this, that they haven't chosen and can't change. And saying that you deserve something more than someone else, because of your race/sex/gender/etc. is simply wrong, in my view. Besides that, I must say this is a great post and it is really helpful and insightful!

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

Hello Vesk, thanks for sharing your thoughts. First off, nowhere in my article did I mention anything about "deserving something more than someone else"; if you're focused on competing with someone else, I think you may be missing the main point of the article.

What I set out to do was present my unique experience, skills and personality (my race being a part of that) in such a way that my prospective employer sees enough value in me.

Secondly, diversity is something I care about and owing from some of the personal experiences I have had, I prefer to work with diverse teams. Though I presented my reasoning, the truth is that the decision is entirely the employer's to make. Notwithstanding, I don't think I want to work in an environment that thinks talking about diversity is "kinda weird".

But again, I really appreciate that you shared your thoughts.

Ruth Ikegah's photo

This is very detailed, thanks for sharing Uduak Obong-Eren

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

Glad you found it helpful Ruth Ikegah.

Chet Kuhn's photo

So you're saying that all we need to do is be top-notch, A-list programmers with years of experience, world class communicators, best-in-class sales people, organizational wunderkinds, and genuine, endearing people pleasers? All at one time?

It's so simple, it's really a wonder that someone else didn't think of it first!

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

Nope Chet Kuhn, all I'm saying is aim to be better one day at a time. If at the end of that journey, you're all of these then why not? :)

Toby Osbourn's photo

As someone who regularly works with companies to hire developers, I wish every applicant could read this advice!

Great writeup!

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

Thanks Toby Osbourn, I'm glad you found this insightful!

Ben Johnston's photo

Thank you Uduak Obong-Eren. I think you could probably flesh this out into an e-book and sell it on Gumroad. As helpful and detailed as this is there is so much more I want to know. You basically took a big enough sample to see the patterns in each step in the process.

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

It's a pleasure Ben Johnston. I'll definitely explore that option. I'm happy to talk more about this if you need to know more, you can reach me on Twitter - my handle is @meekg33k

Efereyan Karen Simisola's photo

E go be. Hahaha . Thanks for this boss. I have had two interviews, one of them I failed because I had issues deploying my app and the second one I assume I failed since I never really got a follow up mail from the company. It hurt a little. But we move

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

There are certain things we have no control of Efereyan Karen Simisola and there are other things we have control of - one of which is taking the learning points from every not-so-good experience we have and using it to make yourself better. I'm hopeful you will get something sooner than later. All the best!

Rana Emad's photo

Wow! That's some great effort! Thank you for the tips

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

I'm glad you found it useful Rana Emad

Sandeep Panda's photo

What a resource! Bookmarked - thanks for writing this!

Yevgeny Lvovski's photo

Thanks for the great tips. One thing that I would add is if you have favorite companies that you really want to work at, I suggest to apply there in a more later stage, after you practiced your interview skills in some low priority interviews.

Destiny Ajakaiye's photo

Uduak Obong-Eren this was an amazing resource. Just in time for what I need actually. Thanks for sharing bro!!

Diogo Machado's photo

Thanks Uduak Obong-Eren for share these amazing points about your experience.

Aliyu Aboubakar's photo

I love this. I've always had it wrong sending applications and interviewing. This has just changed my mindset and perception. Learnt a lot. Thank you very much.

Emmanuela Azubuike's photo

This is so helpful as well as intimidating😥 Any advise for a junior dev who has never had a technical interview? Do all of these apply too? Thanks.

Uduak Obong-Eren's photo

Software Engineer | Technical Writer | Carnegie Mellon Alum

Hi Emmanuela Azubuike, like with every other thing else, the first step to getting comfortable with interviewing is to start interviewing.

For a junior developer, I recommend doing mock interviews a lot, learning your CS fundamentals (data structures and algorithms) while building your experience through contributing to OS projects and other personal projects.

I'll be happy to do a mock interview with you if that's something you're interested in, you can schedule one using this link bit.ly/tech-chat-with-meekg33k

Emmanuela Azubuike's photo

Frontend Web Developer💙

Uduak Obong-Eren Thank you so much. I'll jump on this