(12 minute read; the footnote has my takeaways)
Interview rejection happens to all career endeavors. Recently I was applying for a software engineer position, getting on good terms with the company founder, however soon after the coding challenge you get rejected.
Disclaimer ( these are all experiences from the coding challenges that I’ve received from interviews )
I’m a full stack bootcamp graduate and current software engineer intern but I am also looking for a full time engineering position to fully expand my horizons. Since June 2017 I’ve applied to over 100 various developer jobs, ranging from intern to junior to some 5 year minimum experience super senior wizard dev role. Out of those jobs I’ve had 10 phone screens, and out of those 10 i’ve only had 5 companies give me the opportunity to take their interview challenge. These are the lessons from those 10 companies and how you can improve your interview skills to land your dream job.
First time for everything (5/31/17)
Going into an interview with a learning mindset is the best. Of course I wanted to actually get the job but after the dreaded “good luck on your job search” email I felt no remorse. I was happy I had the chance to actually get an interview, and based on how well or poorly I did in the interview it was a good indicator of where I was in my coding journey. In my first remote interview/coding challenge I was given 3 problems to solve in 3 hours, at first it seemed like a lot of time but I actually used up every minute to solve the problems. In hindsight I also accepted the challenge as soon as it was given to me, I could have studied for a few days before accepting the challenge. The first 2 questions were straightforward or so I thought, which was some variation to find the most frequent element in an array. The hard thing with this was to meet all the test cases by hackerrank. Yes, my coding challenge was through hackerrank. This was hard because I had to pass every single test case on a platform I’ve never used before. I solved the first 2 to the best of my abilities, but the last problem in the set of 3 was the most difficult. I had to parse a text file with multiple columns and rows and only extract a specific location, mind you there was tons of special characters mixed in which definitely threw me off. I did my best but as you know I was passed on for other candidates. In retrospect I just was not ready for this interview, I was actually still part of my bootcamp at the time and wanted to get a head start on the interview process to get experience. I also spent too much time on the first 2 problems, ones that should have been relatively easy, and once I got to the last problem I was flushed out of time. This was also one of the first few times I had to parse a file and extract data from said file. Sooner or later I learned that this was a requirement for a majority of dev jobs.
Take two to tango (8/31/17 – 9/4/17)
Round two of my coding interview. The position I was applying for was an frontend software developer internship at a healthcare company. The interview assessment they gave me was more captivating than the first and it had a similar theme as well. In there own words this was a case study to assess my skill set. I had a data set in the .xls extension, and the data was the first,middle, and last name of a list of physicians, their locations, and extra info on each physician. The mission that was given to me (if I chose to accept) was to create a simple web program that drops a pin on the U.S., highlighting the location where a physician was based. So in an form put in a physician’s name and it will drop a pin on the map. So a couple of things, I had to parse another type of file and the other curveball given to me was that I had to use google maps api to drop a pin somewhere. I was given 4 days and the interviewer gave me a rough estimation that the project should only take 5 hours. I was immediately driven and stressed out at the same time, but even though I was still writing for loops and if statements I accepted the mission impossible. I chose vanilla JS to solve the project and at first I did strenuous research, how to use google maps apis, tutorials videos, libraries(I had no limitations on what I could use). Then I broke this problem up into parts, first extracting the data I needed from the .xls file, printing it out to console to make sure I had the right pieces to connect to the google maps API. At first I found a method that used jQuery and AJAX but was getting stumped with the implementation, sooner or later I went to a library called papa parse that seemed simple enough and did the xls parsing and data extraction for me. I was able to get the data I needed but I had difficulty wiring a button that did the xls parse and returned the physicians address. I barely had any working knowledge of algorithms and was basically brute forcing my solution. Sooner or later I ran out of time and had to come up with another hacky solution that didn’t accomplish the main objective. This is the final solution: https://casestudy-nrsukujezh.now.sh/ In retrospect make sure you are using your time wisely, I spent too much time trying to parse the xls file that I barely had any time to implement the google maps portion. Don’t attempt submitting a half assed solution, ask for more time and finish the problem fully and thoroughly. Lastly know your algorithms, I’m pretty sure linear search could have worked and it was something I was using but was not aware of. On a deeper algorithmic level you could have written binary search to find the physician/address and then use that to connect with the api. Manage your time wisely was the moral of this interview.
Charm times the three (01/12/18 – 01/19/18)
Because of this I had to write a conversion function that changed the comparison values to meet the challenge specifications, this is where things got sticky. I started spending so much time on converting the cmp values without thinking that cmp was the problem the whole time. I think I could have manually written the comparison instead of using the built in cmp method. Finally I was able to get the correct solution but it only worked with a handful of ranges. I repeatedly refactored my solution to accommodate for these one off test cases but time was running out(even though there was no time limit). I kept thinking someone else would be taking my position, that someone else just turned in a solution before me! I pushed the red button and decided to turn in my solution as is. The solution worked for the exact case given in the problem, but for 40% of the other test cases it was a toss up. I never felt burnt out before until I was given this problem. Every day for a full week I was continuously trying new options, different methods, researching and researching. This is what eventually led me to another hacky solution, I just wanted to get something out the door to show I was capable of doing the job. In the end this mindset was wrong, take a break here and there, even a full day break to refresh your mind and step back from trying the same thing over and over again. I learned the hard way, that hacky solutions will never get you to the onsite interview. You always need to test your code and make sure it works 100% of the time, any deviation or mistake will cost you, especially if you have unlimited time.
What are my next steps?
It has been a rollercoaster of a journey but I can safely say I will be even more prepared for the next interview. These hiccups in my coding journey are merely minor milestones before I get my dream job.
Here are some key takeaways I learned from my interviews:
- Research the problem in and out, make sure you understand the problem and can talk about it
- Document everything you’ve tried, this helped for turning in my solution and lead me to cleaner code
- Take your time, i felt rushed through all my interviews, i always felt like i had to deliver something fast and that lead to spaghetti code solutions, which leads me to my next point…
- Don’t submit some hacky solution, architect a real solution and not something strewn together, make sure every part of the code works together and is coherent,
- Write test cases for your solution, make sure you account for every scenario, negative numbers, divisions by 0, this will impress the hiring manager more and show that you think thoroughly
- Be original and be proud, i did use a lot of SO posts and youtube videos to get a good insight on different approaches to the problem, but i also knew my solution was mine and mine alone since it was so hacky, in the end be proud of what you conjure up
- Always show confidence and be an open book, be honest about things you and do not know, if there is something you don’t know let them know how you can find out, or show them an alternative method
- The hiring managers are looking to make sure you can solve the problem and can write effective and elegant code