Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
On tests, take home problems, and a HackerRank bookmarklet

On tests, take home problems, and a HackerRank bookmarklet - lazyblog

So recently I've been interviewing and as you can imagine that means doing take home problems and online tests.

I am not pointing fingers (so please continue hiring me lol), I am addressing the problem in the industry, because almost everyone is doing it in the same way, so you could say no one is directly responsible. Even though willingness to have a better process should be a thing.

Online tests

I am going through a few hypothetical exchanges between me as an interviewee and me as an interviewer, the problem is about writing a CSS selector parser in under 60 minutes

Interviewee: Really now?
Interviewer: This is just an exercise in speed writing and besides, you should've tackled this problem before, that's pretty much the only way you're going to get it right and readable in that time

EE: Why are you doing this to me?
ER: I went through this, and because of this fact, you should too

EE: Are you going to make me write tests of that?
ER: Oh god no, let's just throw it away and do some actual coding, we don't want to review code you wrote in a rush, no one would want to

EE: Have you thought about the fact that it could make me real sad not being able to provide any proof that I even started tackling the problem?
ER: ...

The major problem I see in online tests is the time limit, when does speed win in our everyday lives as developers? If I am writing a tree traversal and I see a clock ticking all I'm thinking about is that now I have 2 seconds less, now 5, now 15 minutes passed and I'm not still sure if I need DFS or BFS! (Am I passing along the anxious sensation? Yes? Good.)

You could say that, as Joel Spolsky said (search for "Jared is a bond trader" in that post), it's the ability to rush through easy concepts that defines how quickly and easily you could grasp more complex ones, but then, if you're asking me to write an algorithm that finds the lowest level manager for a couple employees given a list of manager - employee relations in 45 minutes, what am I going to work on? Is it going to be algorithms full time? And most important of all, are Knuth, Okasaki, and Skiena going to mind my clicky keyboard in the open space?

It has to be, right? We all hate to waste time on useless questions, right?

Take home problems

It's a dissociated practice devoid of any social interaction which are key in the workplace.

You are coding alone, from start to end, no chance to ask for help or opinions, this is not how our days should look like so why are you selecting candidates based on that?

You get feedback that you can't act upon, there's no chance to have a discussion if you get rejected, you just get a bullet list of a few items passed from a developer through an HR person and then to you, where did we lose our humanity? Was it washed away by free breakfast lunch dinner and beanbags?

If you fail in a trivial operation, let's say VAT calculation, you could be rejected, the focus is on seeing something that works as specified, everything else comes after, I feel this to be once again something that does not happen in the real world. I write code that does not work, I get reviews, I talk to my colleagues and then I refine it over time.

IMHO

This time I am going to talk a bit about a process I feel it's worth for both interviewer and interviewee time. Something that brings joy and a good time for both parties, and I've seen used by a few companies.

Chat to see you're not mad

Usually 30 minutes with an HR person or a developer, just to see that

  • you're a real person
  • you can show up on time
  • you can dress respectfully
  • it's going to be nice working with you

Chat with a fellow developer

Technical interview talking about stuff, the goal is to understand what it is like to exchange opinions with the person, so understanding if they are stuck on their positions, if they accept a dialogue from someone more experienced, if they would embrace change when needed, and so on.

Am I going to be happier if this person will be a colleague starting tomorrow? Am I eager to work with them after this chat?

Eventually the discussion will evolve into the correct technical depth, so if you're concerned about CS stuff and functional programming concepts you can discuss about those, I feel that what's important though is to detect passion and willingness to learn, I wouldn't ask tricky questions. Especially on the phone. Especially if I wanted to sound human.

Design our product / role play

I wouldn't do both as they are pretty intense.

Design our product

You get two things from this:

  • an understanding if the interviewee did some research about your product
  • a clear idea if the interviewee has an understanding on how the architecture around the code they write works
Role play

This is about social interactions. It's a great way to talk about product choices and see how the candidate deals with, for example, impossible requirements, if they say yes to everything, and so on.

You could role play as colleagues on a problem (sort of pairing session), or as client and lead developer.

Spend a day with us

Pair program, discuss, sketch ideas on a whiteboard, and in general do all those things you do in your everyday life, the focus here is to do things together, not sitting there looking at the candidate go through problems or whatever, as usual, you just need to answer to "Am I eager to work with them after this chat?".

HackerRank bookmarklet

While I really like how HackerRank has been build and how it works when you go through the problems, there are a couple things I've found to be an obstacle:

  • certain areas have right click disabled, even though it's a legitimate thing wanting to copy, for example, test inputs
  • when you're writing code sometimes you're lost in the page and if you want to run the tests you have to scroll around a bit, it happend to me twice that the boilerplate code was quite big so I almost got outside the zone in that case

The small bookmarklet I wrote removes these two restrictions, I didn't write anything special, this is something anyone could've done.

No, I am not going to use it to post the problem on StackOverflow or ask that CS grad friend of mine, I just want to be able to copy whatever I want so I can have it in my editor, in fact, if you check the areas where one can't double click you will find <pre>s with useful examples included, I want to be able to copy that as well as tests outputs, I don't want to download a file and spend 30 seconds to navigate to ~/Downloads open it, copy what I want, close it, and realise I a wasting precious time: I get this feeling everytime and a worried mind is the last thing you want in an online test.

You could test the bookmarklet on the Hackerrank sample test.

And here how it helps with those two things:

// allow right click and cut copy paste
$(document).off('contextmenu cut copy paste')

// CTRL+ALT runs tests
document.onkeydown = e => {
  const evtobj = window.event? event : e
  if (evtobj.keyCode == 13 && evtobj.ctrlKey) $('.bb-compile').click()
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment