2nd Round Interview Q&A

1. Explain the architecture of your current React Native application.

I generally prefer a feature-based architecture for large React Native applications.

For example:

src/
 ├── app/
 │    ├── navigation/
 │    ├── providers/
 │    └── config/
 │
 ├── core/
 │    ├── api/
 │    ├── storage/
 │    ├── constants/
 │    └── utilities/
 │
 ├── shared/
 │    ├── components/
 │    ├── hooks/
 │    └── types/
 │
 └── features/
      ├── authentication/
      ├── profile/
      ├── payments/
      └── trading/

Each feature owns its screens, components, hooks, API logic and state where possible.

This makes the application easier to maintain and allows multiple developers to work independently without creating a tightly coupled codebase.

2. Why do you prefer feature-based architecture?

In a large application, organizing everything by technical type can become difficult.

For example:

components/
screens/
hooks/
services/

can eventually contain hundreds of files.

With feature-based architecture, everything related to a particular business feature stays together.

It improves:

• Maintainability

• Scalability

• Code ownership

• Testing

• Developer productivity

• Feature isolation

It also makes it easier to remove or modify a feature without affecting unrelated modules.

3. How do you manage state in React Native?

I separate state based on its responsibility.

For example:

• Local UI state → useState

• Complex local state → useReducer

• Server/API state → React Query or an appropriate server-state solution

• Global application state → Redux Toolkit or another centralized solution

• Persistent state → AsyncStorage/Secure Storage depending on sensitivity

I avoid putting everything into global state because it increases complexity and unnecessary re-renders.

4. Redux vs Context API?

Context is useful for relatively stable global values such as:

• Theme

• Authentication context

• Localization

• Configuration

Redux Toolkit is more appropriate when the application has complex global state, multiple consumers, predictable state transitions, middleware requirements, or extensive debugging needs.

I don't choose Redux simply because the application is large. I choose it when the state-management requirements justify it.

5. Why Redux Toolkit instead of traditional Redux?

Redux Toolkit reduces boilerplate and provides recommended Redux patterns.

It gives us:

• createSlice

• createAsyncThunk

• Middleware configuration

• Immutable update handling through Immer

• Better TypeScript support

• Cleaner store configuration

It makes Redux easier to maintain compared with manually writing action types, action creators and reducers.

6. How do you prevent unnecessary re-renders?

First, I identify the source of the re-render instead of blindly memoizing everything.

I use:

• React.memo

• useMemo

• useCallback

• Proper state placement

• Stable props

• Selective Redux subscriptions

• Component decomposition

For example, if a FlatList row receives the same props but its parent keeps rendering, I can use React.memo for the row component.

However, I don't use memoization everywhere because it also has a cost and can make code unnecessarily complex.

7. How would you optimize a slow FlatList?

I would investigate first and then optimize.

Typical techniques include:

<FlatList
  data={data}
  renderItem={renderItem}
  keyExtractor={item => item.id}
  initialNumToRender={10}
  maxToRenderPerBatch={10}
  windowSize={5}
  removeClippedSubviews
/>

I would also:

• Memoize row components

• Keep renderItem stable

• Avoid creating expensive objects/functions inside render

• Use stable keys

• Optimize images

• Avoid unnecessary parent re-renders

• Paginate large datasets

• Avoid expensive calculations inside each row

The exact values should be measured rather than copied blindly.

8. What is the difference between ScrollView and FlatList?

ScrollView renders all of its children at once.

FlatList virtualizes the list and renders only the items required around the visible area.

Therefore:

Small/static content → ScrollView
Large/dynamic list → FlatList

For thousands of records, I would generally prefer FlatList or another virtualized list implementation.

9. Your React Native screen takes 5 seconds to open. How do you debug it?

I would not immediately start changing code.

I would first identify where the time is being spent.

My investigation would include:

1. Navigation timing

2. API response time

3. JavaScript thread performance

