5 Things I Learned While Building Blackjack in an Interview

Not quite the hand I’d say I ended up with…

I am a junior developer transitioning out of the Marine Corps currently going through a full-stack bootcamp out of Chicago — and by that I mean I am sitting in front of my computer in California for 12 hours a day inside of an IDE or a zoom call, an experience normalized by the pandemic. I was fortunate enough to have a senior engineer that works at a company in Boston spend some time pairing with me building a game of blackjack as sort of a mock interview loosely based on his own company’s process, and offering me feedback as a technical interviewer. I reluctantly accepted and was sure that I was doomed — destined to be crushed in the one-hour session, exposed as an incomprehensible fool, a phony, and maybe even ridiculed. Spoiler: None of those things happened, but boy did I learn a thing or two.

1. Ask clarifying questions

I was given an opportunity to email him a few days ahead of time and ask clarifying questions. Honestly, outside of a couple (…ok, 6) booze-filled nights on a cruise ship years ago, I did not have much familiarity with blackjack. I schooled myself up on a wiki I found online and tried to ask questions that would most change the implementation so I would have more time to mentally work through what I could.

Would the dealer be rotating as if it were a house game, or would he be the stationary bank?

Would the game be using a single standard 52 card deck, or would there be multiple decks in play?

Is this a terminal game strictly, or would there be a future release that requires a GUI?

I also asked if there were constraints on the style of programming or language. All in all, I think these questions helped me, and looking back I don’t think I would have asked anything differently. What I learned here is don’t worry about the little details- you will just get hung up on them needlessly. Focus on the bigger picture, and trust that you can take on the small issues as they come. Realize that this is your first demonstration of how you are approaching a problem and your ability to communicate. I suggest you use Grammarly!

2. Do what you need to and relax

We got on the call, had a short chat, and before I knew it I was sharing my screen. Things that are second nature like creating and navigating to the new directory that would house my blackjack game and test file became fumbles of foreign keystrokes. My mind was both blank and chaotic simultaneously, and all I could think is “this guy thinks I am a moron”. Now, while this article isn’t about imposter syndrome, I feel it needs to be addressed. Simply put: I am a junior, and I am learning. I more often don’t know what something is than I do when it comes to tech. Even without the inner battle of the imposter shark, I had expectations of myself that were far too high. What I learned is you need to relax. Manage your expectations and realize that what lies ahead is somewhere between your worst nightmare and peak performance.

Exposing your ignorance can be a scary thing to do, but I have found it almost always leads to growth. Be kind to yourself.

3. Talk while you code and code while you talk.

As I stumbled through the game, I attempted to talk through what I was doing. I defined a few classes that I would create methods for such as Card, Deck, and Player. I would periodically get an inquisition by my interviewer — “Why are you choosing to represent the cards in that way?” “What will that method be responsible for?”

What you may notice about questions like these is they are invitations to explain what is going on in your head, and all of them could have already been answered if I was doing a better job talking while I was coding. The interviewer wants to be able to get a feel for how you are working through the problem and you will want to be sure to keep them in the loop. It also opens up the opportunity for them to give you a hint or a tip along the way. At one point, I decided to do the “pythonic” thing and loop through a string representing suits SHCD while creating the deck in a create_deck method. The interviewer seemed especially interested in this, asking why I thought the string might be better than an array, or why I thought shortening the suits to a single letter representation would be a good idea and if I could think of any problems with it down the way. I did my best to answer these questions, but I believed that these were pointed- he wanted me to consider the readability of the code and to think about what I would be displaying the user in the end. At the end of the interview it was one of the points of improvement, along with a quote that summarizes what I learned here well:

“There is a big difference between being smart and being clever. Don’t be clever”.

4. Understand what and why you are testing

After I created my very first class, Card, that had two properties value and suit, I immediately sprang into my spec file to write a test for it. The interviewer let me begin setting up the unittest spec file but was asking what I was about to write a test for. I confidently told him that I would be writing a test for my Card class to check for the properties. He paused and asked if I created the constructor function right. I peeked back into my main file and answered that I had. He asked me if I felt it reasonable that python would do python things and perhaps I could move on to other parts of the program and test when I built something more kinetic, hinting that this is a limited duration session and I should try and start to flesh out some stuff. This was a learning point for me.

The idea of tests isn’t to get a “100% coverage” gold star sticker and tell everyone how it is true- it is to test points of contention in your program, especially ones that can identify defects early on. Writing a test like the one I was about to would only confirm one thing: that the python __init__ method does what it is supposed to do. I also was having trouble writing a test to confirm that I had 52 unique values in my deck due to the assert statements comparing references of the object versus the value, which is an easy way to get a test to pass when it is not passing, so I strongly urge other junior developers to look into the different assert statements available in their testing libraries and understanding how to compare shallow and deep compare objects and workarounds for type checking.

I learned that testing isn’t just a check in the box, and I should be careful and considerate about the code I write so that it is testable, as well as write tests that are thoughtful and serve as a confirmation that my program is behaving as it should. You also should understand how your testing library is going to act with certain values.

5. Be humble and be willing and able to take critique

Nobody likes to be critiqued. It has long been proven that people will remember critique far longer than they will remember praise, and being told you are far from perfect can be devastating to our egos. At the end of the session, I had finished far less than half of my program. I was already beating myself up enough, but I knew this was important. Something I loosely attribute to the military is understanding the importance of exposing your ignorance and being willing to grow. Not taking the hit and being just as unaware is far more insulting (and maybe lethal) to yourself than taking it on the chin during practice and being better from it. I was honest with my interviewer about parts of the session I felt unsure of or even the parts of his in-session feedback that I disagreed with, and he often had more than a few good examples to help me see the “why” behind- but was also surprisingly willing to see it from my point of view and let me elaborate. He shared with me how he might approach this problem, going over the functional programming style as well which I found extremely helpful. I made sure that I had a notepad next to me and jotted down the big takeaways and it turned out to be an overwhelmingly positive experience for me. I learned to be honest, transparent, and spongelike, as no opportunity to learn and grow should be squandered due to your own ego.

In the end, it was a great first rep for me at getting in front of someone and coding, and I think I will be more prepared for the real deal happening in the near future.

A dog loving Marine vet from New Haven, CT that thoroughly enjoys learning programming fundamentals and sharing them to solidify his own learning.