In an ideal world, whiteboard CS question are usually a good way to discuss implementation strategies, possible issues with suggested solutions, or where the in

In an ideal world, whiteboard CS question are usually a good way to discuss implementation strategies, possible issues with suggested solutions, or where the initial text of the problem might have some scoping issues. It would also help to understand how you would integrate in the team by considering hints and discussing pro/cons. Most of the time it does not work, because it is very hard to find a short problem where the solution is open to discussion, constraints are unrealistics. Willingness to learn and use new/old tools, engineering teams usually already have custom tools in place for historical purpose, most of them could and should be improved, but first it is primordial to know why they are in place in the first place. This is usually quite hard to gauge, but can be discovered through conversation. As software engineer it is very hard to trust a candidate based on what is said by the candidate, keyboard is easy to get a grasp of, stack overflow is only a click away. It is very easy to be a code monkey, it is slightly harder to be a good software engineer. When looking for an answer for your code issue on stack overflow, do you pick up the most praised answer directly ? You should analyze its cost of integrating it in your code, do you understand it enough to debug it ? maybe the solution requires a library, and said library could become a liability for your application. A lot of people can pretend to be a developer, integrating a new member in the team is quite costly ( HR process, hardware procurement, software procurement, training, political cost ), hiring someone for her/his trial period is not quite that simple. From my point of view, a great recruiting process should ( disclaimer: never tried such process from on end or the other ): - First phone contact, description of responsibilities, discussion about experience. - Online test should require around 20 min of coding of something that would look like an (n-queen problem, sudoku solver, boggle, chess game file verifier ... ) - On site interview to discuss implementation of online test - use of dummy code for review, how such code could be improved. - Discussion one of the past issue that the engineering team has encountered, how the candidate would solve such issue, bouncing back the constraints and impact on other part of the product that the team is maintaining.