4. Component render count

5. Large synchronous computations

6. Image loading

7. Expensive useEffect operations

8. Redux state updates

9. Native module operations

10. Network calls

Then I would profile the screen and optimize the actual bottleneck.

For example, if the API takes 4 seconds, optimizing React rendering won't solve the main problem.

10. How do you improve React Native application startup time?

I would investigate:

• JavaScript bundle size

• Unnecessary initialization

• Large dependencies

• Synchronous work during startup

• Initial API calls

• Image loading

• Navigation initialization

• Native modules

• Logging in production

I would defer non-critical work and load data/features when required rather than doing everything during application startup.

11. How do you handle API errors?

I prefer a centralized API layer.

For example:

UI
 ↓
Hook / State layer
 ↓
API service
 ↓
HTTP client
 ↓
Backend

The API layer can handle:

• Authentication headers

• Token refresh

• Common error handling

• Timeouts

• Serialization

• Logging

• Retry policies where appropriate

The UI should then receive a predictable success/error state.

12. What happens if an API returns 401?

I generally treat 401 as an authentication problem.

Depending on the authentication architecture:

Request
   ↓
401
   ↓
Refresh token
   ↓
Success → retry original request
   ↓
Failure → logout/session expired

I also need to prevent multiple simultaneous requests from independently refreshing the token.

A token-refresh queue or centralized interceptor mechanism can solve that problem.

13. How do you prevent duplicate API requests?

I first determine why they are happening.

Common causes include:

• Multiple useEffect executions

• Incorrect dependencies

• Screen focus events

• Multiple components requesting the same data

• User repeatedly pressing a button

Solutions can include:

• Request deduplication

• Server-state caching

• Abort/cancellation

• Proper effect dependencies

• Button loading state

• Centralized data fetching

For frequently requested server data, a query/cache solution can be very useful.

14. How do you handle API timeout?

I would configure a reasonable timeout and show an appropriate UI state.

For example:

Loading
   ↓
Request
   ↓
Timeout
   ↓
Retry / Try Again

For retryable operations, I may use exponential backoff:

1s → 2s → 4s → 8s

But I wouldn't blindly retry every API because POST operations could potentially create duplicate transactions.

15. How would you implement search with API calls?

I would normally debounce the search input.

User types:
R
Re
Rea
Reac
React
       ↓
Wait 300–500 ms
       ↓
API request

This prevents an API request for every keystroke.

I would also cancel or ignore stale requests so that an older response doesn't overwrite a newer search result.

16. What is debounce?

Debounce delays execution until the user stops triggering an event for a specified period.

Example:

const debounce = (fn, delay) => {
  let timer;

  return (...args) => {
    clearTimeout(timer);

    timer = setTimeout(() => {
      fn(...args);
    }, delay);
  };
};

It's useful for:

• Search

• Validation

• Autosave

• API calls

17. What is throttle?

Throttle limits how frequently a function can execute.

For example, instead of processing every scroll event, we might process it at most once every 200ms.

Debounce → execute after activity stops
Throttle → execute at controlled intervals

18. How do you handle memory leaks in React Native?

I look for resources that continue running after a component unmounts.

Examples:

• Timers

• Event listeners

• Subscriptions

• WebSockets

• Location listeners

• BLE listeners

• Uncancelled API requests

For example:

useEffect(() => {
  const subscription = subscribe();

  return () => {
    subscription.remove();
  };
}, []);

Cleanup is particularly important for screens that are repeatedly mounted and unmounted.

19. Explain useEffect dependency problems.

A common mistake is:

useEffect(() => {
  fetchData();
}, []);

when fetchData actually depends on changing values.

Another issue is creating a function/object inside the component and then using it as an effect dependency, causing repeated executions.

I always make dependencies explicit and investigate whether the effect represents synchronization with an external system rather than using useEffect for every piece of logic.

20. What is React.memo?

