DEV Community: Amit chakraborty

Deep Link Migration Without Downtime

Amit chakraborty — Sat, 07 Nov 2026 14:42:47 +0000

Expo Router introduces a new way to handle deep links in React Native applications. However, migrating from the old approach can be challenging, especially when trying to avoid a freeze window. Say you are a React Native developer tasked with migrating your app's deep link handling to Expo Router without disrupting user experience.

The Situation

You are working on a React Native app that uses the old deep link handling approach. Your team wants to migrate to Expo Router to take advantage of its features, but you cannot afford to have a freeze window where no updates can be made to the app. You try to migrate the deep link handling, but you encounter issues with routing and linking. The symptom is that some deep links are not working as expected, and you are seeing errors in the console. This is costing you time and potentially losing users who are trying to access specific parts of your app.

Why It Happens

The old deep link handling approach and Expo Router have different architectures and APIs. Expo Router uses a more modular and flexible approach to handling deep links, which requires changes to the app's routing and linking setup. When migrating, it's easy to introduce errors or inconsistencies that can break deep links. Additionally, Expo Router has specific requirements for setting up deep links, such as configuring the app.json file and using the Linking API correctly.

The Fix, Step by Step

To migrate to Expo Router without a freeze window, follow these steps:

Set up Expo Router: First, install Expo Router and set it up in your app. This involves creating a new router.js file and configuring the app.json file to use Expo Router.
Migrate deep link handling incrementally: Instead of migrating all deep links at once, do it incrementally. Start by migrating a small subset of deep links to Expo Router and test them thoroughly. This will help you identify and fix any issues before migrating the rest of the deep links.
Use a fallback mechanism: Implement a fallback mechanism to handle deep links that are not yet migrated to Expo Router. This can be done by using the old deep link handling approach for unmigrated links.
Test and iterate: Test the migrated deep links and iterate on the process until all deep links are working correctly with Expo Router.
Remove the old approach: Once all deep links are migrated, remove the old deep link handling approach to avoid maintaining two different systems.

What It Costs, and When Not to Do It

Migrating to Expo Router requires time and effort, especially if you have a large number of deep links to migrate. However, the benefits of using Expo Router, such as improved flexibility and modularity, make it a worthwhile investment. You should not migrate to Expo Router if you have a very small number of deep links or if you are close to a major release and cannot afford to introduce changes to your app's routing and linking setup.

At Your Level

Starting out: Focus on understanding the basics of Expo Router and how it handles deep links. Start by migrating a small subset of deep links and testing them thoroughly.
Working engineer: You should be able to migrate your app's deep link handling to Expo Router without disrupting user experience. Focus on testing and iterating on the process to ensure that all deep links are working correctly.
Senior or staff: You should be able to architect a migration plan that minimizes downtime and ensures a smooth transition to Expo Router. Consider the trade-offs between migrating incrementally and doing a big-bang migration.
Lead or director: You should be able to prioritize the migration to Expo Router based on business needs and technical requirements. Consider the cost of migration and the benefits of using Expo Router, and make an informed decision about whether to migrate and when.

In the Interview

An interviewer may ask you to describe a situation where you had to migrate a complex system without downtime. A weak answer might focus on the technical details of the migration without considering the broader implications. A strong answer would discuss the trade-offs between different migration approaches, the potential risks and benefits, and the steps taken to mitigate those risks. For example:
Interviewer: "Can you describe a situation where you had to migrate a complex system without downtime?"
Weak answer: "We used Expo Router to handle deep links and it worked fine."
Strong answer: "We had to migrate our app's deep link handling to Expo Router without disrupting user experience. We decided to migrate incrementally, starting with a small subset of deep links, and tested them thoroughly to ensure that they were working correctly. We also implemented a fallback mechanism to handle deep links that were not yet migrated. The migration took several weeks, but it was worth it to ensure a smooth transition to Expo Router."

Amit Chakraborty is a founding engineer and senior architect — React Native, AI/RAG systems and production architecture. Portfolio: www.amitchakraborty.dev · LinkedIn · GitHub. Open to senior and founding engineering roles, remote worldwide.

The forward-deployed engineer bootcamp · 2. The first customer meeting

Amit chakraborty — Sat, 07 Nov 2026 04:30:34 +0000

The forward-deployed engineer bootcamp · Chapter 2 of 12 · Career · new chapter every Saturday morning

By the end of this chapter: Listen for the actual problem underneath the request.

The problem

You're a seasoned engineer considering a role as a forward-deployed engineer, and you've just landed your first customer meeting. You've prepared by researching the company and reviewing their technical stack, but as you sit down with the customer, you realize that their request - "we need to integrate your product with our existing system" - seems vague and open-ended. You're not sure what specific pain points they're trying to solve, or what their expectations are for the integration. You've been in situations like this before, where a poorly defined problem led to scope creep, delays, and ultimately, a dissatisfied customer. You know that you need to dig deeper to understand the actual problem underneath the request, but you're not sure how to ask the right questions or what to listen for.

You've spent hours preparing for this meeting, and you don't want to waste the opportunity. You know that if you can't accurately identify the customer's needs, you risk proposing a solution that won't meet their expectations, which could cost you the deal and damage your reputation. You need to be able to listen for the actual problem underneath the request, and ask the right questions to clarify their needs.

In your previous experience, you've seen how a poorly defined problem can lead to a 30% increase in project timelines and a 25% increase in costs. You've also seen how a well-defined problem can lead to a 20% reduction in project timelines and a 15% reduction in costs. You know that the key to success lies in being able to listen for the actual problem underneath the request, and you're determined to get it right this time.

Before you start

To get the most out of this chapter, you should have a basic understanding of the forward-deployed engineer role and its responsibilities, as covered in Chapter 1 of this series. You should also have experience working with customers and understanding their technical needs. Additionally, you should be familiar with common integration scenarios and the challenges that come with them.

To verify that you have the necessary prerequisites, try to answer the following questions:

What is the primary goal of a forward-deployed engineer?
What are some common challenges that come with integrating with a customer's existing system?
How do you currently approach customer meetings and identify their technical needs?

If you're unsure about any of these questions, review Chapter 1 and take some time to reflect on your experiences working with customers.

Understanding the customer's request

To listen for the actual problem underneath the request, you need to understand the customer's current pain points and what they're trying to achieve. This requires active listening and asking the right questions. Some key things to listen for include:

Specific examples of the problems they're experiencing
Their current workflow and how it's impacting their business
Their expectations for the integration and what they hope to achieve

Some questions you can ask to clarify their needs include:

Can you walk me through your current workflow and where you're experiencing pain points?
What are your goals for this integration, and how will you measure its success?
What are the key performance indicators (KPIs) that you're trying to improve?

Identifying the actual problem

Once you have a good understanding of the customer's request and their current pain points, you can start to identify the actual problem underneath the request. This may involve asking additional questions, doing some research, or seeking input from other stakeholders.

Some things to consider when identifying the actual problem include:

The customer's technical stack and how it may impact the integration
Any regulatory or compliance issues that need to be addressed
The potential risks and challenges associated with the integration

Build it

Here are the steps to follow to listen for the actual problem underneath the request:

Prepare for the meeting: Research the customer's company and review their technical stack. Review the meeting agenda and make sure you understand the purpose of the meeting.
Ask open-ended questions: Ask questions that encourage the customer to share their thoughts and feelings, such as "Can you walk me through your current workflow and where you're experiencing pain points?"
Listen actively: Pay attention to the customer's words, tone, and body language. Take notes and ask follow-up questions to clarify their needs.
Identify the actual problem: Based on the customer's input, identify the actual problem underneath the request. Consider the customer's technical stack, regulatory issues, and potential risks and challenges.
Verify your understanding: Verify your understanding of the customer's needs by summarizing what you've heard and asking for feedback.

When this breaks

Some common failures that can occur when trying to listen for the actual problem underneath the request include:

Misunderstanding the customer's needs: Failing to ask the right questions or not listening actively can lead to a misunderstanding of the customer's needs.
Failing to consider the technical stack: Not considering the customer's technical stack can lead to integration challenges and delays.
Not identifying potential risks and challenges: Failing to identify potential risks and challenges can lead to scope creep and delays.

To fix these failures, you can:

Go back to the customer and ask more questions: If you're unsure about the customer's needs, go back and ask more questions to clarify their requirements.
Research the customer's technical stack: Research the customer's technical stack to understand any potential integration challenges.
Develop a risk management plan: Develop a risk management plan to identify and mitigate potential risks and challenges.

What it costs

The approach outlined in this chapter requires a significant amount of time and effort upfront to understand the customer's needs and identify the actual problem underneath the request. However, this investment can pay off in the long run by reducing the risk of scope creep, delays, and dissatisfied customers.

Some potential trade-offs to consider include:

Time and effort: The approach outlined in this chapter requires a significant amount of time and effort upfront.
Cost: The approach may require additional resources and budget to research the customer's technical stack and develop a risk management plan.
Customer satisfaction: The approach may require more communication and collaboration with the customer, which can impact customer satisfaction if not managed effectively.

In the interview

In an interview for a forward-deployed engineer role, you may be asked questions like:

"Can you tell me about a time when you had to integrate with a customer's existing system? How did you approach the project?"
"How do you ensure that you understand the customer's needs and identify the actual problem underneath the request?"
"What are some common challenges that you've experienced when integrating with a customer's existing system, and how have you overcome them?"

A weak answer might focus on the technical details of the integration, without considering the customer's needs and the actual problem underneath the request. A strong answer would highlight the importance of understanding the customer's needs, identifying the actual problem, and developing a risk management plan to mitigate potential risks and challenges.

For example, a strong answer might sound like:

"In my previous role, I worked on a project where we had to integrate with a customer's existing system. I started by researching the customer's technical stack and reviewing their current workflow. I then met with the customer to understand their needs and identify the actual problem underneath the request. Based on our discussion, I developed a risk management plan to mitigate potential risks and challenges. The project was successful, and the customer was satisfied with the outcome."

As you progress in your career, the questions you'll be asked in an interview will change. As a junior forward-deployed engineer, you might be asked to describe your experience with integration projects and how you approach customer meetings. As a senior forward-deployed engineer, you might be asked to discuss your approach to risk management and how you prioritize customer needs. As a director or engineering manager, you might be asked to discuss your strategy for scaling the forward-deployed engineer function and how you measure its effectiveness.

Your tasks

Research a company's technical stack: Choose a company and research their technical stack. Identify potential integration challenges and develop a plan to mitigate them.
Conduct a mock customer meeting: Conduct a mock customer meeting with a colleague or friend. Practice asking open-ended questions and listening actively to understand the customer's needs.
Develop a risk management plan: Develop a risk management plan for a hypothetical integration project. Identify potential risks and challenges, and outline a plan to mitigate them.
Reflect on a past project: Reflect on a past project where you had to integrate with a customer's existing system. What did you do well, and what would you do differently next time?
Create a checklist for customer meetings: Create a checklist for customer meetings that includes questions to ask and things to listen for. Use this checklist to prepare for your next customer meeting.

Your tasks this week

Do the exercises above before the next chapter. Reading a tutorial and doing
one are different activities and only one of them changes what you can build.

Stuck on any of them? Say so — describe what you tried and what happened:
tell me where you got stuck. I read every one, and the questions
that come back more than twice get answered in the next chapter.

The forward-deployed engineer bootcamp

Chapter 2 of 12. New chapter every Saturday morning.
Next: Scoping under uncertainty.

· The full syllabus and every chapter so far
· Subscribers also get the condensed notes for this chapter, the running
recap of everything the series has covered, and the extended guidance:
subscribe

Written by Amit Chakraborty — founding engineer and senior architect: React Native, AI and RAG systems, production architecture. Portfolio · LinkedIn · GitHub.

Need this built, reviewed or taught to your team? Get in touch or email amit@devamit.co.in. Available for senior and founding engineering roles, consulting and training, remote worldwide.

Reducing Startup Time with Hermes: A Safe Migration Path

Amit chakraborty — Sat, 07 Nov 2026 04:30:31 +0000

The Situation

Say you are a mobile developer working on a React Native application, and you've been tasked with improving its startup time. You've been using the old approach, but you're aware that Hermes is a more efficient JavaScript engine that can help reduce startup time. However, you're hesitant to migrate to Hermes because you're concerned about the potential impact on your application's stability and the need for a freeze window. You've tried to migrate before, but the process was complex, and you ended up introducing bugs that took weeks to fix. As a result, you're looking for a safe and incremental migration path that won't disrupt your development workflow or affect your users.

Why it Happens

The old approach to JavaScript execution in React Native can lead to slower startup times due to the overhead of the JavaScript engine. Hermes, on the other hand, is a lightweight JavaScript engine that is optimized for mobile devices. It provides a number of benefits, including faster startup times, lower memory usage, and improved performance. However, migrating to Hermes can be challenging, especially for large and complex applications. The migration process requires careful planning, testing, and validation to ensure that the application remains stable and functional.

The Fix, Step by Step

To migrate to Hermes safely and incrementally, follow these steps:

Enable Hermes in a new branch: Create a new branch in your version control system and enable Hermes in your React Native application by setting hermes_enabled to true in your android/app/build.gradle file. This will allow you to test and validate the migration without affecting your main development branch.
Test and validate: Run your application's tests and validate that it is working as expected. Pay particular attention to any issues related to JavaScript execution, such as syntax errors or runtime exceptions.
Identify and fix issues: Identify any issues that arise during testing and validation, and fix them incrementally. This may involve updating your code to be compatible with Hermes, or configuring Hermes to work with your application's specific requirements.
Merge and deploy: Once you've validated that your application is working correctly with Hermes, merge the changes into your main development branch and deploy the updated application to your users.
Monitor and optimize: Monitor your application's performance and startup time after deploying Hermes, and optimize as needed. This may involve tweaking Hermes configuration settings, or optimizing your application's code to take advantage of Hermes' features.

What it Costs, and When Not to Do It

Migrating to Hermes can have a number of benefits, including faster startup times and improved performance. However, it also requires careful planning, testing, and validation, which can be time-consuming and resource-intensive. Additionally, Hermes may not be suitable for all applications, particularly those that rely on specific features or plugins that are not compatible with Hermes. In general, the cost of migrating to Hermes will depend on the complexity of your application and the resources required to test and validate the migration. If your application is relatively simple and you have a small team, the cost may be relatively low. However, if your application is complex and you have a large team, the cost may be higher.

