What I Love About the Engineering Graveyard (and Why You Should Mention It When Interviewing)
I’ve seen varying opinions on whether to talk about side projects in interviews, but my advice is to lean in and highlight your passions
I’ve seen varying opinions on whether to talk about side projects in interviews, but my advice is to lean in and highlight your passions
When I was an early software engineer, my engineering graveyard was gigantic. I would become interested in something, poke around in the documentation, begin to build something relevant to my interests, and move on, leaving the husk of a project behind to wither and wilt.
What Is The Engineering Graveyard?
The Engineering Graveyard is where all of your side projects, Hello World’s, cloned or forked repos exist, all lying in wait for you to return. Not a graveyard so much as a mausoleum in tribute to your varied interests or desire to learn something new. Half-finished, half-buried, this is where your side projects go to die.
Here’s some excerpts from my graveyard:
A Ping Pong web app with ELO rankings built with Meteor (dead since 2019)
Did the Blue Jackets Win Last Night, a site that scrapes the NHL scoreboard with cheer.io and rebuilds daily to say “yes” or “no” (dead since 2017)
A Volleyball stats tracker to determine the result, location, and players involved with a single point of a match, built with Supabase and React (recently dead)
A turntable.fm clone that died once I realized I didn’t understand websockets (dead in 2012)
And those are the projects I actually got off the ground. It would be great if we had a Steam-like tracker that showed how many hours went into the projects, but alas, unless it’s a public commit history or you track it yourself, it’s hard to know.
What Should I Highlight?
For these projects, highlight why you started and left it behind and what you learned along the way. Sometimes a graveyard project is a jumping-off point for something bigger and better. “I learned what I needed to know and moved on” is a totally reasonable answer.
We all start with great intentions on side projects, but what specifically did you set out to do? Sometimes, talking through the “why” gives great insights into how you think about things as an engineer.
Pick one or two projects to highlight. Otherwise, you risk sounding like you can’t keep focus on any one project and have no follow-through.
Manager take: One of my favorite interview questions is “what project are you most proud of?” This is where, if someone doesn’t have a ton of experience or not much experience relevant to the role they’re interviewing for, they may point to one of their side projects. In a lot of cases, I’ve learned a lot more about an individual from these side projects than their current job, because it’s normally just them thinking through a problem.
They might be using a new technology, a new method of integrating the frontend and backend or maybe even refining a skill. The point is, they’re choosing to do this work; no one is forcing them. Engineering Graveyard projects tend to highlight an engineer’s passions.
Any Negatives to Talking About My Side Projects?
The only negative to talking about side projects is if you don’t clearly understand how they work or didn’t take it further than forking a repo and building it locally once.
Be prepared to answer questions like:
Why did you fork another repo instead of building your own?
What new tools did you leverage when extending the fork?
Did you start with a plan, or did you start poking around to see how things work?
What problem were you trying to solve?
Why did you stop?
What was your biggest takeaway?
Go beneath the surface of the project and talk about its underpinnings.
I Don’t Have An Engineering Graveyard. Is That Bad?
Hopefully, it’s because you’ve finished and maintained every side project you ever started. Otherwise, no, that’s not necessarily a bad thing. If you don’t work on side projects, be prepared to talk about how you learn new things.
Do you keep up with blogs, newsletters, or follow folks on Twitter? Maybe you read books or take side courses on Udemy or Coursera. Be prepared to talk through those things if you don’t have any side projects lurking in the graveyard.
Especially when you are moving into a new tech stack, how do I, as an interviewer, know you’ll be able to learn a new language and get comfortable in a codebase you’ve never worked in? There are other ways to suss out your skills, but knowing that you’ve explored other coding arenas gives me a bit more confidence that you could figure it out.
If you are a less experienced engineer looking for your first or new role, I want to know that you’re excited about your industry and your enthusiasm extends beyond your day-to-day. I realize this is not a possibility for everyone, but between two entry-level engineers with the same resume, I will almost always hire someone interested in their craft past their 9–5.
Final Thoughts
Poke around, get crazy, and try out new languages, technology, or ways of doing things in your engineering graveyard. I taught myself PHP by making basic Mad Lib sites, which gave me a foundation in a new language and helped prove I wanted to improve. I’ve never heard an engineer talk about a side project and thought, “ugh, why did they waste their time on that!”
Whether public on GitHub or something that further highlights your skill set, refer to your engineering graveyard. It may give you the extra boost you need to land the job.