34 architecturalist papers: how to interview a senior engineer
When I started my career in software engineering, I didn’t know how to interview. But I did know that the basic paradigm was engineered to keep people like me out.
Let me explain. I have ADHD. And I can’t read quickly. And I was taught at a young age that speed measured fluency in a task, not the ability to perform it automatically. And I had marginal dyslexia, so my handwriting was poor.
Put me on a whiteboard, and ask me to write code, and it looked messy. I would forget semi-colons. Error conditions would be skipped over. Subtle details about the problem would be missed.
In short, the test would be an excellent evaluation of my ADHD/Dyslexia and a poor evaluation of my ability to be a software engineer.
SGI offered a program on how to interview, and so I decided to take it.
And the key insight the person who was doing the class had was that past success was a measure of future success.
And so I changed my strategy. I stopped asking stupid technical puzzles and instead asked them about what they did.
The problem with that strategy is that what you did is a good predictor of what you will do in a similar circumstance, but will it predict what you will do in a new environment on a new problem?
Also, it results in overemphasis on skills rather than aptitude. And the specific skills you may need change over time. And I saw this play out at a former employer where we switched to mobile, and the needs of backend software dropped. Engineers quit or were asked to leave because they lacked the skills and either lacked the interest or aptitude to acquire new ones.
At Zynga, we had this level that was just above MTS, called Principal Engineer. I discovered that a lot of those engineers who were hired into those roles flamed out. After I dug into it, I discovered that we had created a role for people who had mastered some technology. When we hired them at Zynga, they had to master a new thing, and not all of them succeeded at that. I will observe a larger part of it that we didn’t set them up for success, but it was interesting.
Especially because the level just above Principal Engineer was Architect, an architect demonstrated that they had mastered multiple technologies.
Architects almost always succeeded at Zynga.
This then leads to my next observation, that a good predictor of a senior engineer is someone who has mastered multiple different technologies and made an impact on them in multiple environments.
And then I went to VMware and realized that that wasn’t a perfect definition either.
Some companies need to have world-class experts in a specific technology. For example, VMware has world-class experts in compute virtualization. Those individuals are undoubtedly senior engineers who have mastery and depth that is astonishing.
And then, I learned about how some people don’t get an opportunity because of their gender, orientation, and skin color. And that reminded me of the story of Devil and the King. The King asked — “Who was the General that could have saved us?” and the Devil pointed to the King’s slave, “he was.” And the King said indignantly- “but he’s a slave!” And the Devil said, “yep, and you lost the war and your country because that is all you saw him as. Funny how that works.”
Finding a senior engineer is about finding a needle in a haystack. You have to look hard, and wide and deep and in places, you wouldn’t. You have to look at objective criteria. And you have to keep your ears and eyes open to see people you don’t normally see.
So? So, hiring a senior engineer is a multi-faceted process. It would help if you looked at a bunch of criteria, your team composition, the problem you are solving for in their hiring, and in the end, make a judgment call.
Anyone who says that they can evaluate a senior engineer by themselves in 45 minutes is — I hate to admit this about myself and people I have judged — lying to themselves.
Originally published at http://wrongtool.kostadis.com on March 5, 2021.