We had the privilege of interviewing Jose Dalino Jr., the CTO of PayMongo, one of Southeast Asia’s fastest-growing fintech companies.
With experience at leading tech companies like Traveloka, AWS and Accenture, Jose has played a key role in building and scaling PayMongo’s engineering team. PayMongo provides a full suite of financial tools – from online payments and APIs to wallets, capital, and issuing. They empower businesses of all sizes to accept payments, manage transactions, and access financing in one seamless platform.
In this conversation, he shares his hard-won insights on everything from crafting an effective interview process to building a culture that attracts and retains top talent. His advice is essential for any founder looking to build a strong technical foundation for their startup.
Beyond technical proficiency, what is the single most important, non-obvious trait you look for when hiring an engineer for the PayMongo team?
Beyond the technical skills, the single most important trait I look for is a high degree of ownership and customer-centricity. This isn’t just about accountability; it’s about a proactive mindset. A great engineer doesn’t wait to be told what to do. They identify a problem, propose a solution, and drive it to completion. At a fast-growing company like PayMongo, where we are often building the plane as we fly it, this trait is non-negotiable. It’s the difference between someone who delivers a ticket and someone who solves a business problem. They see a gap in our processes, our products, or our code, and they take the initiative to close it.
How has your philosophy on what makes a “great” engineer evolved from the early days of being an engineering leader to now?
In my early days, I focused heavily on pure technical horsepower—the ability to write elegant code, design complex systems, and solve hard algorithmic problems. While those are still important, my philosophy has matured to a more holistic view. A “great” engineer is no longer just a technical wizard. They are a force multiplier for the entire team and the business. This means they are excellent communicators, can influence their peers, and deeply understand the business context of their work. They ask “why” and “what’s the impact” before they jump to “how.” This shift has been crucial for PayMongo, as our engineers are not just coders; they are product builders who contribute to strategy and innovation.
How do you evaluate or think about engineers differently at an early-stage startup compared to a larger, late-stage tech company?
At a larger, late-stage company like AWS, engineers often work within well-defined roles and established processes. The focus is on deep specialization, operational excellence, and robustness. At an early-stage startup like PayMongo was, the context is completely different. We need generalists who are comfortable with ambiguity and thrive in chaos. They must be resourceful and able to wear multiple hats—from debugging a production issue to helping with a customer support ticket. The ability to learn quickly and adapt is more valuable than having a decade of experience in a single technology. The questions I ask are less about how they’d optimize a system for a million requests per second and more about how they would build a minimal viable product that works, iterate quickly, and handle the unexpected.
Could you walk us through the stages of your engineering interview process? What is the specific goal you’re trying to achieve at each step?
Our process is designed to be comprehensive yet respectful of the candidate’s time.
- Initial Screen (30 mins): The goal here is to assess basic technical background, communication skills, and alignment with the role’s requirements. We want to understand their motivation for joining PayMongo and their high-level career goals. This is a chance for both sides to see if there’s a good initial fit.
- Technical Challenge (Take-home or Live Coding): We use a take-home assignment to evaluate a candidate’s real-world problem-solving abilities. It’s designed to be a microcosm of the kind of work they would do at PayMongo. The goal is not just to see if they can solve the problem, but how they approach it—how they structure their code, handle edge cases, write tests, and document their solution. For a more senior role, we might use a live system design session to understand their architectural thinking.
- Technical Deep Dive / System Design Interview (60 mins): We review the take-home challenge or discuss a system design problem. The goal is to see how they think, their depth of knowledge, and their ability to defend their design choices. This is where we assess their understanding of trade-offs, scalability, and maintainability.
- Behavioral / Leadership Interview (60 mins): This stage, typically with me or our Chief People Officer, focuses on assessing non-technical traits like ownership, communication, collaboration, and learning potential. We use behavioral questions (e.g., “Tell me about a time you had a disagreement with a teammate”) to understand how they handle real-world scenarios. We’re looking for signs of resilience, humility, and a growth mindset.
- Final Offer: Once a candidate has successfully navigated all stages, we extend an offer and begin the onboarding process.
How do you balance hiring for immediate needs versus building long-term engineering capacity as the company scales?
This is a constant balancing act. For immediate needs, we focus on candidates who have proven experience with our current tech stack and can hit the ground running. They fill critical gaps and help us move forward quickly. However, a significant part of my strategy is to always be hiring for “long-term capacity.” This means we actively look for engineers with high learning potential, strong fundamentals, and a passion for continuous improvement. While they may not be a perfect fit for a specific, urgent project, their ability to grow and adapt will be invaluable as our tech stack evolves and our business challenges become more complex. We’ve found that investing in these individuals early pays dividends down the line, as they become the future leaders and architects of the company.
How do you design technical assessments to effectively evaluate a candidate’s real-world problem-solving skills, rather than just their coding skills?
We design our technical assessments to be as close to real-world scenarios as possible. A typical coding challenge might ask a candidate to build a simple, functional service that consumes an API, processes data, and stores it in a database. This is not about writing a sorting algorithm from scratch; it’s about putting together a mini-application. We provide a clear problem statement and let the candidate choose the tools they are most comfortable with. This approach allows us to evaluate a range of skills and gives us a much richer signal than a simple coding exercise.
- Problem comprehension: Do they understand the requirements?
- Architectural thinking: How do they structure the project?
- Code quality: Is the code clean, readable, and well-documented?
- Testing: Do they write unit, integration & e2e tests?
- Error handling: Do they consider what happens when things go wrong?
With AI tools becoming more common in coding and technical work, how do you think engineering assessments should evolve to fairly evaluate candidates’ true skills?
- The rise of AI tools like GitHub Copilot is a significant shift, and we need to adapt our assessments. I believe we should move away from questions that can be easily solved by an AI and focus more on:
- System-level thinking: AI is great at generating code for a single function, but it’s not yet great at designing a complex system that is scalable, fault-tolerant, and secure. Our assessments should focus on architectural decisions and trade-offs.
- Debugging and problem-solving: Give candidates a buggy or incomplete codebase and ask them to fix it. This tests their ability to read, understand, and debug someone else’s code—a skill that is arguably more important than writing new code.
- Communication and collaboration: Have candidates explain their thought process and design decisions. The ability to articulate and defend their approach is a key skill that AI cannot replicate.
- We should acknowledge that candidates will use these tools and assess how effectively they use them as a productivity aid. The goal is to evaluate the engineer, not the code they can generate.
What’s your strategy for assessing a candidate’s potential and ability to learn, especially when they might not have experience with your exact tech stack?
- I believe in hiring for aptitude over specific experience. Our strategy focuses on a few key areas:
- Fundamentals: We probe for a deep understanding of core computer science principles—data structures, algorithms, and system design. These are the building blocks that are transferable across any tech stack.
- Past Learning Experiences: I ask candidates to walk me through a time they had to learn a new technology or a complex concept. What was their process? How did they overcome challenges? This reveals their learning habits and resilience.
- Enthusiasm: Is the candidate genuinely excited about the problems we are solving and the technology we use? A passion for the domain and a curious mindset are strong indicators of a quick learner.
- A candidate who has a strong foundation and a track record of successfully learning new things is often a better long-term hire than someone who has rote experience in our stack but lacks the intellectual curiosity to grow.
How do you evaluate “culture fit”?
- I prefer to use the term “culture add” over “culture fit.” We’re not looking for someone who simply conforms to our existing norms. We’re looking for individuals who share our core values—like ownership, empathy, and a commitment to excellence—but also bring a new perspective and skill set that enriches the team. We evaluate this through:
- Value-based questions: We ask questions that reveal how they align with our core values. For example, “Tell me about a time you took ownership of a problem that wasn’t strictly in your job description.”
- Team collaboration questions: We look for signs of humility and a collaborative spirit. Are they willing to admit when they don’t know something? Are they generous with their knowledge?
- Observing their interactions: During the interview process, we pay attention to how they interact with everyone they meet, from the recruiter to the senior engineer. Are they respectful and engaged?
- Ultimately, “culture add” is about finding someone who will elevate the team and help us evolve, not just fit in.
What strategies have you found most effective for keeping engineers motivated and engaged over the long term, especially in a competitive talent market?
Beyond compensation, which is table stakes, the most effective strategies are:
- Meaningful Work: Engineers are motivated by solving challenging, impactful problems. We ensure our engineers understand the “why” behind their work and the direct impact it has on our customers and the broader financial ecosystem.
- Autonomy and Ownership: We give our engineers a high degree of autonomy over their projects. They are empowered to make decisions, own their code from development to production, and propose new solutions.
- Continuous Learning and Growth: We invest in our people through mentorship, a strong feedback culture, and opportunities for professional development. We encourage them to explore new technologies and take on projects that stretch their skills.
- Recognition: We celebrate successes, both big and small. This isn’t just about promotions; it’s about acknowledging their contributions and showing gratitude for their hard work.
Can you share a key lesson you’ve learned from a hiring decision that didn’t work out as planned?
I once made a hiring decision based primarily on a candidate’s impressive technical resume and their ability to ace a system design interview. Their technical skills were undeniable, but I didn’t probe enough into their communication style and ability to collaborate with a team. Once they joined, it became clear that they preferred to work in isolation and struggled to articulate their ideas to others. Their brilliant code was difficult for the team to integrate and maintain. The key lesson I learned is that no matter how technically brilliant an engineer is, if they cannot work effectively within a team, their impact will be limited. Now, I put a much greater emphasis on assessing collaboration and communication skills during the interview process.
What is one common hiring practice you see founders get wrong, and what should they do instead?
A common mistake I see founders make is to hire solely for skills and experience, and not for potential. They look for someone who has done the exact same thing before, with the exact same technologies. This leads to a team that is well-suited for the immediate needs but lacks the adaptability and growth mindset needed for a rapidly scaling company. Instead, founders should adopt a “hire for potential” mindset. Look for candidates with strong fundamentals, a proven track record of learning, and a curious, ownership-driven attitude. These are the individuals who will not only solve today’s problems but will also grow with the company, take on new challenges, and become the leaders of tomorrow.
