Learning From Interviews

Want to know what a real coding interview experience is like? Let me share with you my most recent experience and key takeaways I walked away with.

Summary

The software development industry has a lot of steps to take in its interview process. Frequently, you have multiple interview rounds, and a coding challenge of some sort, some of which are live in front of your interviewer(s).

Recently, I was interviewed and had to do a live coding challenge over the web. I was comfortable, in my own home, yet, I still had some pretty major failures that made it so I wasn't able to show my true colors as a software developer.

I want to go over what happened over the course of the interview, as well as what my takeaways were after some reflection about how it went.

Coding Interview Sections

• First 5 minutes - Background
• Last 45 minutes - Coding Challenge
• Takeaways

Background

The first part of the interview was extremely short, and was the easy part. The interviewer, who was really kind and friendly, asked me to introduce myself and my developer background. So, I dove right in and explained where I'd come from, what technologies I'd used up to now, and what I was currently working on. Awesome, things were going alright so far, and I had nothing that was bothering me yet.

Good good...

Then the next question is where I probably could have selected something better. I was asked to describe a recent project that I'd been working on and I chose a Node.js project that I'd worked on solo a while back to help someone move data from a database to a 3rd party service.

I explained everything that was involved with that project, like how I was able to validate the data moved successfully. It was a good conversation, yet, I didn't feel good about my choice of project discussion. The role I was applying for wouldn't really take advantage of the skills I was talking about...

Lesson Learned - When I get asked this question next time, I'll select a project relevant to the role I want.

Coding Challenge

...The Coding Challenge...

The general format of the coding challenge section of the interview felt pretty good and fair. It started out with the interviewer explaining the puzzle that was to be solved during the interview. After the puzzle was explained, I could ask any clarifying questions, and begin to solve the puzzle in whatever way I chose. I was also able to choose one of many different programming language options, which was great.

I began by creating some pseudocode-comments and spoke out loud what my thought process was. During this portion of the coding challenge, I feel like I actually did "ok" on a first draft attempt at the solution. I had some data structure usage in mind to help solve it, which I talked through with the interviewer. We went back and forth a little bit in discussion but agreed it sounded like an OK plan overall.

After feeling like I found something that might work, I began to actually write some code. Of course, this felt ok right at the start but as I started to dive in I realized I definitely had some weaknesses I didn't realize I had. Only through this type of interview would I have learned I need to strengthen certain areas.

...The Environment...

The coding environment was in the browser, and of course, this means it was pretty much a text editor that I was writing code in. I felt like I was writing code BLIND... IDEs provide a really good environment to work in, but I've relied on their help to use the various APIs so much that I had to look up the docs frequently in the interview, which thankfully was allowed.

In the real world day to day, I've not had to memorize all the order of parameters of various APIs, but oh man it would have helped me to perform better in the interview. I'm strongly considering taking some time to specifically code "blind" without the IDEs help so I can find out what APIs I actually know.

...Finishing? the Challenge...

As the challenge continued, I got down into the depths of the puzzle, started to struggle a little bit, and the interviewer chimed in with helpful hints here and there. While somewhat helpful, some of the hints actually swayed me away from my initial design that we talked through in the beginning. Because there were now a few very different designs going into the algorithm I started to really struggle in my solution. The pieces weren't fitting together how I was hoping, and the answers just weren't coming together. I really should have kept going with my initial design and thought. If you are pretty confident in a solution, don't let the interviewer sway your design.

The key here being, the interviewer doesn't know your whole solution. They might not know you've already got a solution to a piece they haven't thought of, so when the give you a hint, make sure it fits your design and you don't have to implement their idea.

...Times Up...

Unfortunately, the challenge ended, and I didn't have a working solution in the allotted time. Of course, this comes with feelings of shame, regret, failure, imposter syndrome, etc. It's wild how emotion plays into the interviewing experience as a developer, and it really can do a number on your confidence when you fail to show what you can do.

Now, I know I am totally capable of solving many problems, moving data around, integrating 3rd parties, creating reusable components, building web pages and styling for mobile devices etc. But after the coding puzzle and performance, I don't know if I'd hire me either if I was the interviewer that ran the coding challenge.

As hard as it is to not just feel bad about the whole thing, I knew I needed to take a step back and not let a bad interviews kill my drive.

...After Math...

After finishing up with the interview, I didn't stop solving the challenge and walk away with it unsolved. I wasn't about to let some silly puzzle in a timed challenge beat me. I took some more time and FINISHED the puzzle and wrapped it into a nice little bow to prove to myself that I am absolutely capable of delivering the desired solution. I specifically allowed my failures to strengthen my weaknesses directly after the interview.

The best part is, for this particular problem, I now know what kind of data structure will support what I needed to solve. If I run into something similar later I'll be able to remember this as a strengthening moment, not a complete failure.

Takeaways

Here's a quick rundown of the key takeaways and tips

• When asked to give a background, highlight the role's requirements you're interviewing for
• Have a project example ready which is directly relevant for the job you're interviewing for
• Know your crutches, since live coding typically isn't inside of your own IDE
• Be sure to know your APIs, like how to use various string and array APIs without looking things up
• Code "blind" to find out what you really know in a language
• Freshen up or strengthen your algorithm skills, even if it is only for interviews. I typically don't have to iterate through strings the same way and unscramble words in my job, but many code challenges will have you doing it.

Conclusion

These timed coding experiences often feel very different from the real world work that needs to be done. For example... In my career I've been building parts of CRM products, back-end office websites, or handling MySQL and Mongo data structures, but all of that hasn't felt anything like the live-coding challenges you get into the interviews.

I learned a lot over the course of this single coding interview. Some about me, and some more about the interview process in general. I now know what I need to practice and study in order to perform well in the time-crunched coding experience.

Coding Interviews are the standard it seems for most organizations, so I'll be practicing these types of problems until I feel very comfortable with the process. In doing so, I hope to open more doors of opportunity for my career and social network as I speak with more brilliant engineers.