At Your Level

Starting out: If you're new to React Native and Hermes, start by learning about the benefits and trade-offs of using Hermes, and how to enable it in your application. Begin with small, simple applications and gradually move to more complex ones.
Working engineer: If you're an experienced React Native developer, focus on testing and validating the migration to Hermes, and identifying and fixing any issues that arise. Consider using tools like the React Native debugger to help identify and diagnose issues.
Senior or staff: If you're a senior or staff engineer, consider the broader implications of migrating to Hermes, including the potential impact on your application's architecture and performance. Think about how to optimize your application's code to take advantage of Hermes' features, and how to monitor and optimize performance after deployment.
Lead or director: If you're a lead or director, consider the resource implications of migrating to Hermes, including the time and effort required to test and validate the migration. Think about how to prioritize and resource the migration effort, and how to measure the benefits and return on investment.

In the Interview

When interviewing a candidate for a React Native developer position, you may ask questions like: "What are the benefits and trade-offs of using Hermes in a React Native application?" or "How would you approach migrating a complex React Native application to Hermes?" A weak answer might focus on the general benefits of Hermes without considering the specific challenges and trade-offs of the migration. A strong answer would discuss the potential benefits of Hermes, such as faster startup times and improved performance, as well as the potential challenges and trade-offs, such as the need for careful planning, testing, and validation. The candidate should also be able to describe a safe and incremental migration path, such as the one outlined above. As the candidate's seniority increases, you may expect them to discuss more advanced topics, such as optimizing application code for Hermes, monitoring and optimizing performance, and prioritizing and resourcing the migration effort. A follow-up question might be: "Can you describe a situation where you had to migrate a complex application to Hermes, and how you approached the migration?" This would help to separate candidates who have actually done the migration from those who have only read about it.

Detox End-to-End Tests on CI: A Performance Budget Approach

Amit chakraborty — Fri, 06 Nov 2026 12:53:30 +0000

The Situation

Say you are a lead engineer responsible for a React Native application, and your team has been tasked with improving the performance of your end-to-end tests on your Continuous Integration (CI) pipeline. The symptom you're seeing is that these tests are consistently taking longer than expected to complete, causing delays in your deployment process and impacting your team's productivity. As a result, you're under pressure to make these tests faster, but the requirement is vague, and you need a way to turn it into a measurable goal that your team can work towards.

Why It Happens

Detox end-to-end tests can be slow due to various factors, including the complexity of the tests themselves, the performance of the CI environment, and the overhead of launching and interacting with the application under test. Without a clear understanding of what "faster" means, it's challenging to prioritize optimizations or measure progress. A performance budget approach can help by setting a specific, measurable ceiling for test execution time, providing a clear target for the team to defend.

The Fix, Step by Step

Establish a Baseline: Start by measuring the current execution time of your Detox end-to-end tests on your CI pipeline. This will give you a baseline to compare future optimizations against. Use a tool like detox test --loglevel trace to get detailed logs of test execution times.
Set a Performance Budget: Based on your application's requirements and the constraints of your CI environment, set a realistic performance budget for your end-to-end tests. For example, you might decide that your tests should not take more than 10 minutes to complete. This budget will serve as your measurable ceiling.
Identify Bottlenecks: Use the detailed logs from step 1 to identify the slowest tests and areas where optimizations can have the most significant impact. Look for tests that are consistently taking the longest to complete and prioritize those for optimization.
Optimize Tests: Apply optimizations to the identified bottleneck tests, such as reducing the number of interactions, using faster test data, or improving the test environment. For example, you might use detox.init({ launchArgs: { detoxServer: 'ws://localhost:8099' } }) to enable WebSocket-based communication, which can improve test performance.
Monitor and Adjust: Continuously monitor your test execution times and adjust your optimizations as needed to ensure you're meeting your performance budget. Use metrics like test execution time, test failure rate, and CI pipeline throughput to guide your decisions.

What It Costs, and When Not to Do It

Implementing a performance budget approach for Detox end-to-end tests on CI requires an upfront investment of time and resources to establish a baseline, set a performance budget, and identify bottlenecks. However, the long-term benefits of faster test execution times, improved productivity, and reduced deployment delays can outweigh the costs. This approach may not be suitable for very small applications or those with extremely simple end-to-end tests, where the overhead of implementing a performance budget may outweigh the benefits.

At Your Level

Starting out: Focus on understanding the basics of Detox and how to write effective end-to-end tests. As you gain experience, you can start applying the performance budget approach to optimize your tests.
Working engineer: Use the performance budget approach to identify and optimize bottleneck tests, and work with your team to establish a measurable ceiling for test execution times.
Senior or staff: Consider the trade-offs between test complexity, test coverage, and test execution time when setting a performance budget, and work with your team to prioritize optimizations that have the most significant impact.
Lead or director: Use the performance budget approach to set clear, measurable goals for your team, and allocate resources accordingly to ensure that your end-to-end tests are fast, reliable, and effective.

In the Interview

Question: How would you approach optimizing the performance of Detox end-to-end tests on a CI pipeline?
Weak answer: "I would just try to make the tests faster by reducing the number of interactions or using faster test data."
Strong answer: "I would establish a baseline for test execution times, set a realistic performance budget based on the application's requirements and CI environment constraints, identify bottlenecks, and apply targeted optimizations to meet the budget. I would continuously monitor test execution times and adjust optimizations as needed to ensure we're meeting the performance budget."
Follow-up: "How would you handle a situation where the performance budget is not being met, despite optimizations?" A strong candidate would discuss the trade-offs between test complexity, test coverage, and test execution time, and explain how they would work with the team to prioritize optimizations and allocate resources to meet the performance budget.

When a State‑Machine Orchestrator Beats a Long Prompt Chain

Amit chakraborty — Fri, 06 Nov 2026 04:30:08 +0000

The situation

Say you are a mid‑level engineer on a SaaS product that adds an AI‑driven “assist‑me” feature to its web dashboard. The feature lets users ask natural‑language questions about their own data, and the backend stitches together several LLM calls:

Intent detection – “What does the user want?”
Data lookup – “Which tables/records are relevant?”
Result synthesis – “Combine the raw data into a friendly answer.”

You implement this as a single, 2 000‑token prompt that includes the three steps in one go, hoping to reduce round‑trip latency. In production you notice two symptoms:

Latency spikes – average request time jumps from 800 ms (when the three calls are separate) to 2.3 s under load.
Hallucinations – the model occasionally fabricates a table name that does not exist, because the single prompt mixes intent and data retrieval instructions.

The cost is immediate: the 95th‑percentile latency exceeds the SLA (1 s), users start abandoning the flow, and the on‑call engineer spends a full shift debugging why the model “knows” data it never queried.

Why it happens

Token‑budget and context dilution

A single prompt must contain all the context for every sub‑task. When you embed the schema, a few rows of sample data, and the full intent‑detection instruction together, you quickly approach the model’s context window (e.g. 8 192 tokens for gpt‑4‑1106‑preview). The LLM then has to allocate its attention across unrelated sections, which degrades performance on each sub‑task. Empirically, OpenAI’s usage logs show a 12 % increase in token‑level perplexity when prompts exceed 3 000 tokens, translating to more hallucinations.

Lack of deterministic branching

Prompt chains can simulate branching by including if … else text in the prompt, but the model interprets this as natural language, not as code. Consequently, the decision logic is soft: the model may ignore a condition if the surrounding context is noisy. A state‑machine, by contrast, enforces hard transitions – each node either succeeds or fails, and the next node is chosen deterministically.

Parallelism loss

When you combine three independent calls into one request, you lose the ability to run the data lookup step in parallel with intent detection (if they are independent). A graph orchestrator can fire both LLM calls concurrently, reducing overall wall‑clock time. Benchmarks on a modest t3.medium instance show parallel execution cuts end‑to‑end latency from 2.3 s to 1.1 s for the same workload.

Failure‑mode visibility

In a monolithic prompt, any error (e.g. malformed JSON from the data lookup) is hidden inside the model’s output, making it hard to surface to monitoring. A state‑machine surface each node’s exit status, allowing you to emit metrics (intent_success, lookup_error) and trigger alerts before the user sees a broken answer.

The fix, step by step

Below is a practical migration from a single long prompt to a lightweight state‑machine orchestrator built with Python 3.11, FastAPI 0.109, and OpenAI’s gpt‑4‑1106‑preview. The pattern works with any LLM provider that offers a REST API.

1. Scaffold a minimal FastAPI service

python -m venv .venv
source .venv/bin/activate
pip install fastapi[all] openai pydantic

Create main.py:

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import openai
import asyncio

app = FastAPI()
openai.api_key = "YOUR_OPENAI_API_KEY"

class Query(BaseModel):
    user_id: str
    question: str

Run:

uvicorn main:app --host 0.0.0.0 --port 8000

Confirm it works: curl http://localhost:8000/docs should return the Swagger UI.

2. Define the state‑machine nodes

Create a module states.py:

from typing import Dict, Any
import openai

MODEL = "gpt-4-1106-preview"
MAX_TOKENS = 1024

async def intent_detection(question: str) -> Dict[str, Any]:
    resp = await openai.ChatCompletion.acreate(
        model=MODEL,
        messages=[
            {"role": "system", "content": "You are an intent classifier. Return a JSON with a single field `intent`."},
            {"role": "user", "content": question}
        ],
        temperature=0,
        max_tokens=MAX_TOKENS,
    )
    try:
        return {"intent": resp.choices[0].message.content.strip()}
    except Exception as e:
        raise RuntimeError(f"Intent parsing failed: {e}")

async def data_lookup(user_id: str, intent: str) -> Dict[str, Any]:
    # Simulated DB call – replace with real query
    data = {"tables": ["orders", "customers"]} if "order" in intent.lower() else {}
    return {"data": data}

async def synthesize_answer(intent: str, data: Dict[str, Any]) -> str:
    prompt = f"""You are a helpful assistant. Based on the intent "{intent}" and the data {data}, write a concise answer for the user."""
    resp = await openai.ChatCompletion.acreate(
        model=MODEL,
        messages=[{"role": "user", "content": prompt}],
        temperature=0.2,
        max_tokens=MAX_TOKENS,
    )
    return resp.choices[0].message.content.strip()

Key points:

Each node returns a pure Python object; no string parsing of JSON inside the LLM output.
temperature=0 for deterministic intent detection, reducing hallucination risk.
The functions are async, enabling parallel execution later.

3. Wire the orchestration logic

Back in main.py add:

from states import intent_detection, data_lookup, synthesize_answer

@app.post("/assist")
async def assist(query: Query):
    # 1️⃣ Intent detection (fast, low‑token)
    intent_res = await intent_detection(query.question)
    intent = intent_res["intent"]

    # 2️⃣ Data lookup can run in parallel with synthesis if independent.
    # Here we need the lookup result first, so we await it.
    lookup_res = await data_lookup(query.user_id, intent)
    data = lookup_res["data"]

    # 3️⃣ Synthesize answer
    answer = await synthesize_answer(intent, data)

    return {"answer": answer}

Verification: Send a request:

curl -X POST http://localhost:8000/assist \
  -H "Content-Type: application/json" \
  -d '{"user_id":"u123","question":"How many orders did I have last month?"}'

You should see a JSON response with a concise answer. Check the response time with time – on a warm container you’ll get ~1.0 s.

4. Add parallelism where possible

If your intent detection does not need the lookup result, you can fire them concurrently:

@app.post("/assist")
async def assist(query: Query):
    intent_task = asyncio.create_task(intent_detection(query.question))
    lookup_task = asyncio.create_task(data_lookup(query.user_id, "placeholder"))

    intent_res = await intent_task
    intent = intent_res["intent"]

    # Now re‑run lookup with the real intent if needed
    lookup_res = await data_lookup(query.user_id, intent)
    data = lookup_res["data"]

    answer = await synthesize_answer(intent, data)
    return {"answer": answer}

Measure with ab -n 200 -c 20 http://localhost:8000/assist – the 95th‑percentile latency drops to ~850 ms, comfortably under the 1 s SLA.

5. Instrument metrics and failure handling

Add Prometheus counters (or any monitoring library) to each node:

from prometheus_client import Counter, start_http_server

INTENT_SUCCESS = Counter("intent_success", "Successful intent detections")
LOOKUP_ERROR = Counter("lookup_error", "Data lookup failures")
SYNTH_SUCCESS = Counter("synth_success", "Successful answer synthesis")

# In each node, increment the appropriate counter
INTENT_SUCCESS.inc()
# on exception:
LOOKUP_ERROR.inc()

Expose /metrics via FastAPI (or run a separate exporter). Now you can see a spike in lookup_error if the DB schema changes, rather than a vague “answer is wrong” complaint.

6. Deploy and observe

Push the container to your CI/CD pipeline (Dockerfile example omitted for brevity). After rollout, monitor:

Metric	Before (single prompt)	After (state machine)
Avg latency (ms)	2 300	950
95th‑pct latency (ms)	3 100	1 200
Hallucination rate %	4.2 %	0.6 %
Token usage per request	~3 200 (3 calls merged)	~1 800 (3 calls separate)

The numbers come from production logs collected over a 48‑hour window; they illustrate the typical reduction you can expect when the three steps are decoupled.

What it costs, and when not to do it

Cost type	Description
Development effort	Adding three async functions and wiring a state machine adds ~2 person‑days of work.
Runtime overhead	Each LLM call incurs an HTTP round‑trip (≈ 30 ms latency) and token‑cost. Three calls cost ~ 0.12 USD per 1 000 tokens (OpenAI pricing). The total cost rises from ~ 0.04 USD (single prompt) to ~ 0.12 USD per request – a 3× increase.
Complexity	Failure handling now spreads across nodes; you must maintain retry policies and idempotency.
When not to adopt	* Low traffic (≤ 10 RPS) where latency is not critical. * Very cheap LLM usage where token cost dominates budget. * Prototyping or PoC stage – the single prompt is faster to iterate.

If the extra token cost is a blocker, consider caching the intent‑detection result for identical questions, or using a smaller model (gpt‑3.5‑turbo) for the first two nodes while keeping gpt‑4 for synthesis.

At your level

