Two weeks ago, after applying for over 30 internships and facing may well-meaning, thoughtful and personal rejection responses (as if), I was finally able to get a tech interview with a dev shop in Des Moines, Iowa.

After meeting them at a hackathon they sponsored as well as a career fair in the Fall where they told me to “work on some stuff”, they offered to take me through the recruitment process. Great! I thought to myself. After applying to dozens of places, and most of them either flaking out, rejecting me outright or telling me that only juniors need apply, I felt great that I at least got **one **interview. I mean, it isn’t Facebook, Uber or some company with a valuation of over $100 million on Crunchbase, but it is something!

The first part of the application process was to do a short quiz on Hackkerank. The questions I got was the infamous FizzBuzz problem, the coin counting problem as well as checking if two elements in an array summed up get a given number. I got to choose the language to work with and I choose Python, a language I have spent many hours using. The option for Python3 went away after FizzBuzz, so I just worked with Python 2.

FizzBuzz is a typical gotcha question in which you are given a number `n`

where for each number up until then, you need to print out either “Fizz” is the number is divisible by 3, “Buzz” if the number is divisible by 5, “FizzBuzz” if the number is divisible by 3 and 5 or just the number if it is neither divisible by either 3 nor 5. Sounds simple enough, except that I nearly failed to do this because I put the if conditions in the wrong place that would fail if the number was divisible by 3 and 5 since `if i%3 == 0 `

was my first condition.

As for coin counting, that was also easy- just use a greedy algorithm to subtract as many coins as you need until you can no longer do so at the current coin value. This also seemed straight forward, but as I learned recently, the greedy method won’t work for all coin denominations, so you have to use a technique called dynamic programming. The final problem was rather simple as well, just using a doubly nested loop to check all items until a certain combination equals the required sum.

Once that was submitted, I waited for a reply and they told me that I was scheduled for an interview the following Wednesday. I thought it would be online, but I found out on the day of the interview that I would have to drive down to Ames missing another day of classes and some work. After going to another career fair along the way, ending up at a random guy’s house as well as three near misses, I arrived **exacly on time **as I entered the waiting room as soon as they called me in for the interview.

In the interview itself, I was asked which language I would want to solve the problem in. At first, I yelled out “Python!”, but they didn’t have a test case for it, so then I was like “JavaScript works too!” and they agreed to test me in JS. The screening required me to find the duplicate element in an array. They said that it is encouraged to think out loud and I could ask for help if I needed it.

At first, I thought I would just sort the array and walk through and check if the next index is different and if it was, return the element in that index. Then, he told me that has the worst cast of O(n^{2}) which is pretty damn slow and was asked to pick another data structure that has constant time inserts and deletes. “Ha, Dictionaries!” (or HashMaps/Objects) I thought to myself. I then implemented a way to insert each item into the dictionary along with an occurrence value and if it has been placed in the array, I would add one to the occurrence. Once I’ve done that, I would then go through the dictionary keys and find the element with an occurrence value of one and return it.

Still, it had a worst case of O(n^{2}) and the tests even failed because of a few bugs, like adding indexes as opposed to value. I was then asked what I could do to drastically improve performance given what I knew about dictionaries. I blanked out and I was told I could just delete the element instead of modifying the occurrence, making the worst case O(n) instead which is much faster. I felt really dumb, but I was able to do this and the tests passed!

Apparently, there was an even better way. Still, I could do even better by not using a dictionary at all. At this point, I was like “screw that” and he showed me that I could do a cumulative XOR into an initial value of 0 that would eliminate duplicates since that an XOR gate works by returning false for two truthy values and true otherwise. I was really confused and when I asked my advisor the next week, he walked me through it and it turns out that using the XOR will include elements that appear an odd number of times in an array.

Once I felt dumb and acknowledged the need for my Data Structures and Algorithms class, I asked about the testing framework used which was Mocha.js and he also explained some of the other node dependencies he had. After a bit of small talk, I was on my way back to Wartburg.I felt so happy that I was finally able to get

I felt so happy that I was finally able to get a chance to prove myself instead of getting brushed aside. Granted that many others got dozens of interviews in **their freshman year**, but this was a big deal for me. Fortunately, they invited me for a more formal interview so I’ll see how it goes. Hopefully, this will be the first of many interviews as well as offers.

*So, if the one reader of the blog has noticed, I haven’t published anything for nearly three weeks. That’s because I was busy doing a whole bunch of stuff like hackathons and classes. Fortunately, it’s spring break, so I’ll be able to catch up on my writing. I’m not sure what I’ll write on next, but I hope to get back into the game!*

## One thought on “My First Tech Interview”