DEV Community: Amit chakraborty

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.

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.

Product management for engineers

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

· 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.

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

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.

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.

When a Fabric rewrite feels faster but you can’t prove it

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

The situation

Say you are a React Native engineer on a mobile team that has just upgraded the UI stack from the legacy renderer to the new Fabric renderer (React Native 0.71). Your goal is to reduce frame‑drop on a scrolling list that currently hits 45 ms per frame on a mid‑range Android device. After switching to Fabric you notice the UI feels smoother during a quick manual test, but the performance monitor still reports occasional spikes to 70 ms. The team’s sprint deadline is two weeks away and the product manager is demanding a quantifiable improvement before the release can be approved.

The cost of not having a solid measurement is threefold:

Time: you may spend another week chasing “feel‑good” changes that don’t actually move the needle.
Risk: a regression could slip into production because the baseline wasn’t captured.
Stakeholder confidence: without hard data the product manager will push back, potentially delaying the launch.

The core problem is how to instrument a Fabric‑based app so you can decide, with numbers, whether the rewrite is worth the effort.

Why it happens

Fabric changes the way the JavaScript thread talks to the UI thread:

Legacy (Bridge)	Fabric
JSON‑encoded messages over a single queue	Direct, typed C++ bindings; batched UI commands
All layout work on the UI thread	Layout can be off‑loaded to the JS thread via `LayoutAnimation` APIs, but still ends up on UI thread for final paint

Because the data path is different, the existing instrumentation that ships with React Native (e.g., Systrace or the “Performance Monitor” in the developer menu) often does not surface the new cost centres:

The “JS → Native bridge” graph still shows a single “Bridge” node, even though Fabric bypasses it.
The UI thread’s “Layout” and “Mount” phases are now split into separate C++ calls that are invisible to the default timeline.

Consequently, developers see the same “JS time” and “UI time” numbers, but the underlying work has moved. Without specialised metrics you cannot tell whether the new path reduced overall work or simply shifted latency to a place you’re not watching.

The fix, step by step

Below is a reproducible workflow that adds low‑overhead instrumentation to a Fabric app, validates the data, and uses it to decide if the rewrite is worthwhile.

1. Enable the Fabric‑specific PerfMarkers

Fabric ships a set of PerfMarker strings that are emitted via ReactPerfLogger. They are only active when the RCT_ENABLE_FABRIC build flag is true and when RCT_DEV is true.

What to do

# In ios/Podfile or android/app/build.gradle set:
RCT_ENABLE_FABRIC=1
RCT_DEV=1

Then rebuild the app (npx react-native run-android or run-ios).

Why
These markers are emitted as RCTLog events that systrace can capture. They give you timestamps for:

FabricMountStart / FabricMountStop
FabricLayoutStart / FabricLayoutStop
FabricCommitStart / FabricCommitStop

How to confirm

Run adb shell setprop debug.reactperf 1 (Android) or set the RCT_DEBUG environment variable (iOS). Then launch the app and open adb logcat | grep PerfMarker. You should see lines like:

[PerfMarker] FabricMountStart: 1234567890
[PerfMarker] FabricMountStop: 1234567950

If you see matching start/stop pairs, the markers are active.

2. Capture the markers with Systrace (or Perfetto)

Systrace aggregates PerfMarker events into a timeline you can view in Chrome.

What to do

# Android
adb shell atrace --async_start -c -b 4096 -t 10 -z -o /data/local/tmp/trace.html \
    -a com.yourapp -p com.facebook.react.perfmarker

adb pull /data/local/tmp/trace.html .

Open trace.html in Chrome’s chrome://tracing UI. Look for the Fabric sections; they will appear as distinct rows labelled “FabricMount”, “FabricLayout”, etc.

Why
The visual timeline lets you compare the duration of each phase before and after your optimisation.

How to confirm

Zoom into a frame where you expect a change (e.g., a scroll event). Note the duration of FabricMount in milliseconds. Record the value (e.g., 3.2 ms). Do the same for the baseline (legacy) build; you should see a separate set of markers called BridgeMount with a larger duration (e.g., 7.8 ms).

If the numbers differ, you have measurable data.

3. Add a custom `RCTPerformanceLogger` counter

The built‑in RCTPerformanceLogger stores timings in a circular buffer. You can add a custom counter for “total frame time” that includes both JS and UI work.

What to do

Create a native module (Android example):

// FabricPerfModule.java
package com.yourapp;

import com.facebook.react.bridge.ReactApplicationContext;
import com.facebook.react.bridge.ReactContextBaseJavaModule;
import com.facebook.react.modules.core.DeviceEventManagerModule;
import com.facebook.react.uimanager.ReactPerformanceLogger;

public class FabricPerfModule extends ReactContextBaseJavaModule {
  private static final int CUSTOM_TOTAL_FRAME = 1000; // arbitrary id > 500

  public FabricPerfModule(ReactApplicationContext reactContext) {
    super(reactContext);
    ReactPerformanceLogger logger = ReactPerformanceLogger.getInstance();
    logger.addCustomMetric(CUSTOM_TOTAL_FRAME);
  }

  @Override
  public String getName() {
    return "FabricPerf";
  }

  // Expose a method to JS to read the metric
  @ReactMethod
  public void getLastFrameTime(Promise promise) {
    long duration = ReactPerformanceLogger.getInstance()
        .getDuration(CUSTOM_TOTAL_FRAME);
    promise.resolve(duration);
  }
}

import {NativeModules} from 'react-native';
export const getLastFrameTime = () => NativeModules.FabricPerf.getLastFrameTime();

Why
A custom metric lets you aggregate the time spent in FabricMount + FabricLayout + JS execution for each frame, giving a single “frame budget” number you can compare against the 16 ms target for 60 fps.

How to confirm

Add a useEffect hook that logs the value after each render:

useEffect(() => {
  const id = setInterval(async () => {
    const ms = await getLastFrameTime();
    console.log('Last frame time (ms):', ms);
  }, 1000);
  return () => clearInterval(id);
}, []);

Run the app and watch the console. You should see a stable series of numbers (e.g., 12.4, 13.1). If the numbers stay below 16 ms consistently, you have quantitative proof of success.

4. Automate regression detection in CI

Instrumented measurements are only useful if they are repeatable. Add a script that runs the app on a headless emulator, captures the PerfMarker trace, extracts the average FabricMount duration, and fails the build if it exceeds a threshold.

What to do

Create a Node script measure-fabric.js:

const {execSync} = require('child_process');
const fs = require('fs');

function runTrace() {
  execSync(`adb shell setprop debug.reactperf 1`);
  execSync(`adb shell am start -n com.yourapp/.MainActivity`);
  execSync(`adb shell sleep 5`); // let the app settle
  execSync(`adb shell atrace --async_start -c -b 4096 -t 5 -z -o /data/local/tmp/trace.html -a com.yourapp -p com.facebook.react.perfmarker`);
  execSync(`adb pull /data/local/tmp/trace.html .`);
}

function parseTrace() {
  const html = fs.readFileSync('trace.html', 'utf8');
  const mountTimes = [...html.matchAll(/FabricMountStart.*?(\d+).*?FabricMountStop.*?(\d+)/g)]
    .map(m => Number(m[2]) - Number(m[1]));
  const avg = mountTimes.reduce((a,b) => a+b,0) / mountTimes.length;
  return avg;
}

runTrace();
const avgMount = parseTrace();
console.log(`Average FabricMount: ${avgMount.toFixed(2)} ms`);
if (avgMount > 4.0) {
  console.error('❌ FabricMount exceeds budget (4 ms)');
  process.exit(1);
}

Add this step to your CI pipeline (e.g., GitHub Actions).

Why
CI gating prevents accidental regressions caused by future library upgrades or code changes.

How to confirm

Push a change that deliberately adds a heavy view (e.g., a FlatList with 10 000 items). The CI run should fail, printing the “exceeds budget” message. Reverting the change restores the green status, proving the test works.

5. Correlate with real‑world metrics (FPS, UI‑thread CPU)

Instrumentation inside the app tells you about internal timings, but the ultimate metric is frames per second as observed by the user. Use Android’s adb shell dumpsys gfxinfo or iOS’s measureFPS tool to capture the FPS while the same interactions are performed.

What to do (Android)

adb shell dumpsys gfxinfo com.yourapp > gfx.txt
# Parse the “Total” column for each frame; compute average FPS

What to do (iOS)

Open Xcode Instruments → “Core Animation” → record a scroll session. Export the CSV and calculate average FPS.

Why
If your Fabric metrics show a 3 ms reduction in mount time but FPS stays at 55 fps, the bottleneck lies elsewhere (e.g., image decoding).

How to confirm

Run the same scripted scroll (e.g., using detox or appium) on both the legacy and Fabric builds. Compare the average FPS numbers:

Build	Avg Mount (ms)	Avg FPS
Legacy	7.8	48
Fabric	3.2	57

A clear uplift in both columns validates that the rewrite is worth shipping.

What it costs, and when not to do it

Cost	Detail
Runtime overhead	Each `PerfMarker` incurs a nanosecond‑scale write to a shared buffer. In production builds the overhead is typically < 0.5 % CPU on modern devices, but on low‑end Android (e.g., Snapdragon 450) you may see a 1–2 % increase in UI‑thread utilisation.
Bundle size	Adding the native module (`FabricPerfModule`) adds ~30 KB of compiled code (mostly logging glue). This is negligible compared with the overall binary (≈ 30 MB).
Build complexity	Enabling `RCT_ENABLE_FABRIC` and `RCT_DEV` together forces a debug build; you cannot collect these markers from a release‑signed APK. Therefore you must maintain a separate “performance‑profile” build variant.
Data noise	In CI, emulator timing can be unstable. Use a physical device (e.g., Pixel 5) with a locked CPU frequency to obtain reproducible numbers.
When not to do it	• If the feature under test is a one‑off UI change that will not be shipped to many users. • When you are already at the 60 fps ceiling and additional optimisation yields diminishing returns. • In a hot‑fix window where adding native modules would delay the release more than the performance gain.

In practice, the benefit‑to‑cost ratio is favourable when you are:

Targeting a high‑traffic screen (e.g., home feed) where a 2 ms reduction translates to a measurable increase in retained users.
Working on a platform‑wide migration (all screens will run on Fabric), making the instrumentation a reusable asset.

At your level

Role	Take‑away	One concrete next step
Student / first‑year	Instrumentation is the only way to turn “it feels faster” into a defensible claim.	Add the `FabricPerfModule` to a sample app, run the CI script locally, and verify the average mount time printed.
Working engineer	Use the built‑in `PerfMarker`s plus a custom counter to create a regression test that gates future changes.	Integrate `measure-fabric.js` into your existing CI pipeline and set a realistic budget (e.g., 4 ms for mount).
Senior / staff	Correlate internal timings with user‑facing metrics (FPS, ANR rate) and expose the data in a dashboard for product owners.	Build a small internal Grafana panel that ingests the CI JSON output and shows trends across releases.
Lead / director	Allocate budget for a dedicated performance‑profiling build variant and for the hardware (mid‑range test phones) needed to keep measurements trustworthy.	Approve purchase of two representative Android devices and schedule a weekly “Performance Health” meeting that reviews the Fabric metrics.

In the interview

Typical interview prompt

“We migrated a large screen from the legacy renderer to Fabric. How would you prove that the migration actually improved performance, and how would you decide whether the effort was justified?”

Weak answer

“I would look at the FPS counter in the developer menu and compare before/after. If the FPS goes up, the migration is good.”

Why it’s weak: It mentions only a surface‑level metric, ignores internal work redistribution, provides no method for repeatable measurement, and does not discuss trade‑offs or failure modes.

Strong answer

Identify the constraint – the 16 ms per‑frame budget for 60 fps on target devices.
Instrument the new path – enable Fabric PerfMarkers, add a custom RCTPerformanceLogger counter for total frame time, and capture the data with Systrace/Perfetto.
Validate the data – confirm start/stop pairs appear, extract average FabricMount and FabricLayout durations, and compare them to the legacy BridgeMount numbers.
Correlate with user‑facing metrics – run adb shell dumpsys gfxinfo (or iOS Instruments) on the same scripted interaction to ensure FPS improves in proportion to the internal timing reduction.
**Quantify the cost

React, deeply · 1. Rendering and reconciliation: what React does on a state change

Amit chakraborty — Mon, 19 Oct 2026 16:30:11 +0000

React, deeply · Chapter 1 of 12 · Web · new chapter every Monday night

By the end of this chapter: Describe the render, reconcile and commit phases precisely enough to predict behaviour.

The problem

Emma is a front‑end engineer on a two‑month sprint for a real‑time analytics dashboard. The UI pulls live metrics from a WebSocket and updates a table every second. After merging a new “filter by region” feature, the dashboard starts missing updates: the table lags by up to three seconds, the CPU on the user’s laptop spikes to 90 % and the performance monitoring alert fires every time a user opens the page. The sprint deadline is three days away, and the team cannot afford to roll back the feature.

Emma knows that React’s useState call in the filter component is being invoked correctly – the state value changes, the UI shows the new region label – but she cannot see why the rest of the component tree is taking so long to reflect the new data. She has the React docs open, but they only describe the high‑level “React re‑renders when state changes”. She needs a concrete, step‑by‑step mental model of what React actually does after a state change, how the three phases (render, reconciliation, commit) interact, and how to predict whether a change will cause extra work. Only then can she pinpoint the bottleneck and fix the dashboard before the deadline.

Before you start

Node ≥ 18.15.0
npm ≥ 9.6.0
React 18.2.0 and React‑DOM 18.2.0 (the current stable release as of October 2026)
A fresh create‑react‑app project (or any existing React 18 app) – run npx create-react-app r18-demo --template cra-template-pwa to get a working baseline.
Verify the setup works by starting the dev server and seeing “Edit src/App.js” in the browser:

cd r18-demo
npm start
# Expected output in the terminal:
# > Local:   http://localhost:3000
# Open that URL – you should see the default CRA page.

If the page renders, you have a correct environment and can proceed.

What does a state update trigger?

1. Does React schedule work or run it immediately?

When setState (or the setter returned by useState) is called, React does not synchronously touch the DOM. Instead it creates a update object, pushes it onto the fiber’s update queue, and asks the scheduler to perform work. In React 18 the scheduler always batches updates that happen within the same tick, even if they originate from different event sources.

Why it matters: If you call setState inside a setTimeout, React still batches that call with any other updates that happen before the next paint. Knowing the batching behaviour tells you whether a series of rapid state changes will cause a single render or many.

2. Render phase – building the “virtual” tree

During the render phase React walks the fiber tree depth‑first, calling each component function to produce a new React element tree (the “virtual DOM”). No side‑effects run here – even useEffect callbacks are not executed. The result is a new set of fibers that mirror the element tree.

Key points:

Concept	What happens	Why it matters
Pure function execution	Component bodies run with the current state/props.	Guarantees determinism – the same inputs give the same output.
Hooks order	React validates that the hook call order matches the previous render.	Mismatched order throws “Rendered more hooks than during the previous render”.
Early bail‑out	If a component’s props and state are shallow‑equal to the previous render, React may skip rendering its children (the memo optimisation).	Prevents unnecessary work.