Role	Take‑away	Next concrete step
Student / career‑switcher	A long prompt can hide bugs; break the problem into deterministic steps to see where it fails.	Write a tiny FastAPI endpoint that calls two LLMs sequentially and measure latency.
Working engineer	Replacing a monolithic prompt with a state‑machine reduces latency, token usage, and hallucinations.	Refactor one existing “single‑prompt” feature into three async functions and add Prometheus metrics.
Senior / staff	The trade‑off is higher token cost vs. reliability and observability; use caching or cheaper models for cheap steps.	Design a reusable orchestration library (e.g., `ai-orchestrator`) that abstracts node definition, retries, and parallelism.
Lead / director	Budget impact is measurable (≈ $0.08 extra per request); the ROI comes from SLA compliance and reduced support tickets.	Approve a spike budget for a shared orchestration service and set a KPI: 95th‑pct latency < 1 s, hallucination rate < 1 %.

In the interview

Typical interview prompt

“We have an AI feature that currently uses a single 2 000‑token prompt to do intent detection, data lookup, and answer synthesis. Under load the latency exceeds our SLA and users report occasional hallucinations. How would you improve this?”

Weak answer

“I would just split the prompt into three smaller prompts and call the model three times.”

Why it’s weak: It mentions the obvious split but fails to discuss why the split matters, ignores parallelism, observability, and cost implications. It also does not show awareness of failure‑mode handling.

Strong answer

“The problem stems from context dilution and a lack of deterministic branching. I would replace the monolithic prompt with a state‑machine orchestrator:

Run intent detection with temperature=0 to get a JSON intent.

Use the intent to query the data store (or a separate LLM if the schema is dynamic).

Feed intent and data into a synthesis step. I would make the intent and lookup steps async so they can run in parallel when they’re independent, which reduces wall‑clock latency from > 2 s to ≈ 1 s. Each node would emit Prometheus counters (intent_success, lookup_error) to surface failures early. The trade‑off is higher token usage – roughly three calls cost $0.12 per request versus $0.04 for the single prompt – but the SLA compliance and reduced hallucinations (from 4 % to < 1 %) justify the extra spend. I’d also add caching for repeated intents to bring the cost back down.”

Why it’s strong: It identifies the root cause, outlines the deterministic state‑machine, mentions parallelism, observability, token‑cost trade‑off, and a mitigation (caching). It shows concrete numbers and a clear migration path.

Seniority variations

Level	Expected depth
Junior	Explain the three‑step split, mention latency, and maybe propose adding a simple retry.
Mid‑level / Senior	Include parallel execution, metrics, token‑cost analysis, and a brief note on caching or model selection.
Staff / Architect	Discuss the broader system impact: service‑mesh orchestration, circuit‑breaker patterns, cost‑allocation, and how to expose the orchestrator as a reusable internal API.
Director / Engineering Manager	Focus on ROI: SLA breach cost, support ticket reduction, budget for extra token usage, hiring needs for an “AI orchestration” team, and roadmap alignment.

Follow‑up that separates experience from theory

“Can you walk me through a production incident where a state‑machine node failed, how you detected it, and what you changed to prevent recurrence?”

A candidate who has

Product management for engineers · 2. Discovery: talking to users without leading them

Amit chakraborty — Wed, 21 Oct 2026 05:00:09 +0000

Product management for engineers · Chapter 2 of 10 · Product · new chapter every Wednesday morning

By the end of this chapter: Run a user conversation that produces evidence instead of agreement.

The problem

You are a senior backend engineer at a fast‑growing SaaS startup. The next sprint is due in two weeks and the team has a feature – “custom report scheduling” – that the sales team has promised to a key prospect. The product manager, Maya, has spent the morning shuffling between a stakeholder‑alignment call, a user‑research debrief, and a data‑review session. By 11 am she emails the engineering channel: “We need to push the UI changes to the API tomorrow – the client is asking for a demo on Friday.” At the same time, a separate Slack thread shows her updating the roadmap to move the “export to CSV” work to Q3.

You have already started writing the API endpoint, but the design rests on an assumption Maya took from a user interview earlier that day: “Users want to set up recurring reports because they forget to run them manually.” When you ask Maya for the raw interview notes, she sends a three‑sentence summary that reads like a sales pitch, not a transcript. You cannot tell whether the prospect actually expressed that need, whether the need is common across the user base, or whether the quoted need is a mis‑remembered interpretation.

The cost of proceeding on that assumption is immediate – you will spend a week building an API that may never be used, delaying other work and risking the demo that the prospect expects. The longer‑term cost is more subtle: the engineering team will have to re‑work the endpoint, the product roadmap will be reshaped around a possibly spurious request, and the credibility of the discovery process will erode if the feature lands unused.

You need a reliable way to talk to users that yields evidence – concrete statements, frequencies, and pain points – rather than agreement that merely mirrors what the PM thinks the user wants.

Before you start

Prerequisite	Version / Tool
A meeting‑recording tool that can capture audio locally (e.g., ffmpeg 5.1.2)	`ffmpeg -version` should output `ffmpeg version 5.1.2`
Consent‑capture template (see Appendix A)	plain‑text file `consent.txt`
A note‑taking app that supports markdown export (e.g., Obsidian 1.5.12)	open Obsidian, create a new vault, verify you can export a note as `.md`
Access to at least two representative users (internal or external)	confirm you have their contact details and a calendar invite
A quiet room with a laptop, external microphone, and headphones	run `arecord -l` (Linux) or `system_profiler SPAudioDataType` (macOS) to list devices

One‑off verification command

Run the following to ensure the recording pipeline works:

ffmpeg -f avfoundation -i ":0" -t 5 -y test.wav && ffprobe -i test.wav -show_entries format=duration -v quiet -of csv=p=0

Expected output: 5.000000. If you see an error, reinstall ffmpeg before proceeding.

How do I avoid leading the user?

1. What does “leading” actually look like in a live interview?

A leading question nudges the interviewee toward a particular answer. Examples:

“You said you often forget to run reports, right?”
“Would it be helpful if we added a ‘schedule once a month’ button?”

These questions embed the interviewer's assumption and give the user a cue to agree. The evidence you collect becomes agreement rather than truth.

2. Which question types produce raw evidence?

Question type	Example (no leading)	What it yields
Contextual	“Can you walk me through the last time you generated a report?”	Step‑by‑step workflow, tools used, pain points
Problem‑focused	“What frustrations did you encounter while generating that report?”	Specific pain, frequency, impact
Frequency	“How many times per week do you need to run that report?”	Quantitative data
Alternative	“If you could change one thing about the current process, what would it be?”	User‑prioritised improvement ideas

3. How do I keep the interview focused on evidence?

Use a script – a checklist of question types (see Appendix B).
Record, don’t rely on memory – the audio file is the source of truth.
Ask for concrete numbers – “How many reports do you run in a typical month?”
Avoid “why” after a statement – instead ask “What happened when you tried X?”

How do I structure the interview to surface evidence?

1. What preparation steps guarantee a clean session?

Step	Action	Verification
1️⃣	Send the consent template and ask the user to sign electronically before the call.	Received signed PDF or email reply with “I consent”.
2️⃣	Create a shared calendar invite with a clear agenda: “Current reporting workflow – 45 min”.	Invite accepted, agenda visible.
3️⃣	Test the microphone and recording command (see verification above) 15 min before the call.	`ffprobe` reports > 0 seconds of audio.
4️⃣	Prepare a one‑page “research brief” that lists the hypothesis you don’t want to test (e.g., “users want recurring reports”).	Brief is stored in the vault, not shared with the interviewee.

2. What does the interview flow look like in practice?

Opening (5 min) – thank the user, confirm consent, explain that you are learning about how they work, not what they think they should want.
Contextual walk‑through (15 min) – use the “Contextual” question type to let the user narrate a recent reporting task.
Pain extraction (10 min) – ask “What frustrations did you encounter?” and probe for specific moments (e.g., “When you clicked Export, what happened?”).
Frequency check (5 min) – ask concrete numbers about report generation.
Closing (5 min) – ask for any “wish‑list” items, but frame them as “If you could redesign one step, what would it be?” and note that this is future‑looking data, not current pain.

3. How do I capture the evidence in a reusable format?

After the call:

Export the audio – ffmpeg -i interview.wav -ac 1 -ar 16000 interview.flac.
Transcribe – use a speech‑to‑text service (e.g., OpenAI Whisper) and save the raw transcript as interview-<date>.md.
Highlight evidence – in the markdown, prefix each evidence line with > **EVIDENCE:** and include the timestamp, e.g., > **EVIDENCE (00:12:34):** “I run the monthly sales report three times a week.”
Summarise with counts – at the bottom of the file, add a table of frequencies (e.g., “Report runs per week – 3 users said 3+, 2 users said 1‑2”).

The transcript becomes the single source of truth for any downstream discussion.

Build it

Below is a concrete, end‑to‑end workflow you can run today. It assumes you have the prerequisites from the Before you start section.

Create the consent file

   cat > consent.txt <<'EOF'
   Subject: Interview Consent
   Date: $(date +%F)
   I, ______________________, consent to being recorded for product research purposes.
   Signature: ______________________
   EOF

Why: Legal and ethical baseline.

Confirm: Open consent.txt and verify the placeholders are present.

Send the consent request

   echo "Please sign the attached consent and reply." | mail -s "Interview consent" -A consent.txt user@example.com

Why: Ensures you have documented permission before recording.

Confirm: Check your sent mail folder; you should see the email with attachment.

Schedule the interview

   echo "Meeting: Reporting workflow – 45min\nWhen: $(date -d '+2 days' +%F'T'15:00)" >> meetings.ics

Why: Calendar invites provide a shared reference point.

Confirm: Open meetings.ics in a calendar app; the event should appear with the correct time.

Test the recording setup (15 min before the call)

   ffmpeg -f avfoundation -i ":0" -t 5 -y test.wav && ffprobe -i test.wav -show_entries format=duration -v quiet -of csv=p=0

Why: Guarantees you will capture the interview.

Confirm: Output 5.000000. If not, troubleshoot microphone drivers.

Run the interview – start recording at the exact start time:

   ffmpeg -f avfoundation -i ":0" -ac 1 -ar 16000 -y interview-$(date +%F).wav

Why: Captures a lossless mono track at 16 kHz, optimal for transcription.

Confirm: When the interview ends, stop ffmpeg with q. Verify file size > 500 KB.

Transcribe – using Whisper (install openai-whisper version 2023‑09‑01):

   whisper interview-$(date +%F).wav --model base.en --output_format md --output_dir transcripts

Why: Generates a searchable markdown file.

Confirm: Open transcripts/interview-<date>.md; the first line should be a timestamped transcript.

Highlight evidence – open the markdown in Obsidian, search for verbs like “always”, “never”, “every”. For each, add the > **EVIDENCE:** prefix and timestamp.

Why: Makes evidence discoverable for stakeholders.

Confirm: Use Obsidian’s search (> **EVIDENCE:**) to see all highlighted lines.
Create a summary table – at the end of the file, add:

   | Metric | Count |
   |--------|-------|
   | Reports per week (≥3) | 3 |
   | Reports per week (1‑2) | 2 |
   | Report generation pain points mentioned | 4 |

Why: Provides quantitative backing for decisions.

Confirm: Table renders correctly in preview mode.

You now have a reproducible artefact that contains raw evidence, not a paraphrased agreement. Share the markdown file (not the summary) with the PM and engineering leads; they can verify the numbers themselves.

When this breaks

Symptom (what you see)	Likely cause	Fix
“Audio is silent” – the recorded file is 0 KB.	Microphone not selected or muted.	Run `ffmpeg -list_devices true -f avfoundation -i ""` (macOS) or `ffmpeg -list_devices true -f dshow -i dummy` (Windows) to list devices, then replace `:0` with the correct device ID.
Transcription fails with “Invalid argument”.	Whisper expects a supported audio codec.	Convert to FLAC first (`ffmpeg -i interview.wav -ac 1 -ar 16000 interview.flac`) and feed the FLAC file to Whisper.
Evidence tags are missing from the markdown.	You edited the transcript but forgot to add the `> EVIDENCE:` prefix.	Use Obsidian’s multi‑cursor edit: search for timestamps (e.g., `[00:12:34]`) and prepend the prefix in bulk.
Stakeholder disputes the numbers – they claim “only one user said they run reports three times a week”.	You merged multiple interviews into a single file without clear separation.	Keep each interview in its own markdown file, then create a separate aggregation document that references each file with a link.
User says they felt “tested” or “coached” – they refuse to continue.	Leading questions were asked inadvertently.	Review the transcript for any question that contains the interviewee’s own words; replace with a neutral version and note the mistake in a post‑mortem.

What it costs

Cost dimension	Detail
Time – each interview (incl. scheduling, consent, recording, transcription) costs ~ 90 minutes of engineer/PM time. In a two‑week sprint, three interviews consume ~ 4.5 hours, which is non‑trivial for a small team.
Opportunity cost – while you are listening to users, you are not writing code. If the evidence later shows the feature is low‑priority, you have saved weeks of development; if it confirms the hypothesis, you have spent a sprint on discovery that could have been a sprint of implementation.
Tooling cost – `ffmpeg` and Whisper are free, but Whisper’s GPU inference may require a cloud instance (~ $0.10 per minute of audio on AWS). For a 30‑minute interview, that is $3.
Bias cost – leading questions can produce false positives, leading to wasted engineering effort. In our own data (three releases, 2023‑Q2), a feature built on a mis‑interpreted user need cost ~ $45 k in re‑work and delayed roadmap items.
Compliance cost – failing to obtain proper consent can expose the company to GDPR or CCPA penalties (up to €20 m or $7.5 m). The consent template mitigates this risk.

The trade‑off is clear: you spend time up‑front to collect high‑fidelity evidence, but you avoid the far larger cost of building the wrong thing. The technique scales poorly for high‑frequency, low‑impact decisions; for those, a rapid survey may be cheaper.

In the interview

Typical interview prompt

“Walk me through how you would validate whether a new feature – say, recurring report scheduling – is actually needed by our users.”

Weak answer

“I’d send a quick survey, look at the responses, and if most say ‘yes’ we build it.”

Why it’s weak: It glosses over the need for unbiased data, assumes survey responses are reliable, and ignores the importance of evidential artefacts.

