Uncharted Waters

Nov 29 2018   2:38PM GMT

Testing and Developer interviews

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


I mentioned in my last post here that I start a new full time position as a developer next week on Monday. I have done a lot of tester interviews over the last (nearly) 15 years, and for the most part they are obscenely easy. To the point it is obvious that most people don’t know how to tell whether or not someone is competent. Normally, I’d get questions about my experience in agile, they would ask a handful of questions about definitions of words commonly used in testing (regression test, smoke test, you know the drill)  and then the interviewer would ask me how I would test a thing. The last thing I was supposed to imagine I was testing was a cash register. Sillyness.

This isn’t going to surprise you developers out there, but dev interviews are actually hard and stressful. I was surprised how different they were and in particular how different they felt.

The company that hired me ran 3 separate interviews. The first was a normal weeding-out interview. I spoke with the dev director for about 45 minutes about my background, why I wanted to change into a dev role, what I was looking for, and how I might fit on the team. This was low stress but high stakes. If the director isn’t interested, this obviously isn’t going far.


After that I had a 1 hour technical interview. Technical interviews for testing roles, with exception for SDET jobs, are super easy. This was not. There was a coding challenge I had to complete in an hour in my language of choice while the interviewer observes. I was able to ask questions, but obviously didn’t want to ask too many because the point is to demonstrate skill. I chose Ruby because that’s what I’m most familiar with, and test drove my challenge. I finished in about 45 minutes and then we spent the rest of our time debriefing on my code and talking about the role. This was one of the hardest interviews I have ever gone through. Writing code with another person watching and asking questions is difficult. Doing that when they are making observations and judgements is worse. And then doing that when those observations have consequences for a job you really want is ugh. I am sure live coding interviews is a skill that can be developed, but the first one was a challenge, and I was drained when it was over even though I did a decent job (or decent enough to get through to the next interview round).

After this, I had a 3 hour interview where I spent between 30 minutes and an hour talking with various team members. These are tedious because people tend to ask a lot of the same questions, but still better than getting interviewed for 1 hour by multiple people at the same time.

This process was striking to me and reminded me of a few things. Organizations generally value developers and what they do. Companies want to know to some degree that this new person will be able to contribute, and most companies are able to assess developer skill enough that they can find this in the interview process. The other thing, is that development organizations clearly don’t understand testing skill or how to assess it in the context of an interview. They are so easy that it makes me think the role is disposable in the sense that “if this one doesn’t work out we’ll pretend to interview another person and get that role filled”.

This has been a learning experience, I’m glad I won’t need to interview for a while.



1  Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • Matt Heusser
    Great examples, Justin. I think I could add a little bit of color ...

    First of, the style of interview you went through is something that I would call a certain kind of silicon-valley style interview. I suspect those are less common in the midwest, and much less common in organizations that are not software companies. 

    Second, coding while someone watches is weird. What i've done in the past is ask them to code a simple problem in their strongest language. Something that requires a function, a for loop, some if statements. The new cool kids hate fizzbuzz, but I used to use fizzbuzz; today I would use greed. 

    Asking the gets at the idea that the candidate can think abstractly, and if they really have any genuine experience with any programming language, vs code-by-stackoverflow-search. (I search for stuff all the time. I'm not talking about esoteric code libraries here. I'm talking about for, if, while, variables, maybe print and a function signature.)

    I do agree that most classic tester interviews are, well, less pressure. Personally, I have used palindrome in interviews to make testers feel similar pressure - in a simulation. About 10% of the people who take that test get upset and have something like a PTSD-like event, even with a trigger warning slide.

    So, I take your point, I see why they do it, I'm really interested in what comes next for you!
    5,075 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: