What you can learn from a 30-year-old’s first coding interview
Going from a U.S. Navy veteran chef to a programmer
I have previously written about how I helped teenagers learn how to program. In that article, I shared some of the teaching methodologies that I found to be effective for engaging teenagers in learning to program.
In this article, I want to take a different approach and share a completely different personal experience in prepping a 30-year-old U.S. Navy veteran chef for his first coding interview.
Unlike the case of teaching a group of teenagers, the focus for teaching a grown-up is no longer being interactive or being fun. Rather, many grown-ups are goal-driven and they work hard when they really want to achieve something.
For the case of this veteran chef, the main motivation was to transition from being in a culinary arts career to a computer programming career.
However, I realized that a clear goal and motivation is not enough to easily learn programming and succeed in programming interviews. So, I wanted to share my experience with the problems I saw and some of my own solutions to those problems.
In addition, I hope this article engages other grown-ups to recourse the approaches that they have taken when first learning how to program.
Why the Sudden Career Shift?
Just as provocative as the title sounds, my family members were all shocked when my younger brother, a 30-year-old U.S. Navy veteran chef, broke out the news a year ago that he would be going back to college to major in computer science.
It is not that my brother had a failed career as a chef. In fact, he graduated from the Culinary Institute of America, which is one of the most prestigious culinary art schools in the United States and managed to land a pretty well paying job as a culinary manager at a Silicon Valley tech company.
However, a career in culinary arts is very physically demanding and accompanied by long working hours, which is spent mostly standing up. My brother is a disabled veteran with multiple metal rods in his ankle, so the physical demand was getting harder and harder for him to endure.
He knew that he wouldn’t be able to continue on for long and he needed a career that was less demanding physically. He was tech savvy ever since he was young, and figured that it would be a good idea for him to go back to school to learn programming. So, he joined a 2 year program at Oregon State University to get a bachelors degree in computer science.
Prepping for the First Coding Interview
He finished a year of college-level computer science education, consisting of basic object oriented programming, systems programming, web programming, and finished quite well with a high GPA.
Since the first summer break was approaching, my brother started looking for a software engineering internship position. Knowing that most software engineer interviews had an interactive coding session, my brother searched for books and materials that promised success in these interviews. He rushed to buy a book from Amazon that promised its readers that they would crack coding interviews.
After browsing through the book for a couple of days, this is the first conversation we had.
Brother: “How can I memorize the solutions to all 189 programming questions?”
Me: “You don’t and you shouldn’t. You need to learn the algorithms and data structures behind each question.”
Brother: “But there are sooooo many algorithms and data structures to learn and I don’t have enough time. Let me first try to memorize these problems.”
Me: “I can assure you that there there are more problems than algorithms…”
Skeptical of his decisions, I left him to explore the consequences of his choice that he made as a grown up.
After diving into memorizing each question in the book and in various websites, such as LeetCode and HackerRank, he grew very confident that he was good at this interactive programming thing that he has never done before, and he started applying and received interview requests from big name companies like Facebook and Google.
The First Coding Interview…
I think I have given enough spoilers on how this went. For his Google interview, he received a problem that he had never seen before and he was unable to solve it. For the Facebook interview, he felt really confident that he passed, because he got a problem he had seen.
However, he didn’t make it and he came back asking me for help. We started by backtracking what he had done wrong in the prior interviews and also to get a better understanding of how he performs in an interview setting.
I asked him if he wants to do a mock interview both with and without a problem he knew. He agreed and after a couple of interviews, I found a few issues that I wanted to share for the benefit of all.
Facing an Unseen Problem
This is a pretty obvious issue. Although my brother studied hundreds of questions, he’d memorized the solutions to each of them without understanding the algorithms and data structures behind them. Once a given question would deviate from the list of problems that he had seen, he stuttered and started thinking about how to solve it.
Sometimes, he was able to apply similar knowledge, but he had trouble identifying the category of algorithms to use for unseen problems most of the time. If he had a high-level knowledge of the set of widely used algorithms for coding interviews, all he needed to do was find ways to apply them.
The solution I proposed to this problem was to focus on the algorithm, not the solution. In fact, when you approach a problem, make sure to note which algorithm you think you need to use and then verify if the solution actually uses that algorithm.
Excessively Favoring a Language over Another
When you first learn programming, most people start by learning a language and the details of the language constructs, such as loops and conditionals, rather than the important concepts of programming.
I understand that the reason for this is because learners want to get right down to doing some programming. However, such a practice has dire consequences, which makes you become narrow-sighted to a single language as a beginning programmer.
Hence, once an interviewer asks a candidate to implement some library functions that already exist in your favorite language, the candidate often times completely blanks out, mainly because they always took the library functions for granted.
This happened to my brother as well. He was most familiar with C++ and JavaScript and when I asked him to implement a simple library function, such as a power function, he blanked out and couldn’t think about anything more than a naïve implementation.
Also, for string related problems, he focused on using existing methods like substring, which is best to avoid when first learning the essence of the problem.
The interviewer can be nice and let you use library functions, but you cannot always expect such generosity. So, the solution I proposed for this type of problem is to focus on the programming concepts, rather than the language constructs.
In fact, when I first learned programming at Caltech, my entry-level computer science instructors tried hard not to teach the details of a language. They only gave some information on the bare minimum of the language the students needed for the class and allowed the students to use only the minimal features that were discussed for the programming assignments.
Such a practice allowed students to easily switch programming languages at a later time based on which language was more appropriate for the use case. Additionally, it allowed them to think outside the box when they had to face a problem.
Speaking Too Little
There is a saying that goes “Speak less, do more”. However, this is not the advice a prospective candidate should follow when doing programming interviews.
When I gave a problem to my brother, he started writing stuff without talking about the code he was going to write. When I asked what he was thinking about, the words that came out were jumbled and hard for me to follow.
As an interviewer that has interviewed multiple candidates over the years, I always want to hear how candidates think out loud and how they approach a solution.
Many think that this wastes precious time. However, going too deep into an incorrect solution without discussing it with the interviewer could result in more time getting wasted. Most of the time, interviewers look for a solution that they are thinking about. So, talking to the interviewer would put both of you on the same page.
Of course, it is bad to propose an incorrect approach. So always think before proposing something. Therefore, a suggestion I proposed is to think out loud, but be clear and structured in what you are saying.
Overconfidence
On one occasion, my brother had to solve a problem and had seen the solution online earlier. He was very confident and thought he nailed the interview.
I asked him the details of the question, and he said he coded exactly what the solution he memorized said. However, he had a hard time describing the details of the algorithm, such as time complexity, and also had a hard time writing test code. That’s when I knew that he did not do well on the interview.
Most of the time when people see a problem that they know, they blaze through the code without thinking. And most of the time, this happens for easy questions.
However, when an interviewer gives an easy question, the main purpose is to dig really really deep down on the nitty gritty details of the problem. So, knowing just the solution does not cut it.
You must be prepared to know the details of how the algorithm functions, including time complexity and space complexity, and how your solution can fail in various cases.
Also, going back to what I mentioned earlier, don’t just write the solution without talking about it. The interviewer will definitely know that you have seen this problem before. Thus, the solution that I propose for this problem is don’t be overconfident and be mindful of the details.
Final Thoughts
Doing a career shift as an adult is hard. Most adults find it difficult to change practices and habits compared to when they were younger. Thus, when they get accustomed to some habits, such as using one language or not thinking out loud, it is very very hard to change.
Similarly, it will take more and more practice and time for my brother to change the habits that he has acquired, but I am sure that he will succeed in time. In fact, having the courage to change a career with a family to support shows that he has the willingness to change and adopt to new environments. He now has promising prospects as a software engineer and I am very happy for him.
Thank you for reading my article and please feel free to share your experiences too! I am sure they would be very very motivating to all!