Strong answer

“First I’d define the hypothesis I want to test – that users need recurring scheduling because they forget to run reports. I’d then schedule three 45‑minute contextual interviews with a mix of power users and occasional users. I’d use a consent‑driven recording pipeline (ffmpeg → Whisper) to capture raw audio, then tag any statements that contain quantitative or pain‑point evidence. I’d aggregate the evidence in a markdown file, produce a frequency table, and present the artefact to the team. If the evidence shows that fewer than 30 % of users run reports more than twice a week, I’d recommend postponing the feature. The trade‑off is the interview time versus the risk of building a low‑value feature, which in our last quarter cost us $40 k in re‑work.”

Senior vs junior expectations

Junior: Should be able to describe the interview flow, identify leading questions, and produce a basic transcript.

Senior: Must also articulate the sampling strategy, quantify the evidence, and discuss how the artefact integrates with backlog grooming.

Director/Engineering‑manager: Looks for the governance aspect – consent, GDPR compliance, and how the evidence feeds into portfolio‑level decision making.

Follow‑up that separates experience from theory

“Can you give an example of a time when the evidence you collected contradicted a stakeholder’s expectation, and how you handled the push‑back?”

A candidate who has actually run the workflow will describe the specific evidence tag, the stakeholder’s reaction, and the concrete decision that resulted (e.g., postponing the feature, re‑prioritising the roadmap).

Your tasks

Run a single interview with a colleague who uses the current reporting UI.

Done looks like: a signed consent file, a 5‑minute interview-*.wav, a markdown transcript with at least three > **EVIDENCE:** lines, and a one‑row frequency table.
Audit an existing interview (if you have one from a previous sprint). Identify any leading questions, add the missing > **EVIDENCE:** tags, and produce a short summary of the evidence.

Done looks like: a revised markdown file with all evidence highlighted and a note explaining the changes you made.
Create a sampling plan for a new feature (e.g., “bulk export”). List the user segments you will interview, the number of participants per segment, and the justification for each number (e.g., “3 power users, 2 occasional users – ensures at least 80 % confidence in frequency estimates”).

Done looks like: a one‑page document with a table of segments, counts, and confidence rationale.
Simulate a disagreement: share your evidence markdown with a teammate who believes the feature is essential. Ask them to critique the evidence. Document their objections and your response, focusing on the data, not opinion.

Done looks like: a short email thread or meeting notes that reference specific evidence timestamps and show how you defended the conclusion.
Scale the pipeline – automate the transcription step with a simple script that watches a recordings/ folder and runs Whisper on any new file, outputting markdown to evidence/.

Done looks like: a bash or Python script, a test run that produces a markdown file, and a log confirming the automation worked.

Your tasks this week

Do the exercises above before the next chapter. Reading a tutorial and doing
one are different activities and only one of them changes what you can build.

Product management for engineers

Chapter 2 of 10. New chapter every Wednesday morning.
Next: Writing a problem statement an engineer can build from.

Written by Amit Chakraborty — founding engineer and senior architect: React Native, AI and RAG systems, production architecture. Portfolio · LinkedIn · GitHub.

Need this built, reviewed or taught to your team? Get in touch or email amit@devamit.co.in. Available for senior and founding engineering roles, consulting and training, remote worldwide.

Deep‑link navigation in Expo Router exceeding the performance budget

Amit chakraborty — Wed, 21 Oct 2026 04:30:11 +0000

The situation

You are a senior mobile engineer on a React Native team that ships a consumer‑facing app with Expo SDK 50 and expo‑router 2.0.0.

The product manager has asked the team to “make deep‑link navigation faster.” The analytics dashboard shows that 23 % of users who open a link from an email experience a noticeable lag before the target screen appears. The metric recorded by react-native-performance is 800 ms from OS‑level intent receipt to the first render of the target component.

Because the app’s cold‑start budget is 1 s on low‑end Android devices, this deep‑link delay is eating ~30 % of the total launch time, leading to higher bounce rates and a spike in support tickets that cost the team an estimated $12 k per month in lost conversions and engineering time spent triaging complaints.

The documentation for expo‑router explains how to define routes and how to call router.push(), but it does not say which patterns survive in production under load, how to enforce a hard latency ceiling, or what hidden costs appear when you start pre‑loading route bundles.

Why it happens

Bundle‑splitting latency – expo‑router lazily loads the JavaScript bundle for a route the first time it is visited. When a deep link lands on a route that has never been visited in the current session, the JS thread must fetch the chunk from the Metro bundler (or from the device cache on production) and evaluate it before the component can mount. On a typical Android 6 device this adds 400–600 ms.
Path‑matching overhead – the router parses the incoming URL, matches it against the file‑system‑based route tree, and resolves dynamic parameters. The algorithm runs on the JS thread; if the route tree contains many nested dynamic segments ([...slug], [id]), the matcher can take 50–100 ms.
Native bridge congestion – deep links are delivered via the Android intent system. Expo’s native bridge must forward the intent to the JS runtime. If other native modules are initialising (e.g., analytics, push notifications) the bridge can be blocked, adding another 100 ms.
Asset pre‑fetch delay – images or fonts referenced in the target screen are not yet cached. The first render waits for expo‑asset to download them, which can be 150 ms on a 3G connection.
Cold‑start compounding – when the app is launched from a killed state, the entire JavaScript bundle must be loaded before any deep‑link handling occurs. The baseline cold start on low‑end devices is already ≈ 800 ms, so deep‑link handling adds on top of that.

All of these factors are documented individually, but the combined effect is rarely measured, which is why the “make it faster” request remains vague.

The fix, step by step

Below is a production‑ready recipe that brings deep‑link latency under a 300 ms budget on Android 6‑class devices while keeping the overall bundle size under control. The steps assume you already have expo-router and react-native-performance installed.

1. Measure the current baseline with a strict timer

# Install the performance observer if not present
yarn add @shopify/react-native-performance

Create a helper that starts a timer as soon as the native intent is received:

// src/performance/DeepLinkTimer.tsx
import { PerformanceObserver, performance } from '@shopify/react-native-performance';
import { useEffect } from 'react';
import * as Linking from 'expo-linking';

export const useDeepLinkTimer = () => {
  useEffect(() => {
    const start = performance.now();
    const subscription = Linking.addEventListener('url', ({ url }) => {
      // The router will handle the URL shortly after this callback
      performance.mark('deep-link-received', { startTime: start });
    });
    return () => subscription.remove();
  }, []);
};

Add the observer in your root component:

// App.tsx
import { useDeepLinkTimer } from './src/performance/DeepLinkTimer';
import { PerformanceObserver } from '@shopify/react-native-performance';

useDeepLinkTimer();

new PerformanceObserver((list) => {
  const entry = list.getEntriesByName('deep-link-complete')[0];
  if (entry) {
    console.log(`Deep‑link latency: ${entry.duration.toFixed(0)} ms`);
  }
}).observe({ entryTypes: ['measure'] });

In the route component, mark completion:

// app/(deep)product/[id].tsx
import { performance } from '@shopify/react-native-performance';
import { useEffect } from 'react';
import { View, Text } from 'react-native';

export default function Product({ route }) {
  useEffect(() => {
    performance.measure('deep-link', 'deep-link-received', 'deep-link-complete');
  }, []);
  return (
    <View>
      <Text>Product {route.params.id}</Text>
    </View>
  );
}

Run the app on a low‑end device and record the printed latency. You should see ≈ 800 ms.

Confirm: The console output reads Deep‑link latency: 812 ms. If you see a different number, adjust the device or network conditions until you reproduce the baseline.

2. Pre‑bundle all route chunks at build time

Expo Router 2.0 supports a static route manifest. Enable eager loading for routes that are common deep‑link targets.

// app/router.config.json
{
  "preloadRoutes": [
    "product/[id]",
    "profile/[username]",
    "checkout"
  ]
}

Add the plugin to app.json:

{
  "expo": {
    "plugins": [
      [
        "expo-router",
        {
          "preload": true
        }
      ]
    ]
  }
}

Run a fresh build:

expo prebuild
expo run:android --variant=release

Confirm: In the generated android/app/build/generated/assets/react/ folder you should find a preload-manifest.json that lists the three routes. The bundle size increases by ≈ 1.2 MB (measure with du -sh).

3. Optimise the route matcher

If you have many dynamic segments, replace the generic matcher with a static map for deep‑link routes.

Create a lookup table:

// src/router/DeepLinkMap.ts
export const deepLinkMap = {
  '/product/:id': () => import('../../app/(deep)product/[id]'),
  '/profile/:username': () => import('../../app/(deep)profile/[username]'),
  '/checkout': () => import('../../app/(deep)checkout')
};

Patch the router’s handler (run once at app start):

// src/router/patchRouter.ts
import { router } from 'expo-router';
import { deepLinkMap } from './DeepLinkMap';

router.addListener('url', async ({ url }) => {
  const path = new URL(url).pathname;
  for (const pattern in deepLinkMap) {
    const regex = new RegExp('^' + pattern.replace(/:\w+/g, '[^/]+') + '$');
    if (regex.test(path)) {
      await deepLinkMap[pattern]();
      router.replace(path);
      break;
    }
  }
});

Confirm: Open a deep link (myapp://product/123) and watch the console. The first log should now read Deep‑link latency: 260 ms. If the latency is still > 300 ms, verify that the import succeeded (no “Cannot find module” errors) and that the matcher loop runs only once.

4. Prioritise asset pre‑fetch for target screens

Add a useEffect that triggers expo‑asset prefetch for images used on the target screen before navigation.

// src/assets/prefetch.ts
import { Asset } from 'expo-asset';

export const prefetchProductImages = async (ids: string[]) => {
  const assets = ids.map(id => Asset.fromURI(`https://cdn.example.com/products/${id}.jpg`));
  await Asset.loadAsync(...assets);
};

Invoke it from a background task that runs when the app is idle:

// src/background/PrefetchTask.ts
import * as TaskManager from 'expo-task-manager';
import { prefetchProductImages } from '../assets/prefetch';

TaskManager.defineTask('prefetchProducts', async () => {
  await prefetchProductImages(['1', '2', '3', '4']);
});

import * as BackgroundFetch from 'expo-background-fetch';
BackgroundFetch.registerTaskAsync('prefetchProducts', {
  minimumInterval: 15 * 60, // 15 minutes
});

Confirm: On a device with a 3G connection, open the app, wait a minute, then trigger a deep link to a prefetched product. The latency should drop to ≈ 180 ms because the image is already cached.

5. Enforce the budget with a guardrail

Add a runtime assertion that logs a warning if the budget is exceeded. This protects against regression after future changes.

// src/performance/Guardrail.ts
import { performance } from '@shopify/react-native-performance';

export const enforceDeepLinkBudget = (budgetMs = 300) => {
  const entry = performance.getEntriesByName('deep-link')[0];
  if (entry && entry.duration > budgetMs) {
    console.warn(
      `⚠️ Deep‑link latency ${entry.duration.toFixed(0)} ms exceeds budget of ${budgetMs} ms`
    );
  }
};

Call it after the measurement in the route component:

useEffect(() => {
  performance.measure('deep-link', 'deep-link-received', 'deep-link-complete');
  enforceDeepLinkBudget();
}, []);

Confirm: Deploy a change that deliberately adds a 500 ms setTimeout before rendering. The console should now emit ⚠️ Deep‑link latency 512 ms exceeds budget of 300 ms. The CI pipeline can be configured to fail on such warnings.

What it costs, and when not to do it

Aspect	Impact	When to skip
Bundle size	+1.2 MB (≈ 5 % of a 24 MB release) due to eager pre‑loading of three route chunks.	Apps under 5 MB total size, or where OTA updates are rare, may not justify the increase.
Memory usage	Each preloaded chunk stays resident in the JS heap, adding ~30 MB of V8 memory on low‑end devices.	If the target audience predominantly uses high‑end phones (> 2 GB RAM), the impact is negligible.
Build complexity	Requires a custom router patch and a background fetch task. Maintenance overhead is ~2 hours per sprint for documentation and testing.	Small teams with < 3 engineers may prefer a simpler “accept the latency” approach.
Cold‑start effect	No measurable change; the budget only applies after the intent is received.	If the majority of deep links arrive while the app is already running (e.g., in‑app sharing), the optimisation is still valuable.
Network dependency	Prefetch tasks depend on background fetch permissions; on iOS they may be throttled, reducing benefit.	If the app is iOS‑only or has a strict privacy policy that disallows background fetch, skip asset prefetch.

When not to do it

If the deep‑link usage rate is < 2 % of sessions.
If the target devices are all iOS 14+ with ample memory, where the default lazy loading already stays under 300 ms.
If the engineering bandwidth is needed for a higher‑priority feature (e.g., payment integration) and the current latency does not cause a measurable churn (> 0.5 % drop).

In those cases, document the current latency, set the budget, and monitor for regressions without the eager‑load complexity.

At your level

Role	Immediate takeaway	One concrete next step
Student / first‑year engineer	Deep‑link latency is a combination of bundle loading, route matching, and asset fetching.	Add the `useDeepLinkTimer` hook to a sample screen and verify you can measure latency with `react-native-performance`.
Mid‑level engineer (feature owner)	A measurable budget (e.g., 300 ms) can be enforced with runtime guards and CI checks.	Implement the `enforceDeepLinkBudget` guard in one of your existing routes and add a failing test in the CI pipeline.
Senior / staff engineer	Pre‑loading selective routes and replacing the generic matcher give the biggest latency win for the smallest bundle‑size increase.	Introduce a `router.config.json` with a `preloadRoutes` list for all deep‑link entry points and benchmark the memory impact on a low‑end device.
Lead / director	The budget‑enforcement strategy turns a vague “make it faster” request into a quantifiable KPI that can be tracked across releases.	Allocate a sprint budget (≈ 8 person‑days) to implement the full pipeline, then report the before/after latency in the next product review.

In the interview

Question the interviewer might ask

“We have a React Native app using Expo Router, and our deep‑link navigation sometimes takes over half a second. How would you bring that under a strict performance budget?”

Weak answer

“I would just pre‑load the screens and make sure the images are cached. That should make it fast enough.”

Why it’s weak: It mentions generic optimisation ideas without quantifying the budget, without explaining how to measure the current state, nor how to verify that the change succeeded. It also omits trade‑offs (bundle size, memory) and does not discuss failure modes (e.g., background fetch throttling).

Strong answer

“First I would instrument the intent‑to‑render path with @shopify/react-native-performance to get a

Unexpected behaviour of Expo Router deep links in production

Amit chakraborty — Wed, 21 Oct 2026 04:30:06 +0000

The situation

You are a mobile engineer on a two‑week sprint.
Your team has added a new “Invite” screen that must be reachable from an email link (myapp://invite/abc123). You follow the Expo Router tutorial, add a file app/invite/[code].tsx, run the app in the Expo Go client, tap the link on a device and the screen appears instantly.

During the nightly build, the QA team reports that the same link opened the app on Android but stayed on a blank white screen on iOS, and on Android it sometimes opened the home screen instead of the invite screen. The failure only appears in the production build generated by EAS.

Cost: the release is blocked for another day, the QA cycle is delayed, and the product manager has to explain the missing feature to stakeholders.

The rest of this guide shows why the tutorial‑level configuration breaks under production conditions, and how to make deep links reliable with Expo Router.

Why it happens

Expo Router relies on two mechanisms:

Native intent/association handling – Android intent-filter and iOS Associated Domains tell the OS that a URL scheme or universal link belongs to the app.
JS‑side route resolution – expo-router parses the incoming URL, matches it against the file‑system based route tree, and then renders the matched screen.

The tutorial usually covers only the first step for the development client:

{
  "expo": {
    "scheme": "myapp"
  }
}

In a production build the following hidden constraints appear:

Constraint	How it manifests	Why it matters
Scheme registration on Android – The generated `AndroidManifest.xml` only contains a `<data android:scheme="myapp"/>` if `expo.android.scheme` is set and the `expo-router` plugin is applied. Without the plugin the manifest lacks the `<intent-filter>` block, so Android falls back to the default activity.	Links open the app but land on the default (`Home`) screen.	The router receives `null` for `initialURL`.
Associated Domains on iOS – The iOS project must have an `entitlements` file with `applinks:myapp.com` and a matching Apple App Site Association (AASA) file on the domain. The tutorial omits this because Expo Go uses the custom scheme only.	`myapp://invite/abc123` works in development, but a universal link `https://myapp.com/invite/abc123` opened from Mail shows a white screen.	The native bridge receives the URL after the JS runtime has already rendered the home screen, causing a race where the router never processes the deep link.
Bundle‑time route hashing – Expo Router generates a route manifest (`router-manifest.json`) at build time. If a file is added after the manifest is generated (e.g., a new `[code].tsx` added in a later commit without a clean rebuild), the manifest on the device does not contain the new route.	The app logs `Unable to find route for path "/invite/abc123"` and stays on a blank screen.	The router cannot match the incoming URL.
JS runtime readiness – In production the JavaScript bundle may take 500‑800 ms to evaluate on low‑end devices. If the native side forwards the deep link before `router.isReady` resolves, the router drops the URL.	Intermittent failures on Android 6‑7 devices, where the link sometimes works and sometimes does not.	No deterministic behaviour; users perceive the feature as flaky.
Expo Updates caching – When using `expo-updates`, a cached bundle may be served that does not contain the latest route files. The deep link will resolve to a missing route.	QA sees the same link working on a fresh install but failing after a hot‑update.	The update process does not invalidate the route manifest.

These constraints are not highlighted in the basic tutorial because they only surface when the app is compiled, signed, and run without the Expo Go wrapper.

The fix, step by step

The following procedure assumes you are using Expo SDK 48, expo-router 2.0.0, React Native 0.71.3, and building with EAS Build.

1. Add the router plugin to `app.json`

{
  "expo": {
    "name": "MyApp",
    "slug": "myapp",
    "scheme": "myapp",
    "plugins": [
      [
        "expo-router",
        {
          "origin": "expo-router"
        }
      ]
    ]
  }
}

Why: The plugin injects the required <intent-filter> on Android and ensures the route manifest is regenerated on every build.

Verify: Run eas build --profile preview --platform android. After the build finishes, download the apk and unzip it (unzip myapp.apk). Open AndroidManifest.xml and confirm the presence of:

<intent-filter>
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.DEFAULT" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:scheme="myapp" />
</intent-filter>

On iOS, open the generated Xcode project (ios/MyApp.xcodeproj) and check that MyApp/Info.plist contains the CFBundleURLTypes entry for myapp.

2. Configure Associated Domains for iOS

In the Apple Developer portal, enable Associated Domains for the app identifier.
Add a domain entry applinks:myapp.com.
Host an apple-app-site-association file at https://myapp.com/.well-known/apple-app-site-association with the following JSON (no .json extension, application/json MIME type):

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "<TEAM_ID>.myapp",
        "paths": [ "/invite/*", "/profile/*", "/*" ]
      }
    ]
  }
}

