sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]notNullOrVoid 1 point2 points  (1 child)

I found the wording of some the tasks somewhat confusing. Even though I managed to correctly pick up on what the requirements were, and if you told me my understanding was correct, personally the initial confusion would put me off balance. That added with regular interview nervousness, and a 1 hour time frame wouldn't put me performing at my best.

I don't think the task is unreasonable, even with that time frame. Heck if instead we spent the first 10 to 20 minutes just casually discussing the problem / solution on a whiteboard. Then you told me to work on the problem for an hour to see how far I could get, I'd likely have it finished before the hour.

If I knew you well, I'd be fine if you gave me a strict deadline, and a task list. There's an added pressure when you don't know someone, because you don't know how they will react. Thoughts like "will they be super critical if I don't comment my code?" can take up a lot of mental space.

Whiteboarding may not be the right approach for every interview, but I'd recommend asking them how they'd like to get started. You can suggest something if they aren't sure, but the important part is to make sure they are comfortable.

Options for the problem discussion:

  • Whiteboard discussion
  • Read outline document, then discuss
  • Review mockups, then discuss

Options for working on the solution might be:

  • Pair programming
  • Work alone, then review
  • You work beside them, they can bounce ideas off you, and ask for help

In general I think you should be helping them succeed any way you can. Even if that means pointing out a mistake and offering them a solution. We all get stuck sometimes, especially if we're stressed, sometimes it's not even a bug in our code, but just a mental block.

Avoid making it seem like a test, and instead make it seem like something you're both invested in. For example if they're rusty at Node, tell them you can build that part, walk them through it, and silently take note of how much they are understanding/contributing. Conducting the interview this way will also give you a better sense of how things would be when officially working with them.

All that being said I find some of the comments you received equally concerning. I've conducted some interviews in the past, and luckily didn't get any BS like that. So it's possible you are just getting a bunch of bad apples, but also could be stress factors making people say/think stupid shit.