Pro whiteboard interviews or against?

@Nanos with black marker

I like greenboards

I'm learning so much! @Nanos @github

@Nanos like this one

https://goo.gl/images/wkjEnJ

@github wish I had one that size in my room haha

@dalastTomCruise I wish that too.
I find this one of the best thing to brainstorm and deep dive into stuffs.

Only if I had Sherlock's mind palace power, any boards would have never required.

@github lol yeah I have a tiny dry erase board I use from time to time, but I would love a standup whiteboard

I love how this was suppose to be about whiteboArd interviews but turned into this lol

@dalastTomCruise coming back to your question.
I am for whiteboard interviews. Or even pen paper is ok.

Whiteboarding doesn't show you anything about a candidate except perhaps their ability to code under pressure -- something they shouldn't be doing anyway.

I am firmly against whiteboard or paper interviews, also against asking too specific questions.

First of all, I try to make the interview as field and pressureless as possible, because most people don't deal well with interviews and I just want to tali to them, not drill them.

Also, the nature of our job requires and allows for constant research, googling, reading SO, etc. So I think it is unfair to make someone perform out of their usual setting.

@Nanos I think the points both @Root and @electronix made were moreso along these lines:

*a company shouldn't have their employees stressed out and rushing all the time because that's not healthy for anyones thought process and you can't expect quality software when the company doesn't have it structured to where the workload is delegated reasonably and the planning should be efficient to where their is time to think, plan and implement. Not hiring candidates to work under pressure because the work ecosystem is complete shit.
*@root point

*most of the time you can get a great explanation of a piece of technology online when you query a search engine right. Whether that's looking up documentation to learn about a class/library/framework to use for a specific domain problem or if you are trying to get more insight to the nuances of something that could be causing the runtime error you're getting... you have so many resources online that can help you remember conventions ...cont...

@Nanos you should instead be tested on not only you comfortability of a language but also your ability to research about the things your in the dark about, because that shows you're willingness to learn to get the job done. And most programming jobs require a lot of learning and understanding of peripheral things besides just the code at hand but with the things your code interacts with: database, frameworks, design patterns, libraries ect for backend and closely the same for frontend where yku have your own nuances, conventions and libraries you need to dig deep in to leverage.

@Nanos programming is about thinking carefully, identifying and addressing all possible cases, and writing efficient, performant code. You Cannot do these things properly, let alone well, if you're being rushed.

Code quality and pressure are inversely proportional.

You need some motivation to keep developers active and productive, by any more than that serves only to decrease quality. It also makes developers resent you.