Graduating from a 4 month Software Engineering immersion school does not, by itself, prepare you to ace technical interviews in the job market. It may not even adequately prepare students in a number data structures you are likely to encounter on these tests(like stacks, hashmap operations, binary search, ect.). What bootcamp-style engineering schools give students are the fundamentals in a few languages and the ability to learn how to learn programming concepts so that they are set-up to excel on the job. My personal experience is echoed by many other graduates I know so I wanted to frame my experience with algorithms and technical coding challenges and what I am personally doing to solve these challenges in the limited time period.
My first technical interview was the week after graduation and was in a mock format to evaluate and prepare for the real-deal. A third-party company affiliated with Flatiron School(my bootcamp), was contracted to give an hour-long technical interview and provide feedback. My question was in regards to string-manipulation of a 200 line string that looked like it contained objects with key-value pairs. The interviewer informed me I would be required to change all the key values to camal-case; that is: transform a key-value from something like dog-walker: "Bernard" to dogWalker: "Bernard". I also had to account for a number of edge-cases where the key was dog-walker-address to dogWalkerAddress or city/state to cityState.
As I talked though the problem before diving into coding, I felt confident. I was going to parse the single huge string into an array of objects with JSON.parse and then assign all the key-value pairs to variables with Object.assign. Then I would use regular expressions to find any separating characters like '-', '/', or '=', determine the position of that character, and operate to make the next character uppercase before continuing onto the next object. After confirming this was an acceptable solve for the interviewers requirements I dived into the coding.
40 minutes had elapsed by the time I was able to get the objects into variables, had created an iterative approach to working with each key, and used the regular expression to find the positions I needed to operate on, and changed these to uppercase. Congratulations, I was able to solve the equation for the base cases! At this point the interviewer let me know we had reached the time-limit and although I only accounted for one edge-case I thought I had performed fairly well. The feedback I received a day-later was a bit of a shock:
"Andy was a pleasure to have in an interview setting, and he definitely checked off all the boxes when it comes to soft skills. Based on the observations in the coding exercise, Andy sounds very confident and its clear that he has a sense of what he wants to accomplish and how he'd like to get there. The main feedback for Andy would be to remain confident and trust the output that he receives in the console. It was often the small mistakes that really held Andy back from moving through this problem efficiently. Little typos, not fully investigating the output of the console, as well as some of the methods he was using to solve the problem all contributed to the time it took to get to the result of the first part of the problem. Throughout the interview, Andy would express his concern for the run-time performance of the problem, which is good to bring up as an optimization, but he should focus on simply solving the problem, and only then consider optimizations. He might find the original approach is an optimal solution. 2/5"
2/5... Despite implementing a naive solution that admittedly did not solve the edge cases, I thought my solution was adequate enough to at least mean I would pass. The experience was instructional. When given a challenge, the bar is to at least solve a challenge to the full extent of the question, and then it is acceptable to refactor for performance and other tasks that give style points.
Unfortunately for me, when it then came time for technical interviews in the next week for actual developer positions I applied for, I was similarly hit by the unexpected. I took one screening test in Javascript which required me to solve a number of array tasks. Again I was able to solve all the functionality required, but the testing site HackerRank wants all the outputs in a node function process.stdout format instead of simply being returned. At Flatiron school we were not introduced to Node.js as a server/backend as we exclusivley used Ruby on Rails. After failing to figure out how to output my correctly coded question, I ran up against the time limit and was unable to get any of the tests to pass. That night after researching I found that node handles the return similar to console.log in the following format and that was the only way to pass the tests:
console.log = function (d) {
process.stdout.write(d + '\n');
};
Similarly, I took two code screening challenges that used data structures I was unfamiliar with and subsequently did not make the next interview round. One was on working with a stack to check if any word was a palindrome and the other was a hashmap operations challenge. I had seen neither of these data structures before and was forced to spend the whole challenge time period researching and not solving.
My experiences with technical interviewing has confirmed that bootcamp graduates do have gaps in their knowledge that make these interviews potentially challenging. There is simply too much information to fully teach in a 4 month course to master or touch on all of the concepts. After graduation, I recommend you dive into Leetcode, Hackerrank, Geeks for Geeks, ect. and expand your ability solve coding challenges in a variety of different formats. Additionally, review all the data structures present in the languages you are interviewing for and make sure you have a firm understanding of all of these. Finally, the only thing holding bootcamp grads back is experience, so just keep plugging away and get better!
Top comments (0)