Betterhalf.ai SDE-2 (React Native) Interview Experience

Betterhalf.ai reached out to me through LinkedIn. Senior React Native Developer role. I’d heard of them — they’re doing interesting work in the AI-powered matchmaking space, serving millions of users across India.

I was curious. Not desperately looking, but curious enough to take the call.

The recruiter was refreshingly honest. “Look, this isn’t going to be a typical interview. Our team cares a lot about how you think through problems, not just what you’ve memorized.”

I appreciated that. But also, every recruiter says something like that, right?

Walking In

I’ll be honest — I was a little nervous. Not because I doubted my skills, but because I genuinely liked what the company was doing. Sometimes that makes it harder.

The office had that startup energy — people actually seemed excited to be there, not just collecting paychecks. Good sign.

My interviewer introduced himself and immediately put me at ease. “I’ve been looking forward to this conversation. I read through your background, and I’m curious about some of the architectural decisions you’ve made in your projects.”

Already different from the “tell me about yourself” opener I was expecting.

The Questions That Made Me Think

Libraries and Boilerplate

“If you were starting a new React Native project tomorrow, what would you absolutely include in your setup?”

Simple question, right? But the way he asked it made me realize he wasn’t looking for a shopping list. He wanted to understand my decision-making process.

I started with the obvious ones — React Navigation, Redux Toolkit, debugging tools. But then I found myself explaining the “why” behind each choice.

“Redux Toolkit because it eliminates so much boilerplate compared to vanilla Redux, and the DevTools integration is incredible for debugging.”

“MMKV instead of AsyncStorage because the performance difference is dramatic — we’re talking 30x faster for key-value operations.”

He was nodding along, asking follow-up questions. “What about when Redux becomes overkill?”

That led to a great discussion about Context API vs Redux, when complexity justifies the overhead, team considerations. This wasn’t an interrogation — it felt like two developers talking shop.

The Performance Question That Stumped Me (For a Second)

Then he showed me some code on his laptop:

function ParentComponent() {
 const [count, setCount] = useState(0);
 
 return (
 <ChildComponent 
 user={{ name: 'John', age: 30 }}
 onPress={() => handlePress()}
 />
 );
}
const ChildComponent = React.memo(({ user, onPress }) => {
 console.log('Child rendered');
 return <Text>{user.name}</Text>;
});

“What’s going to happen here when the parent re-renders?”

I looked at it for a moment, and then it clicked. “Oh, the child is going to re-render every time even though it’s memoized, because the parent is creating new objects for the props on every render.”

“Exactly. How would you fix it?”

We talked through useMemo for the user object, useCallback for the function, or restructuring to avoid inline object creation entirely. But what I really appreciated was that we discussed the trade-offs. When is this optimization worth it vs. premature optimization?

He shared a story about their app where they discovered this exact performance bottleneck affecting scroll performance on lower-end devices. Real-world context always makes these discussions better.

The Live Coding Challenge

“Alright, here’s a fun one. Can you build me a timer component? Start, pause, reset functionality. Don’t worry about making it pretty.”

I started coding, talking through my approach as I went:

`const Timer = () => {
 const [time, setTime] = useState(0);
 const [isRunning, setIsRunning] = useState(false);
 const intervalRef = useRef(null);
 
 useEffect(() => {
 if (isRunning) {
 intervalRef.current = setInterval(() => {
 setTime(prevTime => prevTime + 1);
 }, 1000);
 } else {
 clearInterval(intervalRef.current);
 }
 
 return () => clearInterval(intervalRef.current);
 }, [isRunning]);
 
 // … rest of the component
};

“Why useRef for the interval ID?”

“Because if I stored it in state, clearing the interval would trigger a re-render, which could cause issues. useRef gives me a mutable container that persists across renders without triggering updates.”

He seemed pleased with that explanation. Then came the follow-up questions that showed he was really thinking about production use:

“What happens if the user backgrounds the app while the timer is running?”

“What about accessibility?”

“How would you handle really long timer values — like hours?”

These weren’t gotcha questions. They were the kinds of things you actually have to think about when building features users depend on.

Storage Solutions

The last technical question was about AsyncStorage alternatives, which turned into a great discussion about trade-offs:

• MMKV for general key-value storage (performance beast)
• Keychain for sensitive data like tokens (security first)
• SQLite when you need real queries and relationships
• AsyncStorage when you need the simplest possible solution

We talked about real scenarios where each made sense. I shared a story about migrating from AsyncStorage to MMKV in a previous project and seeing immediate performance improvements.

The Outcome (And What I Learned)

Unfortunately, I got rejected for next round. But I left that conversation feeling energized rather than drained.

Here’s what I learned:

Senior interviews are about judgment, not just knowledge. Anyone can Google “how to use React.memo.” Not everyone can explain when it’s worth using and when it’s overkill.

Real-world experience shows. The best answers weren’t textbook perfect — they were informed by actual problems I’d solved and mistakes I’d made.

Good interviewers want to see your thought process. They’re not looking for the “right” answer as much as they want to understand how you think through problems.

Technical discussions > technical interrogations. The interview felt collaborative because they made it collaborative. That’s usually a good sign about company culture.