You can confirm the render phase by adding console.log('render', name) at the top of a component; you’ll see it run before any DOM changes.

3. Reconciliation – diffing the old and new fibers

After the new tree is built, React enters the reconciliation (or “diff”) phase. It compares the new fibers with the previous ones to decide what needs to change.

Keyed children – If a list has a stable key prop, React can match old and new items by key, moving existing DOM nodes instead of recreating them. Without keys, React falls back to index‑based matching, which can cause unnecessary re‑mounts.
Type change – If the element type changes (e.g., <div> → <span>), React discards the old fiber subtree and creates a new one.
Effect list construction – While reconciling, React builds three linked lists: Placement, Update, and Deletion. These lists are later used in the commit phase.

The cost of reconciliation is proportional to the number of fibers examined. A deep tree with many siblings can become expensive if keys are missing or if component props change on every render.

4. Commit phase – mutating the DOM and running effects

The commit phase is the only phase that mutates the host environment (the browser DOM). It proceeds in three sub‑steps:

Before mutation – Runs getSnapshotBeforeUpdate (class components) and prepares layout effects. No DOM changes yet.
Mutation – Applies all changes from the effect lists: inserts, updates, deletions. This is where the browser repaints.
Layout effects – Executes useLayoutEffect callbacks synchronously after the DOM mutation but before the browser paints.
Passive effects – Schedules useEffect callbacks to run after the paint (asynchronously).

Because layout effects run before the browser paints, they can block rendering if they perform heavy work. Passive effects, on the other hand, never block the paint.

How to observe each phase in a real component

1. How can I tell when the render phase starts and ends?

Add a console.time/console.timeEnd pair at the top of the component:

function TableRow({ row }) {
  console.time('TableRow render');
  // component body …
  console.timeEnd('TableRow render');
  return <tr>{/* … */}</tr>;
}

The console will show a line like TableRow render: 0.42ms. If you see many rows each taking > 1 ms, the render phase is a candidate for optimisation.

2. How do I see the reconciliation decisions?

React DevTools’ “Profiler” tab records mount and update timings and shows a “flame graph”. Hover over a component to see whether the update was a “re‑render” (same type, same key) or a “re‑mount” (type changed, key missing). A re‑mount will display a “Mount” badge.

3. How can I verify when effects run relative to the DOM mutation?

Insert logs in both useLayoutEffect and useEffect:

useLayoutEffect(() => {
  console.log('layout effect – DOM ready');
}, [data]);

useEffect(() => {
  console.log('passive effect – after paint');
}, [data]);

Open the console and watch the order. Layout effects will always appear before the passive ones for the same update.

Build it – instrument a component to visualise the three phases

Below is a minimal reproducible example that logs every phase for a component that displays a counter. Follow the steps exactly; each command’s output is shown so you can confirm you’re on track.

Create the component file

   mkdir -p src/diagnostics && touch src/diagnostics/PhaseLogger.jsx

Add the code (src/diagnostics/PhaseLogger.jsx):

   import React, { useState, useLayoutEffect, useEffect } from 'react';

   export default function PhaseLogger() {
     const [count, setCount] = useState(0);

     console.time(`render ${count}`);

     // Render phase ends when the function returns
     console.timeEnd(`render ${count}`);

     useLayoutEffect(() => {
       console.log('🔧 layout effect – count:', count);
     }, [count]);

     useEffect(() => {
       console.log('🌀 passive effect – count:', count);
     }, [count]);

     return (
       <div>
         <p>Count: {count}</p>
         <button onClick={() => setCount(c => c + 1)}>+1</button>
       </div>
     );
   }

Why: console.time/console.timeEnd surround the component body, marking the render phase. The two effects log when they fire.

Render the component – replace the default App content with PhaseLogger:

   // src/App.js
   import React from 'react';
   import PhaseLogger from './diagnostics/PhaseLogger';

   function App() {
     return (
       <div className="App">
         <PhaseLogger />
       </div>
     );
   }

   export default App;

Run the dev server (if not already running):

   npm start

Observe the console – open Chrome DevTools, go to the Console tab, and click the “+1” button three times. You should see a repeating pattern:

   render 0: 0.12ms
   🔧 layout effect – count: 0
   🌀 passive effect – count: 0
   render 1: 0.09ms
   🔧 layout effect – count: 1
   🌀 passive effect – count: 1
   …

Confirmation: The render log appears before any effect logs, proving the order of phases.

Add a heavy computation to the render to see the impact:

   // Inside PhaseLogger, before the return:
   const heavy = Array.from({ length: 1e5 }, (_, i) => i).reduce((a, b) => a + b, 0);
   console.log('heavy sum', heavy);

Reload the page and click the button. The render time will jump (e.g., render 2: 12.4ms). This demonstrates how expensive work in the render phase directly slows the UI.

Move the heavy work to a layout effect:

   useLayoutEffect(() => {
     const heavy = Array.from({ length: 1e5 }, (_, i) => i).reduce((a, b) => a + b, 0);
     console.log('layout heavy sum', heavy);
   }, [count]);

Remove the computation from the render body. Now the render logs stay ~0.1 ms, while the layout effect logs the heavy sum. The UI feels snappier because the render phase is fast, but the layout effect blocks the paint – you’ll notice a brief freeze after each click.

Finally, move the work to a passive effect:

   useEffect(() => {
     const heavy = Array.from({ length: 1e5 }, (_, i) => i).reduce((a, b) => a + b, 0);
     console.log('passive heavy sum', heavy);
   }, [count]);

Now the render is fast, the layout effect does nothing, and the heavy sum appears after the paint. The UI feels responsive, but the heavy work still consumes CPU in the background.

You have built a minimal instrumented component that demonstrates the three phases, their ordering, and the performance impact of doing work in each phase.

When this breaks

Symptom (what you see)	Likely cause	Fix
“Maximum update depth exceeded” (stack overflow)	A state update inside a `useEffect` (or `useLayoutEffect`) that depends on the same state, causing an infinite loop.	Ensure the effect’s dependency array does not include the state you set, or guard the update with a condition. Example: `useEffect(() => { if (ready) setState(...); }, [ready]);`
Rows in a list lose their input values after a filter change	Missing `key` on list items, causing React to treat them as new mounts on each filter.	Add a stable `key` prop (e.g., `key={row.id}`) to every element in the array map.
UI freezes for ~200 ms after a state change, even though the component is tiny	Heavy computation performed during the render phase (or inside a `useLayoutEffect`).	Move the work to a `useEffect` (passive) or, if it must be synchronous, memoise it with `useMemo` and ensure the memoisation dependencies are correct.
`useLayoutEffect` logs appear after the DOM is painted	Running the app in React 18’s concurrent mode with `StrictMode` enabled, which intentionally runs layout effects twice in development.	Remember that the double‑run only happens in dev; it does not affect production. If the double execution is problematic, temporarily disable `StrictMode` for that subtree.
Profiler shows “mount” instead of “update” for a component that should only re‑render	The component’s `key` changed between renders, or its type changed (e.g., switching from `<ComponentA>` to `<ComponentB>`).	Keep the component type and key stable; if you need to swap implementations, wrap them in a parent that preserves the key.

Each of these failures can be reproduced by the instrumented PhaseLogger component: add a setState inside an effect that depends on the same state to trigger the infinite loop; remove key from a list to see lost inputs; insert a heavy loop in the render body to cause a freeze.

What it costs