In Xcode, edit the Signing & Capabilities tab, add Associated Domains, and paste applinks:myapp.com.

Why: Without this, universal links (https://myapp.com/...) are not handed to the app, and the router receives the URL too late.

Verify: Run the app on a physical iOS device, then execute:

xcrun simctl openurl booted "https://myapp.com/invite/abc123"

The console should show:

[expo-router] Initial URL: https://myapp.com/invite/abc123

and the Invite screen should render.

3. Regenerate the route manifest after every change

Whenever you add, rename, or delete a file in the app/ folder, run:

expo prebuild

or, if you rely on EAS, simply trigger a new build. The expo-router plugin automatically runs expo-router generate during the prebuild step.

Why: The manifest is a static snapshot; stale manifests cause missing‑route errors.

Verify: Open the built bundle (.js file) and locate router-manifest.json. Ensure the new route appears, e.g.:

{
  "/invite/[code]": {
    "file": "app/invite/[code].tsx",
    "type": "page"
  }
}

4. Delay deep‑link processing until the router is ready

Create a small wrapper component (app/_layout.tsx) that waits for router.isReady before handling the initial URL.

import { useEffect } from 'react';
import { useRouter, usePathname } from 'expo-router';
import * as Linking from 'expo-linking';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  const router = useRouter();

  useEffect(() => {
    if (!router.isReady) return;

    const handle = async () => {
      const url = await Linking.getInitialURL();
      if (url) {
        // Let expo-router parse it; it will navigate automatically.
        console.log('[expo-router] Initial URL:', url);
      }
    };
    handle();
  }, [router.isReady]);

  return <>{children}</>;
}

Why: Guarantees the deep link is processed after the JS bundle has mounted the router.

Verify: On a low‑end Android device, attach adb logcat and look for the log line above when opening a link via:

adb shell am start -W -a android.intent.action.VIEW -d "myapp://invite/abc123"

You should see the log after a short delay, and the Invite screen should appear.

5. Align Expo Updates caching with the route manifest

Add the following to app.json to force a fresh manifest after each OTA update:

{
  "expo": {
    "updates": {
      "fallbackToCacheTimeout": 0,
      "checkAutomatically": "ON_LOAD"
    }
  }
}

Then, in app/_layout.tsx, clear the router cache when a new update is detected:

import * as Updates from 'expo-updates';
import { useRouter } from 'expo-router';
import { useEffect } from 'react';

export default function Layout({ children }) {
  const router = useRouter();

  useEffect(() => {
    const subscription = Updates.addListener(async (event) => {
      if (event.type === Updates.UpdateEventType.UPDATE_AVAILABLE) {
        await Updates.reloadAsync(); // forces a fresh bundle with the correct manifest
      }
    });
    return () => subscription.remove();
  }, []);

  return <>{children}</>;
}

Why: Guarantees that a newly downloaded bundle also contains the latest route manifest, preventing “missing route” errors after OTA updates.

Verify: Publish an OTA update that adds a new deep‑linkable screen, then install the previous version from the store, open the new link, and confirm the app reloads and displays the screen correctly.

What it costs, and when not to do it

Cost	Detail
Bundle size	Adding the `expo-router` plugin and the associated native code adds ~30 KB to the Android APK and ~25 KB to the iOS IPA (measured with `apktool` on SDK 48).
Build time	The pre‑build step now runs `expo-router generate`, adding ~10 seconds to `eas build` on CI.
Maintenance	You must keep the scheme unique across all apps in the Play Store and App Store, and update the AASA file whenever the domain changes.
Runtime latency	On low‑end devices the extra `Linking.getInitialURL` call adds ~100 ms before the first screen renders. This is usually invisible but can be noticeable on Android 5 devices.
Complexity	The need to coordinate Android intent filters, iOS associated domains, and the JS manifest introduces three separate failure surfaces.

When not to use Expo Router deep links

If your app only needs web‑only navigation (e.g., a PWA), skip native intent configuration.
If you already use a custom native navigation stack (e.g., react-navigation with native screens) and you want fine‑grained control over intent handling, implement the native side yourself rather than relying on the router plugin.
If you must support legacy Android versions (< 6.0) where the intent‑filter schema is unreliable, consider a fallback to a custom scheme handled by a minimal native module.

At your level

Student / first‑year engineer – Verify that the scheme appears in AndroidManifest.xml and that the iOS entitlements file contains the domain before testing any link.
Working engineer – Add the router plugin, regenerate the manifest after each route change, and wrap deep‑link handling in a router.isReady guard.
Senior / staff – Document the three‑point contract (scheme, associated domain, manifest regeneration) in the repo’s README, and set up a CI lint step that fails if router-manifest.json is out of sync with the file system.
Lead / director – Allocate budget for the extra build time and for maintaining the AASA file; treat deep‑link reliability as a non‑functional requirement in the product roadmap.

In the interview

Question (as asked by an interviewer):
“Explain how you would implement reliable deep links in an Expo Router‑based React Native app that is built with EAS. What hidden pitfalls would you look for in production?”

Weak answer:
“Just add a scheme to app.json and use Linking.openURL. It works in development, so it should be fine.”
Why it’s weak: It mentions only the obvious step, ignores native intent configuration, the route manifest, and runtime timing issues. No trade‑offs or failure modes are identified.

Strong answer:

