My Hiring Philosophy
I joined Momos in June 2024 and became the 4th engineer in Vietnam. We have almost 20 engineers in the Ho Chi Minh City office now, and still growing.
I shadowed an interview on my second day at Momos and started interviewing candidates after crossing the 6-month mark.
For us, both false positives and false negatives are costly. We need to hire more engineers to serve the expansion of the business. But a bad hire will also cost us a lot, as any additional person will help shape the culture of this relatively small, growing team going forward.
Having seen many soft no’s, especially from younger candidates, I’m writing this to explain what I’m looking for to help candidates prepare better for the interviews. I believe this will also apply if you are looking to join a tech startup/scale up.
While my hiring philosophy is influenced by how Momos operate and how we hire software engineers, this is my personal view and does not represent the whole company or engineering organization.
If you check all the boxes, I consider you a strong hire. But it does not mean you will pass the whole recruitment process (even though I’m often considered the toughest interviewer in the team). The reverse also applies: you may still get the job if you don’t meet all of my requirements.
Too many disclaimers already. Let’s go!
Curiosity
To me, this is the strongest signal for a good candidate.
Being a software engineer at a startup, your scope constantly changes. And lots of time, you need to create new scopes for yourself - by identifying gaps and proposing solutions that no one else has thought of. Without curiosity, it’s very unlikely for someone to achieve this.
There are many ways to test curiosity. My favorite is to ask the candidate what they are interested in or confident with the most, and try to go deep into that subject.
Having said that, even though I hope the candidate can explain what they claim to be strong at in and out, I don’t need them to do so perfectly.
They can also use the “breath” approach, but I expect them to know one thing in relatively good depth instead of scratching many things on the surface.
First principles thinking
This can be tested by the same question above. After going deep into the thing the candidate is most confident with, I try to ask them to question some of the fundamental truths and reason from there.
One question I like to ask is to compare the languages listed in the resume in a certain area - of course, after making sure they have decent experience with all those languages. If they ace it, I will ask more why questions, usually around language design decisions. The goal is not to test how much they know, but how well they can connect things people often take for granted to the fundamentals.
I value this because in startups, we need to solve for the why’s as much as we need for the what’s and how’s. Without the ability to think clearly, it’s hard for one to succeed in this environment.
Product mindset
This interleaves with the first two values a lot, so I usually don’t ask any questions to directly test the product mindset. Nevertheless, I see my boss asking this in the behavioral round a few times.
Product mindset is not only about the final product - in our case, the Momos platform. It’s about the thing you build that others, including your future self, use. If you are a software engineer, it’s the code you write and the system you design. Having a user-centric mindset will bring significant value.
Growth
This is for the young folks. Since you just entered the workforce for a few years (or even less), I don’t expect you to know a lot - I didn’t either. You may not show a strong signal for a certain important trait above, but I can still give you a yes.
This is because Momos is at the stage of being willing to invest in young people. We didn’t have enough resources to do so previously. And I am willing to devote my time to train young engineers if they are hungry and have growth potential.
If I told you to slow down and think carefully before answering some particular question, you'd better do so. It’s usually the time when I’m giving you a chance (or a second chance).
What I intentionally left out
There are things that we used to test and still test, but I left them out of my hiring philosophy since they are either 1) not as important as what is listed above, or 2) almost impossible to test fairly with the latest AI advancement.
We value attention to detail, which was (and still is) tested by the take-home assessment. It is a straightforward problem, and we care more about the delivery than the actual product. I think this is no longer a strong filter since AI can deliver very well now (which was not the case a few months ago).
Knowing fundamentals is another thing. It’s hard to define what the fundamentals are in this context. I still prefer people who understand how computers work, but it will filter out many strong candidates who can contribute a lot to the company. For certain roles, we still have a fixed set of problems about JS/TS (our main programming language) and database (since we work with data a lot), but it’s no longer a hard deal-breaker.
While the traits above are important to me in identifying a strong candidate, standard things like having the ability to explain past experience and projects, knowing how to code, decent communication, etc., still apply.
I’m still learning, both as a software engineer and an interviewer. My hiring philosophy might still be refined along the way. If you see it resonates with your value, give me a heads-up!