Reading02: My Interview Experience

Reading02: My Interview Experience

Going into the fall of my Junior year, I was completely overwhelmed.  Not only did I have zero technical (and almost no behavioral) interview experience, but I had essentially no idea what I wanted to do.  All I knew is I wanted a job where I would be coding.  This combination led me to essentially go rogue in my application process and apply to no less than 116 companies in industries from consulting to tech to finance and cities across the country from San Fransisco to Chicago to Washington DC.  After going through this somewhat ridiculous wide-net search, I feel quite acquainted with the ins and outs of the technical interview process and feel am in a decent position to speak on its merits and shortcomings.  Throughout the process last year, I experienced my fair share of behavioral and other non-technical interviews, but for the purposes of this blog, I will focus mostly on technical interviews.

At most firms I applied to, the process went somewhat like the following.  First, I would submit my resume into the black hole that was an online application.  If I was lucky, I did some sort of networking with that company through Notre Dame, but for the most part, this was completely random.  Due to the disconnected nature of this slingshot approach, I knew my response rate would be pretty low, but that was okay with me.  When I actually did receive a response that wasn’t just a standard rejection, most companies would ask me to complete a coding test (or some other type of technical assessment) on HackerRank or some similar online provider.  These tests would typically consist of about three coding questions of varying difficulty, usually structured so that time is not a horrible issue.  Though questions here or there were sometimes difficult, I usually felt that these tests were mostly manageable.  I completely understand the need for companies to screen their applicants with something like this before actually talking to them, so I was totally fine with them.

If I passed the coding test, the next step was usually a phone interview that could either be technical, behavioral, or a mixture, and often involved using a shared screen for coding.  In my experience, these interviews varied wildly in quality.  The worst phone screen I had felt more like a grilling on obscure data structures questions than a test for whether I would be a good fit at the firm.  I simply do not understand why being able to answer unrelated brain teasers like the data structures questions I received is even a somewhat good indicator of whether I’d be a good fit.  On the other hand, the best (and one of the most difficult) phone interview I had entailed me debugging an error I had made in the coding test I took in my application while talking to the interviewer.  I found this to be a much better assessment of my technical abilities than your standard algorithm/data structure coding interview question (which are a pain to prepare for and I don’t think are great predictors of actual job performance).

After these phone screens, the process diverged substantially (and I didn’t get to see it through completely due to thankfully finishing up relatively quickly), but most companies’ final round interviews involved an actual visit to the office for in-person interviews.  I won’t discuss those in this post, but before concluding, I would like to mention one other innovative interview tactic I found useful.  One company asked me to complete a small coding project to fulfill a prompt very relevant to its actual business and gave me a week to do so.  This allowed me to tackle a programming project in the way that I normally would with a timeline that wasn’t too much of a burden for me while going through other interviews and normal schoolwork.  And on the company’s end, it gave them a clear view into my coding style and problem solving ability.  Though candidates could certainly cut corners with this interview approach, I think it is a much better screening tactic than your typical coding interview.

In conclusion, I believe that while traditional coding interviews aren’t necessarily useless, they are best used when supplemented with some of the more innovative approaches I have discussed in this blog.