Technique	Trade‑off
Running heavy work in the render phase	Guarantees the DOM reflects the latest data before the paint, but each render blocks the main thread, leading to jank. Use only for cheap calculations.
Using `useLayoutEffect` for synchronisation	Provides a hook that runs before the paint, useful for measuring layout or synchronising scroll positions. However, it blocks the paint and can cause noticeable pauses on low‑end devices.
Moving work to `useEffect` (passive)	Keeps the UI responsive because the effect runs after the paint. The downside is that any DOM measurement must be deferred, and the UI may briefly show an intermediate state.
Relying on key‑based reconciliation	Greatly reduces unnecessary re‑mounts, but requires that every item in a list has a stable, unique identifier. Generating keys on the fly (e.g., using `index`) defeats the optimisation and can cause state loss.
Batching updates (default in React 18)	Reduces the number of renders, but can hide bugs where you expect an immediate DOM update after a `setState`. If you need the update instantly, use `flushSync` (cost: forces a synchronous render, defeating the batch).

Understanding these costs lets you decide where to place work in the lifecycle and when to sacrifice immediacy for smoother frames.

In the interview

Typical interview prompt

“Walk me through what happens when you call setState in a function component. Include the phases React goes through and why the order matters.”

Weak answer – “React re‑renders the component and updates the DOM.”

Why it’s weak: It mentions only the render, omits reconciliation and commit, ignores effects, and gives no insight into performance implications.

Strong answer –

Scheduling – React creates an update object, pushes it onto the fiber’s queue, and asks the scheduler to perform work; updates are batched.
Render phase – React calls the component function, builds a new virtual tree, and validates hook order; no side‑effects run.
Reconciliation – The new tree is diffed against the previous one; keys guide matching, and three effect lists (Placement, Update, Deletion) are built.
Commit phase – React first runs getSnapshotBeforeUpdate/layout effects, then mutates the DOM according to the effect lists, then runs passive effects after the paint.
Why order matters – Doing heavy work in render or layout effect blocks the paint, causing jank; passive effects run asynchronously and cannot block the UI.

Senior‑level expectation – In addition to the above, discuss:

The role of the Fiber data structure and how it enables interruption (concurrent mode).
How strict mode in development double‑invokes render and layout effects, and why that matters for debugging.
The cost model: O(N) traversal of the fiber tree, the impact of missing keys, and the memory overhead of keeping two trees simultaneously.

Director/Engineering‑manager angle – The interviewer may ask: “How would you decide whether to optimise a component based on this model?” A good answer references measurable render times, the cost of extra DOM nodes, and the business impact (e.g., latency SLA).

Follow‑up that separates theory from practice – “Can you give an example of a bug you encountered that stemmed from misunderstanding the commit phase?” A candidate who describes an infinite render loop caused by a useEffect that set state without a guard demonstrates real‑world experience.

Your tasks

Log the three phases in an existing component

Add console.time/console.timeEnd around the component body, and useLayoutEffect/useEffect logs as shown in the “Build it” section.

Done when you can see the render log, layout effect log, and passive effect log in the correct order for each state change.
Identify a needless re‑mount

In a list component that renders <input> fields, remove the key prop, type into an input, then trigger a state change that filters the list. Observe that the input loses its value.

Done when you add a stable key and the input retains its value across filters.
Create and fix an infinite render loop

Add a useEffect(() => setCount(c => c + 1), [count]); to a component. Observe the “Maximum update depth exceeded” error. Then fix it by adding a guard (if (count < 5) setCount(...)).

Done when the component updates without crashing and the console no longer shows the error.
Measure the impact of moving work between phases

Implement a 100 ms for‑loop in the render body, then move it to a useLayoutEffect, then to a useEffect. Use the Chrome Performance tab to record each version and note the CPU time and frame rate differences.

Done when you can state the measured frame‑time for each version and explain why the passive effect version is the most performant for UI responsiveness.
Optimise a list with missing keys

Take a component that renders 500 rows, each with a button that toggles a local selected state. Remove the keys, observe that toggling one row causes many rows to re‑mount. Add stable keys and verify that only the clicked row re‑renders (use the React Profiler to confirm).

Done when the Profiler shows a single “Update” for the clicked row and no unnecessary mounts.

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.

React, deeply

Chapter 1 of 12. New chapter every Monday night.
Next: State that scales: useState, useReducer and the point they stop working.

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.

Reconciling Dual Crypto and Fiat Payments in a Mobile App

Amit chakraborty — Mon, 19 Oct 2026 16:30:06 +0000

The situation

Say you are a lead mobile engineer on a fintech startup that just launched a React Native app supporting both fiat purchases (via Stripe) and crypto purchases (via a custodial blockchain API). The product roadmap promised “one‑tap buying” for either asset class. After the first week of production, the support inbox filled with complaints:

“My crypto purchase shows as pending forever, but my card was charged.”
“I was refunded twice for a fiat transaction.”
“The dashboard shows a total balance that does not match the sum of my individual transactions.”

The team spent three days investigating, discovered that the backend was creating duplicate transaction records, and that some on‑chain confirmations never arrived before the retry logic gave up. The cost was lost revenue (refunds), increased support load, and a delay in the next sprint while the bug‑fix branch was merged.

The rest of this guide shows how to design a reliable reconciliation layer that survives production load, handles retries without double‑charging, and makes every state observable to the client.

Why it happens

1. Asymmetric latency

Fiat gateways are typically synchronous: a card‑present request returns a success or decline within seconds. Crypto APIs are asynchronous; a transaction is submitted to the mempool, then confirmed after an indeterminate number of blocks (often 1‑5 minutes). If the mobile client treats both responses as “completed” at the same point, the UI will display a success while the blockchain is still pending.

2. Lack of idempotency

Both Stripe and most custodial crypto services accept an idempotency_key header, but the key is often generated on the client. If the client retries after a network glitch and generates a new key, the backend creates a second charge. The database ends up with two rows that look identical except for the key.

3. Partial failure windows

Consider the following sequence:

Mobile app sends a fiat charge request → Stripe returns succeeded.
The same request also triggers a crypto purchase request → the custodial API returns queued.
The backend writes two rows: fiat_status = succeeded, crypto_status = pending.
The app crashes before receiving the webhook that updates crypto_status to confirmed.

Now the system holds a mixed state: the user has been debited, but the crypto asset is not credited. Without a periodic reconciliation job, this state persists indefinitely.

4. Race conditions in status updates

Webhooks from Stripe and from the custodial provider may arrive out of order. If the fiat webhook marks the transaction completed and the crypto webhook later marks it failed, the final state may be incorrectly set to failed unless the system tracks the source of each status change.

5. Missing “unknown” bucket

Most documentation lists three statuses: pending, succeeded, failed. Production reveals a fourth reality: unknown – the system has not received any confirmation within the expected window (e.g., 15 minutes for crypto, 30 seconds for fiat). Treating “unknown” as “failed” forces premature refunds; treating it as “pending” leaves users staring at a stale UI.

The fix, step by step

Below is a production‑grade pattern that works with React Native 0.76, Node 18, PostgreSQL 15, Stripe 2023‑10‑16, and a custodial crypto API that follows the JSON‑RPC 2.0 spec.

Step 1 – Define a single source of truth for transaction state

Create a table that stores one logical transaction, with separate columns for each rail.

