playing cards

Face Value

I'd recently been on a job hunt (now fulfilled), and I was contacted through stackoverflow by a recruiter that had located my stackoverflow Developer's Story and was impressed. He'd asked me to complete a coding challenge which I passed with flying colors. I was then invited to participate in a technical interview with one of their team leaders and a developer - this is where the trouble began.

The first problem was that recruiter had informed me that this interview was to go over my code sample and take a deeper dig into my background; so I wasn't expecting a full-blown technical interview and therefore had failed to do any preparation.

The second problem is that I'd never taken part in a "real" technical interview and as such as I wasn't sure what to expect. I had, of course, read articles in the past about technical interviews, but it had been quite some time. It would have behooved me to reread some articles to have a better idea of what to expect.

So problems one and two are closely related and boil down to a lack of preparation and experience. It is my insight garnered from the third strike that I would like to share with you today: take all interview questions at face value.

The job posting for this position had a salary range that, to me, was "crazy" money. Imposing a sense of imposter syndrome from the get-go, so the very first question caught me off guard.

"How would you model a deck of playing cards? What members would you use and what methods would you need to make available?"

Simple, right? A deck of cards is simply an array of cards, each card having a suit and a value. However, I had the thought, "this question cannot be this simple, can it? There has to be a trick. What's the catch?"

So instead of giving the simple answer, I stuttered and stammered, trying to buy time to process the question from other angles. I had entered a state of analysis paralysis. I was overthinking the problem to the nth degree. Instead of giving the simple (and correct) answer, I tried to make my answer as complicated as my perceived (and unreal) impression of the question. I was seeing a hidden meaning behind the question that just was not there. I did not take the question at its face value.

This was only the first question, and I was crashing and burning, HARD. They let me flounder for about ten minutes before stopping me and moving on to the next question. No, that's not fair. They didn't let me flounder. They tried to steer me towards the right answer. They even went so far as to "rephrase" my answer back to me to make it sound like I had given the right answer. I was not having that, so I stuck to my guns; I "corrected" them - to make sure that they knew that I had given the wrong answer. They were great. Kudos to them for not calling me an idiot.

I did manage to recover, for the most part, and partially redeem myself for the rest of the interview. At least to the point that I am pretty sure that they don't think someone else wrote my sample project.

Several days later, I received the nicest rejection email that I have ever received. The recruiter encouraged me to try again in the future and wished me the best of luck on my future endeavors.

All in all, even though I was kicking myself in the butt for the next 48 hours, it was a positive experience. I got some valuable interview experience, for one. A couple of hours later, I fired up IntelliJ and modeled a deck of playing cards, properly - in an attempt to strengthen my Java knowledge in preparation for another interview I had coming up. I did land that position, which I felt was a much better fit for me, anyway. Also, most importantly, I learned, the hard way, to always take an interview question at face value.

If you liked this post, you can subscribe to the rss feed or follow me @ToddEidson on Twitter to be notified of future blog posts.

Date Published: 28 September, 2019

Tags: interview general programming

About Todd

Full stack application developer. Life-long learner. Pragmatic programmer. Believer in clean coding. Proponent for extensible and reusable code. Hobbies include (very) amateur photography, collecting old jazz records and going to live music performances.

North Central Ohio, US

Obligatory Disclaimer

All opinions are my own, probably wrong, and subject to change without notice.

© 2017-2019 Todd Eidson. All content is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.

Hosted on linode