SiteMinder: How We Build Strong Engineering Teams at SiteMinder
By Omar Mujtaba, Mobile Technical Lead at SiteMinder
Craftsmanship Over Construction
Anyone who has spent time in the world of hotel tech, especially today, knows how fast-moving and dynamic the industry is. There is immense room for innovation, particularly with the rapid evolution of AI and the constant demand for more seamless customer experiences.
This is why at SiteMinder, when we hire software engineers, we aim to hire craftsmen — not just carpenters who can hammer nails into wood.
Think of it like furniture making: anyone can assemble a cupboard with straight planks and some nails, but true craftsmen know the finer details of the grain, the weight, the joints, the finishing. They build beauty and durability, not just function.
The same analogy applies to software engineering.
Anyone can stitch together a working app using modern frameworks, libraries or build an app from AI. But when things go wrong — when performance lags, when UX demands precision, when the stack’s convenience breaks down — do they know how to go back to fundamentals and solve the real problems?
This distinction is critical to how we interview and hire engineers at SiteMinder.
My Role: Building the Mobile Teams
I’m the Technical Lead of the Mobile Application Development Team at SiteMinder, responsible for leading our Android and iOS native app teams. As part of my role, I actively hire mobile app developers to ensure our teams remain strong, agile, and technically excellent.
Today, I’ll walk you through how I approach hiring, using examples from interviewing Android engineers to illustrate the process — though the same philosophy applies across platforms.
The Role of Tech Leads in Hiring
At SiteMinder, technical leads are active participants in hiring tech talent across our global offices – from Sydney to Manila to London.
Tech Leads conduct the final stage technical interviews because we will be the line managers and will be accountable for these engineers. We have to make sure that the person not only looks good on paper but also genuinely possesses the skills and mindset required to thrive here.
Even if a candidate impresses in the early screening stages, the technical interview is where they have to prove they are a craftsman, not just a code assembler.
Experience ≠ Expertise
One important lesson we've learned over time: years of experience do not automatically mean technical depth.
Early on, I used to adjust my interviews based on tenure — giving advanced questions to those with longer careers. Over time, I realized that regardless of claimed experience, I have to always start with fundamentals.
Some of the biggest surprises came from candidates with 10+ years of experience who initially sounded strong — but struggled badly when asked fundamental, critical questions.
This changed my entire approach: every candidate, regardless of title, starts with the basics.
Starting Interviews by Setting Expectations
When interviewing, I start by telling the candidate:
- We will begin with basic questions and progressively move towards more advanced topics.
- They are encouraged to be technical in their answers — that's what matters most.
- I’m not evaluating their memory of exact function names or code snippets; I want to understand if they truly grasp how systems are architected and maintained.
This sets a professional but comfortable tone and encourages genuine technical discussion.
A Practical Example: The Two Screens Test
One of my go-to exercises when hiring Android engineers is what I call the "Two Screens Test."
I ask candidates:
Suppose you have two screens:
- Screen A has a button to open Screen B.
- Both screens should make an API call as soon as they load.
- Screen A must not block the button while waiting for the API call.
I ask them:
- How would you divide the responsibilities across architectural layers (repository, service, ViewModel, UI)?
- How would you manage UI responsiveness?
- Which lifecycle methods would you leverage?
- How would you ensure that the app doesn’t crash if the user transitions quickly between screens?
What This Simple Scenario Reveals
At first glance, this seems straightforward — and in real-world apps, it is.
But there is so much an interview can demonstrate through this simple example.
An engineer's answer could — and should — touch on:
- Where to trigger API calls within the lifecycle.
- Threading considerations to avoid blocking the UI.
- Proper state management between screens.
- Dealing with screen orientation changes and preserving state.
- Handling memory leaks and preventing UI crashes when backgrounded.
- Structuring code across repository, service, and presentation layers.
- When and how to safely update UI components post-API responses.
A true craftsman naturally brings up these points, asks clarifying questions, and reasons through trade-offs.
The depth of the conversation reveals far more than any memorized textbook answer.
The Typical Response I Often Get
In contrast, the typical answer I get always involves using some convenience libraries the Android system provides like Lifecycle-aware ViewModels, Couroutines for safe networking, etc:
"I'll create an Android ViewModel, make the API call using coroutines, and update the UI using Observables or LiveData when the data comes back."
Some candidates also mention breaking down business logic into service and repository layers — which is technically correct at a high level.
But when I follow up with:
"Let’s imagine you don't have lifecycle-aware ViewModels or modern coroutine libraries. How would you manage threading, state, and lifecycle manually?"
— that’s where many candidates falter.
This is when you can distinguish the true craftsmen.
Candidates who really understand Android fundamentals (or iOS, in the case of mobile engineers generally) can still reason through a clean, safe, scalable solution — even without relying on frameworks or libraries.
Frameworks Are Helpers, Not Crutches
Modern tools like Jetpack Compose and SwiftUI simplify many aspects of mobile development — but real senior engineers must be able to think beyond them.
Why is this important if frameworks can get the job done? At SiteMinder, we’ve had real-world cases where we hit performance limits using frameworks.
For example:
- In Android (and iOS as well), complex UI grids built with Jetpack Compose or RecyclerViews were lagging.
- We had to abandon these libraries and manually draw UIs using Canvas APIs for a truly smooth, high-performance experience.
Only engineers who understand the lower layers could help us do that.
This is why it’s imperative that senior engineers detach themselves from library comfort zones and go back to first principles when needed.
While we prioritise fundamentals, we also value engineers who stay up to date with the latest stacks. It shows curiosity and a growth mindset — traits we look for at SiteMinder. Our goal is to hire technical experts and then train them on the hotel industry and customer needs to build truly impactful products.
Hiring for Organizational Fit
Technical skill is critical — but so is fit with our values.
At SiteMinder, we don't just hire people who can deliver — we hire people who embody our culture and the values we all adhere to:
- We HUSTLE: We move fast and own outcomes.
- We GROW: We learn, adapt, and level up.
- We make it SIMPLE: We value clarity over complexity.
- We work TOGETHER: Collaboration and accountability are non-negotiable.
Engineers here have autonomy and are trusted to deliver high-quality outcomes without micromanagement.
There’s no clock-watching. The quality of your work speaks louder than your hours logged.
Your code, your collaboration, and your technical decision-making are always visible to your peers — and if you cut corners, it shows.
Craftsmanship Is a Mindset
Being a strong engineer is not about knowing everything.
It’s about:
- Being aware of your strengths and weaknesses.
- Asking questions when unsure.
- Going back to fundamentals when faced with challenges.
- Always striving to grow and improve.
At SiteMinder, we don't rush to fill seats.
We wait — sometimes months — to find engineers who are genuine craftsmen: engineers who build with care, reason with depth, and elevate the teams they join.
That’s why we say:
We hire craftsmen, not just coders.