CREATE TABLE user_transactions (
    id               UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id          UUID NOT NULL,
    amount_cents     BIGINT NOT NULL,
    currency         TEXT NOT NULL,               -- e.g. 'USD' or 'USDC'
    fiat_status      TEXT NOT NULL DEFAULT 'none',-- none|pending|succeeded|failed|unknown
    crypto_status    TEXT NOT NULL DEFAULT 'none',
    fiat_intent_id   TEXT,                        -- Stripe PaymentIntent ID
    crypto_tx_hash   TEXT,                        -- on‑chain transaction hash
    idempotency_key  TEXT NOT NULL,
    created_at       TIMESTAMP WITH TIME ZONE DEFAULT now(),
    updated_at       TIMESTAMP WITH TIME ZONE DEFAULT now()
);

Why: A single row guarantees that retries affect the same logical purchase, preventing duplicate charges. The none status distinguishes “no request sent yet” from “pending”.

Confirm: Run SELECT COUNT(*) FROM user_transactions; – it should return 0 on a fresh DB.

Step 2 – Generate a stable idempotency key on the server

Never let the client create the key. In the API endpoint that starts a purchase, generate a UUID and store it before any external call.

// src/routes/purchase.js (Node/Express)
import { v4 as uuidv4 } from 'uuid';
import { db } from '../db.js';
import stripe from 'stripe')(process.env.STRIPE_SECRET);
import { submitCryptoTx } from '../crypto.js';

router.post('/purchase', async (req, res) => {
  const { userId, amountCents, currency, paymentMethodId } = req.body;

  const idempotencyKey = uuidv4();

  const tx = await db.one(
    `INSERT INTO user_transactions
       (user_id, amount_cents, currency, idempotency_key, fiat_status, crypto_status)
     VALUES ($1,$2,$3,$4,'pending','pending')
     RETURNING *`,
    [userId, amountCents, currency, idempotencyKey]
  );

  // Fire‑and‑forget calls; errors are handled by retry workers.
  stripe.paymentIntents.create(
    {
      amount: amountCents,
      currency: currency.toLowerCase(),
      payment_method: paymentMethodId,
      confirm: true,
    },
    { idempotencyKey }
  ).then(pi => {
    db.none(
      `UPDATE user_transactions SET fiat_intent_id=$1, fiat_status='succeeded'
       WHERE id=$2 AND fiat_status='pending'`,
      [pi.id, tx.id]
    );
  }).catch(err => {
    db.none(
      `UPDATE user_transactions SET fiat_status='failed'
       WHERE id=$1 AND fiat_status='pending'`,
      [tx.id]
    );
  });

  submitCryptoTx({
    amount: amountCents,
    currency,
    userId,
    idempotencyKey,
  }).then(hash => {
    db.none(
      `UPDATE user_transactions SET crypto_tx_hash=$1, crypto_status='pending'
       WHERE id=$2 AND crypto_status='pending'`,
      [hash, tx.id]
    );
  }).catch(err => {
    db.none(
      `UPDATE user_transactions SET crypto_status='failed'
       WHERE id=$1 AND crypto_status='pending'`,
      [tx.id]
    );
  });

  res.json({ transactionId: tx.id });
});

Why: The same idempotency_key is reused for both Stripe and the crypto provider, guaranteeing that any retry hits the same logical operation.

Confirm: After a successful POST, query the row:

psql -c "SELECT fiat_status, crypto_status FROM user_transactions WHERE id='<returned-id>';"

Both columns should read pending.

Step 3 – Persist webhook events with ordering metadata

Both Stripe and the custodial provider send webhooks. Store each webhook payload in a separate webhook_events table with a received_at timestamp and a source field (stripe|crypto). Then process them in order of received_at.

CREATE TABLE webhook_events (
    id          BIGSERIAL PRIMARY KEY,
    source      TEXT NOT NULL,
    payload     JSONB NOT NULL,
    received_at TIMESTAMP WITH TIME ZONE DEFAULT now(),
    processed   BOOLEAN DEFAULT FALSE
);

Processing worker (Node):

import { db } from './db.js';

async function processEvents() {
  const events = await db.any(
    `SELECT * FROM webhook_events
     WHERE processed = FALSE
     ORDER BY received_at ASC
     LIMIT 100`
  );

  for (const ev of events) {
    if (ev.source === 'stripe') {
      const pi = ev.payload.data.object;
      await db.none(
        `UPDATE user_transactions
         SET fiat_status = CASE
               WHEN pi.status = 'succeeded' THEN 'succeeded'
               WHEN pi.status = 'requires_payment_method' THEN 'failed'
               ELSE 'unknown'
             END
         WHERE fiat_intent_id = $1`,
        [pi.id]
      );
    } else if (ev.source === 'crypto') {
      const { tx_hash, status } = ev.payload;
      await db.none(
        `UPDATE user_transactions
         SET crypto_status = CASE
               WHEN status = 'confirmed' THEN 'succeeded'
               WHEN status = 'reverted'   THEN 'failed'
               ELSE 'unknown'
             END
         WHERE crypto_tx_hash = $1`,
        [tx_hash]
      );
    }

    await db.none(`UPDATE webhook_events SET processed = TRUE WHERE id = $1`, [ev.id]);
  }
}

Why: Ordering guarantees that a later “failed” event cannot overwrite an earlier “succeeded” event for the same rail. The unknown bucket captures any status that does not map cleanly.

Confirm: Insert a test webhook payload manually and run processEvents(). Verify that the corresponding transaction row updates as expected.

Step 4 – Add a periodic reconciliation job

Even with webhooks, network outages can drop events. Run a nightly job that scans for rows where either status is still pending after a timeout and queries the external API directly.

async function reconcile() {
  const stale = await db.any(
    `SELECT * FROM user_transactions
     WHERE (fiat_status = 'pending' AND created_at < now() - interval '30 seconds')
        OR (crypto_status = 'pending' AND created_at < now() - interval '10 minutes')`
  );

  for (const tx of stale) {
    // Re‑query Stripe
    if (tx.fiat_status === 'pending') {
      const pi = await stripe.paymentIntents.retrieve(tx.fiat_intent_id);
      await db.none(
        `UPDATE user_transactions SET fiat_status = $1 WHERE id = $2`,
        [pi.status === 'succeeded' ? 'succeeded' : 'failed', tx.id]
      );
    }

    // Re‑query crypto provider
    if (tx.crypto_status === 'pending') {
      const status = await queryCryptoStatus(tx.crypto_tx_hash);
      await db.none(
        `UPDATE user_transactions SET crypto_status = $1 WHERE id = $2`,
        [status, tx.id]
      );
    }
  }
}

Timeout values: 30 seconds for fiat (Stripe’s typical response window) and 10 minutes for crypto (average block confirmation on Ethereum mainnet). Adjust based on the chain you use; for Solana you might use 30 seconds, for Bitcoin 20 minutes.

Confirm: Run the job manually after creating a pending transaction and verify the status changes to succeeded or failed within the expected window.

Step 5 – Implement exponential back‑off retries for external calls

Network glitches are inevitable. Wrap each external request in a retry helper that respects the idempotency key.

import retry from 'async-retry';

async function safeStripeIntent(params, idempotencyKey) {
  return retry(async bail => {
    try {
      return await stripe.paymentIntents.create(params, { idempotencyKey });
    } catch (err) {
      if (err.type === 'card_error' || err.type === 'invalid_request_error') {
        // Do not retry on client errors
        bail(err);
        return;
      }
      throw err; // retry
    }
  }, {
    retries: 5,
    minTimeout: 500,      // 0.5 s
    maxTimeout: 4000,     // 4 s
    factor: 2,
  });
}

Why: The bail call prevents endless retries on unrecoverable errors (e.g., insufficient funds). The exponential back‑off caps total retry time at ~7 seconds per call, which is acceptable for a user‑initiated purchase.