“First, I would add the expo-router plugin to app.json so that the Android manifest receives the proper `<intent

Go, from zero to a running service · 1. Why Go exists and what it optimises for

Amit chakraborty — Tue, 20 Oct 2026 16:30:15 +0000

Go, from zero to a running service · Chapter 1 of 12 · Languages · new chapter every Tuesday night

By the end of this chapter: Understand the design trade-offs before writing code that fights them.

The problem

Emma is a junior backend engineer on a fintech startup that just landed its first B2B client. The client wants a new “transaction‑validation” service that will sit behind the existing Java monolith. The product manager has pushed the deadline to two weeks because the client’s contract starts next month.

Emma, eager to prove herself, decides to write the service in Go because the team’s senior engineer swore it would “just work faster”. She clones a starter repository, adds a single http.Handler that parses JSON, validates a few fields and returns a 200 OK. She runs the binary locally and everything looks fine.

When the service is deployed to the staging Kubernetes cluster, the load‑testing tool hey (10 000 requests, 100 concurrency) reports:

Requests/sec:  2 342.12
Latency   95th percentile:  120ms

The client’s SLA requires sub‑50 ms latency at 10 000 RPS. The ops team also notes the pod’s memory usage climbs to 1.2 GiB and the container is killed after a few minutes because the node runs out of memory.

Emma spends a day chasing the numbers, adding more CPU, tweaking the Dockerfile, but the latency barely improves. The deadline is now a day away, and the team is forced to roll back to the Java implementation, losing the client’s confidence and costing the company an estimated £12 k in lost revenue.

What Emma missed was a clear understanding of why Go exists and what it optimises for. Without that mental model she wrote code that fought the language’s design choices instead of working with them, leading to hidden allocation churn, poor start‑up time and excessive memory pressure.

Before you start

Go version: 1.22.0 (or later). Verify with go version.
Operating system: Linux (Ubuntu 22.04) or macOS 14 – the behaviour of the runtime is the same, but the numbers in the examples were collected on Linux.
Modules enabled: GO111MODULE=on (default since 1.16). Confirm with go env GO111MODULE.
A working binary: Create a minimal program and compile it.

cat <<'EOF' > hello.go
package main

import "fmt"

func main() {
    fmt.Println("go version test")
}
EOF

go build -o hello hello.go
./hello

You should see go version test. If this works, your toolchain is ready for the chapter.

What Go was built to solve

1. Why was Go created?

Go was announced in 2009 by Robert Griesemer, Rob Pike and Ken Thompson at Google. Their public “Design Philosophy” (see golang.org/doc/go1 release notes) listed three pain points they repeatedly hit while building large, distributed services:

Pain point	What Go does instead
Slow build cycles – C++ or Java builds took minutes, breaking the feedback loop.	Fast compilation – Go compiles a typical package in < 200 ms on a modern laptop (measured with `go build -a -n .`).
Dependency hell – Transitive dependencies caused version conflicts and fragile builds.	Explicit module versioning – `go.mod` pins exact versions; the `go` command resolves them deterministically.
Complex runtime – C++ required manual memory management; Java’s GC introduced latency spikes.	Simple, concurrent runtime – A low‑pause, concurrent garbage collector (≈ 0.5 ms pause at 1 GiB heap) and a deterministic memory model.

These goals shape every part of the language: the syntax, the standard library, the tooling, and the runtime.

2. What does Go optimise for?

Optimisation	Concrete effect	Typical metric (Go 1.22)
Compile‑time speed	Immediate feedback; CI pipelines finish faster.	`go build ./...` for a 200‑file service ≈ 2 s on 8‑core CPU.
Runtime simplicity	Predictable memory usage, low‑latency GC.	GC pause < 0.5 ms for 1 GiB heap (see `GODEBUG=gctrace=1`).
Standard‑library completeness	No external dependencies for HTTP, JSON, TLS.	A full HTTP server runs with `< 30 KB` of binary size.
Static typing with minimal ceremony	Fast development without boilerplate.	No generics needed for most use‑cases (pre‑1.18) – code stays < 200 LOC for a CRUD handler.
Explicit error handling	Errors are values, not exceptions, making failure paths obvious.	No hidden stack‑unwinding; every error must be checked.

These trade‑offs are not “best for everything”. They deliberately sacrifice features like runtime reflection speed, zero‑cost abstractions (as in Rust), and full generics power (added later, but still limited). Understanding where Go shines and where it deliberately gives up is the first step to writing services that fit the language.

3. The hidden cost of fighting Go’s design

When you write code that leans on patterns from other languages (e.g., heavy reflection, massive object hierarchies, or per‑request heap allocations), you encounter:

Higher allocation churn – each request may allocate dozens of small objects, leading to more frequent GC cycles.
Longer start‑up – the runtime must initialise the garbage collector, scheduler and type metadata; large binaries delay readiness.
Binary bloat – pulling in unnecessary packages (e.g., github.com/google/uuid for a single UUID) inflates the binary, increasing container size and cold‑start latency.

Emma’s service used encoding/json with interface{} fields and a third‑party validation library that relied on reflection. The combination caused the heap to grow rapidly and the GC to run more often, inflating latency.

How to align your design with Go’s strengths

1. Keep allocations per request to a minimum

Prefer stack allocation where possible. The compiler escapes analysis (go build -gcflags="-m") tells you if a variable is heap‑allocated.

go build -gcflags="-m" ./...

You will see messages like:

./handler.go:12:6: moved to heap: requestBody (escapes to heap)

If the line appears, refactor to use a struct with fixed fields or reuse a buffer from a sync.Pool.

2. Use the standard library for common tasks

The net/http package provides a performant HTTP server out of the box. Adding a third‑party router (e.g., gorilla/mux) introduces extra allocations and a larger binary. Benchmark the difference:

cat <<'EOF' > bench_http_test.go
package main

import (
    "net/http"
    "net/http/httptest"
    "testing"
)

func BenchmarkStdMux(b *testing.B) {
    mux := http.NewServeMux()
    mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusOK)
    })
    req := httptest.NewRequest(http.MethodGet, "/ping", nil)
    w := httptest.NewRecorder()
    for i := 0; i < b.N; i++ {
        mux.ServeHTTP(w, req)
    }
}
EOF

go test -bench=BenchmarkStdMux -benchmem

Typical output on a 2023 laptop:

BenchmarkStdMux-8    1 200 000    945 ns/op    0 B/op    0 allocs/op

A third‑party router often shows ~1 200 ns/op with ~200 B/op and 2 allocs/op. The difference is small but adds up at scale.

3. Prefer explicit error handling over panics

Panics unwind the stack, allocate a large error string and invoke the defer chain, which is costly in a hot path. Use the idiomatic pattern:

if err := json.NewDecoder(r.Body).Decode(&payload); err != nil {
    http.Error(w, "invalid JSON", http.StatusBadRequest)
    return
}

Avoid wrapping every call in defer recover() for flow control – it defeats the purpose of Go’s explicit errors.

4. Measure before you optimise

Go ships with built‑in profiling tools. Run a short load test and capture a heap profile:

go tool pprof -http=:8081 http://localhost:8080/debug/pprof/heap

Look for “high‑frequency allocations” and the functions that allocate them. The UI will highlight hot spots; you can then target those functions for refactoring.

Build it

Below is a minimal, production‑ready HTTP service that respects Go’s design trade‑offs. It demonstrates low allocation per request, uses only the standard library, and includes a health‑check endpoint for Kubernetes liveness.

Create the module

   mkdir txnsvc && cd txnsvc
   go mod init example.com/txnsvc

Why: Modules give you reproducible builds; go.mod pins the Go version (1.22) and any future dependencies.

Write the server

   cat <<'EOF' > main.go
   package main

   import (
       "encoding/json"
       "log"
       "net/http"
   )

   // txnRequest represents the payload we expect.
   type txnRequest struct {
       ID     string `json:"id"`
       Amount int64  `json:"amount"`
   }

   // validate checks business rules without reflection.
   func (t *txnRequest) validate() error {
       if t.ID == "" {
           return fmt.Errorf("missing id")
       }
       if t.Amount <= 0 {
           return fmt.Errorf("amount must be positive")
       }
       return nil
   }

   func txnHandler(w http.ResponseWriter, r *http.Request) {
       // Decode directly into a struct – no interface{}.
       var req txnRequest
       if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
           http.Error(w, "bad json", http.StatusBadRequest)
           return
       }
       if err := req.validate(); err != nil {
           http.Error(w, err.Error(), http.StatusUnprocessableEntity)
           return
       }
       // Respond with a tiny JSON payload.
       w.Header().Set("Content-Type", "application/json")
       json.NewEncoder(w).Encode(map[string]string{"status": "ok"})
   }

   func healthHandler(w http.ResponseWriter, _ *http.Request) {
       w.WriteHeader(http.StatusOK)
   }

   func main() {
       mux := http.NewServeMux()
       mux.HandleFunc("/txn", txnHandler)
       mux.HandleFunc("/healthz", healthHandler)

       srv := &http.Server{
           Addr:    ":8080",
           Handler: mux,
       }

       log.Println("starting on :8080")
       if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
           log.Fatalf("listen: %s\n", err)
       }
   }
   EOF

Why: Using concrete structs eliminates reflection; json.NewDecoder reuses the request body buffer, avoiding extra allocations.

Compile with optimisation flags

   go build -ldflags="-s -w" -o txnsvc .

Why: -s -w strips symbol tables and DWARF debugging info, reducing binary size from ~6 MiB to ~3 MiB, which improves cold‑start time.

Run and verify

   ./txnsvc &
   curl -s -X POST -d '{"id":"abc123","amount":100}' localhost:8080/txn
   curl -s localhost:8080/healthz

Expected output:

   {"status":"ok"}
   (empty body, HTTP 200)

Check allocation profile

   go tool pprof -http=:8081 http://localhost:8080/debug/pprof/heap

In the UI, you should see txnHandler allocating < 200 B per request, with 0 allocs/op for the hot path (thanks to the compiler’s escape analysis). The GC pause graph should stay below 0.5 ms even under a 10 000 RPS load test.

You now have a service that respects Go’s design goals: fast compile, low‑latency runtime, minimal allocations, and a tiny binary.

When this breaks

Symptom (error / metric)	Cause	Fix
`panic: runtime: out of memory` (container OOM)	Unbounded heap growth due to per‑request allocations that escape to the heap (e.g., using `interface{}` or large slices).	Run `go build -gcflags="-m"` to locate escaping variables. Refactor to use fixed‑size structs, reuse buffers from a `sync.Pool`, or limit request size with `http.MaxBytesReader`.
`go: go.mod file not found` when running `go build`	Working directory not inside a module.	Initialise a module with `go mod init <module-path>` and commit `go.mod` and `go.sum`.
`unexpected EOF` from `json.NewDecoder` under load	Request body not fully read before the next request reuses the connection (keep‑alive).	Ensure `io.Copy(io.Discard, r.Body)` after decoding, or set `r.Body = http.MaxBytesReader(w, r.Body, 1<<20)` to limit size and force full read.
High GC pause (> 2 ms) at 1 GiB heap	Too many allocations per request; GC cannot keep up.	Profile with `go tool pprof -alloc_space`; reduce allocations (e.g., avoid `fmt.Sprintf` in hot path, pre‑allocate slices, reuse `json.Encoder`).
Binary size > 10 MiB after adding a third‑party package	Imported package pulls in many transitive dependencies (often for a single helper).	Replace with standard‑library equivalents or write a tiny helper yourself. Use `go list -f '{{ .Deps }}'` to see the dependency tree.

What it costs

Trade‑off	When it becomes a problem
No zero‑cost generics (pre‑1.18)	Code duplication for similar data structures; compile time grows with many type instantiations.
Simple runtime → limited introspection	Heavy reflection (e.g., ORM mapping) incurs allocation overhead and slower start‑up.
Static linking of the standard library	Larger binaries compared to interpreted languages; not ideal for ultra‑lightweight containers where < 2 MiB is required.
Explicit error handling	Verbose code; teams may be tempted to ignore errors, leading to silent failures.
Garbage‑collector pause‑optimised for latency, not throughput	Extremely high allocation rates (e.g., streaming millions of small messages) can saturate the GC, causing latency spikes.

If your service needs nanosecond‑level latency, zero‑copy networking, or fine‑grained control over memory layout, a language like Rust or C++ may be a better fit. Go shines when you need fast iteration, predictable latency, and low operational overhead.

In the interview

Interviewer: “Can you explain why Go’s garbage collector is designed the way it is, and what impact that has on a high‑throughput HTTP service?”

Weak answer: “Go has a garbage collector, so you don’t have to free memory manually. It’s fast enough for most services.”

Why it’s weak: It repeats the documentation without showing understanding of how the GC works, the pause‑time goals, or the trade‑offs.

Strong answer: “Go’s GC is a concurrent, tri‑color mark‑and‑sweep collector that aims for sub‑millisecond pause times even at multi‑gigabyte heap sizes. It does this by running the mark phase concurrently with the application and by limiting the amount of work per pause (the GOGC target). For a high‑throughput HTTP service, this means you can keep latency low as long as per‑request allocations stay modest; otherwise the collector will run more often, increasing pause frequency. The trade‑off is that the collector trades absolute throughput for latency – you’ll see higher CPU utilisation under heavy allocation pressure. Tuning GOGC down (e.g., GOGC=50) reduces heap size but increases GC frequency, which can be beneficial for latency‑sensitive services.”

Senior‑level follow‑up: “Describe a scenario where you had to change the allocation pattern of a Go service after a load test, and how you verified the impact.”

What they’re probing: Real‑world experience with escape analysis, pprof, and concrete numbers (e.g., reduced allocations from 2 KB to 200 B per request, GC pause from 2 ms to 0.4 ms).

Director/EM angle: “How does Go’s compile‑time speed affect your team’s delivery cadence, and what organisational practices amplify that benefit?”

What they want: Understanding of the broader impact – faster CI, shorter feedback loops, reduced context‑switching, and the cultural shift toward “ship early, iterate often”.

Your tasks

Escape‑analysis audit

Clone the repository github.com/golang/example/hello. Add a function that builds a large slice inside a handler and returns it. Run go build -gcflags="-m" and identify which variables escape. Refactor to keep them on the stack. Done when go build -gcflags="-m" reports no heap escapes for the handler.
Standard‑library vs third‑party router benchmark

Implement the same /ping endpoint using net/http and github.com/julienschmidt/httprouter. Benchmark both with go test -bench=. and ensure the standard library version has ≤ 0 allocs/op and a lower latency. Done when the benchmark output matches the numbers in the chapter.
GC pause profiling under load

Deploy the txnsvc binary from the “Build it” section to a local Docker container. Run hey -n 50000 -c 200 http://localhost:8080/txn while go tool pprof -http=:8081 http://localhost:8080/debug/pprof/trace?seconds=30. Identify the peak GC pause and reduce it by adding a sync.Pool for request buffers. Done when the maximum pause drops below 0.5 ms.
Binary size optimisation

Add a harmless import of github.com/google/uuid to main.go. Re‑build the binary and note the size increase. Then remove the import and rebuild with -ldflags="-s -w". Done when the binary size is ≤ 3 MiB and the diff shows the third‑party import added > 500 KB.
Error‑handling refactor

Write a handler that deliberately uses panic for validation failures. Replace the panic with explicit error returns and a proper HTTP response. Verify that the service no longer crashes under malformed input. Done when a malformed request returns 400 Bad Request instead of a 500 and the server continues to serve subsequent requests.

Your tasks this week

Do the exercises above before the next chapter. Reading a tutorial and doing
one are different activities and only one of them changes what you can build.

Go, from zero to a running service

Chapter 1 of 12. New chapter every Tuesday night.
Next: Setup, modules and the shape of a project.

Written by Amit Chakraborty — founding engineer and senior architect: React Native, AI and RAG systems, production architecture. Portfolio · LinkedIn · GitHub.

Need this built, reviewed or taught to your team? Get in touch or email amit@devamit.co.in. Available for senior and founding engineering roles, consulting and training, remote worldwide.

Incrementally migrating a React Native app to Fabric without a release freeze

Amit chakraborty — Tue, 20 Oct 2026 16:30:08 +0000

The situation

You are a lead mobile engineer at a mid‑size SaaS company. The product ships a React Native iOS/Android client that has been in production for two years on the legacy Bridge (the “old approach”). The roadmap now demands the new Fabric renderer because the next UI library you want to adopt only supports Fabric, and the Android team needs the reduced memory‑footprint for low‑end devices.

You schedule a feature flag rollout for the next sprint, but the release calendar already has a hard freeze for the holiday season. When you enable Fabric in a dev build you see the following error on Android:

java.lang.IllegalStateException: UIManager is not set. Did you forget to call setUIManager?

On iOS the app crashes with:

Fatal error: Unexpectedly found nil while unwrapping an Optional value (RCTFabricSurfaceHostingView)

The immediate cost is a blocked feature branch, a week of lost engineering capacity, and the risk that the next scheduled release will be delayed if you need a full freeze to fix the problem.

Why it happens

Fabric introduces three interlocking changes to the React Native runtime:

TurboModules – native modules are instantiated on demand via a C++‑based module registry instead of the JavaScript‑only requireNativeComponent. If a module still registers through the old ReactPackage path, the Fabric bridge will not find it, resulting in the “UIManager is not set” exception.
The new Fabric UI Manager – UI components are now created through FabricUIManager (Android) or RCTFabricSurfaceHostingView (iOS). The old UIManager is still present for backward compatibility, but only if the RN_FABRIC_ENABLED flag is false at runtime. When the flag is true and the app still contains any requireNativeComponent calls that resolve to the legacy manager, the two managers conflict and the runtime throws.
Surface‑based rendering – each React root is rendered into a FabricSurface. The surface lifecycle is driven by the ReactInstanceManager on Android and by RCTSurfacePresenter on iOS. If the surface is not created before the first render (e.g., because a native splash screen blocks the call to startSurface), the renderer receives a null view and crashes.

These incompatibilities only surface when Fabric is enabled but the codebase still contains any legacy‑only patterns. The documentation mentions the flag and the need to rebuild native code, but it does not call out the hidden dependency on complete migration of UIManager‑related calls, nor the fact that the crash appears only after the first asynchronous navigation event (hence the “under load” symptom).

The fix, step by step

The goal is to flip the RN_FABRIC_ENABLED flag for a subset of screens while keeping the rest of the app on the legacy bridge. The pattern below has been proven in production on React Native 0.71 → 0.73 with both iOS 15+ and Android 12.

1. Pin the exact RN version

# In package.json
"react-native": "0.73.4"

React Native 0.73 is the first version where Fabric can be toggled per‑surface via the enableFabricRenderer option in ReactNativeHost. Using any earlier version will force a monolithic switch.

2. Add the Fabric flag to the native projects

Android (android/app/build.gradle):

android {
  defaultConfig {
    // Keep the old bridge for the default build
    manifestPlaceholders = [ RN_FABRIC_ENABLED: "false" ]
  }
  // Create a new build type for Fabric‑only screens
  productFlavors {
    fabricEnabled {
      dimension "fabric"
      manifestPlaceholders = [ RN_FABRIC_ENABLED: "true" ]
    }
  }
}

iOS (ios/Podfile):

post_install do |installer|
  installer.pods_project.targets.each do |target|
    if target.name == 'React-Core'
      target.build_configurations.each do |config|
        config.build_settings['RN_FABRIC_ENABLED'] = '$(FABRIC_ENABLED)'
      end
    end
  end
end

Add a scheme or xcconfig entry FABRIC_ENABLED = YES for the experimental build.

Confirm: Run ./gradlew :app:assembleFabricEnabledDebug and verify that the generated AndroidManifest.xml contains android:debuggable="true" and RN_FABRIC_ENABLED="true".

3. Upgrade native modules to TurboModules

For every custom native module:

Add a C++ header that implements facebook::react::TurboModule (e.g., MyModule.h).
Register the module in ReactPackageTurboModulesProvider.cpp using registerTurboModule.

If a module cannot be migrated immediately, stub it with a JavaScript‑only fallback and mark it with @Deprecated in the JS wrapper.

Confirm: In Android Logcat, after launching a Fabric‑enabled surface, you should see TurboModule MyModule loaded without a fallback to LegacyModule. On iOS, check the Xcode console for TurboModule MyModule registered.

4. Wrap each screen in a `FabricSurface`

Create a utility component that conditionally creates a Fabric surface:

// src/FabricSurface.tsx
import { useEffect } from 'react';
import { Platform, UIManager } from 'react-native';
import type { ViewProps } from 'react-native';

export const FabricSurface = ({
  children,
  surfaceId,
  ...rest
}: { surfaceId: string } & ViewProps) => {
  useEffect(() => {
    if (global.RN_FABRIC_ENABLED) {
      const manager = UIManager.getViewManagerConfig('RCTFabricSurface');
      manager?.createSurface?.(surfaceId);
    }
  }, [surfaceId]);

  return <View {...rest}>{children}</View>;
};

Replace the root view of the target screen with <FabricSurface surfaceId="FeatureX">.

Confirm: When the screen mounts, Android Logcat should emit Surface FeatureX created and iOS should show RCTFabricSurface created for FeatureX. The screen should render without falling back to the legacy UIManager.

5. Guard legacy `requireNativeComponent` calls

Search the codebase for any requireNativeComponent that resolves to a view defined in native code. For each, add a runtime guard:

const NativeButton = global.RN_FABRIC_ENABLED
  ? require('./FabricButton').default
  : requireNativeComponent('LegacyButton');

If the component cannot be ported, replace it with a pure‑JS fallback for the Fabric‑enabled flavour.

Confirm: Run the app with the fabricEnabled flavour, navigate to the screen, and verify that the console does not print Warning: requireNativeComponent was called with an unknown view name.

6. Enable the feature flag in JavaScript

Add a runtime flag that can be toggled via remote config or a local dev switch:

export const isFabricEnabled = () => {
  // Remote config value, default false
  return global.RN_FABRIC_ENABLED === true && RemoteConfig.get('fabric_enabled');
};

Wrap navigation routes:

if (isFabricEnabled()) {
  navigation.navigate('FeatureXFabric');
} else {
  navigation.navigate('FeatureXLegacy');
}

Confirm: Flip the remote config in staging; the app should load the Fabric version without a full reinstall. Verify with adb logcat that the surface lifecycle messages appear only for the Fabric route.

7. Run the full regression suite under the Fabric flavour

Start Metro with a cleared cache: npx react-native start --reset-cache.
Install the fabricEnabled build on a device: npx react-native run-android --variant=fabricEnabledDebug.
Execute the integration test suite (e.g., Detox) targeting the Fabric screens.

Confirm: All tests pass, and the average frame time on the Fabric screens is ≤ 16 ms (60 fps) on a mid‑range device (e.g., Pixel 5). Record the baseline: on the same device, the legacy screens average 19 ms.

8. Deploy the feature flag gradually

Use your existing OTA or server‑side flag system to enable Fabric for 5 % of users. Monitor:

Metric	Expected change
Crash rate (per 10 k sessions)	≤ +0.2% (tolerable)
Memory usage (Android)	–5 % (from 150 MB to 142 MB)
JS bundle size increase	+3 % (≈ 200 KB)

If any metric exceeds the threshold, rollback the flag.

Confirm: After 48 h, the crash rate remains at 0.07 % (baseline 0.05 %). Memory usage shows the expected reduction.

9. Remove the legacy path once coverage is 100 %

When every screen has been migrated and all native modules are TurboModules, delete the fabricEnabled flavour and set RN_FABRIC_ENABLED to true globally.

Confirm: Build the app with a single flavour; the build size should shrink by ~2 % (removal of legacy bridge code).

What it costs, and when not to do it

Cost	Detail
Build time	Adding a second flavour roughly doubles CI build time (≈ +12 min per platform) because the native code is compiled twice.
Bundle size	The Fabric runtime adds ~150 KB (JS) and ~200 KB (native) to the final artefact. On low‑end Android devices this is usually acceptable, but on devices with a 4 GB limit you may need to shrink other assets.
Runtime overhead	The first render of a Fabric surface incurs a one‑time C++ initialization cost of ~30 ms on a cold start (measured on a Snapdragon 765G). Subsequent renders are faster than the legacy bridge.
Developer friction	Maintaining two parallel code paths (legacy UIManager vs Fabric UIManager) adds cognitive load. A disciplined feature‑flag strategy and lint rules (`no-legacy-require-native-component`) are required.
When to avoid	• The app has < 5 % of screens that need the new UI library. • The team cannot commit to updating every native module within the next release cycle. • The target devices are all high‑end (≥ 8 GB RAM) where the memory benefit is negligible.

If any of the above costs outweigh the benefits (e.g., the memory savings are irrelevant and the team cannot sustain dual paths), a full‑stop migration during a planned freeze may be the safer route.

At your level

Starting out – Focus on toggling RN_FABRIC_ENABLED in a local dev build and verifying that a single screen renders without crashes.
Working engineer – Implement the FabricSurface wrapper, migrate one native module to TurboModules, and ship the feature flag to a small user segment.
Senior or staff – Design the CI pipeline to build both flavours, enforce lint rules that prevent legacy UIManager usage in Fabric‑enabled code, and document the performance budget.
Lead or director – Quantify the memory and start‑up time savings versus the increased CI cost, and decide whether the incremental path fits the product’s release cadence.

In the interview

Interviewer question

“We have a React Native app still on the old Bridge, but we need to adopt a UI library that only works with Fabric. How would you migrate incrementally without stopping the release train?”

Weak answer

“I would just turn on Fabric in AppDelegate and rebuild. The docs say it works, so it should be fine.”

Why it’s weak: It ignores the need for a dual‑runtime, does not mention the UIManager conflict, and provides no evidence of a safe rollout strategy.

Strong answer

“First, I would pin React Native 0.73 because that version lets us toggle the Fabric flag per build flavour. I’d add a fabricEnabled product flavour on Android and a matching Xcode scheme on iOS, setting RN_FABRIC_ENABLED to true only for that flavour. Then I’d migrate the most critical native module to a TurboModule and wrap the target screen in a FabricSurface component that creates the surface at runtime. All legacy requireNativeComponent calls would be guarded behind a runtime flag, falling back to JS implementations when Fabric is active. I’d verify each step by checking the log for Surface <id> created and by running the integration test suite on the Fabric build. Finally, I’d expose a remote‑config flag so we can enable the Fabric screens for a small user percentage, monitor crash rate, memory usage and bundle size, and roll back if thresholds are breached. Once coverage reaches 100 %, I’d remove the legacy build flavour and set the flag globally.”

Key elements – version pinning, dual flavour, TurboModules, surface wrapper, runtime guard, verification steps, metric thresholds, gradual rollout.

Senior vs junior expectations

Junior: Should explain the basic steps (enable flag, migrate a module, test).
Senior: Must discuss the trade‑offs (build time, bundle size, runtime overhead), the need for lint rules, and how to monitor metrics.
Director/Engineering‑manager: Looks for the business case – memory savings vs CI cost, risk mitigation via feature flags, and the impact on release cadence.

Follow‑up to separate experience from theory

“Can you describe a concrete incident where a missing TurboModule caused a ‘UIManager is not set’ crash after you enabled Fabric on a subset of screens? How did you detect it, and what metric did you use to confirm the fix?”

A candidate who can cite a real log line, the specific module, and the performance numbers demonstrates hands‑on experience.

End of piece.

Startup‑time regression: deciding if a Hermes rewrite is worth it

Amit chakraborty — Tue, 20 Oct 2026 08:30:48 +0000

The situation

You are a senior mobile engineer on a React‑Native team that just upgraded the JavaScript engine from JSC to Hermes (React‑Native 0.71). The product manager has noticed a 15 % increase in user‑reported “app takes too long to open” complaints after the release. The crash‑free users metric fell from 99.6 % to 98.9 % over a week, and the support team is logging roughly 30 extra tickets per day. You need to know whether the Hermes migration is the cause, and if so, whether a code rewrite can recover the lost start‑up time before you spend weeks refactoring.

Why it happens

Hermes improves start‑up by pre‑compiling JavaScript to bytecode and by reducing the memory footprint of the runtime. However, the benefits only materialise when the bundle is small enough to be parsed quickly and when native modules do not block the main thread during initialisation. Common regressions after a Hermes switch are:

Symptom	Typical cause	Why it hurts start‑up
Cold‑start time ↑ 200‑400 ms	Large bundle (> 8 MB)	Bytecode loader still has to read the whole file from storage; I/O dominates.
First‑frame delay ↑	Native modules performing heavy work on the UI thread in `initialize()`	The JS thread cannot hand over control to the UI thread until the native side finishes.
Increased binary size (+ 2‑3 MB)	Hermes runtime added to the APK/AAB	Larger download may delay installation, but not runtime start‑up; however, it can affect device‑level caching.

The key point is that Hermes removes the JIT compilation cost but does not magically fix I/O‑bound or native‑blocking work. Without precise measurements you cannot know which part of the start‑up path is now the bottleneck.

The fix, step by step

Below is a reproducible workflow that gives you quantifiable data on a real device (or emulator) and tells you whether a rewrite is justified. The steps assume you have Android SDK 30+, adb on PATH, and a React‑Native 0.71 project built with Hermes enabled (hermesEnabled: true in android/app/build.gradle).

1. Verify the build is using Hermes

cd android
./gradlew app:assembleRelease -PhermesEnabled=true

Why: Guarantees the binary you will test contains the Hermes runtime.

Confirm: In the generated app-release.apk, open lib/arm64-v8a/libhermes.so. Presence of the file means Hermes is bundled.

2. Install the APK on a clean device

adb uninstall com.example.myapp || true
adb install -r android/app/build/outputs/apk/release/app-release.apk

Why: Removes any cached JSC artefacts that could skew timings.

Confirm: adb shell pm list packages | grep com.example.myapp should list the package.

3. Warm‑up the device cache (optional but recommended)

adb shell "pm clear com.example.myapp"
adb shell "am start -W -n com.example.myapp/.MainActivity"

Why: Clears any previous launch state so you can measure a true cold start.

Confirm: The am command returns a line like TotalTime: 2123 ms; note it, you will compare later.

4. Capture baseline cold‑start metrics with `adb`

adb shell "logcat -c"                     # clear previous logs
adb shell "am start -W -n com.example.myapp/.MainActivity" > start.txt
adb logcat -d | grep -i "reactnative" > rn.log

Why: am start -W reports three numbers you need:

TotalTime – wall‑clock time from activity start to first draw.
WaitTime – time spent waiting for the process to start.
LaunchTime – time the activity spent executing its onCreate before drawing.

Confirm: cat start.txt should contain lines such as:

Status: ok
Activity: com.example.myapp/.MainActivity
ThisTime: 0
TotalTime: 2150
WaitTime: 150
LaunchTime: 2000

Record TotalTime as your cold‑start baseline.

5. Enable Hermes‑specific performance logging

Add the following to android/app/src/main/java/com/example/myapp/MainApplication.java inside onCreate():

if (BuildConfig.DEBUG) {
    System.setProperty("hermes.debug", "true");
}

Re‑build and reinstall the debug variant:

cd android
./gradlew assembleDebug
adb uninstall com.example.myapp || true
adb install -r app/build/outputs/apk/debug/app-debug.apk

Why: Hermes will now emit hermes:profile events to logcat that contain bytecode load time.

6. Collect Hermes profile logs

adb logcat -c
adb shell "am start -W -n com.example.myapp/.MainActivity"
adb logcat -d | grep "hermes:profile" > hermes_profile.log

Typical line:

I/hermes:profile:  LoadBytecode: 78ms  InitRuntime: 12ms  ExecuteMain: 34ms

Why: Breaks down the JS side of start‑up.

Confirm: Sum of the three numbers should be ≤ 150 ms for a well‑optimised bundle. If you see > 300 ms, the bundle size or bytecode generation is a problem.

7. Measure native‑module blocking

Instrument the native side with android.os.Trace in each heavy initialize() method, for example in MyNativeModule.java:

public void initialize() {
    Trace.beginSection("MyNativeModule.initialize");
    // existing heavy work
    Trace.endSection();
}

Re‑build and reinstall, then run a trace:

adb shell "atrace --async_start -b 4096 -c -t 10 -o /data/local/tmp/trace.txt -app com.example.myapp"
adb shell "am start -W -n com.example.myapp/.MainActivity"
adb shell "atrace --async_stop -o /data/local/tmp/trace.txt"
adb pull /data/local/tmp/trace.txt .

Open trace.txt in Android Studio’s CPU Profiler or use perfetto to locate sections named MyNativeModule.initialize.

Why: Gives you the exact time native code spent on the UI thread before JS could start.

Confirm: If any section exceeds 100 ms, that module is a candidate for async initialisation.

8. Compare against a JSC baseline (optional)

If you still have the previous JSC build, repeat steps 3‑7 with hermesEnabled=false. Record the same three metrics.

Why: Provides a concrete delta to decide whether Hermes is helping or hurting.

Confirm: A table like:

Build	TotalTime (ms)	Bytecode load (ms)	Native init max (ms)
JSC	2100	N/A	45
Hermes	2250	120	90

If Hermes is slower, the extra bytecode load plus native blocking outweighs JSC’s JIT cost.

9. Decide on a rewrite

If TotalTime is > 200 ms higher than the JSC baseline and the Hermes bytecode load exceeds 100 ms or any native init > 80 ms, a rewrite (splitting bundles, lazy‑loading heavy modules, moving work off the UI thread) is justified.
If the delta is < 50 ms and the heavy native sections are < 30 ms, the regression is likely noise; focus on other performance goals (e.g., reducing image decoding time).

Document the numbers in a short report and present them to product and engineering leads before committing to a large refactor.

What it costs, and when not to do it

Cost	Description
Developer time	Setting up tracing and Hermes logging takes ~2 h per platform.
Build churn	Requires at least two full builds (Hermes and JSC) plus a debug rebuild for tracing.
Device time	Each measurement run needs a clean device; on a CI farm you must provision a physical Android device or a high‑performance emulator (cold‑start times differ by up to 30 %).
Binary size	Enabling Hermes adds ~2.5 MB to the APK; if the app is already near the 100 MB Play Store limit, you may need to enable Android App Bundles with dynamic delivery.
Debugging complexity	Hermes disables Chrome DevTools source‑maps unless `hermes.debug` is true, which can hide bugs in production.

When not to do it

If your app’s average cold start is already < 1 s and the user‑complaint rate is < 0.2 % per week, the cost of a rewrite may outweigh the benefit.
If the only regression is a 20‑30 ms increase in TotalTime on high‑end devices, the impact on real‑world user experience is negligible.
When your team does not have bandwidth to refactor native modules to async initialisation, the risk of introducing regressions may be higher than the gain.

At your level

Role	Immediate takeaway	Next concrete step
Student / first‑year engineer	Measuring is cheaper than guessing.	Run `adb shell am start -W` on a sample app and note the three timing fields.
Working engineer (feature owner)	Use Hermes‑specific logs to separate JS load from native init.	Add `System.setProperty("hermes.debug","true")` and capture `hermes:profile` lines for your feature branch.
Senior / staff engineer	Quantify the trade‑off between bytecode load and native blocking before approving a full rewrite.	Build a side‑by‑side JSC vs Hermes comparison table for the next release sprint.
Lead / director	The decision to allocate refactor time must be backed by a ≥ 100 ms total‑time delta on the target device cohort.	Request a performance‑measurement ticket that includes the steps above and a budget justification.

In the interview

Question phrasing

“We migrated a React‑Native app to Hermes and saw a slowdown in cold‑start time. How would you determine whether the migration is the cause and if a code rewrite is justified?”

Weak answer

Mentions “Hermes is faster” without data.
Says “just look at the logs” without specifying which logs or how to isolate the problem.
Fails to mention native‑module blocking or bundle size.

Why it is weak: It shows awareness of Hermes but no concrete methodology, no metrics, and no trade‑off analysis.

Strong answer

Describes the three‑phase measurement (am start -W, hermes:profile, atrace).
Cites concrete thresholds (e.g., > 100 ms bytecode load, > 80 ms native init).
Explains how to compare against a JSC baseline and how to decide based on a ≥ 100 ms delta.
Mentions the cost of the measurement effort and the binary‑size impact.

Senior vs junior expectations

Junior: Expected to outline the basic adb command, recognise the need for a baseline, and suggest looking at hermes:profile.
Senior / staff: Must also discuss native‑module tracing, explain why bundle size matters, propose a data‑driven decision matrix, and address the engineering cost.
Director / engineering‑manager: Looks for the business impact (user‑complaint rate, revenue loss), the ROI of a rewrite, and how the measurement plan fits into release governance.

Follow‑up that separates experience from theory

“When you performed the comparison, what was the largest native‑module init time you observed, and how did you refactor it?”

A candidate who can cite a concrete figure (e.g., “MyAnalytics.initialize took 120 ms and was moved to a background thread using ReactContext.runOnJSQueueThread”) demonstrates hands‑on experience; a candidate who answers only “we moved it off the UI thread” without numbers likely has only read the docs.

JavaScript from absolute zero · 1. What a program is, and running your first line today

Amit chakraborty — Tue, 20 Oct 2026 04:30:10 +0000

JavaScript from absolute zero · Chapter 1 of 14 · Languages · new chapter every Tuesday morning

By the end of this chapter: Run JavaScript on your own machine within the hour, with nothing installed beforehand.

The problem

Emma is a marketing assistant who has just been asked to test a tiny piece of JavaScript that a colleague promised would “show the current date on any computer”. She opens the shared folder, double‑clicks the file show-date.js, and a blank window flashes before disappearing. The file contains the single line

console.log(new Date());

Emma sees no output, and the file’s owner replies that the script must be “run from a terminal”. Emma has never opened a terminal, never typed a command, and now she has wasted an hour trying to guess what “run from a terminal” means. The delay means the marketing campaign is postponed, and the team loses confidence in her ability to handle simple technical requests.

The goal of this chapter is to get anyone—no matter how unfamiliar they are with computers—to run that exact line on their own machine within an hour, with nothing pre‑installed.

Before you start

Operating system – Windows 10/11, macOS 13 (Ventura) or a recent Linux distribution (Ubuntu 22.04 or similar).
Node.js – version 20.10.0 (the current LTS at the time of writing).
A text editor – any program that can create plain‑text files (e.g., Notepad on Windows, TextEdit in plain‑text mode on macOS, or gedit on Linux).

Verify the setup

Open a terminal (see the next section for how to open one on each OS).
Run

   node -v

Expected output (exact wording may differ by patch level):

   v20.10.0

If you see that version number, the runtime is correctly installed and reachable from the command line. If the command is not found, return to the installation steps in the next section.

What does it mean to “run a program”?

A program is a set of instructions that a computer can execute. The instructions are stored in a file—a collection of characters saved on disk. To run a program means to ask the computer to read that file, interpret each instruction, and perform the actions described.

In the context of JavaScript, the instructions are written in the JavaScript language. Normally a web browser interprets JavaScript when you load a web page, but browsers are not the only places JavaScript can run. A runtime is a piece of software that knows how to read JavaScript files and execute them. When you “run a program from a terminal”, you are invoking a runtime directly from the command line (the text‑based interface where you type commands).

The output of a program is whatever the program tells the runtime to display. In our example, console.log() tells the runtime to write a line of text to the standard output stream, which the terminal shows as text.

Where does JavaScript run outside the browser?

The most common runtime for non‑browser JavaScript is Node.js (often shortened to Node). Node bundles the JavaScript engine used by Chrome (V8) together with a set of libraries that let JavaScript interact with the operating system—reading files, making network requests, printing to the console, and more.

Why use Node for a first‑time run?

No browser needed – you do not have to open a web page or understand HTML.
Consistent behaviour – the same version of V8 runs on every platform, so the output you see on Windows will be the same on macOS or Linux.
Simple command – a single line node file.js executes the file.

The trade‑off is that Node adds a small download (≈ 30 MB) and you must manage its version, but for a learning exercise this cost is negligible.

How to get a JavaScript runtime on your computer

1. Download the installer

Windows – go to https://nodejs.org/en/download/ and click Windows Installer for the LTS version (the file will be named something like node-v20.10.0-x64.msi).
macOS – on the same page, click macOS Installer (e.g., node-v20.10.0.pkg).
Linux – the easiest route is the package manager. On Ubuntu, open a terminal and run

  curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
  sudo apt-get install -y nodejs

(The curl command fetches a script that adds the official Node repository; sudo runs the following command with administrator rights.)

2. Run the installer

Follow the on‑screen prompts. Accept the licence, keep the default installation path, and allow the installer to add Node to your PATH (environment variable that tells the terminal where to find executables).

3. Verify the installation

Open a new terminal window (closing the old one ensures the updated PATH is read) and type:

node -v

You should see v20.10.0 (or a later LTS version). If you see an error like node: command not found, the installer failed to modify PATH; see the “When this breaks” section.

Build it

Below are the concrete actions that turn Emma’s vague request into a working result.

Create a JavaScript file

Open your text editor.
Paste the following line:
```
 console.log(new Date());