React.memo prevents a functional component from rendering when its props haven't changed.

Example:

const UserCard = React.memo(({ user }) => {
  return <Text>{user.name}</Text>;
});

But if a new object is created on every render:

<UserCard user={{ name: "Salil" }} />

the reference changes, so memoization may not help.

Therefore, stable props are important.

21. useMemo vs useCallback?

useMemo memoizes a calculated value.

const total = useMemo(
  () => calculateTotal(items),
  [items]
);

useCallback memoizes a function reference.

const handlePress = useCallback(() => {
  doSomething(id);
}, [id]);

A common use case for useCallback is passing callbacks to memoized child components.

22. When should you NOT use useMemo/useCallback?

I don't use them automatically.

For simple calculations or components where rendering is already cheap, memoization can add unnecessary complexity.

I use them when profiling or component behavior indicates that referential stability provides a real benefit.

23. Explain React Native's bridge / communication architecture.

Conceptually, React Native allows JavaScript code to communicate with native platform functionality.

Historically, this involved the asynchronous Bridge.

Modern React Native uses the newer architecture involving:

• JSI

• TurboModules

• Fabric

• Codegen

The newer architecture reduces some of the overhead associated with the old bridge-based communication model and provides more direct interaction between JavaScript and native functionality.

24. What is JSI?

JSI stands for JavaScript Interface.

It provides a way for JavaScript to interact more directly with C++ and native functionality without relying exclusively on the traditional asynchronous bridge serialization model.

It's an important part of React Native's New Architecture.

25. Fabric vs old renderer?

Fabric is React Native's newer rendering system.

It was designed to improve the rendering architecture and integration with modern React capabilities.

It works alongside other parts of the New Architecture such as JSI and TurboModules.

26. What are TurboModules?

TurboModules are part of React Native's New Architecture.

They provide a more efficient way for JavaScript to communicate with native modules, including concepts such as lazy loading and stronger type/code generation support.

27. When would you write native Android code in a React Native application?

I would consider native code when:

• React Native doesn't provide required functionality

• A third-party library doesn't support a required native capability

• Platform-specific performance is critical

• Bluetooth/BLE functionality requires native APIs

• Background services require native implementation

• Existing native SDKs need integration

I would first check whether a reliable existing library can solve the problem before introducing custom native code.

28. You have a crash occurring only on Android. How do you debug it?

I would isolate the platform-specific path.

I'd check:

1. Crash logs

2. Android Logcat

3. Stack trace

4. Device/OS version

5. Native modules

6. Permissions

7. ProGuard/R8 issues

8. Release vs debug differences

9. Reproduction steps

Then I'd reproduce on the closest Android version/device configuration and identify whether the crash originates in JavaScript or native Android code.

29. How do you handle Android permissions?

I treat permissions as part of the feature flow rather than simply requesting everything at startup.

For example:

Feature requested
      ↓
Check permission
      ↓
Granted → continue
      ↓
Not granted → explain/request
      ↓
Denied → provide appropriate fallback

For sensitive permissions, the user experience and Android version-specific behavior need to be considered carefully.

30. How do you manage environment configurations?

I separate environment-specific configuration from application logic.

For example:

Development
Staging
Production

Each environment can have different:

• API URLs

• Feature flags

• Logging configuration

• Analytics configuration

• Third-party keys/configuration

Sensitive secrets should not be treated as secure simply because they are stored in a mobile environment file. Anything shipped in the application can potentially be extracted.

31. Explain your CI/CD process for React Native.

A typical pipeline I have worked with is:

Git Push
   ↓
Pull Request
   ↓
Lint + TypeScript
   ↓
Unit Tests
   ↓
Build
   ↓
QA/Staging
   ↓
Release Build
   ↓
Play Store / App Store

Depending on the project, we can automate signing, versioning, build generation, distribution, and deployment.

The objective is to make releases repeatable rather than relying on manual local builds.

