DEV Community

loading...
Cover image for So you hate those whiteboard interviews, huh?

So you hate those whiteboard interviews, huh?

mjlmo profile image João Osório ・1 min read

A lot of people have started to learn to code. If you got to social networks hashtags related to coding are a rising trend. The site Hackernoon even has an article on the subject.
The catch here is that everyone can learn to code, but that doesn't necessarily make them a good or even proper developer.
A lot of programmers on the market are able to build stuff with some cookbook recipes and then surf the Web (i.e. Stackoverflow) until it's no longer a broken piece of software.
Employers need to assess if you're the real deal or not. So you can prove your worth with decent activity on an open source side project, past project experience where your old boss can recommend your work, being a certified professional. But maybe you don't have the time (or luck) to have none of these things.
When all else fails, accept the challenge and show them what you've got. Think of it as public speaking mixed with a training session where you are the trainer.
If you think anyone can learn something, than you have to stand out from the rest.

Knowing how to move the pieces of a chess game doesn't make you a good player.

Discussion

pic
Editor guide
Collapse
alainvanhout profile image
Alain Van Hout

You make the (perhaps not very warranted) assumption that prowess at solving puzzles on a whiteboard is closely associated with a person's skills for efficiently developing maintainable software.

That this is an invalid assumption is the main argument against whiteboard interviews, so I'm somewhat surprised that you don't address that.

Collapse
mjlmo profile image
João Osório Author

Thank you for your remark. It's in fact a questionable technique for developer evaluation. But with everyone learning to code, what's your take on the subject?

Collapse
alainvanhout profile image
Alain Van Hout

From my own experience, far more reliable information can be gleaned from questions like

  • what libraries and frameworks do you regularly use and [this being the important bit] what do you like and dislike about them, what are their strengths and what are the issues you tends to get when using them?
  • what are the organisational and process issues you have noticed in different teams in the past? and how have you (and the team) tried to remedy them?
  • how would you define reliable code? How does reliability relate to things like security, return-on-investment, time-to-production, etc?

What these kind of open-ended questions offer, is that they let you evaluate how your prospective team mate handles problems and to what degree their knowledge goes beyond textbook stuff and relates to the real-world practicalities of software development.