Occasionally, I stream on Twitch and I wanted to be able to publicly share things without attaching my real name because… something about growing up in the 90s and constantly being told not to share too much on the internet.
So, I bought the aymeeko.com domain and moved my blog there. This way, I’m hoping to share more openly about my learnings and journey in software.
I’m on the hiring panel for my company, and we’re looking to hire backend engineers of various levels. A topic of discussion has been to revisit the question bank we’ve used in the past. Are they good questions? What makes a question “good?”
I set out to find more questions for our bank and realized some of the problems I worked through didn’t fit the bill for various reasons. I had to quantify what I consider a good question.
For problem solving / pairing style questions, I came out with the following:
This is a tall order, surprisingly. Another piece of criteria to consider is the prevalence of the problem existing on the internet. I haven’t decided how that criteria should factor into questions. A good question is extensible, so maybe it’s okay if the base of the question is known, as long as the actual problem statement is varied enough that the candidate is unlikely to have seen or worked through the whole solution.
Maybe even if the question is not super extensible, a question that allows you to ask the question to talk through pros/cons of their approach is also okay. A candidate who memorizes a solution will likely struggle to explain why choices were made, or other approaches they could’ve taken.
I spent a few hours looking for and solving a handful of questions I found on the internet. Most of them didn’t pass the “good question” criteria by at least one thing. One of the questions did make me think of something else though: the value in having a question that starts with non-trivial existing code. Engineers spend significantly more time reading code than writing it, so problems that require a candidate to understand the existing codebase can be interesting!
One of the problems I found was very straight forward to implement, but along the way, I wrote a bunch of tests to validate my code. Maybe there was value in this problem as one where we give the candidate the full working code and ask the candidate to write tests. Writing tests is super valuable and often undervalued.
I’m still on this journey, so I don’t really have a conclusion here. Maybe I’m overthinking this problem. The fact that the industry has no standardization for interviewing makes me think I’m not, though. Maybe by putting effort into finding what makes a good problem and creating some that fit that criteria, I can help with that standardization, at least within my current company.
Algorithms are wild. I never really learned them properly because… Well, I guess I never had to. I interviewed at companies that didn’t ask DSA questions and it didn’t seem to hold me back. I never really understood the value of studying DSA because its rarely applicable past interviews, but I’m beginning to understand now.
In my spare time, I’ve been studying and it’s been really interesting and fun. It feels good to understand new (to me) ways of thinking about problems. I generally consider my time in college as where I learned how to think and learn, not where I learned x or y. Learning DSA feels like that. The value is only a little bit the actual algorithms you learn. The rest is just learning to think differently.
I’m not really sure why I decided to go this route but I’m happy I did.
Leetcode. Most software engineers have heard of it. I’d never used it, but I decided to check it out because I’ve been so absorbed in work and life recently that I needed something else.
I understand why it’s regarded as it is – both a blessing and a curse. It’s a great source of small but manageable coding problems. Not only that, you can see how others solved the problem. It’s really neat that it shows you how your solution compares to others’ in regards to runtime and memory usage. I’m enjoying these parts a lot.
What I’m not enjoying is how many of these problems rely on algorithms. In real life, the opportunity to use algorithms is so low. I want problems that require me to actually understand what I’m writing, not just regurgitate an algorithm I learned. Maybe this just means I haven’t really learned enough algorithms. I need to work on that.
As I mentioned, it’s awesome that you can see others’ solutions. However, I’ve noticed a theme that people don’t tend to write maintainable code. Or even very readable code, at that. This is also not what I’m looking for. I’m only a few problems in, so I’m not sure if this is a result of the nature of these problems, or the nature of the people solving the problems. Maybe it’s half and half. I do think it’s very common for people, when given a problem, to keep much more of the problem in their head than they need to. They don’t start with OOP. They don’t build objects with reasonable relationships and ownership. They use primitive data objects and maintain that modeling and data ownership in their heads. I do this too… but I want to practice not doing that.
I’m still having fun, and I’m glad I finally checked it out. Like most things, you get what you put in.
Recently, my company started rolling out a mandatory Diversity and Inclusion training. It was a 90 minute session that mainly focused on introducing a very open ended conversation about identity: how we all have things we identify as or with, how those identities can be expressed, how that expression can be voluntary or involuntary, and how those expressions can be perceived by others.
Mostly I walked out of the training realizing how very lucky I am to have landed where I am, at the time that I did. I joined Venmo about 3 months ago, and the last 6 months for the company has been explosive for growing the Chicago office. Nearly everyone I work with day-to-day is pretty new, and I’m realizing that what this means is there was no culture to assimilate into because we’re still making it. Everyone is just showing up as they are, meeting people where they are. We’re building a culture of openness and communication, and it feels so good. It’s an amazing opportunity, and I’m so happy to be here for it.