Confirm: Simulate a transient network error (e.g., by blocking outbound traffic for 2 seconds) and observe that the request eventually succeeds without creating duplicate rows.

Step 6 – Surface a combined status to the mobile client

Expose an endpoint that returns a derived status: complete only when both rails are succeeded; partial_success when one succeeded and the other is failed; in_progress when any rail is pending or unknown.

router.get('/transaction/:id', async (req, res) => {
  const tx = await db.oneOrNone(
    `SELECT fiat_status, crypto_status FROM user_transactions WHERE id=$1`,
    [req.params.id]
  );

  if (!tx) return res.status(404).send('Not found');

  let overall;
  if (tx.fiat_status === 'succeeded' && tx.crypto_status === 'succeeded')
    overall = 'complete';
  else if (tx.fiat_status === 'failed' && tx.crypto_status === 'failed')
    overall = 'failed';
  else if (tx.fiat_status === 'succeeded' || tx.crypto_status === 'succeeded')
    overall = 'partial_success';
  else
    overall = 'in_progress';

  res.json({ overall, fiat_status: tx.fiat_status, crypto_status: tx.crypto_status });
});

Confirm: Hit the endpoint with curl after each stage and verify the JSON reflects the expected overall value.

Step 7 – Guard against double refunds

When a transaction ends in failed on either rail, the refund logic must check the other rail’s status before issuing a second refund.

Engineering Resilient Systems for a Magnitude 5.7 Earthquake in Pakistan

Amit chakraborty — Mon, 19 Oct 2026 08:30:17 +0000

Observed 2026‑10‑17 – USGS event page

The sudden release of strain that generated a 5.7‑magnitude event in Pakistan highlights the need for engineered solutions that operate under extreme time pressure and with severely degraded communications. This article examines four technical domains that are repeatedly stressed in such scenarios: early‑warning latency budgets, offline‑first responder applications, store‑and‑forward mesh networking, and high‑throughput sensor data pipelines.

Early‑Warning Systems and the Seconds‑Matter Latency Budget

Detection Chain and Latency Constraints

An earthquake early‑warning (EEW) system must capture the initial P‑wave (primary wave) and disseminate an alert before the damaging S‑wave (secondary wave) arrives. In the Pakistani context, the distance between the epicenter and the most vulnerable urban centers can be on the order of 30–70 km, giving a theoretical warning window of 3–10 seconds. The latency budget therefore breaks down into distinct stages:

Stage	Typical Duration	Engineering Implications
Sensor acquisition (accelerometer/strong‑motion)	≤ 10 ms	High‑rate sampling (≥ 200 Hz) and low‑noise front‑ends to guarantee reliable P‑wave detection.
On‑site trigger algorithm	20–50 ms	Deterministic, low‑complexity classifiers (e.g., STA/LTA) running on embedded microcontrollers; deterministic execution avoids jitter.
Edge aggregation & validation	30–100 ms	Redundant edge nodes cross‑validate triggers to suppress false alarms; requires ultra‑low‑latency inter‑node messaging (e.g., IEEE 802.15.4e TSCH).
Alert generation & encoding	≤ 20 ms	Compact binary payloads (≤ 64 bytes) to minimize transmission time; include timestamp, magnitude estimate, and location.
Distribution (cellular, broadcast, satellite)	100 ms–1 s	Multi‑path broadcast (cellular SMS, LTE‑M, satellite beacons) with priority queuing; network‑level QoS tagging is mandatory.
End‑user device processing	≤ 50 ms	Pre‑loaded EEW clients that parse binary alerts, compute local arrival times, and trigger UI/actuator responses.

Summing the upper bounds yields a worst‑case latency of roughly 1.3 seconds, comfortably within the available warning window for most urban receivers. However, any single stage that exceeds its budget can erode the entire margin, making deterministic design and rigorous profiling essential.

Trade‑offs in Algorithmic Design

Sensitivity vs. false‑positive rate – Lowering detection thresholds improves early detection but increases spurious alerts, which erodes public trust. A hierarchical approach (local trigger → regional consensus) mitigates this risk.
Computation vs. power – High‑frequency sampling and complex signal processing increase power draw on battery‑powered stations. Ultra‑low‑power DSPs (e.g., ARM Cortex‑M4 with hardware multiply‑accumulate) enable real‑time processing while preserving multi‑year autonomy.
Centralized vs. decentralized validation – Central servers can apply sophisticated Bayesian filters but introduce network latency. Decentralized peer validation keeps latency low but requires robust consensus protocols (e.g., Raft with sub‑second election timeouts).

Failure Modes and Mitigations

Failure Mode	Symptom	Mitigation
Sensor saturation (clipping)	No P‑wave detection	Deploy dual‑range accelerometers; implement automatic gain control.
Communication blackout (cellular overload)	Alert not delivered	Multi‑modal broadcast (cellular + satellite + FM radio); pre‑load fallback tones on devices.
Clock drift across stations	Inconsistent timestamps	Use GPS disciplined oscillators; periodic NTP sync over low‑bandwidth links.
Software exception in trigger code	Missed detection	Watchdog timers; fail‑safe default to “no alert” with post‑event audit.

Designing EEW systems thus revolves around guaranteeing that each component respects its latency envelope, while providing redundancy that tolerates the inevitable failures of a seismic event.

Offline‑First Applications for Responders with No Network

When the earthquake damages telecom infrastructure, first‑responders must rely on applications that continue to function without connectivity. An offline‑first architecture treats the local device as the source of truth, synchronizing with the backend only when a link becomes available.

Data Model and Local Persistence

Immutable event logs – Each field observation (e.g., damage classification, resource request) is stored as an append‑only record with a UUID, timestamp, and cryptographic hash. Immutability simplifies conflict resolution during later merges.
Versioned entities – For mutable objects (e.g., status of a relief hub), maintain a version vector (Lamport timestamps) to detect concurrent updates.
Embedded databases – Use lightweight, ACID‑compliant stores such as SQLite or Realm that support on‑device indexing and full‑text search, enabling rapid query even on low‑end Android devices.

Synchronization Protocol

A bi‑directional sync engine must reconcile divergent histories while preserving causality:

Change export – The client bundles unsent logs into a compact binary envelope (e.g., Protocol Buffers) and signs it with a device‑specific key.
Transport abstraction – The envelope can be sent over any available channel: Wi‑Fi hotspot, Bluetooth LE, or a temporary satellite link.
Server‑side merge – The backend applies a deterministic merge function: sort by timestamp, resolve conflicts using version vectors, and reject duplicates via hash comparison.
Acknowledgment – The server returns a receipt containing the highest applied version per entity, allowing the client to prune confirmed entries.

The protocol must be tolerant of out‑of‑order delivery and partial payload loss, which is common on opportunistic links. Implementing forward error correction (e.g., Reed‑Solomon) on the envelope mitigates the need for retransmission.

UI/UX Considerations Under Offline Constraints

Graceful degradation – Hide features that require remote data (e.g., live maps) and replace them with locally cached raster tiles or vector overlays pre‑loaded before the event.
Explicit connectivity status – Show a persistent banner indicating “offline – data will sync when connection restores.” This reduces user anxiety and prevents accidental data loss.
Battery awareness – Defer non‑essential background sync until the device is charging or a high‑capacity power source is detected; expose a “low‑power mode” toggle.

Security and Data Integrity

End‑to‑end encryption – Encrypt each log entry with a symmetric key derived from the responder’s credential; rotate keys daily to limit exposure.
Tamper‑evident logs – Chain hashes of consecutive entries (hash‑linked list) so any post‑event alteration is detectable during audit.
Access control – Enforce role‑based permissions locally; e.g., a field medic cannot modify logistics entries, and the UI must enforce this even when offline.

