The “perfect” interview (for me)

I want to start with a healthy dose of “the world does not revolve around me” before these hot takes.

I’ve felt myself struggling to best demonstrate my capabilities during this round of interviews. I don’t expect myself to perform flawlessly in every situation, but there seems to be more resistance to my transition to engineering than expected. This hesitation is exclusively from people who don’t already know me. It’s been more than a year since I’ve been an engineer. There’s rust.

It’s just awful timing that I’m being vocal about all of this in light of the recent “the new hire who showed up is not the same person we interviewed” article.

Accommodations

I fall apart in live coding challenges in general, and every company but one was willing to adapt their process. I use “accommodation” very intentionally because they went out of their way to make me feel more comfortable. I think it’s a win/win because I know plenty of people who cannot perform well in these interviews. But it can be seen as unfair to others who didn’t get the same opportunity. Also, each one of the four that changed their processes on my behalf had to scramble to come up with something different. I was a test pilot for their new way of interviews.

“Accomodations”

The worst was a company that took their live coding challenge and turned it into “you can drop off zoom.” In their defense, I agreed to this and thought it would work. It didn’t. I fell apart. 1-hour limit. No advance preparation. Granted, I wasted too much time trying to leverage a library that I had trouble remembering how to use when simple calculations would have worked… and I could have jumped back on zoom with questions… but I didn’t and I flopped hard. The recruiter reached out with something along the lines of “what happened?” and I just said it felt just like any other live coding challenge and that I appreciated the attempt.

What am I interviewing for?

Live coding is not real life. There is no situation where someone will drop a surprise on my plate and say perform at exactly this time or else you don’t work here.

Live coding is not pairing. Your partner my not be helpful. They can’t just give you the answer. You can validate things with them and ask leading questions but it’s still a game and it sucks. Unless you primarily operate with pair programming, I don’t see how this is remotely applicable.

Live coding is nerve wracking. I perform well remotely because I can create a distraction free environment. I might even gasp close slack. Having someone figuratively watching over my shoulder does not make me feel comfortable.

Live coding exercises are more contrived and trivial or unrealistic. Maybe not all coding exercises need to result in a solution, but that’s how I’ve operated. Take-homes aren’t much different here, but they seem to be a little more about design and implementation.

The perfect interview

Take home

It’s in the title. I want to block off some time of my choosing to take it on. I like to think about things before diving into code in real life. While I do chores, my morning routine, etc. Take-home challenges typically come with a time limit and a window of completion e.g. “spend 2-5 hours within a 48-hour window.” In most cases, the honor system is used, but some technically enforce this.

Coming from a management role, I really enjoy these challenges . They are simple enough that I don’t need to dig deep, interesting enough that I might try and over-engineer a thing or two, and small enough that I might put an extra amount of attention to detail.

An actual repo

On GitHub. Let me show you more than code. More than a commit history. I want to show you pull requests. Yes, I will comment on my own PRs in real life.

Don’t review my submission, perform a code review

One of the more interesting opportunities had me create a PR and more or less pretended like it was real life. This was the same opportunity that invited me to a private slack channel. It truly felt like what real life would be. Our back and forth spanned over a few days and our slack conversations have continued beyond the duration of the coding part of the challenge.

Technical AND written challenge

One of the most significant reported drawbacks of take-home interviews is that you don’t get to see how the person thinks or gets over hurdles. That can be done with a written component. Give me a problem that is far too big for the time to be completed, but ask me to describe how I would have approached the things I couldn’t get done.

Then ask follow-up questions. How would the design or implementation change if this were in a web context? If it had to scale to infinity? How would you have prevented the Byzantine empire from falling? I should be able to convey my thoughts concisely in issue comments. Just like PRs, I am fine talking to myself in issue comments.

Able to ask questions at any time

After thinking about things, I’ll generally have some questions. Ambiguities are common, and edge cases are a big thing in interviews. One opportunity was run by someone who was on the east coast. At the end of my day, I dropped an email and found a thorough response at the beginning of the following day.

Slack?

One opportunity dropped me into a private slack channel with the people I’d be working most closely with and the hiring manager. Everyone greeted me, and we talked about their (brand new) challenge. Ultimately, we escalated to a video chat which I thought was funny.

Test data

Don’t give me a comprehensive set of data, but a basic “does this thing work” set of input and expected output can really get things going. It can also help answer any questions around expected output in an obvious manner.

Repo template

This is specific to job opportunities that want to test knowledge of a limited set of languages. Rails shop? What testing framework do you use? What’s your coding style? Anything else? I’ll speak your language, but I don’t want someone to be thrown off because they have strong opinions about my style. I don’t think anyone would discount code because someone used the wrong quote style, but I want to show that I can produce code that would immediately pass a code review.

The problems with my perfect interview

I’ve already mentioned that I was the first to go through this process with some job opportunities. Previous and current applicants might not have known to request such accommodation. Fairness, at least during the transitionary period is a problem, and I don’t want to ignore that. But it is transitory as I think accommodating both styles is the future.

Live coding exercises can give you a quick glimpse into how people use google (half kidding) in a concise amount of time for both parties. I have lots of time. Being unemployed means I can manage a handful of these at once.

My time

Live coding challenges take an hour, take-home exercises are expected to take 2-5 or even more. Not only can I devote time behind a keyboard, but I also have time to think about things casually. It may lead to me looking something up ahead of time to apply something less familiar. These problems are often contrived and don’t accurately reflect web programming. Not everyone has this luxury.

I had enough time to create a basic repo template since most of these involved some sort of CLI. Prepared with unit/acceptance/linter/etc. GitHub actions ready. In Codespaces. With my settings synced.

Your time

A live coding exercise can prove that someone can write code and solve problems. It’s not very deep or demonstrative but plenty find it adequate to make decisions. A take-home challenge typically involves more setup and evaluation time. Especially if you’ve checked all of the boxes on my perfect interview!

Because of the expanded time, there is typically more code to review. If you’re like me and had a repo template with all the bells and whistles, then you might be presented with a lot of things that aren’t exactly the code you are looking for.

If you’ve added a written section, you have a reading assignment. I do my best to use precise language in a business context. Still, I’m not immune from typos or submitting an obvious error. As you get to know people and their communication styles, it can help reduce confusion. Generally, you don’t necessarily know the people you’re interviewing with and trying to decipher potential nonsense can take energy.