Here are some general principles and tests I accumulated over a long career, mostly gotten from managers a lot better at hiring that I was ^_^: If you have dou

Here are some general principles and tests I accumulated over a long career, mostly gotten from managers a lot better at hiring that I was ^_^: If you have doubt over a certain low threshold about the candidate, don't hire. A bad hire, especially in a startup, is terribly expensive. Testing coding is mandatory. Back in the '90s when C/C++ were the game, we used two tests, write code to create a doubly linked list, and look at a small function we'd put up on the white board and find problems with it. Both were graded generously, it was pretty clear if the candidate had a clue or not. Then general problem solving, i.e. some design problems, perhaps including a big/relatively difficult one, and have the candidate describe some design solutions they were proud of. Code samples were very welcome if available, of course. In all of this, you'd get a pretty good sense of whether you'd like to work with this person. You'd also use the whole process to sell the company/project to the candidate, and see how they responded to that, they had to show either some interest in it, or for the more professionally oriented, something like an attitude that it would be no problem in due course and they would like the work. Ah, especially for startups, get across the concept that "you can't be too proud to not sweep floors" if needed, but that each engineer would be allocated both some of the less interesting work that just has to be done, and the interesting work.