Tech screens, how do they work

I just had So Many job interviews, which means I had so many tech screens, all of which ran differently. I didn’t know what to expect going into most of them — I’ve only interviewed in the library world in the past, where many organizations don’t have tech screens at all, but some of these were industry jobs — and organizations varied in how much they explained what to expect, so I’m going to outline the varieties of tech screen I faced in hopes this will help you. All organization names are, obviously, anonymized.

The Order of the Promethean Banner

A screen (preceding any human interviews) via Triplebyte, which presented short blocks of code and asked multiple-choice questions about their outputs, flaws, et cetera. Questions were timed. Googling, documentation, REPLs, et cetera were disallowed.

I am pretty sure I went down in flames on this one. While I got to choose a language I am familiar with, the questions mostly concerned obscure edge cases and details of that language — some of which I know, some of which I have literally never used in ten years of writing software. (One of which my husband, who has been writing extremely hardcore software for thirty years, thinks he’s used once.)

But also: I don’t think it’s a fair assessment of my skills, or the job’s skills. In the real world, I actually do read documentation, or write tests, or try something out in a REPL if I’m not sure of how something works. And: the job description wasn’t for someone writing 6-line functions to exercise weird edge cases; it was for someone operating at a much more senior level where architecture and communication skills are important.

This was also, in effect, the front door to the company. I decided I didn’t want to work at a place whose opener was so hostile, and withdrew this application.

The Society of the Emerald Smiles

“Bring a piece of code you have written, or substantially contributed to, and tell us about it.”

This was great. I knew exactly what to expect in advance. My prep was limited to choosing code and finding its GitHub link, and that was short because I know off the top of my head the code I’m proudest of. I knew that code showcased — not only my skills in general — but the particular skills I wanted them to see for this position. I came in feeling confident and relaxed, because I know this code, and I know I did an excellent job with it. I got to be the expert in the room storytelling and fielding questions rather than a supplicant in an interrogation. The code was firmly grounded in the real world. We got to talk about design decisions, aesthetics, documentation, et cetera as well as syntax-level stuff. 👍

The Union of the Ancient Oak

A take-home: they added me to a private repo which contained a small but working app, and asked me to add some small and clearly-scoped features. Then in the interview we talked about the code I’d written, why I made those choices, alternative possibilities, et cetera.

I’m sensitive to concerns that take-homes unfairly privilege people with lots of spare time, but I don’t think it’s unreasonable to ask candidates to do short prep work, and this was well-scoped. (They said it should take less than three hours, and it did; quite a lot less if I recall correctly.) It used a familiar web framework and followed its conventions, so for anyone familiar with that framework (which successful candidates for this job will be) it was quite easy to get oriented to the code and figure out where the new features might go. The code came with tests (not all of which worked — a nice way to check that your candidates actually run the tests — all of which were simple to fix). Writing the code here was not hard but it was realistic. The sample data had a sense of humor, which was fun, and made their company culture look good.

As with the previous format, this meant that I got to come into the interview with code I was familiar with and could talk about from a position of expertise, which meant I felt confident. Not coincidentally, in both of these interviews, I got strong positive feedback about my code — because both of them had set me up for success, made it easy for me to show them my best work.

The League of the Ghostly Well

Another take-home, this one strictly timed to 90 minutes (solidly within my “reasonable to expect of a candidate” realm). Two parts: one writing up a feature proposal; one doing code review. In other words, this one is striking for involving no actual coding! But above the junior level these skills of design, communication, and mentorship are more important, and this exercise seemed well-scoped to capture those skills. At the same time, it did draw on my syntax-level knowledge due to the utter haplessness of the code I was reviewing 😂

I did feel some breathlessness from the time pressure (while simultaneously appreciating that the organization was being respectful of people who have less available time). But as with the preceding, the format meant that I got to the subsequent human interview with code that I was familiar with and could discuss from a position of some confidence. The interviewers were also totally aware that in the real world they would have needed more time to do their best work on these prompts, so they didn’t expect me to be perfect. It left room for conversations about alternatives I would have considered with more time, which is a good sort of thing to talk about in an interview.

The Guild of the Radiant Visage

We had a video call via Hackerrank. They sent me a link to a Hackerrank sandbox first so that I could get familiar with the platform, which was a hospitable touch. It’s quite nice, actually; in-browser coding with input, output, REPL, editor; nice syntax coloring, tab completion, the stuff I do subconsciously while typing works more or less as I expect, the editor has vim and emacs modes too if you’re into that sort of thing.

I was worried this might be like Triplebyte, but no; they presented me with a description of a function they wanted to implement. This function was a simplified version of something they encounter in their day-to-day work, and they took the time to explain the context. The description included sample input and expected output.

I found it extremely nerve-wracking to do live coding, but they were nice about both stepping back when I needed space to think, and throwing me some lifelines. In the end I missed one edge case and was totally kicking myself about that (it’s absolutely the sort of thing I would have caught in a calmer situation) and sure I’d tanked it. But my husband (who does a lot of interviewing for his company) said that the fact that I finished with time to spare was a good sign and that in his standard interview problem (a code review), people who get 40% of the available bugs get a thumbs-up from him. Whew. And as it turns out I did get an offer from this organization, so apparently you really don’t have to be perfect!

Hope this helps, people of the internet. Good luck in your interviews.