Technical coding interviews for testers?

About a year ago I was asked to apply to work at a startup here in Brisbane. I’ve never really been that keen on the idea of working for a startup as I prefer stability over exhilaration, I’m not looking for rapid promotion and I don’t really care for the speculative wealth that startup employee stock options provide – but I was curious about the job as it was working with a well-respected person I’d known for a while so I went ahead with an interview.

Little did I know that it would be a coding technical interview – where candidates – testers included – connect to a web session where a blank IDE is opened and you’re given a problem verbally and you need to write code to solve it on the spot.

I can’t remember the exact problem(s) but they were something like writing a way to reverse strings, do custom sorts and some fairly complex coding problems.

The reason I don’t remember is I totally blanked. As an anxious person with post traumatic stress disorder, staring at an empty JavaScript IDE whilst the interviewer watches every keystroke you type to solve the problem on the spot felt a lot like this to:

Coding Interview?

The interview was like fuel on my burning imposter syndrome fire and the next six months of my life was spent ruminating and questioning whether I could even do my job as a technical QA.

This was despite the facts I highlighted when applying for the job:

  • I have 16 public GitHub code repositories including 7 in JavaScipt, 4 in Ruby and 1 in C#
  • I’ve been writing this blog since 2006 and have shared numerous code samples across years of blogging.
  • I successfully completed a 3 month trial to work at Automattic/ during which I built the foundation for the first ever automated e2e test suite to be successful at

I’d suggest to startups considering to do technical on-the-spot coding examinations whether these are absolutely necessary considering the candidate and knowing that people may not perform well in that situation.

Whilst I raised this feedback after the interview and I could have actually progressed along (despite flunking the coding exercises) I decided I didn’t want to work somewhere that would do that to potential employees. I’ve never had to sit next to someone in my working career and have them watch every keystroke I made writing code from scratch. Instead I’ve worked at great places that have measured me by my great outputs (thoughts/code/prose), and outcomes (software quality) without worrying about how I generate those.

I noticed the person who asked me to apply left the startup a few months after my interview anyway 🙃

Aside: perhaps the diagram above may also explain how some people, including myself, don’t like pair-programming as the main way of delivering code?

5 replies on “Technical coding interviews for testers?”

Yeh, lightning coding tests always give me a jolt to the heart, making me go away to research/refresh up on stuff I’ve taken for granted.

Personally I still think those tests are 1 dimensional, because we are capable to write that code, just not on the spot perhaps.

I quite agree — asking people to perform in the spot probably won’t give an accurate representation of their skills.

In my company we do, however, ask candidates to complete some technical assessment exercises in their own time (about 3 hours in total, due one week after being set) as a means of assessing candidates who do not have a strong GitHub account or other visible indicators (which is true of most of our candidates).

What do you think to that practice? Is there a better way you’d advise assessing ‘normal’ candidates’ abilities if not a coding exercise?

Being watched definitely changes coding behaviour. I used to mentor frontend students online and it was a thing worth addressing early on. Doesn’t really apply in this situation, but I used to explain they weren’t bugs or mistakes unless you ship them (and even that is okay!) — it’s like writing a draft, or doing pencils for an artwork — creation can be messy.

That said, for interviews I definitely would prefer to work in my own time and then to have a review discussion (which both sides can learn from). Some places do this well.

My first code test in an interview experience was fizzbuzz. I did not know what it was about and spent quite a while wondering what the trick was to it that I had missed. Eventually the interviewers came back (they didn’t tell me to fetch them!) and said I had taken too long. I didn’t continue with that place either — too confusing to work with.

I like that you post these reality checks — this is what a career in (para) development looks like ~:) Thanks for sharing!

Leave a Reply

Your email address will not be published.