Whether applying for one of the Big-4, medium-sized firms, or local startups, interviewing for companies can take a lot of time. In fact, it's a bit overwhelming.

In my 2.25 years of recruitment, I've found myself faced with a variety of circumstances - coding challenges, phone interviews, video interviews, in-person whiteboarding.

Each interface presents itself with a list of benefits as well as a whole set of challenges that the other platforms do not have.

For instance, coding challenges are flexible because you get to do them whenever and wherever you want without worrying about being interrupted (as long as you finish by the deadline). Of course, finding a 60min+ block of time can be hard to find. But for someone who's busy (or watches lots of Youtube) it helps in scheduling events on the fly.

As a verbal learner, coding challenges pose a tougher obstacle for me. Since processing thoughts internally usually causes my mind to overload itself, it can be a bit more difficult to do coding challenges when all I have to talk to is my computer screen and my trusty debugging duck, Charlie, who I gave away to my friend. (You will be missed, Charlie).

Phone interviews are a bit more interesting since you get more one-on-one interaction, a company summary, and Q&A about an engineer's experience at the company. Unfortunately, there are some challenges that arise when having no face to face interaction, such as silent awkward moments of thought, and it can be a complicated issue when connection issues arise.

The fun part about phone interviews is that it opens up a new range of dynamics that coding challenges lacked. Depending on the interview, you could be presented with many different things to traverse: a behavioral, technical, or combinational interview. Each of these aims to get to know you on your way to communicate with others or dissect you ability in technical problems.

Video interviews are possibly my least favorite of all interview platforms (sorry video-call software companies). Even though I get a more face-to-face interaction with the engineer and become freed from traveling off to a specific interview site, the tradeoff is rough. Weak connection can bring about a wide spew of technical difficulties, making the interview a very tough time for everyone.

(Of course, if I get a job through a video interview, I might change my opinion on it :P)

In-person whiteboarding is probably one of my favorite ways for interviewing. Not only do I have the opportunity to go on-site to companies (I've only done it twice :P), but I also get the privilege to personally interact with an engineer (hopefully) in person. With direct communication, almost all barriers of miscommunication are erased, allowing for a very raw and genuine interview.

At these moments, these interviews become more of "What you see is what you get".

As a verbal processor during a white-board interview, having someone in front of me to bounce my thoughts off makes my life easier than talking to an inanimate duck-like object. Additionally, though awkward silent moments can be more experientially difficult, I feel more at ease knowing that the engineer can see what I'm doing and I don't shy away from asking questions/hints.

Subsequently, using an expo marker whilst writing on a whiteboard brings many nostalgic memories - Operating Systems, Hackathons, Ideating, Project Management planning - I get into a sort of comfort (as well as triggered) zone when I get to whiteboard a problem out.

Most of all, nothing gives me more satisfaction (other than my faith) than being physically present when solving a problem and presenting the solution with pride in-person.

Now, with all these different interviews, one of the toughest things that I've had to learn over the past few years (and probably the main point in this blog post) is how to approach an interview with all the preconceived notions/obstacles.

Feeling the jitters. Being unsure of what to say for my introduction. Cramming topics from Cracking the Coding Interview. Looking up all the methods that data structures contained. Doing last minute coding questions on Leetcode.

Many times, I found myself stressed out to the point that throughout the interview, I'd be tensely on the tip of my chair while my heart pounds to the max as all the weight of my body rested on the tip of my toes.

Though it was exhilarating, it was very taxing.

I've learned that interviews can be also hyped up too much. A talk with an engineer from a hotshot company can be frightening. Additionally, it may seem like the interviewers are out to get you - one fumble in a problem can turn into an interception, before snowballing into a touchdown for failure - all of which seems to cast you out of the recruiting game. Most of all, not being able to find the words to say and sitting/standing in a moment of awkward silence as the cogs in your brain seem to churn out nothing can be one of the most horrifying things to experience - second to possibly public speaking.

But interviews aren't as intimidating as people think.

The interviewers are cheering you on. They want to help and guide you so that you can achieve the main goal that they have - not to solve the problem (though that's one of the goals), but to see how you work with others, witness your thought process and communication skills as you work through a problem, and figure out whether behaviorally you would fit within the company culture.

For me, it's been quite a ride coming to that conclusion. I've developed from being a stiff self-conscious student who didn't know what I was doing, to a more relaxed, chill, and attentive programmer with a goal in mind.

My goal is not to worry about what the interviewer thinks about me (even though that is something to think about). Rather, my aim is to do my best.

Whether it's explaining my personal background, attempting to ace programming questions, or learning about the company to see if it's a good fit for me, all these things are aimed at a long-term goal - to better myself.

If the company doesn't take me cause I didn't do my best, I iterate over my mistakes, learn from it, and attempt to do better next time.

If the company doesn't take me when I did my best, then maybe the company wasn't a right fit for me, or I didn't achieve the expectations they had. That's ok. Learn and move on.

If the company does take me, well... then I guess it worked out. :)

Anyways, the goal is not to prove something to a company - that's short-term.

The important thing is to become the best you can, not by the standards of others, but by your own past history. Computer science is tough since it can come down to a comparison game. But if you always strive to be better than what you were previously and aim for your peak, you will do great things.

So please don't settle for less. Do your best in your interviews, have an open heart in learning while recruiting. And I know, with that mindset, you'll be fine :)

Anyways, thanks for reading my blog post guys. For those of you who are still doing interviews, I wish you all the best! For those who have internships, good job and learn lots in the summer. And for those who are just passing by, hopefully, this gives you a few insights to help you in the future :P

If you like reading my blog posts and want to read more, you can find some of my more personal blog posts here at Medium. You can also follow me on Twitter @SoloTheCreedo for technical updates in my life. And if you're interested, you can rate my code on Github.

Have a good week, good luck on what you have to do, and see you guys next time! Ciao.


The views, opinions and positions expressed by the authors and those providing comments on these blogs are theirs alone, and do not necessarily reflect the views, opinions or positions of UT Computer Science, The University of Texas or any employee thereof.