Offline‑first design thus ensures that responders retain full situational awareness and can continue to record critical observations, regardless of the state of the communications fabric.

Store‑and‑Forward and Mesh Networking When Infrastructure Is Down

When conventional backhaul fails, a store‑and‑forward (S&F) mesh provides a resilient data plane that can ferry messages across fragmented nodes until a gateway to the internet re‑appears.

Mesh Topology and Routing

Hybrid mesh – Combine static backbone nodes (e.g., pre‑installed high‑gain radios on municipal buildings) with mobile ad‑hoc nodes (e.g., responder handhelds, UAV‑mounted radios).
Routing protocol – Use a delay‑tolerant variant of B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking) that incorporates store‑and‑forward queues and opportunistic forwarding. Nodes maintain a neighbor table with link quality metrics (RSSI, packet loss) and forward packets to the neighbor with the highest delivery probability.
Message TTL and priority – Assign a time‑to‑live (TTL) field based on the message class (e.g., “life‑threatening” gets 30 seconds, “log‑entry” gets 24 hours). Priority queues ensure that high‑urgency packets are transmitted first when bandwidth is scarce.

Store‑and‑Forward Mechanics

Ingress – An originating device creates a packet, tags it with a unique identifier, priority, and TTL, then places it in the local outbound queue.
Buffer management – Each node allocates a persistent buffer (e.g., flash‑based circular log) sized to hold at least 48 hours of high‑priority traffic. The buffer is organized by priority to prevent low‑importance data from starving critical messages.
Forwarding decision – Upon detecting a neighbor, the node evaluates the neighbor’s delivery estimate (based on historical contact frequency) and forwards packets that improve the

This piece is about the engineering, not the event. For what actually happened and for anything anyone affected needs to act on, go to the source: USGS. Emergency guidance comes from your local emergency service and from nobody else.

Written by Amit Chakraborty — founding engineer and senior architect: React Native, AI and RAG systems, production architecture. Portfolio · LinkedIn · GitHub. Building systems that have to work when things are going wrong is most of what this is — get in touch or email amit@devamit.co.in.

Startup‑time regression after enabling Hermes in a React‑Native app

Amit chakraborty — Mon, 19 Oct 2026 08:30:08 +0000

The situation

Say you are a lead mobile engineer on a two‑month sprint for a consumer‑facing React‑Native app (React‑Native 0.73). The product team has pushed a deadline to ship version 2.1, and the QA team reports that the app now takes ≈ 1.8 s to reach the first screen on a mid‑range Android 11 device (Pixel 5). The same build, but with the default JavaScript engine (JSC) enabled, consistently hits ≈ 1.2 s on the same device.

The regression was discovered after a tutorial‑style pull request that added the following to android/app/build.gradle:

project.ext.react = [
    enableHermes: true   // <‑‑ added per tutorial
]

The change was merged without measuring the impact. The cost is three‑fold:

User experience – a 0.6 s extra delay on the splash screen, which translates to a measurable drop in conversion (internal telemetry shows a 3 % lower “continue” rate after the delay).
Release schedule – the team now needs to allocate a day of debugging and a possible rollback, jeopardising the sprint goal.
Team morale – the incident triggers a “why‑did‑we‑do‑that?” post‑mortem, consuming meeting time.

Below is a practical, production‑tested path to understand why Hermes can hurt startup time in some scenarios, how to verify the cause, and how to mitigate it without sacrificing the long‑term benefits Hermes provides.

Why it happens

1. Bytecode loading overhead

Hermes ships as a native library (libhermes.so) that must be loaded and initialised before the first JavaScript bytecode can be executed. On devices with limited I/O bandwidth, the extra ~ 2 MB of native code adds a measurable disk‑read latency. In the RN 0.73 benchmark suite, the engine load adds ≈ 120 ms on a Snapdragon 765G, while the JSC interpreter is already resident in the system image and incurs virtually no load cost.

2. AOT compilation vs. JIT warm‑up

Hermes performs ahead‑of‑time (AOT) bytecode generation at build time. This eliminates JIT compilation at runtime, which is why many apps see a 30 % reduction in CPU usage after the first frame. However, the AOT step produces a single monolithic bytecode file (index.android.bundle). The OS must map the whole file into memory before execution, which can be slower than JSC’s incremental parsing on low‑end devices that benefit from lazy loading of script chunks.

3. Incompatible third‑party modules

Some native modules (e.g., react-native-reanimated < 2.12, react-native-gesture-handler < 2.4) rely on eval or dynamic import(). Hermes disables eval by default for security and performance. When such calls are encountered, Hermes throws:

HermesException: Unexpected eval or new Function usage.

If the code falls back to a JavaScript‑only path, it may trigger additional bundle parsing that negates the bytecode advantage, inflating startup time.

4. Debugger attachment delay

When Hermes is enabled, remote JS debugging via Chrome DevTools is disabled. Developers often attach the Hermes Debugger (react-native-debugger with Hermes support) which establishes a WebSocket connection and loads the Hermes inspector. On a cold start, the app waits for this handshake (≈ 80 ms) before proceeding, whereas JSC’s Chrome‑based debugging can be skipped entirely in production builds.

5. Build‑time cost

Enabling Hermes adds a bytecode generation step (hermesc) to the Gradle pipeline. On a CI runner with limited CPU, this can increase the Android build time by ≈ 30 % (from 8 min to 10 min). Longer builds reduce the frequency of releases and increase the risk of stale dependencies slipping into production.

The fix, step by step

Below is a reproducible workflow that isolates the startup‑time impact, validates the trade‑offs, and lets you decide whether to keep Hermes enabled for a given release.

Step 1 – Reproduce the regression locally

Check out the exact commit that introduced enableHermes: true.
Run a clean build on a physical device that matches the failing spec (Pixel 5, Android 11, API 30):

   cd android
   ./gradlew clean assembleRelease
   adb install -r app/build/outputs/apk/release/app-release.apk

Measure startup time with adb logcat filtering for the RN splash event:

   adb logcat -s ReactNativeJS:V | grep -i "JS load time"

Expected output (Hermes):

   ReactNativeJS: JS load time: 1760 ms

Record the value; you now have a baseline.

Step 2 – Switch back to JSC for comparison

Edit android/app/build.gradle:

project.ext.react = [
    enableHermes: false   // revert temporarily
]

Re‑build and re‑measure using the same commands. You should see a lower time (≈ 1200 ms). This confirms that the regression is tied to the engine switch, not to unrelated code changes.

Step 3 – Profile engine load time

Hermes provides a hermes-profile binary that can be embedded in the app to log engine initialisation. Add the following to MainApplication.java (after ReactInstanceManager creation, only in a debug build):

if (BuildConfig.DEBUG && BuildConfig.ENABLE_HERMES) {
    com.facebook.hermes.reactexecutor.HermesRuntimeFactory.enableRuntimeProfiling(true);
}

Run the app and capture the log entry:

HermesRuntime: Engine init time: 115 ms

If the init time exceeds ≈ 150 ms, you are hitting the disk‑read overhead on the device. Consider compressing the native library with android.packagingOptions to reduce load time.

Step 4 – Verify bytecode size and mapping

Inspect the generated bundle:

cd android/app/build/generated/assets/react/
du -h index.android.bundle

Typical Hermes bundle size: ≈ 5 MB (vs. ≈ 6 MB for JSC). However, the memory‑mapped size can be larger because the OS rounds up to page boundaries. Use adb shell cat /proc/<pid>/maps | grep index.android.bundle to see the mapped region. If the mapped size is > 8 MB, you may be exceeding the device’s low‑memory threshold, causing the OS to trigger a GC pause that adds ≈ 200 ms to startup.

