Give me a Mac and I'll spend half of the time asking you how to do X on a Mac, keyboard, mouse, touchpad, menus and unfamiliar software.
Do you really have to test for the ability to use tools instead of the ability of reasoning? A whiteboard doesn't seem bad for that. I would like to understand how the candidates reason, how they interact with colleagues and yes, also how they handle stress.
Example from yesterday: I had to fix a problem on a software in production before the end of the day (it must be available today) and before a reasonable hour (I wanted to go out at night.) That means working fast, debug, find solutions, possibly develop workarounds that leave the system working even if the problem is still not fully understood and solved and, most important, don't panic.
> Give me a Mac and I'll spend half of the time asking you how to do X on a Mac
I worked at a place that got around this by giving the candidate a choice of their own laptop, a Windows laptop, a Mac laptop, and an Ubuntu laptop. Half a dozen different IDEs on each.
Of course, you have to find someone to take on the glamorous job of keeping track of all the laptops, and wiping them between candidates...
> Do you really have to test for the ability to use tools instead of the ability of reasoning? A whiteboard doesn't seem bad for that.
It depends: If you're a big believer in test-driven development, red-green-refactor, clear naming and good code structure, test coverage, use of version control - you don't tend to see those in whiteboard coding.
Do you really have to test for the ability to use tools instead of the ability of reasoning? A whiteboard doesn't seem bad for that. I would like to understand how the candidates reason, how they interact with colleagues and yes, also how they handle stress.
Example from yesterday: I had to fix a problem on a software in production before the end of the day (it must be available today) and before a reasonable hour (I wanted to go out at night.) That means working fast, debug, find solutions, possibly develop workarounds that leave the system working even if the problem is still not fully understood and solved and, most important, don't panic.