A friend who was looking for a new job texted me "how does one become a demonstrably better engineer?"
Given what I knew of their context, I assumed they were looking for something actionable that would ratchet them up a notch in interviews (perceived more senior). The question stumped me. I just didn't have a good answer. Given the longstanding situation where companies interview in a manner optimized for the software engineering challenges of last century, there are only two ways I really know of that typically manner: be recruited directly by ex-colleagues who know your skills well, or excel at those wrongly optimized tech interview shenanigans. Sometimes the timing is off for the former to work.The problem with the latter is that the longer you spend actually doing typical 21st century engineering work, the less you remember how to pass those useless puzzles that rarely come up in real work (and when they do, are more quickly and reliably solved by doing a litle research rather than trying to implement something from 30 minutes at a white board).
It stumped me so much, I didn't reply for a few days while I mulled it over. Then I went on vacation for a couple of weeks, feeling guiltier every time I remembered I still didn't have an answer.
Procrastination is like a credit card: it's a lot of fun until you get the bill. - Christopher Parker
— The Quote (@thequote) June 2, 2021
I've spent a couple of decades hiring engineers off and on. Most of that time I've conducted the exact same pair programming interview, but that would be a whole other post and not likely to be relative to my friend's interviews. I considered how I would start to believe someone was a senior level engineer in the absence of my usual rubric.
I still don't have a great answer but I do have a couple of thoughts.
1) I believe that the best software engineers are like blacksmiths.
Photo credit: Yi Chen
Both blacksmiths and software engineers make their own tools. The tools they use on the job are made of the same stuff they produce, so a master of the craft should be comfortable doing this. Making your own tools demonstrates not only that you understand how to do basic tasks for your job, but you probably also understand which tasks are the most important to the overall goals, and have creative thoughts about how the approach to those tasks could be improved. So one way to demonstrate your skills are to be able to talk about the tools you have made and how they helped you and/or your colleagues reach team goals better.
- Maybe you automated a tedious task that used to waste time and/or allow human error to creep in.
- Maybe you extracted data on your processes and built a report to show where bottlenecks lie.
- Maybe you built a tool to visualize your app logs in a richer way, allowing issues to be found quicker.
- Maybe you extracted code to a sharable package so that it could be shared by system components.
- Maybe you developed an IDE plugin that improved support for a custom part of your system.
I believe conversation about tools you've built reveal a lot about how an engineer thinks and can highlight the skills with which you feel comfortable. It can also be interesting to discuss the tools you didn't build and why.
2) Have a portfolio
One of the major problems with demonstrating your skill at interviews, is that probably all that great code you've written for past employers is closed source and unavailable to show. One solution to this is to have contributed to open source projects. Not everyone has time to start and maintain their own meaningful Open Source Software project, or even to make significant contributions to one, but just like the professional artists' need to maintain a public portfolio, there is a benefit to having something on Github you can point to and talk about.
I don't plan on ever being a hiring manager again, but if I were I would consider the following as an addition to my usual pair programming exercise: ask the interviewee to be prepared to talk about a few contributions they made to OSS projects. It could be simply finding open Issues in an existing project and submitting a PR for it. Some things that might be interesting to discuss:
- Why did they choose the project?
- How did they communicate with existing contributors? (if the communication was public on Github, walk me through it)
- Why do they think the Issue had not already been resolved?
- What approaches did they consider in implementation? Why did they decide on the one that they did?
- What tests did they add to ensure their implementation was correct?
- How did they handle PR feedback?
There are similar opportunities to have something in the OSS ecosystem without even contributing shipping code:
- They could pick a project with a lot of open PRs and in a technology they know well and simply code review them. In fact, given modern prevalence of code reviews, I think this would be a great thing to demonstrate to an interviewer.
- They could contribute tests to low code coverage projects. It's an even better story if these tests exposed previously unknown bugs!
- They could contribute failing tests that highlight an open Issue.
Obviously the interviewee could cherry pick their best OSS contribution narratives to demonstrate, but as an interviewer I would value recency so even if you have a great story to tell and show from years back, I would still put a little time into having one or two recent examples as well.
Comments