Ask HN: How do you define a good engineer?

The whiteboard CS questions are probably favored as they require very little effort on the part of the interviewer and off-load the responsibility of making a hire decision to the stated problem rather than the interviewer's professional judgment.

The trend now seems to be to judge people based on whether they use the same tech stack as the hiring organization.

An engineer by definition is somebody who has completed a university course in engineering in a specific discipline. As a practising engineer they demonstrate their skills by having a solid grasp of all applicable principles in their field and being able to apply them to the design of solutions to specific needs and problems.

A computer science education does not make one a software engineer. Just like mathematics and physics knowledge is only the foundations for engineering knowledge. Knowing how and when to apply that knowledge and being familiar with the body of pre-existing practices and standards is the key to being a competent engineer.

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.