32. What Git workflow do you follow?

A typical workflow is:

feature branch
      ↓
Pull Request
      ↓
Code Review
      ↓
CI checks
      ↓
Merge
      ↓
Release branch/tag

I prefer small, meaningful commits and avoid committing generated files or unrelated changes.

For conflicts, I first understand the intent of both changes rather than blindly accepting one side.

33. What do you check during code review?

I check:

• Correctness

• Readability

• Architecture

• Type safety

• Error handling

• Performance

• Security

• Reusability

• Testing

• Edge cases

• Unnecessary complexity

For React Native specifically, I also look for unnecessary re-renders, improper FlatList usage, incorrect effects, memory leaks and platform-specific issues.

34. How would you design a reusable Button component?

I would avoid creating a component that only works for one screen.

For example:

<Button
  title="Continue"
  variant="primary"
  loading={loading}
  disabled={disabled}
  onPress={handleContinue}
/>

The component should own common visual behavior while the screen owns business logic.

This allows consistent UI and makes future design changes easier.

35. How do you make a React Native application scalable?

I focus on several areas:

Architecture

Feature-based modular structure.

State

Separate local, global and server state.

Components

Reusable components with clear responsibilities.

API

Centralized API layer.

TypeScript

Strong domain types.

Testing

Unit, integration and end-to-end coverage where appropriate.

CI/CD

Automated quality and release checks.

Performance

Profiling and performance budgets.

Documentation

Architecture decisions and important technical decisions should be documented.

36. How do you handle offline support?

First I determine which functionality actually needs to work offline.

For read-heavy features:

Network
   ↓
Fetch
   ↓
Local cache
   ↓
Display

When offline, cached data can be displayed.

For operations that modify data, I may use a queue:

Offline action
     ↓
Local queue
     ↓
Network available
     ↓
Sync
     ↓
Success / retry

Conflict resolution needs to be defined according to business requirements.

37. How do you secure authentication tokens?

I avoid storing sensitive authentication credentials in plain AsyncStorage when stronger secure storage is appropriate.

For sensitive tokens, I would consider platform-backed secure storage such as:

• Android Keystore

• iOS Keychain

I also avoid logging tokens and sensitive API responses.

38. How do you handle sensitive information in logs?

Production logs should never expose:

• Passwords

• Access tokens

• Refresh tokens

• Payment information

• Personal sensitive data

I prefer structured logging with different levels for development and production.

39. How would you troubleshoot a production issue reported by a client?

I would follow a structured process:

Understand issue
      ↓
Reproduce
      ↓
Collect logs
      ↓
Identify affected version/platform
      ↓
Find root cause
      ↓
Fix
      ↓
Test regression
      ↓
Release
      ↓
Monitor

I would also communicate status clearly to the client or relevant stakeholders instead of only focusing on the technical fix.

40. A client says the application is slow. What do you do?

I would ask:

• Which screen?

• Android, iOS, or both?

• Which application version?

• Is it startup, navigation, API or scrolling?

• Is the issue consistent?

• Which devices are affected?

Then I would measure the actual performance.

I wouldn't assume that React Native itself is the problem without profiling.

41. How do you handle disagreement with a developer during implementation?

I focus on the technical requirement rather than making it personal.

I would explain my reasoning and ask the other developer to explain theirs.

Then we compare:

• Maintainability

• Performance

• Complexity

• Requirements

• Long-term impact

If necessary, we can involve the technical lead and make the decision based on the project's requirements.

42. How do you estimate a React Native feature?

I break the feature into smaller tasks.

For example:

Requirement analysis
UI
Navigation
API integration
State management
Validation
Error handling
Testing
Platform-specific work
QA fixes
Release

I identify dependencies and risks before giving an estimate.

I also communicate assumptions because an estimate without assumptions can easily become misleading.

43. What would you do if requirements are unclear?

I don't start implementation based on assumptions.

I clarify:

• User flow

• Expected behavior

• API contract

• Validation

• Error states

• Platform differences

• Acceptance criteria

If some decisions cannot be finalized immediately, I document the assumption and proceed with the agreed interpretation.

44. How do you handle tight deadlines?

I prioritize functionality based on business impact.

I separate:

Must have
Should have
Nice to have

Then I communicate risks early.

I don't compromise critical security, stability or data correctness just to meet a deadline.

45. How do you handle a production bug that you introduced?

First, I take ownership.

I reproduce and identify the root cause, then work on the safest fix and regression testing.

Afterward, I also look at why the issue wasn't caught earlier—for example, missing tests, unclear requirements or insufficient review—and improve the process where appropriate.

The goal isn't just to fix one bug but to reduce the chance of repeating it.

46. Tell me about a challenging technical problem you solved.

A strong answer should follow:

Situation
   ↓
Problem
   ↓
Investigation
   ↓
Solution
   ↓
Result

For example:

"In one of my mobile projects, we had a performance issue on a data-heavy screen. I first profiled the screen and found that unnecessary re-renders and expensive list rendering were contributing to the problem. I optimized the list, memoized appropriate components, reduced unnecessary state updates and improved data handling. After testing on different devices, the screen became significantly more responsive."

Use your actual project metrics if you have them.

47. How would you integrate an AI feature into a React Native application?

I would avoid putting sensitive AI credentials directly into the mobile application.

A safer architecture is:

React Native
      ↓
Backend API
      ↓
AI Provider
      ↓
Backend
      ↓
React Native

The backend can handle authentication, authorization, prompt construction, rate limiting, logging and provider credentials.

For UX, I would also consider:

• Loading states

• Streaming where useful

• Timeout handling

• Retry

• Error handling

• Response validation

• Privacy

• Cost control

48. What AI features could you build into a mobile application?

Depending on the product, possibilities include:

• Smart search

• Personalized recommendations

• Text summarization

• Intelligent suggestions

• Conversational assistance

• Automated categorization

• Content generation

• Document extraction

I would first validate whether AI actually solves a user problem instead of adding AI simply because it is available.

49. How would you reduce AI response latency?

I would look at the entire pipeline:

Mobile
 ↓
Network
 ↓
Backend
 ↓
AI provider
 ↓
Backend
 ↓
Mobile

Possible improvements include:

• Smaller prompts

• Appropriate model selection

• Streaming responses

• Caching

• Reducing unnecessary requests

• Parallelizing independent operations

• Moving non-critical processing out of the critical path

I would measure each stage before optimizing.

50. What would you do if you don't know the answer in an interview?

I would be honest.

For example:

"I haven't implemented that directly yet, so I don't want to give you an incorrect answer. Based on my understanding, I would approach it by..."

Then I would explain the relevant concept I do know.

For a senior developer, showing how you reason through an unfamiliar problem is often more useful than pretending to know everything.

High-Priority Questions to Practice First

If you have limited time before the interview, prioritize these:

1. Explain your current project architecture.

2. How do you optimize FlatList?

3. How do you debug a slow screen?

4. Explain Redux/state management.

5. How do you handle API failures?

6. How does token refresh work?

7. How do you prevent duplicate API calls?

8. Explain useMemo, useCallback, and React.memo.

9. Explain React Native New Architecture.

10. JSI vs Bridge.

11. TurboModules and Fabric.

12. When do you write native Android code?

13. Explain your CI/CD pipeline.

14. How do you handle production crashes?

15. How do you secure tokens?

16. How do you structure a large RN project?

17. How do you handle offline functionality?

18. How do you resolve Git conflicts?

19. How do you handle client disagreements?

20. Explain a difficult problem you solved.

21. How would you integrate AI into an RN application?

22. How would you reduce AI latency?

23. How do you estimate a feature?

24. How do you handle unclear requirements?

25. What would you do if you don't know something?