Mitigation: Split the bundle using RAM bundles (enableHermes: true, bundleInDebug: true, hermesFlags: ["-O", "--emit-binary"]). This creates a index.android.bundle with a table of small bytecode chunks, allowing the OS to map only what is needed for the first screen.

Step 5 – Detect incompatible modules

Run the app with Hermes in debug mode and watch for the HermesException message. If you see:

HermesException: Unexpected eval or new Function usage.

Identify the offending module by checking the stack trace. Common culprits are older versions of react-native-reanimated. Upgrade to ≥ 2.13 which ships a Hermes‑compatible implementation, or replace the dynamic code path with a static import.

Step 6 – Benchmark with Hermes debugger disabled

In production, the Hermes debugger is never attached. To simulate this, run a release build with the hermes-debugger flag set to false:

project.ext.react = [
    enableHermes: true,
    hermesDebugEnabled: false
]

Re‑measure startup. If the time drops by ≈ 80 ms, the delay you observed in step 1 was due to the debugger handshake. Ensure that your CI pipeline builds a release variant for production, not a debug variant that inadvertently includes the debugger.

Step 7 – Evaluate the trade‑off numerically

Collect the following metrics on the target device:

Metric	JSC (baseline)	Hermes (current)	Difference
Startup time (ms)	1200	1760	+560
Engine load time (ms)	0 (system)	115	+115
Bundle size on disk (MB)	6.0	5.0	-1.0
APK size increase (MB)	0	+2.5 (libhermes)	+2.5
CI build time (min)	8	10	+2

If the +560 ms startup penalty outweighs the ‑1 MB bundle reduction and the +2.5 MB APK growth, you may decide to ship with JSC for this release, or adopt the RAM‑bundle optimisation in step 4.

Step 8 – Apply the chosen mitigation

If you stay with Hermes:

project.ext.react = [
    enableHermes: true,
    hermesFlags: ["-O", "--emit-binary", "--compact"]
]
android {
    packagingOptions {
        // Compress native lib to reduce load time
        doNotStrip "**/libhermes.so"
    }
}

If you revert to JSC:

project.ext.react = [
    enableHermes: false
]

Commit the change, run a full CI build, and verify that the release APK size and startup time meet the SLA (≤ 1.3 s on the target device).

What it costs, and when not to do it

Cost category	Hermes advantage	Hermes drawback (when it hurts)
Startup latency	AOT bytecode eliminates JIT warm‑up → faster after first frame.	Engine load + full bundle mapping can add 300‑600 ms on low‑end Android.
APK size	No JSC runtime → smaller JavaScript payload.	Adds ~2‑3 MB native library (`libhermes.so`).
Build time	Bytecode generation enables source‑map debugging.	CI builds 20‑30 % longer; may hit timeouts on constrained runners.
Debugging	Hermes debugger provides precise source‑level breakpoints.	Remote Chrome debugging disabled; extra handshake adds ~80 ms.
Compatibility	Works out‑of‑the‑box with most RN core modules.	Modules using `eval`, dynamic `import()`, or old native bridges may crash or degrade performance.

When not to enable Hermes

Targeting a large share of low‑end Android devices (≤ 2 GB RAM, API 21‑23) where the extra native library load dominates the startup budget.
CI pipelines constrained to < 10 min builds and lacking parallelism; the bytecode step will become a bottleneck.
Heavy reliance on third‑party libraries that have not declared Hermes compatibility (check each library’s peerDependencies).
Strict APK size limits (e.g., for OTA updates where payload must stay < 5 MB).

In those cases, either stay with JSC or adopt a hybrid approach: ship JSC for Android < 8 and Hermes for newer devices using product flavours.

At your level

Role	Immediate takeaway	One concrete next step
Student / first‑year engineer	Hermes can slow startup on some devices despite a smaller bundle.	Run the `adb logcat` measurement on a real device after toggling `enableHermes`.
Mid‑level engineer (feature owner)	Quantify the trade‑off (startup ms vs. APK size vs. build time) before merging the engine switch.	Add a CI step that records `hermesc` duration and fails if it exceeds a threshold (e.g., 2 min).
Senior / staff engineer	Architecture must include a decision matrix for JavaScript engines per device tier.	Implement a Gradle product flavour (`hermesRelease` / `jscRelease`) and automate device‑tier detection at install time.
Lead / director	Enabling Hermes without measurement can jeopardise release schedules and user metrics.	Allocate a sprint budget for “engine‑performance validation” and track the KPI (startup ≤ 1.3 s) in the release dashboard.

In the interview

Question (as asked by a senior engineering manager):

“We recently enabled Hermes in our React‑Native Android builds to reduce bundle size, but we observed a 0.5 s increase in cold‑start time on low‑end devices. Walk me through why that can happen, how you would diagnose it, and what trade‑offs you would consider before deciding whether to keep Hermes enabled.”

Weak answer (why it’s weak):

“Hermes is faster because it pre‑compiles JavaScript. Maybe the device is slow, so we should just keep JSC.”
Fails to name the concrete cause, the diagnostic steps, and the quantitative trade‑off.

Strong answer (what it must contain):

Identify the failure mode – engine load and full‑bundle mapping add I/O latency; incompatible modules trigger fallback parsing; debugger handshake adds delay.
Diagnostic plan – reproduce on a representative device, measure startup with

DEV Community: Amit chakraborty

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

The problem

Before you start

How do I avoid leading the user?

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

2. Which question types produce raw evidence?

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

How do I structure the interview to surface evidence?

1. What preparation steps guarantee a clean session?

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

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

Build it

When this breaks

What it costs

In the interview

Your tasks

Your tasks this week

Product management for engineers

Deep‑link navigation in Expo Router exceeding the performance budget

The situation

Why it happens

The fix, step by step

1. Measure the current baseline with a strict timer

2. Pre‑bundle all route chunks at build time

3. Optimise the route matcher

4. Prioritise asset pre‑fetch for target screens

5. Enforce the budget with a guardrail

What it costs, and when not to do it

At your level

In the interview

Unexpected behaviour of Expo Router deep links in production

The situation

Why it happens

The fix, step by step

1. Add the router plugin to app.json

2. Configure Associated Domains for iOS

3. Regenerate the route manifest after every change

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

5. Align Expo Updates caching with the route manifest

What it costs, and when not to do it

When not to use Expo Router deep links

At your level

In the interview

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

The problem

Before you start

What Go was built to solve

1. Why was Go created?

2. What does Go optimise for?

3. The hidden cost of fighting Go’s design

How to align your design with Go’s strengths

1. Keep allocations per request to a minimum

2. Use the standard library for common tasks

3. Prefer explicit error handling over panics

4. Measure before you optimise

Build it

When this breaks

What it costs

In the interview

Your tasks

Your tasks this week

Go, from zero to a running service

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

The situation

Why it happens

The fix, step by step

1. Pin the exact RN version

2. Add the Fabric flag to the native projects

3. Upgrade native modules to TurboModules

4. Wrap each screen in a FabricSurface

5. Guard legacy requireNativeComponent calls

6. Enable the feature flag in JavaScript

7. Run the full regression suite under the Fabric flavour

8. Deploy the feature flag gradually

9. Remove the legacy path once coverage is 100 %

What it costs, and when not to do it

At your level

In the interview

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

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

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

4. Wrap each screen in a `FabricSurface`

5. Guard legacy `requireNativeComponent` calls

9. Remove the legacy path once coverage is 100 %

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

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

3. Add a custom `RCTPerformanceLogger` counter