TLDR:
They are nice. They care about the places they’ve worked/studied. They are interested in computer science.
Details:
Do they care about software engineering/computer science?
Did they participate in open source? What does their GitHub profile look like? Are they a member of IEEE or ACM? Do they read about software engineering, computer science?
If they don’t… well that’s just not somebody that’s gonna work for us because almost all we do is applying software engineering and computer science.
Would you like to go to a doctor that keeps up with the latest studies? Or an electrician that knows the new building codes and technology? Yes, you would!
Software isn’t some mystical “different” thing -like anything else it goes a lot better if the people doing it are interested in it.
Are they reliable and do they care about where they have worked (or studied)?
How long did it take them to get their degree? How long did they stay where they worked, and what were the reasons they left. Layoffs are one thing. Leaving in a huff, quite another.
Using the same examples from above… do you want a doctor that hops practices? Or an electrician that just can’t keep his job for long? Hmmm…. maybe not.
What if they say that their boss was a jerk? It might be true. Or it might be that, for this person, any boss is a jerk. Making you a future jerk.
The next question would be “After you determined she was a jerk, did you finish your work?”
They Care About Their Colleagues
Software development, for the most part, is a team sport. It’s important to be on the same team as everybody else, as 2 different teams within one adds stress and a touch of chaos to what is already really hard to do.
How do you discern this? Ask them to rate who they worked with before, or other students in their class. And ask them where they think other colleagues or students would rate them.
This is called “peer review”. It’s something I was subjected to in the Army and it is very powerful. I’ve seen big tough Army officers cry from bad peer reviews. I use “subjected to” on purpose because it is very stressful to be reviewed publicly by your peers.
I do not recommend peer review for software development team use. I do, however, ask about peers when talking with potential new hires. How do you rate who you worked with? How do you think they would rate you?
What answer am I looking for? It’s fine to rate others low – it’s how you say it. “The other developers were fools” – not good. “We had hired some people who were not really cut out for embedded work, just a lack of rigor in their training” would be a lot better way to describe it.
Summary:
I do not have a perfect record on hiring. A lot of those mistakes would have been avoided if I’d paid closer attention to these guidelines.
The one I’ve never gotten wrong was the 3rd one… because I’ll take a less productive but happy place over a stressful but productive work environment.
We aren’t a going-public startup – we play a longer game here. I can’t stress out for 30 years, and I don’t want to build a structure that imposes that on others.
Here is my triage of considering new hires:
- Are they nice?
- Are they interested in what we do (computer science!)
- Will they care about us?
Good luck!