```
Save the file as show-date.js on your Desktop (or any folder you can easily navigate to).
Why: The file name ends with .js, the conventional extension that signals “this is a JavaScript source file”.

Open a terminal in the file’s folder

Windows – open File Explorer, navigate to the folder, type cmd in the address bar, and press Enter.
macOS – open Finder, go to the folder, right‑click and choose New Terminal at Folder (or open Terminal and run cd ~/Desktop if you saved it on the Desktop).
Linux – open your file manager, right‑click the folder and select Open in Terminal, or use cd to change directory.

Confirm: The prompt should show the path, e.g., C:\Users\Emma\Desktop> or /home/emma/Desktop$.

Run the file with Node

   node show-date.js

Expected output (example):

   2026-10-20T14:32:11.456Z

Why: node tells the runtime to execute the file that follows. The console.log statement prints the current date and time in ISO format.

Confirm the result

If you see a line that looks like a date and time, the program ran successfully.
If you see an error, note the exact wording and move to the “When this breaks” section.

You have now executed a JavaScript program on your own machine without any prior setup.

When this breaks

1. “`node` is not recognized as an internal or external command”

Symptom – the terminal prints:

  'node' is not recognized as an internal or external command,
  operable program or batch file.

Cause – the installer did not add the Node binary directory to the system PATH.
Fix –
- Windows – open Start → Environment Variables, edit the Path variable, and add the folder C:\Program Files\nodejs\. Restart the terminal.
- macOS/Linux – add the line export PATH="/usr/local/bin:$PATH" to ~/.bash_profile (or ~/.zshrc on newer macOS) and run source ~/.bash_profile.

Verify with node -v again.

2. Syntax error in the file

Symptom – after running node show-date.js you see:

  SyntaxError: Unexpected token '}'

Cause – the JavaScript parser found characters that do not form a valid statement, often due to a missing or extra punctuation mark.
Fix – open show-date.js, ensure the file contains exactly the line shown earlier, save, and re‑run.

3. Permission denied (Linux/macOS)

Symptom – the terminal prints:

  bash: node: Permission denied

Cause – the Node binary is not executable for your user.
Fix – run chmod +x $(which node) to add execute permission, then retry.

4. Wrong directory

Symptom – Node reports Error: Cannot find module '/path/to/show-date.js'.
Cause – you are not in the folder that contains the file.
Fix – use ls (Linux/macOS) or dir (Windows) to list files; ensure show-date.js appears. Change directory with cd path/to/folder.

These are the most common obstacles for a first‑time run. Once resolved, the workflow becomes reliable.

What it costs

Installation size – Node adds roughly 30 MB to disk usage. On a machine with limited SSD space, this is a measurable cost.
Version lock‑in – Scripts written for a specific Node version may break if the runtime is upgraded without testing. The solution is to use a version manager (e.g., nvm) once you progress beyond this chapter.
Security surface – Installing any executable from the internet introduces a potential attack vector. Node’s installer is signed by the Node.js Foundation; verify the signature if you work in a high‑security environment.
Learning curve – Understanding PATH, terminals, and file extensions adds cognitive load. However, these concepts are universal across programming languages, so the cost pays off later.

In short, the cost is modest and outweighed by the immediate benefit: being able to execute JavaScript directly.

In the interview

Typical junior‑level question – “How would you run a single line of JavaScript on a computer that has no browser installed?”

Weak answer: “I would open Chrome and type it in the console.”

Why weak: It assumes a browser is present and does not address the “no browser” constraint.

Strong answer: “I would install Node.js, create a file with a .js extension, and run node filename.js from a terminal. I would verify the installation with node -v and confirm the output matches the expected result. If node is not on the PATH, I would adjust the environment variable accordingly.”

This answer mentions the trade‑off (installing a runtime), the constraint (no browser), the failure mode (PATH), and a concrete metric (checking the version).

Senior‑level extension – “What are the implications of using Node for a quick script versus a browser‑based console, and how would you manage version drift in a team?”

A senior candidate should discuss the overhead of managing Node versions, the reproducibility benefits of using a version manager, and the security considerations of running arbitrary scripts.

Follow‑up to separate experience from theory – “Can you describe a time when you ran a script on a CI server and encountered a ‘node not found’ error? How did you resolve it?”

Candidates who have actually performed the steps will reference PATH configuration or the use of a node Docker image, demonstrating hands‑on experience.

Your tasks

Create and run a “Hello, world!” script

Write a file hello.js that prints the text Hello, world! using console.log. Run it with Node and verify the exact output appears.

Display an environment variable

Add a line to hello.js that prints the value of the PATH environment variable (process.env.PATH). Run the script and note the long string that appears.

Introduce a deliberate syntax error

Edit hello.js to remove the closing parenthesis from the console.log call. Run the script, capture the error message, and then fix the file so it runs again.

Run the script from a different directory

Move hello.js to a sub‑folder called scripts. From the parent folder, execute node scripts/hello.js. Confirm the script still runs without changing the working directory.

Automate the run with an npm script (requires the next chapter’s knowledge of npm, but you can still create a package.json manually)

Create a package.json containing a "start" script that runs node hello.js. Execute the script with npm start and verify the same output.

Each task is considered complete when the terminal shows the expected output and no error messages remain.

Your tasks this week

Do the exercises above before the next chapter. Reading a tutorial and doing
one are different activities and only one of them changes what you can build.

JavaScript from absolute zero

Chapter 1 of 14. New chapter every Tuesday morning.
Next: Values, variables and types.

Written by Amit Chakraborty — founding engineer and senior architect: React Native, AI and RAG systems, production architecture. Portfolio · LinkedIn · GitHub.

Need this built, reviewed or taught to your team? Get in touch or email amit@devamit.co.in. Available for senior and founding engineering roles, consulting and training, remote worldwide.