Discussing Projects in Interviews
I’m a Data Engineer at a slow-moving finance company who’s looking for my next job in Big Tech. I just had a recruiter from Stripe reach out about scheduling an interview, which happened because I had a buddy who works at stripe refer me to the role. The position is for backend engineer.
The recruiter says the call will be 20 minutes and I should come prepared with “the most technically complex project” I’ve worked on, and talk about my role, duration, number of engineers, and stakeholders.
I’m nervous about this because my current role is something of a hybrid between data engineer and data analyst and I do a fair bit of data-analyst type work. It’s not that I don’t have projects I can talk about, it’s just that I’m insecure about them and I feel like they are unimpressive to a ‘real’ software engineer and this becomes apparent under sustained scrutiny. So maybe I can get by the 20 minute intro call, but there will surely be an hour-long session later where they want to go into excruciating detail. I do have some experience with backend as well, but it’s already almost 3 years ago now.
My question is this: how can I go about improving my situation? I’m applying for entry-level roles (IC1) and was under the naïve assumption that I just had to get very good at DSA/Leetcode. Obviously, this is not the case.
In order to better handle these project walkthroughs going forward, I see a number of potential approaches, which are not necessarily mutually exclusive:
- Get better at discussing projects in my current toolkit. Ditch the imposter syndrome and spend more time thinking about what I already have.
- Invest more in my current job to create better projects with ‘scope’ that are more impressive in interview rounds. Right now, I’m not very committed to my work and coast, doing whatever is assigned to me but in a minimalist way. My current manager has told me how he wants me to be more active in getting things done and taking on a larger role, but as a Tier-3 company, there is no expectation or requirement for me to do so (i.e. very low chance of me being let go), and furthermore, I tell myself I will be leaving soon, so why take on more responsibility? This might ironically contribute to it being harder for me to move since I don’t do the kinds of things that make it easier to interview.
- Do side-projects outside of work that I can discuss. But here I run into the issue that I’m not working with anyone (unless it’s open source) and this is probably not the best approach unless my side-project is really good with users. I’ve heard Alex and Rahul say this a number of times.
Happy to hear anyone’s thoughts about how I can improve my situation. I probably have the wrong attitude towards my current role, as I’ve been wanting to leave it for over a year. I’ve thought about quitting a lot so I can have more time for interviewing, side-projects, networking, learning, and prep, but everyone says that’s a bad idea (especially in the current climate), so it’s easier to just muddle on in my current role.
Thoughts are welcome!
Discussion
(1 comment)- 3a year agoSenior Software Engineer [L5] at Google
Short answer, (1) is the way to go.
I know your projects are complex, because complexity is everywhere, no matter the stack and no matter the technology.
"Tell me about the most difficult / complex project you've done" is probably one of the most common non-technical questions we are asked about in interviews.
These questions are asked to college sophomores, some of whom have only taken intro CS classes. Do you think the college students' projects are technically complex, at least from an experienced interviewer's perspective? Likely not, but it doesn't matter - and it won't matter for your case either.
The reason the actual complexity doesn't matter is because the main point of these questions aren't to examine whether you had project with sufficient technical complexity, but to figure out how good you are at explaining complex things.
I think the reason this question is so popular, is because the ability to explain complex topics simply is indicative of how well a person understands a complex topic. And the ability to understand complex topics (and explain them) to paramount to collaborating in big tech. Ultimately, they are looking to hear a story that demonstrate (1) your depth of understanding of a specific topic (2) how you overcome challenges.
So, having said, that, here's what I recommend you prepare.
First, search through your past projects to find a project you really, really enjoyed, and one you enjoyed especially because it was complex and it took you a while to figure out what you needed to do.
Note down what was so challenging about it. Was it the multiple layers of abstraction? Or the fact the the dependent data arrived at different times?
Then try to remember the things you did to actually overcome this complexity, or if you didn't overcome it, how did you work around it? Maybe all you did was to actually fully understand the complexity and what it required of you. Whatever it is, note it down.
Finally, try to "explain to a 5-year old". Or your sibling/cousin/a friend who doesn't know a thing about your field. Can you explain them and help them understand that what the project was all about, and why it was so hard / complex, and how you came up with the ways to overcome that challenge?
If you can do that, you will do just fine when you explain that same project to an interviewer at Big Tech :)
Best of luck!
===
P.S. If you are applying to entry-level roles, you will be compared to recent college graduates, whose technical scope is very unlikely to be complex. Heck, it might not even matter which professional project you decide to explain, as long as you explain it well and crush your technical interviews (since that's where almost all of the weight is).
P.S.S. I would be a bit more careful about "coasting" at my current company, especially since you are going to need references to back you up. You don't need to acquire bigger scope projects for interviews, but your reputation, where you work at, matters. Tech is a small world and you don't know who will be running into down the road.
