For an intern full-stack role, interviewers check that you understand how a web page and a mobile app talk to a server, the basics of HTML, CSS and JavaScript, how HTTP, REST and JSON work, simple databases, Git, and the difference between native and cross-platform mobile apps. Nobody expects production experience; they want clear fundamentals, honest answers and the ability to explain a small project you built yourself.

A full-stack developer works on every layer of a product: the user interface (web pages and mobile screens), the server-side API and business logic, the database, and enough deployment to ship it. For a "web and mobile" role that usually means one backend serving both a web app and a mobile app. You don't have to be an expert in everything, but you should be able to follow a feature from the button the user taps all the way to the row saved in the database.

The front end is what runs on the user's device — the browser page or the mobile app — and handles layout, interaction and calling APIs. The back end runs on a server: it receives requests, checks permissions, applies business rules, talks to the database and returns data. The front end should never be trusted with secrets or final validation, because the user controls their device.

Roughly, the browser does these steps in order:

HTTP is the request–response protocol of the web: a client sends a method, a path, headers and an optional body, and the server answers with a status code, headers and a body. GET reads data, POST creates or triggers something, PUT replaces a resource, PATCH updates part of it and DELETE removes it. GET should never change data, because browsers, caches and crawlers may repeat it freely.

The first digit tells you the category, and a good API uses them honestly so web and mobile clients can react correctly.

REST is a style of designing HTTP APIs around resources identified by URLs, such as /users/42/orders, with HTTP methods expressing the action. Requests are stateless — each one carries everything the server needs, like an auth token — and responses are usually JSON. The same REST API can serve a website, an iOS app and an Android app, which is why it is so common in full-stack work.

JSON (JavaScript Object Notation) is a lightweight text format for structured data: objects, arrays, strings, numbers, booleans and null. Every language and platform can read and write it, it is easy for humans to inspect, and it maps naturally to JavaScript objects. Note that JSON has no date type, so dates are usually sent as ISO 8601 strings like "2026-10-12T09:30:00Z".

A native app is written in the platform's own language and SDK — Swift or Kotlin — and gets the best performance and full device access. A cross-platform app is written once in a framework like React Native or Flutter and runs on both iOS and Android, still rendering real native-feeling UI. A hybrid app wraps a web page inside a WebView (for example with Capacitor or Cordova); it is the quickest to build from web skills but usually feels the least native.

React Native lets you build iOS and Android apps with React and JavaScript or TypeScript; your components map to real native views. Flutter is Google's toolkit that uses the Dart language and draws every pixel with its own rendering engine, so the UI looks identical on each platform. React Native is a natural fit for teams that already use React on the web; Flutter is popular for highly custom, consistent UI.

HTML gives the page its structure and meaning — headings, paragraphs, forms, links. CSS controls how it looks — layout, colours, fonts, spacing and responsiveness. JavaScript adds behaviour — reacting to clicks, fetching data and updating the page without a reload. Keeping these roles clear makes code easier to maintain and more accessible.

Semantic HTML means choosing elements by their meaning: <nav>, <main>, <article>, <button>, <label> instead of generic <div>s everywhere. Screen readers, search engines and browsers understand the page better, keyboard support often comes for free (a real <button> is focusable and reacts to Enter and Space), and the code is easier to read.

Every element is a box made of content, then padding, then border, then margin on the outside. By default width only covers the content, so padding and border make the box bigger than you expect. Most projects set box-sizing: border-box so that width includes padding and border, which makes layouts much easier to reason about.

Flexbox lays items out in one direction — a row or a column — and is great for navbars, toolbars, centring and distributing space between items. Grid controls two dimensions at once, rows and columns, and suits page layouts, card galleries and dashboards. Many real layouts use Grid for the overall page and Flexbox inside each component. Interestingly, React Native uses Flexbox (with column as the default direction) for all its layouts.

Responsive design means one website adapts to any screen size — phone, tablet or desktop — using fluid widths, flexible images, Flexbox/Grid and media queries. A mobile-first approach writes the small-screen styles first and adds min-width media queries for larger screens. Don't forget the viewport meta tag, or phones will render the page zoomed out.

var is function-scoped and hoisted, which causes surprising bugs, so modern code avoids it. let and const are block-scoped; let can be reassigned and const cannot. Note that const doesn't make an object immutable — you can still change its properties — it only stops the variable pointing to something else. Default to const and use let only when you really reassign.

=== compares value and type with no conversion, so 1 === "1" is false. == converts types first, so 1 == "1" is true and 0 == "" is also true, which hides bugs. Always use === and !==; the only common exception is value == null, which deliberately checks for both null and undefined.

The DOM (Document Object Model) is the browser's tree of objects that represents the HTML page. JavaScript can read and change it — add elements, change text, toggle classes — and the browser re-renders. Frameworks like React update the DOM for you, but knowing it helps when debugging layout, events and performance. Mobile frameworks have their own equivalent: a tree of native views.

When you click an element, the event fires on it and then bubbles up through each parent to the document. Event delegation uses this: instead of one listener per list item, you put one listener on the parent and check event.target. It uses less memory and automatically works for items added later.

They are three ways to handle work that finishes later, like a network request. A callback is a function you pass to be called when the work is done; nesting many of them gets messy. A promise is an object representing a future result that you chain with .then() and .catch(). async/await is syntax on top of promises that reads like normal top-to-bottom code; use try/catch for errors.

fetch only rejects on network failures, such as no connection or a blocked request. A 404 or 500 response still resolves successfully, so if you skip the res.ok (or res.status) check, your code will try to use an error page as data. The same rule applies to fetch in React Native.

A closure is a function that remembers the variables from the scope where it was created, even after that outer function has returned. Closures power private state, factory functions, event handlers and React hooks. A classic example is a counter whose count variable can only be changed through the returned function.

undefined means a value was never set — a missing property, a variable without a value, or a function with no return. null is an intentional "no value" that a developer assigns. APIs should be consistent about which one they use; optional chaining (user?.address?.city) and nullish coalescing (value ?? "default") handle both safely.

A component is a reusable piece of UI — a button, a card, a whole screen — written as a function in React and React Native, or as a widget in Flutter. Props are inputs passed in by the parent and are read-only inside the component. State is data the component owns and can change, such as the text in an input; changing state re-renders the component.

useState stores a value that survives re-renders and gives you a setter that triggers a re-render. useEffect runs code after rendering to sync with something outside React — a subscription, a timer, a non-React widget — and its cleanup function runs before the next run or on unmount. Don't use an effect for values you can calculate during render; that just causes extra renders.

The React concepts are identical — components, props, state, hooks — but the building blocks differ. Instead of <div>, <span> and <img> you use <View>, <Text> and <Image>, all text must be inside <Text>, styles are JavaScript objects (usually via StyleSheet.create) rather than CSS files, and there are no browser APIs like window.localStorage.

A StatelessWidget is built only from its constructor arguments and never changes by itself, like a label or an icon. A StatefulWidget has a separate State object that holds changing data; you call setState() to update the data and rebuild the UI. Keep as much as possible stateless and move shared state into a state-management solution.

An Android emulator and the iOS Simulator run your app on your computer, which is fast for development and debugging. But they don't match real hardware exactly: performance, camera, push notifications, battery behaviour, gestures and slow networks behave differently. Always test important flows on at least one real, preferably mid-range, phone before a release.

Hot reload injects your code changes into the running app without restarting it, often keeping the current state, so you see edits in about a second. React Native calls it Fast Refresh, and Flutter has hot reload plus hot restart. Some changes — native code, new native dependencies, app config — still need a full rebuild.

A database stores data permanently and lets you query it efficiently. SQL (relational) databases like PostgreSQL and MySQL store data in tables with a fixed schema and relationships, and are strong at joins and transactions. NoSQL databases like MongoDB store flexible documents (or key–value pairs, graphs, etc.) and are convenient when the shape of data varies. Both are valid; the choice depends on the data and its access patterns.

A primary key uniquely identifies each row in a table, such as users.id. A foreign key is a column that points to a primary key in another table, such as orders.user_id pointing to users.id, and the database can enforce that the referenced user exists. Together they model relationships like "a user has many orders".

CRUD is the four basic data operations, and each one lines up neatly with SQL and REST:

An inner join returns rows that match in both tables. This query lists each order with the customer's name, newest first; a LEFT JOIN would also keep users who have no orders.

Git is a version control system that records the history of your code and lets many people work in parallel on branches. A typical daily flow looks like this:

A pull request (PR) asks the team to review and merge your branch. A good PR is small and focused on one change, has a clear title and description explaining what and why, includes screenshots for UI changes (for both web and mobile if relevant), has passing tests, and responds to review comments politely. Small PRs get reviewed faster and break less.

Authentication answers "who are you?" — logging in with a password, a social login or a passkey. Authorization answers "what are you allowed to do?" — for example, only an admin can delete users, and a user can only edit their own posts. Authorization must always be checked on the server, because hiding a button in the app does not stop someone calling the API directly.

Never store passwords in plain text or with fast hashes like MD5 or SHA-256 alone. Use a slow, salted password-hashing algorithm such as bcrypt or Argon2, which makes cracking stolen hashes very expensive. When the user logs in, hash the attempt and compare it with the stored hash using the library's compare function.

Cookies are small values the browser sends automatically with every request to their domain; they can be HttpOnly (hidden from JavaScript) and Secure, so they are the safest place for session tokens on the web. localStorage keeps data with no expiry and sessionStorage keeps it until the tab closes; both are readable by any script on the page, so never put secrets there. Mobile apps have no cookies jar by default and use secure storage (Keychain or Keystore) instead.

CORS (Cross-Origin Resource Sharing) is a browser security rule: a page from app.example.com can only read responses from api.other.com if that server sends headers like Access-Control-Allow-Origin allowing it. It is enforced by browsers only, so native mobile apps and server-to-server calls are not affected. Fix CORS errors on the server by allowing the specific origins you trust, not * with credentials.

HTTPS is HTTP encrypted with TLS. It hides passwords, tokens and personal data from anyone on the network, proves the server is really who it claims to be through its certificate, and stops content being modified in transit. Browsers mark plain HTTP as "not secure", and both iOS (App Transport Security) and Android block plain-HTTP traffic by default.

Environment variables hold configuration that changes between environments — database URLs, API keys, feature switches — outside the code. That keeps secrets out of Git and lets the same build run in development, staging and production. Remember that anything bundled into a web or mobile app (for example NEXT_PUBLIC_* or EXPO_PUBLIC_* variables) is visible to users, so real secrets belong only on the server.

npm is the package manager and registry for JavaScript. package.json lists your project's name, scripts (like dev, build, test) and dependencies, and the lock file (package-lock.json, yarn.lock, pnpm-lock.yaml or bun.lock) pins exact versions so every machine installs the same thing. Commit the lock file; don't commit node_modules.

Reproduce it reliably first, then narrow it down: read the full error and stack trace, check the browser DevTools console and Network tab (or the React Native / Flutter dev tools and device logs), add logs or breakpoints, and test one assumption at a time. Check recent changes with git log or git bisect. Once it's fixed, add a test so it can't quietly come back.

A unit test checks one small piece of code, like a function, in isolation. Tests catch regressions when you change code later, document how the code is meant to behave, and give you confidence to refactor. Common tools are Jest or Vitest for JavaScript, React Testing Library for components, and the built-in flutter_test package for Flutter.

Accessibility (a11y) means people with disabilities can use your product: screen-reader users, keyboard-only users, people with low vision or colour blindness. The basics are semantic HTML, alt text on images, labels on form fields, visible focus styles, enough colour contrast and not relying on colour alone. Mobile has the same idea through accessibilityLabel in React Native and Semantics in Flutter.

A mobile app moves between states: launching, active in the foreground, inactive (for example during an incoming call), in the background, and finally suspended or killed by the system to free memory. Your app should save drafts when it goes to the background, pause video or timers, and refresh stale data when it comes back. React Native exposes this through AppState, and Flutter through AppLifecycleListener or WidgetsBindingObserver.

You build a signed release — an AAB for Google Play or an IPA for Apple's App Store — and upload it with screenshots, a description and a privacy policy. Apple and Google review the app before it goes live, which can take hours to days. Testers can get earlier builds through TestFlight on iOS and internal testing tracks on Google Play. Tools like EAS Build and Fastlane automate the signing and uploading.

Deployment is putting your code on servers so real users can reach it. A simple setup: the web front end on a platform like Vercel or Netlify, the API on a service like Railway, Render or Fly.io, and a managed database such as Atlas or Neon, with environment variables set on each. Pushing to the main branch triggers a build and deploy. The mobile app then simply points at the production API URL.

DNS (Domain Name System) is the internet's phone book: it turns names like example.com into IP addresses. Common records are A/AAAA (IPv4/IPv6 address), CNAME (alias to another name), MX (mail servers) and TXT (verification and email security). Changes can take time to spread because resolvers cache answers for the record's TTL.

Agile is a way of working in short cycles, delivering small working pieces and adjusting based on feedback. Scrum is one popular framework: work happens in sprints of one or two weeks, with sprint planning, a short daily stand-up, a review demo and a retrospective. As an intern you'll mostly take small tickets, give honest updates at stand-up and ask for help early when you're stuck.

Pick one project and walk through it clearly: the problem it solves, the stack (for example a React web app, an Expo mobile app and a Node.js API with PostgreSQL), one feature you're proud of and how it works end to end, one hard bug and how you fixed it, and what you would improve with more time. Have the code on GitHub with a clear README and, if possible, a live demo or a short screen recording of the app.

A mid-level full-stack developer is expected to own a feature end to end: design the API, model the data, build the web and mobile screens, handle auth, caching, errors and offline cases, write the tests and get it through CI to production and the app stores. Interviewers listen for trade-offs, real examples and an awareness of how mobile clients differ from the web.

REST is simple, cache-friendly over HTTP and easy to secure and monitor per endpoint. GraphQL lets each client ask for exactly the fields it needs in one request, which helps when a web dashboard and a small mobile screen need very different shapes of the same data, but it adds complexity: schema design, N+1 resolvers, query cost limits and harder HTTP caching. For a small team with one app, REST is usually enough; GraphQL pays off with many clients and complex, nested data.

With sessions, the server stores session data and the client holds only a random session ID, usually in an HttpOnly cookie; logging out or revoking is easy. With JWTs, the token itself carries signed claims, so any server can verify it without a lookup, which suits mobile apps and multiple services, but a stolen token is valid until it expires. A common combination is a short-lived access token (minutes) plus a long-lived refresh token that can be revoked on the server.

Issue a short-lived access token and a refresh token stored securely: an HttpOnly, Secure, SameSite cookie on the web, and the iOS Keychain or Android Keystore (for example via expo-secure-store) on mobile. Rotate the refresh token on every use and store a hash of it in the database, so a reused old token reveals theft and you can revoke the whole family. On the client, queue requests while one refresh is in flight so ten parallel 401s don't trigger ten refreshes.

Public clients like mobile apps and SPAs can't keep a client secret, so they use the Authorization Code flow with PKCE:

Store tokens in the platform's secure storage — Keychain on iOS and Keystore-backed encrypted storage on Android — never in plain AsyncStorage or SharedPreferences. And never ship real secrets such as a payment provider's secret key or a database password in the app: an app bundle can be downloaded and decompiled. Anything that needs a secret should go through your backend.

Use a plural resource noun, query parameters for filtering, sorting and pagination, and a consistent response envelope with the data plus paging info. Validate and cap the inputs (for example limit at most 100) so a client can't request a million rows.

Offset pagination (?page=3&limit=20) is simple and lets users jump to page 10, but it gets slow on large tables because the database still scans the skipped rows, and items shift when new rows are inserted. Cursor pagination (?after=<last id>) uses an indexed column to continue from the last item, so it stays fast and stable — ideal for infinite scrolling feeds in mobile apps.

Validate every request body, query and path parameter at the API boundary with a schema library such as Zod, Joi or class-validator, and reject bad input with a 400 and clear field errors. Client-side validation in the web form or mobile screen is for user experience only; the server must re-check, because anyone can call the API directly. Sharing the same Zod schema between web, mobile and API in a monorepo keeps rules consistent.

Use the right status code and the same JSON shape for every error, with a stable machine-readable code that clients can branch on, a human-readable message, and optional field details. Log the full error with a request ID on the server, but never send stack traces or SQL errors to clients. Mobile apps especially rely on stable error codes because old app versions stay in use for months.

An index is a sorted data structure (usually a B-tree) that lets the database find rows without scanning the whole table, like a book's index. Add indexes on columns you filter, join or sort by often, and use compound indexes that match your query order. Indexes speed up reads but slow down writes and use space, so check with EXPLAIN rather than indexing every column.

A transaction groups several operations so they all succeed or all fail together — for example, creating an order and reducing stock. ACID means Atomicity (all or nothing), Consistency (rules and constraints stay valid), Isolation (concurrent transactions don't see each other's half-done work) and Durability (once committed, it survives crashes). Keep transactions short so they don't hold locks for long.

It happens when you load a list with one query and then run one more query for each item — for example, 50 posts and then 50 separate queries for their authors. It is easy to cause with ORMs and GraphQL resolvers. Fix it with a join or eager loading (include in Prisma, populate in Mongoose), a single WHERE id IN (...) query, or batching with a DataLoader.

ORMs like Prisma, Drizzle, TypeORM or Mongoose give you typed models, migrations, safer parameterised queries and faster development. The downsides are hidden inefficient queries (like N+1), leaky abstractions for complex reports, and sometimes a learning curve of their own. A balanced approach is to use the ORM for everyday CRUD and write raw SQL for the few heavy queries, checking them with EXPLAIN.

Use versioned migration files committed to Git and run automatically in the deploy pipeline, never manual changes in the production console. Each migration should be small and, ideally, reversible. For changes that could break running code, such as renaming a column, split the change into backwards-compatible steps so old servers and old mobile app versions keep working during the rollout.

Cache at the layer closest to the user that is still correct:

Every cache needs an invalidation plan: a TTL, an explicit delete when data changes, or versioned keys.

Server state is data owned by the backend — users, orders, posts — that can go stale and must be fetched, cached and refetched; tools like TanStack Query or SWR handle it well on both React and React Native. Client state is local UI state — a modal being open, a draft form, the selected tab — which useState, context or a small store like Zustand handles. Mixing the two into one big global store is a common source of bugs.

Optimistic UI updates the screen immediately as if the server request succeeded — a like turns red at once — then rolls back if the request fails. It makes apps, especially on slow mobile networks, feel instant. Use it for low-risk, likely-to-succeed actions like likes or reordering; avoid it for payments or anything where showing a false success would be harmful.

They differ in where and when HTML is produced:

They are Google's user-experience metrics measured from real users: LCP (Largest Contentful Paint, loading — aim under 2.5 s), INP (Interaction to Next Paint, responsiveness — under 200 ms) and CLS (Cumulative Layout Shift, visual stability — under 0.1). Improve them with optimised images, less JavaScript, server rendering or static pages, fonts that don't shift layout, and reserving space for images and ads.

Measure first with a bundle analyser, then remove what you don't need: replace heavy libraries with lighter ones, import only what you use so tree-shaking works, lazy-load routes and heavy components (charts, editors, maps) with dynamic import(), move non-interactive parts to server components where your framework supports them, and set a size budget in CI so it doesn't grow back.

Never map a long array inside a ScrollView, because it renders every row at once. Use a virtualised list like FlatList, SectionList or Shopify's FlashList, which only renders what is on screen. Give rows a stable keyExtractor, memoise row components, avoid inline heavy work in renderItem, and use properly sized, cached images.

The web uses URLs and the browser's history; mobile apps use navigators that manage a stack of screens, tabs and modals with native transitions and the Android back button. In React Native, React Navigation or Expo Router (file-based, similar to Next.js) handle this; Flutter uses Navigator or packages like go_router. Map each important screen to a route so deep links and notifications can open it directly.

A deep link opens a specific screen inside the app, like myapp://orders/42. Custom schemes are easy but any app can claim them. Universal Links (iOS) and App Links (Android) use normal https:// URLs verified by a file on your website (apple-app-site-association or assetlinks.json), so the same link opens the app if installed or the website otherwise — ideal for shared links, emails and password-reset flows.

The app asks the user for permission and receives a device token from Apple Push Notification service (APNs) or Firebase Cloud Messaging (FCM), then sends that token to your backend. When something happens, your server sends a message to APNs/FCM (directly or through a service like Expo Push or OneSignal), which delivers it to the device. Store tokens per device, remove invalid ones, let users choose categories, and include a deep link so tapping opens the right screen.

Ask in context, at the moment the user needs the feature — request the camera when they tap "Scan receipt", not on first launch — and explain why first with a short screen of your own, because if the user denies the system prompt you often can't show it again. Request the smallest permission that works (approximate location, "while using the app"), handle denial gracefully with a fallback, and link to the system settings if they change their mind. Both stores reject apps whose permission descriptions are vague.

Cache the data the user needs in local storage (SQLite, WatermelonDB, MMKV, or Hive/Drift in Flutter), show it immediately, and refresh in the background when online. Queue writes made offline in a local outbox with unique IDs and send them when the connection returns. Show clear offline and "syncing" states, and decide how to handle conflicts when the same record was changed elsewhere.

For larger files, avoid streaming them through your API server. The client asks the API for a pre-signed upload URL (for S3, R2 or GCS), uploads directly to storage, then tells the API the file key. Validate type and size on the server, resize or compress images (on the device before upload on mobile, to save data), store the key rather than the full URL, and serve files through a CDN.

Use WebSockets (directly or through Socket.IO) for two-way, low-latency messages like chat and typing indicators; Server-Sent Events for one-way server updates like notifications or progress; and polling only when updates are rare. On mobile, sockets close when the app is in the background, so reconnect on resume, refetch missed messages by "last seen ID", and use push notifications for messages that arrive while the app is closed.

These are three classic web attacks, each with a standard defence:

Rate limiting caps how many requests a client can make in a time window, returning 429 Too Many Requests with a Retry-After header when exceeded. It protects login and OTP endpoints from brute force, stops scrapers and buggy clients (like a mobile app stuck in a retry loop) from overloading the server, and controls costs. With more than one server instance, keep the counters in a shared store like Redis.

An idempotent operation gives the same result whether it runs once or several times. Mobile networks drop connections often, so a client may retry a "create payment" request that actually succeeded. Have the client send a unique Idempotency-Key header; the server stores the key with the result and returns the same result for repeats instead of charging twice.

Move slow or unreliable work out of the request: sending emails and push notifications, generating PDFs, processing images or video, calling flaky third-party APIs, and nightly reports. The API saves a job to a queue (BullMQ with Redis, SQS, RabbitMQ) and responds quickly; workers process jobs with retries and backoff. Make jobs idempotent, because a job may run more than once.

Split it by feature or domain (orders, users, payments) rather than by technical type alone, and keep layers clear: routes or controllers handle HTTP, services hold business logic, and repositories or the ORM handle data. Business logic should not depend on Express or the request object, which makes it easy to test and reuse from jobs or other entry points. Validate at the edges and keep configuration in one place.

Use a monorepo (with pnpm/Bun workspaces and a tool like Turborepo or Nx) with shared packages for things that are truly platform-independent: TypeScript types, API clients, validation schemas, business rules, formatting and i18n strings. UI components are harder to share because web and native render differently; options include a shared design-token package, or React Native Web / Tamagui / NativeWind if the team wants one component set. Don't force sharing where it makes either platform worse.

Have many fast unit tests, fewer integration tests and a small number of end-to-end tests for critical journeys like sign-up and checkout. Typical tools:

In unit tests, mock at the boundary — your API client module or the network layer with a tool like MSW (Mock Service Worker), which works in the browser, Node and React Native tests. Test the error paths too: timeouts, 500s, malformed responses and rate limits. Keep a few contract or sandbox tests against the real provider in a separate, less frequent pipeline.

On every pull request: install, lint, type-check, run unit and integration tests, and build all apps; give preview deployments for the web. On merge to main: run migrations, deploy the API and web app, and trigger a mobile build. Mobile releases are slower — build signed binaries (EAS Build, Fastlane, Codemagic), send them to TestFlight and Play internal testing, then promote to the stores after checks.

Docker packages an application with its runtime and dependencies into an image that runs the same way on any machine. It removes "works on my machine" problems, makes it easy to run the API, database and Redis locally with Docker Compose, and gives a consistent artifact to deploy. Keep images small with multi-stage builds and never bake secrets into images.

Web clients update on the next page load, but mobile users may keep an old app version for months. Prefer additive, backwards-compatible changes: add new fields, don't rename or remove existing ones. When a breaking change is unavoidable, introduce a new version (/v2/ or a header), keep the old one running, track usage by app version, and only remove it once traffic is near zero — ideally with a minimum-supported-version check that asks very old apps to update.

OTA updates let a React Native app download a new JavaScript bundle and assets without going through the app store, using tools like EAS Update. They are great for quick bug fixes and copy changes. They can't change native code or permissions, so the update must match the installed native "runtime version", and store rules still apply — you can't use OTA to change the app's core purpose. Flutter compiles to native code, so it relies on store releases or third-party tools like Shorebird.

Each release has a user-facing version (like 2.4.0, following semantic versioning) and an always-increasing build number (versionCode on Android, CFBundleVersion on iOS). Automate both in CI, tag releases in Git, keep release notes, and use staged rollouts — release to 5–10% of users first and watch crash rates before going to 100%.

Use an error-tracking tool such as Sentry, Crashlytics or Bugsnag in every app. Upload source maps (web) and debug symbols / dSYMs (mobile) so stack traces are readable, tag events with the release version and environment, and attach breadcrumbs and a request ID to link a mobile crash to the matching API logs. Alert on new or spiking errors, not on every single event.

Write structured JSON logs (with a library like pino) containing a timestamp, level, message, request ID, user or tenant ID and relevant context, so you can search and filter them. Log important events and errors, not every line of execution. Never log passwords, tokens, card numbers or full personal data; redact them automatically.

Feature flags turn features on or off at runtime without deploying, for example per user, percentage or app version. They let you merge unfinished code safely behind a flag, roll out gradually, run A/B tests and switch off a broken feature instantly — very valuable for mobile, where a fix through the store takes days. Clean up old flags so the code doesn't fill with dead branches.

Never hardcode user-facing text; keep translations in message files keyed by ID (with libraries such as i18next, react-intl, next-intl, or Flutter's intl/ARB files). Use the locale for plural rules, dates, numbers and currencies via Intl APIs, allow for longer text and different fonts in layouts (for example Burmese text needs more line height), and support right-to-left languages if you target them.

Give interactive elements labels and roles (accessibilityLabel and accessibilityRole in React Native, Semantics in Flutter), keep touch targets at least about 44–48 points, support the system font size (Dynamic Type on iOS, font scale on Android) without breaking layouts, keep good contrast, and don't rely on gestures alone. Test with VoiceOver and TalkBack yourself.

Generics let you write a function or type once and keep it type-safe for many shapes of data. A typed API helper, for example, can return the exact response type to both the web and mobile clients, catching mismatches at compile time instead of at runtime. Combine it with runtime validation (like Zod) at the network boundary, because TypeScript types disappear at runtime.

Usual suspects are missing indexes, N+1 queries, returning too much data, slow third-party calls made in sequence, no caching and heavy CPU work on the request path. Find them by measuring rather than guessing: request timing and p95/p99 latency in your monitoring, slow-query logs and EXPLAIN, and tracing that shows how long each database or HTTP call took.

First, does it solve the right problem and is it correct, including edge cases and error paths? Then security (auth checks, input validation, secrets), data changes (migrations, backwards compatibility with older mobile versions), tests, performance and readability. Ask questions rather than give orders, separate blocking issues from small suggestions, and approve quickly when it's good enough.

Data: a likes table with a unique (user_id, post_id) pair and a like_count on posts updated in the same transaction (or counted asynchronously at large scale). API: idempotent PUT /posts/:id/like and DELETE /posts/:id/like, authenticated and rate-limited. Clients: optimistic toggle in the web and mobile UI with rollback on error, cache update through the query library, and an accessible button with a clear label. Tests: unit tests for the service, an API integration test for double-likes, and one E2E check.

Senior full-stack interviews move from "can you build it?" to "can you design it so it survives growth, failures, old app versions and changing teams?". Expect system design, data consistency, performance across web and mobile, security architecture and observability. Strong answers name trade-offs, give numbers where possible and draw on incidents you actually handled.

Work through it in a clear order and say your assumptions out loud:

For most products and teams, start with a modular monolith: one deployable app with strict internal boundaries between domains (orders, billing, users), each owning its own tables. It is simple to deploy, debug and refactor. Split out a service only when there is a clear reason — a part with very different scaling needs, a separate team that needs independent releases, or strong isolation requirements. Microservices bring network failures, distributed data and much heavier operations, so they are an organisational tool as much as a technical one.

A BFF is a thin API layer built for one type of client — one for the web, one for the mobile apps — that calls the underlying services and shapes responses exactly for that client's screens. It reduces the number of round trips on slow mobile networks, keeps client-specific logic out of core services, and lets each client team move faster. The risk is duplicated logic across BFFs, so keep business rules in the core services and keep BFFs thin.

Make the API stateless — no sessions or uploaded files in local memory or disk — so any instance can handle any request. Put a load balancer in front, run several instances with autoscaling on CPU, latency or queue depth, keep shared state in Redis and the database, and store files in object storage. Then the database usually becomes the bottleneck, which you handle with indexes, caching, read replicas and, much later, partitioning.

A primary database handles writes and streams changes to one or more replicas that serve read queries, spreading load. The catch is replication lag: a user who just updated their profile may read the old value from a replica. Handle it with read-your-own-writes routing (read from the primary for a short time after a user writes, or for that user's own data), and keep critical reads such as balances on the primary.

Partitioning splits a large table into pieces — for example by month — inside one database, which makes queries and data retention easier. Sharding spreads data across several database servers by a shard key such as tenant_id or user_id. Choosing a key that spreads load evenly and keeps related data together is critical; cross-shard queries, transactions and re-sharding are hard, so shard only after simpler options are exhausted.

In a distributed system, when a network partition happens you must choose between consistency (every read sees the latest write, possibly by rejecting requests) and availability (every request gets an answer, possibly with stale data). In practice you choose per feature: an account balance or stock count should prefer consistency, while a like counter, a feed or analytics can accept eventual consistency. PACELC adds that even without partitions you trade latency against consistency.

Common patterns are cache-aside (read from cache, on a miss load from the database and store it), write-through (write to cache and database together) and write-behind (write to cache, flush later). Invalidation options are TTLs, deleting keys on writes, publishing change events, or versioned keys. Protect against stampedes — many requests rebuilding the same expired key — with request coalescing, locks, or serving stale data while one request refreshes.

Serve static assets with long cache times and content-hashed filenames so a deploy never serves stale files. Cache public pages and API responses at the edge with s-maxage and stale-while-revalidate, and purge by tag when content changes. Use the CDN's image resizing to serve properly sized WebP/AVIF images to phones and desktops. Never cache personalised responses publicly — mark them private or no-store.

Services publish events like OrderPlaced, and other services react — billing charges, email sends a receipt, analytics records it — without the publisher knowing about them. It decouples teams and smooths traffic spikes. The costs are eventual consistency, harder debugging across services, duplicate and out-of-order events, and schema evolution of events. Consumers must be idempotent, and you need correlation IDs and tracing to follow a flow.

It solves the "dual write" problem: saving to the database and publishing a message are two separate actions, and one can fail after the other succeeds. With an outbox, you write the business change and an event row into an outbox table in the same database transaction. A separate relay (a poller or change-data-capture) reads the outbox and publishes to the message broker, retrying until it succeeds. Consumers deduplicate by event ID.

Avoid distributed two-phase commit; use a saga instead. A saga is a sequence of local transactions where each step has a compensating action — reserve stock, charge the card, create the shipment, and if charging fails, release the stock. It can be choreographed (services react to each other's events) or orchestrated (one coordinator, often a workflow engine like Temporal, drives the steps). Design each step to be idempotent and make the intermediate states visible to users ("payment pending").

Use expand and contract, so old and new code (and old mobile versions) both work at every step:

Use rolling, blue-green or canary deployments behind a load balancer, with health and readiness checks so traffic only reaches instances that are ready. Handle SIGTERM gracefully: stop accepting new requests, finish in-flight ones and close database connections. Keep every release backwards compatible with the previous one, separate risky changes with feature flags, and make rollback a one-click, well-practised action.

Track the app version and platform on every request (a header like X-App-Version), and watch usage per version. Keep API changes additive, use server-driven configuration and feature flags to adjust behaviour without a release, and maintain a minimum-supported version: the API can return a specific error or the app can check a config endpoint and show a "please update" screen (soft prompt first, forced update only when necessary, such as a security fix).

Give each record a client-generated ID (UUID) and a version or updatedAt from the server. The client keeps a local database plus an outbox of pending changes; sync sends the outbox and pulls changes since the last sync token. For conflicts choose per data type: last-write-wins for simple fields, field-level merges, server-wins for money and stock, or asking the user for important documents. For collaborative editing, CRDTs (like Yjs or Automerge) merge concurrent changes automatically.

The old architecture sent serialized JSON messages over an asynchronous "bridge" between JavaScript and native code, which added latency. The New Architecture, the default since React Native 0.76, replaces it: JSI lets JavaScript hold direct references to C++ objects and call them synchronously; Fabric is the new renderer with support for concurrent React features; TurboModules load native modules lazily with typed interfaces generated by Codegen; and bridgeless mode removes the bridge entirely. Hermes is the default JavaScript engine, compiling JS to bytecode ahead of time for faster startup.

Flutter doesn't use the platform's native widgets; it builds a widget tree, turns it into element and render-object trees, and paints every pixel with its own engine (Impeller on modern iOS and Android) onto a canvas. That gives identical UI and smooth animations across platforms, but platform-specific look and accessibility behaviour must be reproduced by the framework. React Native renders real native views, so it feels native by default and fits teams already using React, at the cost of slightly less pixel-level control.

When you need something the framework or community packages don't cover well: a new platform SDK, a hardware feature (Bluetooth devices, NFC payments, background location), heavy processing like audio or video, a home-screen widget, or a performance hotspot. In React Native you write a Turbo Module or an Expo Module in Swift and Kotlin; in Flutter you use platform channels or FFI. Keep the native surface small and well-tested, because it needs skills on two platforms.

Measure cold start on a real mid-range Android device with release builds, not debug. Then defer everything not needed for the first screen: lazy-load screens and modules, postpone SDK initialisation (analytics, ads, chat), avoid big synchronous storage reads on launch, use Hermes bytecode in React Native, keep the bundle small, and show cached content immediately while fresh data loads. Set a startup budget and track it per release.

Typical causes are listeners, timers and subscriptions not cleaned up, closures holding large objects, global caches that grow forever, and in mobile apps large images kept in memory. Use Chrome DevTools heap snapshots (compare before and after repeating an action), Xcode Instruments and Android Studio's Memory Profiler, and Flutter DevTools. Fix them with cleanup functions in effects or dispose() in Flutter, bounded caches and correctly sized images.

At 60 Hz you have about 16 ms per frame, and only about 8 ms at 120 Hz. Run animations on the UI thread instead of the JavaScript thread — react-native-reanimated worklets or the native driver in React Native, and Flutter's built-in animation system. Animate transforms and opacity rather than layout properties, avoid re-rendering large trees during gestures, and profile with the performance monitor and Flutter DevTools in release or profile mode.

Use one identity service (your own or a provider such as Auth0, Clerk, Cognito or Firebase Auth) speaking OAuth 2.0 / OpenID Connect. The web uses HttpOnly cookie sessions or a BFF that holds tokens server-side; mobile apps use Authorization Code with PKCE through the system browser and keep tokens in secure storage. Short-lived access tokens, rotating refresh tokens, device/session lists so users can sign out other devices, and support for passkeys, Sign in with Apple (required on iOS when you offer other social logins) and Google.

Assume the app can be decompiled and the API called by scripts. Authenticate users properly, authorize every request on the server, rate-limit by user, device and IP, and validate everything. Add app attestation (Apple App Attest / DeviceCheck and Google Play Integrity) to make scripted abuse harder, bot detection on sign-up and login, and anomaly alerts. Certificate pinning can stop casual interception but must be planned with backup pins, or a certificate rotation can lock out every user.

OWASP publishes widely used security guidance, including the Top 10 for web apps and the Mobile Top 10. In real projects the most common problems are broken access control (a user can read someone else's order by changing an ID), injection, security misconfiguration, vulnerable dependencies, weak authentication and sensitive data exposure, plus insecure storage of data on mobile devices. Build checks into the process: threat modelling, dependency scanning, authorisation tests and security review for sensitive changes.

Never trust an ID from the client on its own. Every query that loads a resource must also be scoped to what the user is allowed to see — usually by owner or tenant — and access rules should live in one central, tested place rather than in each route. Write tests that try to access another user's data and expect 404 or 403.

Keep them out of Git and out of client bundles. Store them in a secret manager (AWS Secrets Manager, GCP Secret Manager, Vault, Doppler, or the platform's encrypted env vars), give each service only the secrets it needs, use separate secrets per environment, and rotate them regularly and immediately after a leak. Add secret scanning in CI and on the repository so an accidentally committed key is caught within minutes.

Choose an isolation model: a shared database with a tenant_id on every row (cheapest, needs strict scoping, possibly enforced with PostgreSQL row-level security), a schema per tenant, or a database per tenant (strongest isolation, highest operating cost). Put the tenant in the auth token, scope every query and cache key by tenant, apply per-tenant rate limits so one noisy tenant can't hurt others, and plan for per-tenant data export and deletion.

Logs tell you what happened in detail, metrics tell you how much and how often (request rate, error rate, latency percentiles, saturation), and traces show the path of a single request across services, the database and third parties. With OpenTelemetry you can instrument once and send all three to tools like Grafana, Datadog or Honeycomb. Connect them with a shared trace or request ID, including from the mobile app through to the API.

An SLI is a measurement of user experience, such as "the share of checkout requests that succeed in under 500 ms". An SLO is the target, such as 99.9% over 30 days. The error budget is what's left — 0.1% may fail — and it guides decisions: while budget remains, the team ships features; when it is used up, reliability work takes priority. Alert on fast budget burn rather than on every short spike.

First, mitigate: declare the incident, assign an incident lead, communicate status to stakeholders and users, and restore service quickly — roll back, disable a flag, scale up — before looking for the root cause. Then investigate with logs, metrics and traces, and confirm recovery. Afterwards, write a blameless post-incident review with a timeline, contributing factors and concrete action items that have owners and dates.

Run WebSocket servers as a separate, horizontally scaled tier behind a load balancer that supports long-lived connections. Since a user's connection lives on one node, use a pub/sub backbone (Redis, NATS or Kafka) to route messages to the right node. Keep connection servers lightweight, store messages durably before fanning out, resume by last message ID after reconnects, apply backpressure, and fall back to push notifications for offline mobile users.

Services publish a notification request (who, what type, data) to a queue instead of sending directly. A notification service checks each user's preferences and quiet hours, renders templates per channel and language, and hands off to channel workers for APNs/FCM, email and an in-app inbox stored in the database. Deduplicate and rate-limit per user, retry with backoff, clean up dead device tokens, and track delivery and open rates per channel.

Start with the database: PostgreSQL full-text search or MongoDB Atlas Search covers a lot. Move to a dedicated engine (Elasticsearch, OpenSearch, Meilisearch, Typesense or Algolia) when you need typo tolerance, relevance tuning, facets or high volume. Keep the database as the source of truth and sync the index through events or change-data-capture, accept a short lag, and support reindexing from scratch without downtime by using index aliases.

Use a payment provider such as Stripe so card data never touches your servers, and follow platform rules: digital goods inside iOS and Android apps generally must use in-app purchases, with exceptions and rules that vary by region and are changing, so check current store policies; physical goods and services can use normal payment providers. Create payments on the server, use idempotency keys, treat webhooks as the source of truth (verify signatures, handle duplicates and out-of-order events), and reconcile regularly.

Verify the signature using the raw request body and reject old timestamps to stop replays. Respond 2xx quickly and do the real work in a background job, because providers time out and retry. Store each event ID and ignore duplicates, don't assume events arrive in order (fetch the latest object state when it matters), and alert when processing fails repeatedly.

Treat the API as a product with a contract: an OpenAPI or GraphQL schema that is reviewed before implementation, generated typed clients for web and mobile, consistent naming, pagination, errors and dates, and a changelog. Design around screens and use cases so mobile doesn't need many round trips, support partial responses or field selection where useful, and add contract tests in CI that fail when a change would break a client.

Share decisions, not necessarily components: design tokens (colours, spacing, typography, radii, motion) defined once and generated into CSS variables, a Tailwind theme, React Native styles and Flutter ThemeData. Build components per platform that follow the same names and behaviour, document them in Storybook, and respect platform conventions — navigation, date pickers and haptics should feel native on iOS and Android. Version the design system and include accessibility checks in its tests.

Micro-frontends split a large web front end into parts owned and deployed independently by different teams, combined at build time, on the server or in the browser (for example with Module Federation). They help very large organisations where many teams block each other in one front-end repo. For most teams they add bundle duplication, inconsistent UX and complex tooling; a well-structured monorepo with clear ownership usually solves the same problem more cheaply.

Consider the team's current skills (a React web team is productive in React Native quickly), how much code you want to share with the web, how platform-specific or performance-heavy the app is (AR, complex camera or audio work might favour native), the need for a highly custom, identical UI (favouring Flutter), the maturity of libraries for your integrations, and long-term hiring. Prototype the riskiest screen in the top candidate before committing.

Keep most tests at the unit and integration level and only critical journeys in E2E. Run tests in parallel and shard them in CI, run only affected projects in a monorepo, use real but disposable databases in containers, and seed data per test. Treat flaky tests as bugs: quarantine them with an owner and a deadline, fix root causes like timing and shared state, and track flakiness over time.

Agree budgets that reflect user experience: LCP and INP targets, JavaScript per route, API p95 latency, mobile cold-start time, app download size and crash-free sessions. Enforce them automatically — bundle size checks and Lighthouse CI in pull requests, load tests before big launches, and dashboards with alerts from real-user monitoring. Review regressions in the same way as functional bugs.

Define realistic scenarios from production traffic — the mix of endpoints, think time and data sizes — and run them with a tool like k6, Gatling or Artillery against a production-like environment. Increase load step by step to find the breaking point, and watch latency percentiles, error rates, database CPU, connection pools and queue depth. The goal is to find the first bottleneck and confirm capacity with a safety margin before real traffic does it for you.

New requests wait for a connection, time out and cascade into errors, often after autoscaling adds more app instances, each with its own pool. Prevent it by sizing pools based on the database's limit divided across instances, using a pooler like PgBouncer or the provider's pooling (essential with serverless functions), keeping transactions short, setting query and acquire timeouts, and alerting on pool saturation.

Set a timeout on every outbound call, retry only safe or idempotent operations with exponential backoff and jitter, and use a circuit breaker to stop calling a service that is clearly down. Add fallbacks such as cached data or a degraded feature, use bulkheads (separate pools or queues) so one slow dependency can't exhaust everything, and move non-urgent calls to background jobs.

Collect only the data you need, document why and where it is stored, encrypt it in transit and at rest, and restrict access by role with audit logs. Support user rights — export and deletion across the database, backups policy, analytics, logs and third parties — and get consent where required. On mobile, fill in Apple's privacy nutrition labels and Google Play's Data safety form accurately, and list third-party SDKs that collect data.

Technical debt is the future cost of shortcuts and outdated decisions — sometimes deliberate and worthwhile, sometimes accidental. Make it visible: keep a debt register tied to concrete pain (slow delivery, incidents, onboarding time), prioritise items by impact versus effort, and pay it down continuously — the "boy scout rule", reserving a share of each sprint, or bundling refactors with feature work in the same area. Avoid big-bang rewrites.

An ADR is a short document stored with the code that records an important technical decision: the context, the options considered, the decision and its consequences. ADRs help new team members understand why things are the way they are, prevent the same debates from repeating, and make it easier to revisit a decision when the context changes.

Pair on real work rather than lecturing, give them problems slightly beyond their current level with support, and let them own features end to end. Review code with explanations and links, not just fixes, and ask questions that help them reason ("what happens if this request is retried?"). Share context about the product and business, give specific feedback regularly, and celebrate their growth publicly.

Use a clear structure such as STAR — Situation, Task, Action, Result. For example: our mobile app's offline orders were sometimes duplicated (situation); I owned the fix (task); I introduced client-generated IDs, idempotency keys and an outbox on the device, rolled it out behind a flag to 10% of users and monitored duplicates (action); duplicates dropped to zero and support tickets fell by a third (result). Mention what you'd do differently, which shows reflection.

A tech lead is still technical, but the job is now to multiply the team: set direction, make and explain decisions, keep delivery predictable across web, mobile and backend, protect quality and reliability, and grow people. Interviewers look for judgement, communication with non-engineers and concrete stories about decisions, conflicts and failures.

A senior engineer is measured mostly by their own technical output; a tech lead is measured by the team's outcomes. The lead owns the technical direction, breaks work down and sequences it, makes or facilitates decisions, unblocks people, coordinates with product, design and other teams, and keeps quality and reliability high. They still code — often on the critical path or on enabling work — but less than before, and they avoid becoming the bottleneck.

Start from the business goals for the next one to two years, then describe the target architecture that supports them and the gap from today: for example, one typed API contract for all clients, a shared design-token system, a release process that ships mobile weekly, and observability from the phone to the database. Turn it into a short written strategy with milestones, review it with the team so they help shape it, and revisit it every quarter.

Choose boring, proven technology the team knows well, unless a new tool solves a real problem the old one can't. Weigh team skills and hiring, how much code web and mobile can share, the ecosystem for your integrations (payments, maps, auth), hosting and running costs, and long-term maintenance. A TypeScript stack — for example Next.js on the web, Expo for mobile and a Node.js API with PostgreSQL — is a common choice because one language covers everything; write the reasons down in an ADR.

Build what differentiates your product and buy what doesn't. Authentication, payments, email delivery, error tracking, feature flags and search are usually better bought or adopted as managed services. Compare the total cost of ownership — not just the licence, but engineering time to build, run, secure and maintain it for years — against vendor cost, lock-in risk, data residency and how easily you could migrate away later.

Begin with the user journey and slice it vertically into thin end-to-end increments that each deliver something testable, rather than "backend first, then web, then mobile". Agree the API contract early so web and mobile can build against mocks in parallel, put unfinished parts behind feature flags, identify the riskiest unknowns and spike them first, and plan the mobile store review and release timeline into the schedule.

Break work down until pieces are small and familiar, estimate as a team, and compare with how long similar work took before. Give ranges with confidence ("3–5 weeks, most likely 4") instead of single dates, call out the assumptions and risks, and add time for testing, review, app-store review and bug fixing. Then re-forecast regularly as you learn and share changes early — bad news delivered early is a planning input; delivered late, it is a crisis.

Make all three visible in one backlog and talk about them in business terms: risk, cost of delay and impact on users. Agree a rough capacity split with the product manager (for example 70% features, 20% debt and platform, 10% bugs) and adjust it when reality changes — after incidents, reliability gets more. Critical bugs and security issues interrupt; the rest is prioritised. Tie debt work to the outcomes it unlocks, such as faster releases or fewer incidents.

Translate it into outcomes they care about: "This migration will cut our mobile release time from two weeks to three days", "This fix removes the cause of the last two outages, which cost us X in refunds". Bring data — lead time, incident counts, cloud cost, support tickets — propose a small, time-boxed first step with measurable results, and report back on what it achieved to build trust for the next request.

Make sure the problem and the decision criteria are agreed first, because many disagreements are really about different goals. Ask each side to write down their option with trade-offs, try a quick prototype or measurement when facts can settle it, and involve the people who will maintain it. If consensus doesn't come, decide, explain why in an ADR, and ask for "disagree and commit". Revisit if new evidence appears — and never make it personal.

Set clear expectations: small pull requests, reviews within one working day, automated checks for formatting, linting, types and tests so humans focus on design, correctness and security. Use a checklist for risky areas (migrations, auth, payments, API changes that affect old mobile versions). Encourage kind, specific comments, label nits as optional, and rotate reviewers so knowledge spreads instead of everything waiting on the lead.

Keep the written rules short and automate as many as possible: shared ESLint, Prettier and TypeScript configs, a monorepo template for new packages, commit and branch conventions, and standards for API design, error handling, logging and testing. Document the "why" briefly, let the team propose changes through pull requests, and apply new rules gradually rather than reformatting the entire codebase in one go.

Decouple them. The API is always backwards compatible and deploys continuously; the web deploys many times a day behind feature flags; mobile follows a regular release train (for example weekly or every two weeks) with a code freeze, QA, staged rollout and a hotfix path. Features are enabled with flags once every client that needs them is live, and new API capabilities ship before the clients that use them.

A release train ships mobile versions on a fixed schedule; whatever is ready and tested gets on the train, and anything else waits for the next one. It makes releases predictable for the business, reduces pressure to rush features, and turns releasing into routine. Pair it with a release captain rotation, automated builds and store uploads, a release checklist, staged rollouts and crash-rate gates for halting a rollout.

The DORA metrics — deployment frequency, lead time for changes, change failure rate and time to restore service — give a balanced view of speed and stability, and can be complemented with crash-free sessions, SLO compliance and developer-experience surveys. Use them to spot system problems and trends for the team, never to rank individuals, and don't turn them into targets that people can game. Lines of code and story points per person are not productivity metrics.

Make the right thing the easy thing: fast CI, good test helpers and fixtures, preview environments, templates, and automated checks. Agree a definition of done that includes tests, accessibility, analytics and monitoring. Share ownership of production — the team that builds a feature watches its dashboards after release. Quality improves delivery speed over time, because fewer bugs and incidents mean less rework.

Keep it blameless: focus on how the system and process allowed the failure, not on who made the mistake, so people share the full story. Build a precise timeline, identify the contributing factors (including detection and response delays), and agree on a few concrete action items with owners and due dates, prioritised against other work. Share the write-up widely and track action items to completion — a postmortem without follow-through is just a document.

Have enough people in the rotation (ideally six or more), clear runbooks and escalation paths, and alerts that are actionable and tied to user impact so nights aren't wasted on noise. Compensate on-call time, give time off after rough nights, review every page weekly and delete or fix noisy alerts. Make reducing pages a team goal — if on-call is painful, it is a reliability backlog item, not a personal endurance test.

Define what the team actually needs — maybe a strong mobile engineer more than another generalist — and write a clear, honest job description. Use a structured process with the same questions and a scoring rubric for every candidate: a practical exercise close to real work (a small feature or a code review of a pull request), a system-design conversation scaled to the level, and a behavioural interview. Train interviewers, reduce bias with structure, and give candidates fast, respectful feedback.

Prepare before day one: accounts, a laptop, and a setup script so the web app, mobile app and API run locally on the first day. Give them an onboarding buddy, an architecture overview, a glossary of business terms and a list of "good first tickets" that touch each part of the stack. Aim for a merged pull request in the first week and a small feature shipped in the first month, and ask them to improve the onboarding docs as they go.

Have regular one-to-ones where you talk about goals, not only status. Match work to growth goals — a mid-level developer who wants to become senior leads the design of the next feature, with you as a safety net. Give specific, timely feedback, both positive and constructive, use the career ladder to make expectations clear, and sponsor people by giving them visible opportunities and credit.

Start by understanding: talk privately, ask about blockers, workload, unclear expectations or personal issues, and check whether the problem is skill, will or environment. Then set clear, specific expectations with examples, agree on support (pairing, training, smaller tasks), and follow up regularly with documented feedback. Most cases improve with clarity and support; if they don't, involve your manager and HR early and handle it fairly and respectfully.

Delegate outcomes, not step-by-step tasks: explain the goal, the constraints and what "done" looks like, then let the person choose the approach. Match the level of support to their experience — more check-ins for someone new to the area — and review the design early rather than only the finished code. Accept that their solution may differ from yours; correct only what really matters.

Identify the areas only one person understands — often the mobile build setup, payments or a tricky integration — and spread that knowledge deliberately: pair programming, rotating who works on those areas, recorded walkthroughs, runbooks and ADRs. Require reviews from a second person on critical systems, and make "could someone else fix this at 2 a.m.?" a regular question. Your own knowledge as lead counts too.

Involve engineering early in discovery so feasibility, cost and technical opportunities shape the solution, not just the estimate. Share trade-offs openly ("we can ship the web version in two weeks; mobile needs a store release, so four"), review designs for edge cases such as empty, error, offline and loading states, and agree on how success will be measured. Treat it as one team with shared goals, not a hand-off chain.

Changes are normal; unmanaged changes are the problem. When a new request arrives, make the trade-off visible: what it would replace, how it affects dates and risk. Protect the team from constant interruptions by routing requests through the product manager and planning, keep an explicit buffer for urgent work, and cut scope rather than quality when the date is fixed — ship a smaller version and follow up.

Raise it early with facts, not feelings: what's done, what's left, and why the forecast changed. Present options rather than only the problem — reduce scope, ship web first and mobile in the next release train, add help to a specific part (only if it's truly separable), or move the date — with the consequences of each. Let stakeholders choose, then update the plan and keep communicating. Avoid quietly asking the team to work overtime for weeks.

Separate roles: the incident lead coordinates, engineers investigate, and one person handles communication. Post short, regular updates at a predictable interval to internal channels and to a public status page, saying what is affected, what is known, what's being done and when the next update comes — even if nothing changed. For mobile users, use in-app banners or server-driven messages. Afterwards, share a clear summary and the follow-up actions.

Avoid big-bang rewrites; use the strangler fig pattern. Put a routing layer in front of the old system, rebuild one capability at a time in the new system, route traffic to it gradually behind flags, and compare results (shadow traffic or dual reads) before switching fully. Migrate data incrementally with verification, keep a rollback path for each step, set milestones that each deliver value, and plan the decommissioning of the old parts — or you end up running both forever.

Make costs visible per service and environment with tags and a monthly review, and set budgets and alerts. The common wins are right-sizing over-provisioned instances and databases, autoscaling, shutting down idle preview and staging environments, caching and CDN use to reduce egress and compute, storage lifecycle rules, and reviewing pricey third-party SaaS seats and usage. Consider cost in design decisions, but don't trade engineer weeks for small savings.

Accept some lock-in where the managed service gives real speed — it is usually worth it — but keep an exit path for critical pieces. Wrap vendors behind your own interfaces (a payments or email module), prefer open standards and portable technology (PostgreSQL, OpenTelemetry, containers, OAuth/OIDC), keep your data exportable, and know roughly what a migration would cost. Re-evaluate when contracts renew.

Build it into the workflow: threat-model new features with sensitive data, follow a secure-coding checklist in reviews, scan dependencies and secrets in CI, keep dependencies updated automatically, and test authorisation rules. Assign clear owners for security topics, run regular security training using real examples from your own codebase, and plan penetration tests before major launches. Keep a fast path for patching critical vulnerabilities in web, API and mobile.

Assess quickly: are we actually using the affected code path, is it exposed, and is it actively exploited? If yes, treat it as an incident: patch or upgrade, or apply a temporary mitigation (a WAF rule, disabling a feature) if no fix exists yet. Deploy the API and web immediately; for mobile, ship a hotfix build (or an OTA update if the fix is JavaScript-only) and consider a forced update if the risk is high. Afterwards, review how quickly it was detected.

Treat them like any other tool: run a trial with clear goals, agree on guidelines, and measure the effect on delivery and quality. Guidelines should cover which tools are approved for your code and data, never pasting secrets or customer data into unapproved services, the author owning and understanding every line they submit, the same review and testing standards for generated code, and licence and security checks. Share good prompts and workflows across the team.

Favour written, asynchronous communication: design docs, ADRs, clear tickets, recorded demos and decision logs, so people don't depend on being online at the same time. Keep a small overlap window for the meetings that really need everyone, rotate meeting times fairly, and make sure decisions made in calls are written down. Invest in relationships deliberately — informal calls and occasional in-person meetups matter more when you're remote.

Planning should be about outcomes and a realistic commitment based on past capacity, with work already refined before the meeting. Retrospectives should produce one or two concrete experiments with owners, not a long list of complaints; review last time's actions first. Vary the format to keep people engaged, keep meetings short, and make it safe to raise problems — including about the lead.

Default to incremental refactoring: it keeps delivering value and lowers risk. Consider a rewrite only when the existing code blocks important business goals, can't be changed safely in small steps, and the team understands the domain well enough to rebuild it — and even then do it incrementally, module by module, with the old system still running. Be explicit about what the rewrite will not include, or it never finishes.

Make the API contract the shared source of truth: an OpenAPI or GraphQL schema reviewed by all client teams before implementation, generated typed clients, mock servers so clients can start immediately, and contract tests in CI. Agree on cross-cutting conventions once — authentication, errors, pagination, dates, versioning, deprecation timelines — and publish a changelog. Changes that could break old mobile versions need explicit sign-off.

Use a lightweight RFC (request for comments) process so decisions are open, written and recorded:

When several product teams keep solving the same infrastructure problems — CI pipelines, deployment, observability, mobile build signing, shared component libraries — and that work is slowing feature delivery. A platform team builds paved roads: templates, internal tools and self-service infrastructure that product teams want to use. Before that scale, rotate platform work within teams and assign clear owners.

Add it to the definition of done and the design review, not just a final audit. Use accessible components from the design system, automated checks in CI (such as axe for the web and accessibility lint rules), and manual testing with screen readers — VoiceOver, TalkBack and NVDA — on key flows each release. Train the team, track accessibility bugs like other bugs, and know your legal requirements (such as WCAG 2.2 AA in many markets).

Decide before building what success means and how to measure it: a primary metric (conversion, retention, task completion time) and guardrail metrics (errors, crash rate, performance). Instrument analytics events consistently on web and mobile with a shared event naming plan, use feature flags for A/B tests or gradual rollout comparisons, and review results with product after release — then iterate, or remove the feature if it doesn't help.

Stay technical enough to make good decisions and keep credibility, but avoid owning critical-path tasks that will block the team when you're in meetings. Good lead coding work includes prototypes and spikes, enabling work (tooling, shared libraries), fixing pain points, and reviews. Block focus time in your calendar, delegate work others can grow from, and notice when you're coding to avoid harder leadership work.

Say "no, but" or "yes, if" instead of a flat no: explain the trade-off clearly and offer alternatives — a smaller version, a later date, or what we would stop doing to make room. Base it on shared goals and data, not on preference. If it is truly important to the business, escalate the priority conflict transparently so the right people decide, rather than silently overloading the team.

Identify risks early with the team — technical unknowns, dependencies on other teams or vendors, app store review, data migration, performance and people availability — and rate them by likelihood and impact. Tackle the biggest unknowns first with spikes and prototypes, add mitigations and contingency plans, and keep a visible risk list reviewed in planning. Share the top risks with stakeholders before they become problems.

Write less but better documentation, close to the code: a README per app and package, a one-command setup, an architecture overview with diagrams, ADRs, runbooks for operations and an onboarding guide. Make updating docs part of the definition of done, review them in pull requests, and delete outdated pages — wrong documentation is worse than none. Ask every new joiner to fix what confused them.

Talk to each person privately first to understand their view, then bring them together to focus on the shared goal and specific behaviours, not personalities. Clarify roles and decision-making if the conflict comes from unclear ownership. Agree on concrete ways of working, follow up, and recognise improvements. If behaviour crosses a line — disrespect, harassment — act immediately and involve your manager or HR.

Connect work to its impact — share user feedback, metrics and stories of what the team shipped. Give people autonomy over how they solve problems, opportunities to master new skills (letting a web developer learn mobile, for example), and a sustainable pace. Celebrate wins and learning, remove frustrating friction such as slow builds and flaky tests, and be honest about difficult news. Motivation drops fastest when people feel their work doesn't matter or they aren't heard.

Choose a real failure with real consequences and own your part. For example: I agreed to a launch date for a new mobile checkout without allowing time for store review and payment-provider certification, and we missed it by two weeks. Explain what you did to recover (re-planned with options, communicated early, shipped web first) and what changed afterwards (a release checklist and risk review that now includes external dependencies). Interviewers value self-awareness more than a perfect record.

Follow a small set of trusted sources — official release notes for your core stack (React, React Native, Flutter, Node.js, your database), a few newsletters and conference talks — and share learnings in the team. Evaluate new tools against a real problem with a time-boxed spike and clear criteria, adopt them first in low-risk areas, and keep a technology radar of what to adopt, trial, assess or hold.

First 30 days: listen and learn — one-to-ones with every engineer, product and design partners, reading the code, architecture, incidents and release process for web, mobile and API, and shipping a small change yourself. Days 30–60: fix a few visible pain points (a slow CI job, a noisy alert, a painful release step) and agree working agreements with the team. Days 60–90: share a written technical strategy and roadmap, aligned with the team and stakeholders, covering delivery, reliability, architecture and people growth.

Intern full-stack role အတွက် interviewer တွေက web page နဲ့ mobile app တွေ server နဲ့ ဘယ်လို ဆက်သွယ်လဲ၊ HTML၊ CSS နဲ့ JavaScript အခြေခံ၊ HTTP၊ REST နဲ့ JSON ဘယ်လိုအလုပ်လုပ်လဲ၊ database အရိုးရှင်းဆုံးတွေ၊ Git နဲ့ native app နဲ့ cross-platform mobile app ကွာခြားချက်တွေကို နားလည်လား စစ်ပါတယ်။ Production အတွေ့အကြုံ ရှိဖို့ ဘယ်သူမှ မမျှော်လင့်ပါဘူး။ ရှင်းလင်းတဲ့ အခြေခံ၊ ရိုးသားတဲ့ အဖြေနဲ့ ကိုယ်တိုင် ရေးခဲ့တဲ့ project အသေးလေး တစ်ခုကို ရှင်းပြနိုင်တာကို ကြည့်တာပါ။

Full-stack developer က product တစ်ခုရဲ့ အလွှာတိုင်းမှာ အလုပ်လုပ်ပါတယ် — user interface (web page နဲ့ mobile screen)၊ server ဘက်က API နဲ့ business logic၊ database နဲ့ ship လုပ်နိုင်လောက်တဲ့ deployment အထိပါ။ "Web နဲ့ mobile" role ဆိုရင် များသောအားဖြင့် backend တစ်ခုတည်းက web app ရော mobile app ကိုပါ serve လုပ်တာကို ဆိုလိုပါတယ်။ အရာအားလုံးမှာ expert ဖြစ်စရာ မလိုပေမဲ့ user နှိပ်လိုက်တဲ့ button ကနေ database ထဲ သိမ်းလိုက်တဲ့ row အထိ feature တစ်ခုကို အစအဆုံး လိုက်ကြည့်နိုင်ရပါမယ်။

Front end က user ရဲ့ device ပေါ်မှာ run တဲ့အပိုင်း — browser page ဒါမှမဟုတ် mobile app — ဖြစ်ပြီး layout၊ interaction နဲ့ API ခေါ်တာတွေကို ကိုင်တွယ်ပါတယ်။ Back end က server ပေါ်မှာ run ပါတယ် — request တွေ လက်ခံတယ်၊ permission စစ်တယ်၊ business rule တွေ အသုံးချတယ်၊ database နဲ့ ဆက်သွယ်ပြီး data ပြန်ပို့ပေးတယ်။ Device ကို user က ထိန်းချုပ်ထားတာမို့ secret တွေ ဒါမှမဟုတ် နောက်ဆုံး validation ကို front end ကို ဘယ်တော့မှ ယုံကြည်ပြီး မပေးရပါဘူး။

အကြမ်းအားဖြင့် browser က ဒီအဆင့်တွေကို အစဉ်လိုက် လုပ်ပါတယ် —

HTTP က web ရဲ့ request–response protocol ပါ — client က method၊ path၊ header နဲ့ လိုရင် body ကို ပို့ပြီး server က status code၊ header နဲ့ body နဲ့ ပြန်ဖြေပါတယ်။ GET က data ဖတ်တယ်၊ POST က အသစ်ဖန်တီးတာ ဒါမှမဟုတ် တစ်ခုခု trigger လုပ်တာ၊ PUT က resource ကို အစားထိုးတယ်၊ PATCH က တစ်စိတ်တစ်ပိုင်း update လုပ်ပြီး DELETE က ဖျက်ပါတယ်။ Browser၊ cache နဲ့ crawler တွေက GET ကို လွတ်လွတ်လပ်လပ် ထပ်ခေါ်နိုင်လို့ GET က data ကို ဘယ်တော့မှ မပြောင်းသင့်ပါဘူး။

ပထမဂဏန်းက အမျိုးအစားကို ပြောပြပါတယ်။ Web နဲ့ mobile client တွေ မှန်မှန်ကန်ကန် တုံ့ပြန်နိုင်အောင် API ကောင်းတစ်ခုက သူတို့ကို ရိုးရိုးသားသား သုံးပါတယ်။

REST က /users/42/orders လို URL တွေနဲ့ ခွဲခြားထားတဲ့ resource တွေကို ဗဟိုပြုပြီး HTTP method တွေနဲ့ action ကို ဖော်ပြတဲ့ HTTP API ဒီဇိုင်းပုံစံ တစ်မျိုးပါ။ Request တွေက stateless ဖြစ်ပါတယ် — request တစ်ခုချင်းက auth token လို server လိုအပ်တာ အားလုံးကို ယူလာပါတယ် — response တွေကတော့ များသောအားဖြင့် JSON ပါ။ REST API တစ်ခုတည်းက website၊ iOS app နဲ့ Android app ကို serve လုပ်နိုင်လို့ full-stack အလုပ်မှာ အရမ်းအသုံးများပါတယ်။

JSON (JavaScript Object Notation) က object၊ array၊ string၊ number၊ boolean နဲ့ null ပါတဲ့ structured data အတွက် ပေါ့ပါးတဲ့ text format ပါ။ Language နဲ့ platform တိုင်းက ဖတ်ရေးနိုင်တယ်၊ လူကလည်း လွယ်လွယ်ကြည့်နိုင်ပြီး JavaScript object တွေနဲ့ သဘာဝကျကျ ကိုက်ညီပါတယ်။ JSON မှာ date type မရှိလို့ date တွေကို များသောအားဖြင့် "2026-10-12T09:30:00Z" လို ISO 8601 string အနေနဲ့ ပို့ပါတယ်။

Native app ကို platform ရဲ့ ကိုယ်ပိုင် language နဲ့ SDK — Swift ဒါမှမဟုတ် Kotlin — နဲ့ ရေးတာဖြစ်ပြီး performance အကောင်းဆုံးနဲ့ device feature အားလုံးကို သုံးနိုင်ပါတယ်။ Cross-platform app ကို React Native ဒါမှမဟုတ် Flutter လို framework နဲ့ တစ်ခါရေးပြီး iOS ရော Android မှာပါ run ပါတယ်၊ UI ကလည်း native ဆန်ဆန် ပေါ်ပါတယ်။ Hybrid app က web page ကို WebView ထဲ ထည့်ထုပ်ထားတာပါ (ဥပမာ Capacitor ဒါမှမဟုတ် Cordova)၊ web skill နဲ့ အမြန်ဆုံး ဆောက်နိုင်ပေမဲ့ များသောအားဖြင့် native ဆန်မှု အနည်းဆုံးပါ။

React Native က React နဲ့ JavaScript ဒါမှမဟုတ် TypeScript ကိုသုံးပြီး iOS နဲ့ Android app တွေ ဆောက်နိုင်စေပါတယ်၊ component တွေက တကယ့် native view တွေအဖြစ် ပြောင်းပါတယ်။ Flutter က Google ရဲ့ toolkit ဖြစ်ပြီး Dart language ကိုသုံးကာ ကိုယ်ပိုင် rendering engine နဲ့ pixel တိုင်းကို ဆွဲတာမို့ platform တိုင်းမှာ UI တစ်ပုံစံတည်း ပေါ်ပါတယ်။ Web မှာ React သုံးပြီးသား team တွေအတွက် React Native က သဘာဝကျပြီး၊ custom ဆန်ပြီး တစ်ပုံစံတည်းဖြစ်ရမယ့် UI တွေအတွက် Flutter ကို လူကြိုက်များပါတယ်။

HTML က page ရဲ့ ဖွဲ့စည်းပုံနဲ့ အဓိပ္ပာယ်ကို ပေးပါတယ် — heading၊ paragraph၊ form၊ link တွေ။ CSS က ဘယ်လိုပုံပေါ်မလဲကို ထိန်းပါတယ် — layout၊ အရောင်၊ font၊ spacing နဲ့ responsive ဖြစ်မှု။ JavaScript က behaviour ထည့်ပါတယ် — click ကို တုံ့ပြန်တာ၊ data fetch လုပ်တာ၊ reload မလုပ်ဘဲ page ကို update လုပ်တာ။ ဒီတာဝန်တွေကို ရှင်းရှင်းခွဲထားရင် code ပြင်ရလွယ်ပြီး accessibility ပိုကောင်းပါတယ်။

Semantic HTML ဆိုတာ နေရာတိုင်းမှာ <div> သုံးမယ့်အစား <nav>၊ <main>၊ <article>၊ <button>၊ <label> လို element တွေကို သူတို့ရဲ့ အဓိပ္ပာယ်အလိုက် ရွေးသုံးတာပါ။ Screen reader၊ search engine နဲ့ browser တွေက page ကို ပိုနားလည်တယ်၊ keyboard support လည်း အလိုလို ရတတ်တယ် (တကယ့် <button> က focus ရပြီး Enter နဲ့ Space ကို တုံ့ပြန်တယ်)၊ code လည်း ဖတ်ရလွယ်ပါတယ်။

Element တိုင်းဟာ အထဲက content၊ ပြီးရင် padding၊ border၊ အပြင်ဆုံးမှာ margin ပါတဲ့ box တစ်ခုပါ။ Default အရ width က content ကိုပဲ ဖုံးလို့ padding နဲ့ border က box ကို မျှော်လင့်ထားတာထက် ကြီးစေပါတယ်။ Project အများစုက box-sizing: border-box သတ်မှတ်ပြီး width ထဲမှာ padding နဲ့ border ပါ ပါဝင်အောင်လုပ်တာမို့ layout ကို တွက်ရ အများကြီး လွယ်ပါတယ်။

Flexbox က item တွေကို ဦးတည်ချက် တစ်ခုတည်း — row ဒါမှမဟုတ် column — နဲ့ စီပေးပြီး navbar၊ toolbar၊ အလယ်ပို့တာနဲ့ item တွေကြား နေရာခွဲတာတွေအတွက် ကောင်းပါတယ်။ Grid က row နဲ့ column နှစ်ဘက်လုံးကို တပြိုင်နက် ထိန်းပြီး page layout၊ card gallery နဲ့ dashboard တွေနဲ့ ကိုက်ပါတယ်။ တကယ့် layout အများစုက page တစ်ခုလုံးအတွက် Grid၊ component တစ်ခုချင်းထဲမှာ Flexbox သုံးပါတယ်။ စိတ်ဝင်စားစရာက React Native ဟာ layout အားလုံးအတွက် Flexbox (column ကို default direction အဖြစ်) သုံးပါတယ်။

Responsive design ဆိုတာ website တစ်ခုတည်းက fluid width၊ flexible image၊ Flexbox/Grid နဲ့ media query တွေသုံးပြီး ဖုန်း၊ tablet၊ desktop ဘယ် screen size မှာမဆို လိုက်ညှိပေးတာပါ။ Mobile-first နည်းက screen သေးအတွက် style ကို အရင်ရေးပြီး screen ကြီးတွေအတွက် min-width media query တွေ ထပ်ထည့်ပါတယ်။ Viewport meta tag ကို မမေ့ပါနဲ့၊ မဟုတ်ရင် ဖုန်းတွေက page ကို zoom out လုပ်ထားသလို ပြပါလိမ့်မယ်။

var က function-scoped ဖြစ်ပြီး hoist ဖြစ်လို့ မထင်မှတ်တဲ့ bug တွေ ဖြစ်စေတာမို့ ခေတ်သစ် code တွေက ရှောင်ပါတယ်။ let နဲ့ const က block-scoped ဖြစ်ပြီး let ကို ပြန် assign လုပ်လို့ရတယ်၊ const ကို မရပါဘူး။ const က object ကို immutable မဖြစ်စေပါဘူး — property တွေကို ပြောင်းလို့ရသေးတယ် — variable က တခြားတစ်ခုကို ညွှန်ဖို့ကိုပဲ တားတာပါ။ Default အနေနဲ့ const သုံးပြီး တကယ်ပြန် assign လုပ်မှ let သုံးပါ။

=== က type မပြောင်းဘဲ value နဲ့ type နှစ်ခုလုံးကို နှိုင်းယှဉ်တာမို့ 1 === "1" က false ပါ။ == က type ကို အရင်ပြောင်းလို့ 1 == "1" က true ဖြစ်ပြီး 0 == "" လည်း true ဖြစ်တာမို့ bug တွေကို ဖုံးကွယ်ထားပါတယ်။ အမြဲတမ်း === နဲ့ !== သုံးပါ၊ အသုံးများတဲ့ ခြွင်းချက်တစ်ခုက value == null ပါ — null ရော undefined ပါ တမင်စစ်တာပါ။

DOM (Document Object Model) က HTML page ကို ကိုယ်စားပြုတဲ့ browser ရဲ့ object tree ပါ။ JavaScript က သူ့ကို ဖတ်ပြီး ပြောင်းလို့ရပါတယ် — element ထည့်တာ၊ text ပြောင်းတာ၊ class toggle လုပ်တာ — ပြီးရင် browser က ပြန် render လုပ်ပါတယ်။ React လို framework တွေက DOM ကို ကိုယ့်အစား update လုပ်ပေးပေမဲ့ DOM ကို သိထားရင် layout၊ event နဲ့ performance ကို debug လုပ်ရာမှာ အထောက်အကူဖြစ်ပါတယ်။ Mobile framework တွေမှာလည်း native view tree ဆိုတဲ့ သူတို့ကိုယ်ပိုင် အလားတူ ရှိပါတယ်။

Element တစ်ခုကို click လိုက်ရင် event က အဲဒီ element မှာ ဖြစ်ပြီးနောက် parent တစ်ခုချင်းကနေ document အထိ အပေါ်ကို bubble တက်သွားပါတယ်။ Event delegation က ဒါကို အသုံးချတာပါ — list item တစ်ခုချင်းစီမှာ listener တစ်ခုစီ မထည့်ဘဲ parent မှာ listener တစ်ခုတည်း ထည့်ပြီး event.target ကို စစ်ပါတယ်။ Memory သက်သာပြီး နောက်မှထည့်တဲ့ item တွေအတွက်လည်း အလိုလို အလုပ်လုပ်ပါတယ်။

Network request လို နောက်မှ ပြီးမယ့် အလုပ်တွေကို ကိုင်တွယ်ဖို့ နည်းသုံးမျိုးပါ။ Callback က အလုပ်ပြီးရင် ခေါ်ပေးဖို့ ပေးလိုက်တဲ့ function ပါ၊ အများကြီး ဆင့်ထည့်ရင် ရှုပ်ထွေးလာပါတယ်။ Promise က နောင်ရမယ့် ရလဒ်ကို ကိုယ်စားပြုတဲ့ object ဖြစ်ပြီး .then() နဲ့ .catch() ဆက်ပြီး သုံးပါတယ်။ async/await က promise ပေါ်က syntax ဖြစ်ပြီး ပုံမှန် အပေါ်ကအောက် code လို ဖတ်ရပါတယ်၊ error အတွက် try/catch သုံးပါ။

fetch က connection မရှိတာ ဒါမှမဟုတ် request ပိတ်ခံရတာလို network failure မှာပဲ reject ဖြစ်ပါတယ်။ 404 ဒါမှမဟုတ် 500 response ကတောင် အောင်မြင်စွာ resolve ဖြစ်တာမို့ res.ok (ဒါမှမဟုတ် res.status) ကို မစစ်ရင် error page ကို data အဖြစ် သုံးမိပါလိမ့်မယ်။ React Native က fetch မှာလည်း ဒီစည်းမျဉ်းအတိုင်းပါပဲ။

Closure ဆိုတာ ကိုယ့်ကို ဖန်တီးခဲ့တဲ့ scope ထဲက variable တွေကို အပြင်က function return ပြီးသွားတဲ့နောက်မှာတောင် မှတ်ထားတဲ့ function ပါ။ Private state၊ factory function၊ event handler နဲ့ React hook တွေဟာ closure ပေါ်မှာ အခြေခံပါတယ်။ ဂန္ထဝင် ဥပမာက return ပြန်တဲ့ function ကနေပဲ count variable ကို ပြောင်းလို့ရတဲ့ counter ပါ။

undefined က value ဘယ်တုန်းကမှ မသတ်မှတ်ရသေးတာကို ဆိုလိုပါတယ် — မရှိတဲ့ property၊ value မပါတဲ့ variable၊ return မပါတဲ့ function။ null ကတော့ developer က တမင် assign လုပ်တဲ့ "value မရှိ" ပါ။ API တွေက ဘယ်ဟာသုံးမလဲ တသမတ်တည်း ဖြစ်သင့်ပါတယ်၊ optional chaining (user?.address?.city) နဲ့ nullish coalescing (value ?? "default") က နှစ်ခုလုံးကို ဘေးကင်းစွာ ကိုင်တွယ်ပေးပါတယ်။

Component က ပြန်သုံးလို့ရတဲ့ UI အပိုင်းလေးပါ — button၊ card၊ screen တစ်ခုလုံး — React နဲ့ React Native မှာ function အဖြစ်၊ Flutter မှာ widget အဖြစ် ရေးပါတယ်။ Props က parent က ပေးလိုက်တဲ့ input တွေဖြစ်ပြီး component ထဲမှာ read-only ပါ။ State က input ထဲက စာသားလို component ကိုယ်တိုင်ပိုင်ပြီး ပြောင်းလို့ရတဲ့ data ပါ၊ state ပြောင်းရင် component ပြန် render ဖြစ်ပါတယ်။

useState က re-render တွေကြားမှာ ကျန်နေတဲ့ value ကို သိမ်းပြီး re-render ဖြစ်စေတဲ့ setter ကို ပေးပါတယ်။ useEffect က render ပြီးနောက် React ပြင်ပက subscription၊ timer၊ React မဟုတ်တဲ့ widget လို အရာတွေနဲ့ sync လုပ်ဖို့ code run ပြီး သူ့ cleanup function က နောက်တစ်ကြိမ် မ run ခင် ဒါမှမဟုတ် unmount ဖြစ်ချိန်မှာ run ပါတယ်။ Render လုပ်နေစဉ် တွက်လို့ရတဲ့ value တွေအတွက် effect မသုံးပါနဲ့၊ render အပိုတွေပဲ ဖြစ်စေပါတယ်။

React သဘောတရားတွေ — component၊ props၊ state၊ hook — က အတူတူပဲ ဖြစ်ပေမဲ့ အခြေခံ အစိတ်အပိုင်းတွေ ကွာပါတယ်။ <div>၊ <span>၊ <img> အစား <View>၊ <Text>၊ <Image> ကို သုံးရတယ်၊ စာသားအားလုံး <Text> ထဲမှာ ရှိရမယ်၊ style တွေက CSS file မဟုတ်ဘဲ JavaScript object တွေ (များသောအားဖြင့် StyleSheet.create နဲ့) ဖြစ်ပြီး window.localStorage လို browser API တွေ မရှိပါဘူး။

StatelessWidget က constructor argument တွေကနေပဲ တည်ဆောက်ပြီး label ဒါမှမဟုတ် icon လို ကိုယ့်ဘာသာ ဘယ်တော့မှ မပြောင်းပါဘူး။ StatefulWidget မှာ ပြောင်းလဲနေတဲ့ data ကို ကိုင်ထားတဲ့ သီးခြား State object ရှိပြီး data update လုပ်ပြီး UI ပြန်ဆောက်ဖို့ setState() ကို ခေါ်ပါတယ်။ တတ်နိုင်သမျှ stateless ထားပြီး မျှသုံးတဲ့ state ကို state-management solution ထဲ ရွှေ့ပါ။

Android emulator နဲ့ iOS Simulator က app ကို ကိုယ့်ကွန်ပျူတာပေါ်မှာ run ပေးတာမို့ development နဲ့ debug အတွက် မြန်ပါတယ်။ ဒါပေမဲ့ တကယ့် hardware နဲ့ အတိအကျ မတူပါဘူး — performance၊ camera၊ push notification၊ battery အပြုအမူ၊ gesture နဲ့ network နှေးတာတွေ ကွာပါတယ်။ Release မထုတ်ခင် အရေးကြီးတဲ့ flow တွေကို တကယ့်ဖုန်း အနည်းဆုံး တစ်လုံး၊ ဖြစ်နိုင်ရင် အလယ်အလတ်တန်းစား ဖုန်းမှာ အမြဲ test လုပ်ပါ။

Hot reload က ပြင်လိုက်တဲ့ code ကို run နေတဲ့ app ထဲ restart မလုပ်ဘဲ ထိုးထည့်ပေးပြီး လက်ရှိ state ကိုလည်း များသောအားဖြင့် ထိန်းထားတာမို့ ပြင်တာကို တစ်စက္ကန့်လောက်နဲ့ မြင်ရပါတယ်။ React Native မှာ Fast Refresh လို့ခေါ်ပြီး Flutter မှာ hot reload နဲ့ hot restart ရှိပါတယ်။ Native code၊ native dependency အသစ်၊ app config လို ပြောင်းလဲမှုတချို့ကတော့ full rebuild လိုသေးပါတယ်။

Database က data ကို အမြဲတမ်း သိမ်းပြီး ထိရောက်စွာ query လုပ်နိုင်စေပါတယ်။ PostgreSQL နဲ့ MySQL လို SQL (relational) database တွေက data ကို schema သတ်မှတ်ထားတဲ့ table တွေနဲ့ relationship တွေထဲ သိမ်းပြီး join နဲ့ transaction မှာ အားကောင်းပါတယ်။ MongoDB လို NoSQL database တွေက ပုံစံ လွတ်လပ်တဲ့ document (ဒါမှမဟုတ် key–value၊ graph စသည်) တွေကို သိမ်းပြီး data ပုံစံ ကွဲပြားတဲ့အခါ အဆင်ပြေပါတယ်။ နှစ်ခုလုံး မှန်ပါတယ်၊ ရွေးချယ်မှုက data နဲ့ ဘယ်လို access လုပ်မလဲပေါ် မူတည်ပါတယ်။

Primary key က users.id လို table ထဲက row တစ်ခုချင်းကို တစ်မူထူးခြားစွာ ခွဲခြားပေးပါတယ်။ Foreign key က orders.user_id က users.id ကို ညွှန်သလို တခြား table ရဲ့ primary key ကို ညွှန်တဲ့ column ဖြစ်ပြီး ညွှန်ထားတဲ့ user တကယ်ရှိကြောင်း database က အတင်းအကျပ် စစ်ပေးနိုင်ပါတယ်။ နှစ်ခုပေါင်းပြီး "user တစ်ယောက်မှာ order အများကြီး ရှိတယ်" လို relationship တွေကို model လုပ်ပါတယ်။

CRUD က အခြေခံ data operation လေးမျိုးဖြစ်ပြီး တစ်ခုချင်းက SQL နဲ့ REST နဲ့ သေသေသပ်သပ် ကိုက်ပါတယ် —

Inner join က table နှစ်ခုလုံးမှာ ကိုက်ညီတဲ့ row တွေကို ပြန်ပေးပါတယ်။ ဒီ query က order တစ်ခုချင်းကို customer နာမည်နဲ့ အသစ်ဆုံးကနေ စီပြီး ပြပါတယ်၊ LEFT JOIN သုံးရင် order မရှိတဲ့ user တွေကိုပါ ထည့်ပြပါလိမ့်မယ်။

Git က code ရဲ့ သမိုင်းကြောင်းကို မှတ်တမ်းတင်ပြီး လူအများကြီး branch တွေပေါ်မှာ ပြိုင်တူ အလုပ်လုပ်နိုင်စေတဲ့ version control system ပါ။ ပုံမှန် နေ့စဉ် flow က ဒီလိုပါ —

Pull request (PR) က ကိုယ့် branch ကို review လုပ်ပြီး merge လုပ်ပေးဖို့ team ကို တောင်းဆိုတာပါ။ PR ကောင်းတစ်ခုက သေးပြီး ပြောင်းလဲမှု တစ်ခုတည်းကို အာရုံစိုက်တယ်၊ ဘာလုပ်လဲ ဘာကြောင့်လဲ ရှင်းပြတဲ့ ခေါင်းစဉ်နဲ့ description ရှင်းရှင်းပါတယ်၊ UI ပြောင်းလဲမှုအတွက် screenshot (လိုရင် web ရော mobile ပါ) ပါတယ်၊ test တွေ pass ဖြစ်ပြီး review comment တွေကို ယဉ်ကျေးစွာ တုံ့ပြန်ပါတယ်။ PR သေးရင် review မြန်ပြီး ပျက်စီးမှု နည်းပါတယ်။

Authentication က "မင်းဘယ်သူလဲ?" ကို ဖြေပါတယ် — password၊ social login ဒါမှမဟုတ် passkey နဲ့ login ဝင်တာ။ Authorization က "မင်း ဘာလုပ်ခွင့်ရှိလဲ?" ကို ဖြေပါတယ် — ဥပမာ admin ပဲ user တွေကို ဖျက်နိုင်တယ်၊ user က ကိုယ့် post ကိုပဲ ပြင်နိုင်တယ်။ App ထဲမှာ button ကို ဖျောက်ထားရုံနဲ့ API ကို တိုက်ရိုက်ခေါ်တာကို မတားနိုင်လို့ authorization ကို server ပေါ်မှာ အမြဲ စစ်ရပါမယ်။

Password တွေကို plain text နဲ့ ဒါမှမဟုတ် MD5၊ SHA-256 လို မြန်တဲ့ hash တစ်ခုတည်းနဲ့ ဘယ်တော့မှ မသိမ်းပါနဲ့။ ခိုးယူခံရတဲ့ hash တွေကို crack လုပ်ဖို့ အရမ်းကုန်ကျစေတဲ့ bcrypt ဒါမှမဟုတ် Argon2 လို နှေးပြီး salt ပါတဲ့ password-hashing algorithm ကို သုံးပါ။ User login ဝင်တဲ့အခါ ရိုက်ထည့်တာကို hash လုပ်ပြီး သိမ်းထားတဲ့ hash နဲ့ library ရဲ့ compare function သုံးပြီး နှိုင်းယှဉ်ပါ။

Cookie တွေက သူတို့ domain ကို request တိုင်းမှာ browser က အလိုလို ပို့ပေးတဲ့ value သေးလေးတွေပါ၊ HttpOnly (JavaScript ကနေ မမြင်ရ) နဲ့ Secure ထားလို့ရလို့ web မှာ session token အတွက် အလုံခြုံဆုံး နေရာပါ။ localStorage က သက်တမ်းမကုန်ဘဲ သိမ်းထားပြီး sessionStorage က tab ပိတ်တဲ့အထိ သိမ်းပါတယ်၊ နှစ်ခုလုံးကို page ပေါ်က script တိုင်း ဖတ်နိုင်လို့ secret တွေ ဘယ်တော့မှ မထည့်ပါနဲ့။ Mobile app တွေမှာ default အားဖြင့် cookie jar မရှိလို့ secure storage (Keychain ဒါမှမဟုတ် Keystore) ကို သုံးပါတယ်။

CORS (Cross-Origin Resource Sharing) က browser ရဲ့ security စည်းမျဉ်းပါ — app.example.com က page တစ်ခုက api.other.com ရဲ့ response ကို ဖတ်ချင်ရင် အဲဒီ server က Access-Control-Allow-Origin လို header နဲ့ ခွင့်ပြုမှ ရပါတယ်။ Browser တွေကပဲ အတင်းကျင့်သုံးတာမို့ native mobile app တွေနဲ့ server-to-server ခေါ်တာတွေကို မထိခိုက်ပါဘူး။ CORS error ကို server ဘက်မှာ ယုံကြည်ရတဲ့ origin တွေကိုပဲ ခွင့်ပြုပြီး ပြင်ပါ၊ credential နဲ့ * မသုံးပါနဲ့။

HTTPS က TLS နဲ့ encrypt လုပ်ထားတဲ့ HTTP ပါ။ Password၊ token နဲ့ ကိုယ်ရေးကိုယ်တာ data တွေကို network ပေါ်က ဘယ်သူ့ဆီကမှ ဖုံးကွယ်ပေးတယ်၊ certificate နဲ့ server က သူပြောတဲ့သူ အစစ်ဖြစ်ကြောင်း သက်သေပြတယ်၊ လမ်းမှာ content ပြင်ခံရတာကို တားပါတယ်။ Browser တွေက plain HTTP ကို "not secure" လို့ ပြပြီး iOS (App Transport Security) ရော Android ပါ plain-HTTP traffic ကို default အနေနဲ့ ပိတ်ထားပါတယ်။

Environment variable တွေက database URL၊ API key၊ feature switch လို environment တစ်ခုနဲ့တစ်ခု ကွာတဲ့ configuration ကို code ပြင်ပမှာ ထားပေးပါတယ်။ ဒါကြောင့် secret တွေ Git ထဲ မရောက်ဘဲ build တစ်ခုတည်းကို development၊ staging နဲ့ production မှာ run နိုင်ပါတယ်။ Web ဒါမှမဟုတ် mobile app ထဲ bundle ဝင်သွားတဲ့ အရာမှန်သမျှ (ဥပမာ NEXT_PUBLIC_* ဒါမှမဟုတ် EXPO_PUBLIC_* variable တွေ) ကို user တွေ မြင်နိုင်တာမို့ တကယ့် secret တွေကို server ပေါ်မှာပဲ ထားပါ။

npm က JavaScript အတွက် package manager နဲ့ registry ပါ။ package.json က project နာမည်၊ script တွေ (dev၊ build၊ test လို) နဲ့ dependency တွေကို စာရင်းပြုစုပြီး lock file (package-lock.json၊ yarn.lock၊ pnpm-lock.yaml ဒါမှမဟုတ် bun.lock) က version အတိအကျကို ချိတ်ထားတာမို့ စက်တိုင်းမှာ အတူတူ install ဖြစ်ပါတယ်။ Lock file ကို commit လုပ်ပါ၊ node_modules ကို commit မလုပ်ပါနဲ့။

အရင်ဆုံး bug ကို သေချာ ပြန်ဖြစ်အောင် လုပ်ပြီးမှ ကျဉ်းအောင် ချုံ့ပါ — error နဲ့ stack trace အပြည့်အစုံကို ဖတ်၊ browser DevTools ရဲ့ Console နဲ့ Network tab (ဒါမှမဟုတ် React Native / Flutter dev tool နဲ့ device log) ကို စစ်၊ log ဒါမှမဟုတ် breakpoint ထည့်ပြီး ယူဆချက် တစ်ခုချင်းကို စမ်းပါ။ မကြာသေးခင် ပြောင်းလဲမှုတွေကို git log ဒါမှမဟုတ် git bisect နဲ့ စစ်ပါ။ ပြင်ပြီးရင် ပြန်မဖြစ်အောင် test တစ်ခု ထည့်ပါ။

Unit test က function လို code အပိုင်းသေးလေး တစ်ခုကို သီးခြားစစ်ပါတယ်။ Test တွေက နောက်ပိုင်း code ပြင်တဲ့အခါ ပြန်ပျက်တာတွေကို ဖမ်းပေးတယ်၊ code ဘယ်လို အလုပ်လုပ်ရမလဲ မှတ်တမ်းတင်ပေးတယ်၊ refactor လုပ်ဖို့ ယုံကြည်မှု ပေးပါတယ်။ အသုံးများတဲ့ tool တွေက JavaScript အတွက် Jest ဒါမှမဟုတ် Vitest၊ component တွေအတွက် React Testing Library နဲ့ Flutter အတွက် built-in flutter_test package ပါ။

Accessibility (a11y) ဆိုတာ မသန်စွမ်းသူတွေ — screen reader သုံးသူ၊ keyboard တစ်ခုတည်း သုံးသူ၊ အမြင်အားနည်းသူ ဒါမှမဟုတ် အရောင်ကန်းသူ — ကိုယ့် product ကို သုံးနိုင်တာပါ။ အခြေခံတွေက semantic HTML၊ ပုံတွေမှာ alt text၊ form field တွေမှာ label၊ မြင်ရတဲ့ focus style၊ လုံလောက်တဲ့ အရောင် contrast နဲ့ အရောင်တစ်ခုတည်းကို အားမကိုးတာပါ။ Mobile မှာလည်း React Native ရဲ့ accessibilityLabel နဲ့ Flutter ရဲ့ Semantics ကနေ ဒီသဘောတရားအတိုင်း ရှိပါတယ်။

Mobile app က state တွေကြား ကူးပြောင်းပါတယ် — launch ဖြစ်နေတာ၊ foreground မှာ active ဖြစ်နေတာ၊ inactive (ဥပမာ ဖုန်းဝင်လာချိန်)၊ background မှာ ရှိနေတာ၊ နောက်ဆုံး memory လွတ်အောင် system က suspend ဒါမှမဟုတ် kill လုပ်တာ။ App က background ရောက်တဲ့အခါ draft တွေ သိမ်း၊ video ဒါမှမဟုတ် timer တွေ ရပ်ပြီး ပြန်ရောက်လာတဲ့အခါ ဟောင်းနေတဲ့ data ကို refresh လုပ်သင့်ပါတယ်။ React Native က ဒါကို AppState နဲ့၊ Flutter က AppLifecycleListener ဒါမှမဟုတ် WidgetsBindingObserver နဲ့ ပေးပါတယ်။

Sign လုပ်ထားတဲ့ release တစ်ခု — Google Play အတွက် AAB ဒါမှမဟုတ် Apple App Store အတွက် IPA — ကို build လုပ်ပြီး screenshot၊ description နဲ့ privacy policy တွေနဲ့အတူ upload လုပ်ပါတယ်။ Apple နဲ့ Google က app ကို live မဖြစ်ခင် review လုပ်ပြီး နာရီပိုင်းကနေ ရက်ပိုင်းအထိ ကြာနိုင်ပါတယ်။ Tester တွေက iOS မှာ TestFlight၊ Google Play မှာ internal testing track တွေကနေ build အစောပိုင်းတွေကို ရနိုင်ပါတယ်။ EAS Build နဲ့ Fastlane လို tool တွေက sign လုပ်တာနဲ့ upload လုပ်တာကို automate လုပ်ပေးပါတယ်။

Deployment ဆိုတာ user တွေ တကယ်ရောက်နိုင်အောင် code ကို server ပေါ်တင်တာပါ။ ရိုးရှင်းတဲ့ setup တစ်ခု — web front end ကို Vercel ဒါမှမဟုတ် Netlify လို platform ပေါ်၊ API ကို Railway၊ Render ဒါမှမဟုတ် Fly.io လို service ပေါ်၊ database ကို Atlas ဒါမှမဟုတ် Neon လို managed database ပေါ်မှာ ထားပြီး တစ်ခုချင်းစီမှာ environment variable တွေ သတ်မှတ်ပါ။ Main branch ကို push လုပ်ရင် build နဲ့ deploy အလိုလို ဖြစ်ပါတယ်။ Mobile app ကတော့ production API URL ကို ညွှန်ထားရုံပါပဲ။

DNS (Domain Name System) က internet ရဲ့ ဖုန်းစာအုပ်ပါ — example.com လို နာမည်တွေကို IP address အဖြစ် ပြောင်းပေးပါတယ်။ အသုံးများတဲ့ record တွေက A/AAAA (IPv4/IPv6 address)၊ CNAME (တခြားနာမည်ဆီ alias)၊ MX (mail server) နဲ့ TXT (verification နဲ့ email security) ပါ။ Resolver တွေက record ရဲ့ TTL အတိုင်း အဖြေကို cache လုပ်ထားတာမို့ ပြောင်းလဲမှုတွေ ပျံ့နှံ့ဖို့ အချိန်ယူနိုင်ပါတယ်။

Agile ဆိုတာ cycle တိုတိုလေးတွေနဲ့ အလုပ်လုပ်ပြီး အလုပ်ဖြစ်တဲ့ အပိုင်းသေးလေးတွေကို ပေးပို့ကာ feedback အလိုက် ပြင်ဆင်သွားတဲ့ နည်းလမ်းပါ။ Scrum က လူကြိုက်များတဲ့ framework တစ်ခုပါ — တစ်ပတ်ကနေ နှစ်ပတ် sprint တွေနဲ့ အလုပ်လုပ်ပြီး sprint planning၊ နေ့စဉ် stand-up တိုတို၊ review demo နဲ့ retrospective တွေ ပါပါတယ်။ Intern အနေနဲ့ ticket သေးသေးလေးတွေ ယူမယ်၊ stand-up မှာ ရိုးရိုးသားသား update ပေးမယ်၊ ပိတ်မိနေရင် စောစောစီးစီး အကူအညီတောင်းရပါမယ်။

Project တစ်ခုရွေးပြီး ရှင်းရှင်းလင်းလင်း လမ်းလျှောက်ပြပါ — ဖြေရှင်းပေးတဲ့ ပြဿနာ၊ stack (ဥပမာ React web app၊ Expo mobile app နဲ့ PostgreSQL ပါတဲ့ Node.js API)၊ ဂုဏ်ယူတဲ့ feature တစ်ခုနဲ့ အစအဆုံး ဘယ်လိုအလုပ်လုပ်လဲ၊ ခက်ခဲခဲ့တဲ့ bug တစ်ခုနဲ့ ဘယ်လိုပြင်ခဲ့လဲ၊ အချိန်ပိုရရင် ဘာတွေ ပိုကောင်းအောင် လုပ်မလဲ။ Code ကို README ရှင်းရှင်းနဲ့ GitHub ပေါ်တင်ထားပြီး ဖြစ်နိုင်ရင် live demo ဒါမှမဟုတ် app ရဲ့ screen recording တိုတိုလေး ပြင်ဆင်ထားပါ။

Mid-level full-stack developer တစ်ယောက်က feature တစ်ခုကို အစအဆုံး ပိုင်ဆိုင်ဖို့ မျှော်လင့်ကြပါတယ် — API ဒီဇိုင်းဆွဲမယ်၊ data ကို model လုပ်မယ်၊ web နဲ့ mobile screen တွေ ဆောက်မယ်၊ auth၊ caching၊ error နဲ့ offline case တွေကို ကိုင်တွယ်မယ်၊ test ရေးမယ်၊ CI ကနေ production နဲ့ app store တွေအထိ ရောက်အောင် ပို့မယ်။ Interviewer တွေက trade-off တွေ၊ တကယ့် ဥပမာတွေနဲ့ mobile client တွေက web နဲ့ ဘယ်လိုကွာလဲ သိမသိကို နားထောင်ပါတယ်။

REST က ရိုးရှင်းတယ်၊ HTTP အပေါ်မှာ cache လုပ်ရလွယ်တယ်၊ endpoint တစ်ခုချင်းအလိုက် လုံခြုံအောင်လုပ်ဖို့နဲ့ monitor လုပ်ဖို့ လွယ်ပါတယ်။ GraphQL က client တစ်ခုချင်းကို request တစ်ခုတည်းနဲ့ လိုတဲ့ field အတိအကျကို တောင်းခွင့်ပေးတာမို့ web dashboard နဲ့ mobile screen သေးလေးက data တစ်ခုတည်းရဲ့ ပုံစံ အရမ်းကွာတဲ့အခါ အထောက်အကူဖြစ်ပေမဲ့ ရှုပ်ထွေးမှု ထပ်ထည့်ပါတယ် — schema ဒီဇိုင်း၊ N+1 resolver၊ query cost ကန့်သတ်ချက်နဲ့ ပိုခက်တဲ့ HTTP caching။ App တစ်ခုတည်းရှိတဲ့ team သေးလေးအတွက် REST က များသောအားဖြင့် လုံလောက်ပြီး client အများကြီးနဲ့ ရှုပ်ထွေးတဲ့ nested data ရှိမှ GraphQL က တန်ပါတယ်။

Session သုံးရင် server က session data ကို သိမ်းပြီး client က random session ID ကိုပဲ များသောအားဖြင့် HttpOnly cookie ထဲမှာ ကိုင်ထားပါတယ်၊ logout လုပ်တာ ဒါမှမဟုတ် revoke လုပ်တာ လွယ်ပါတယ်။ JWT သုံးရင် token ကိုယ်တိုင်က sign လုပ်ထားတဲ့ claim တွေကို သယ်လာတာမို့ server ဘယ်ဟာမဆို lookup မလုပ်ဘဲ စစ်နိုင်ပြီး mobile app နဲ့ service အများကြီးအတွက် ကိုက်ပေမဲ့ ခိုးခံရတဲ့ token က expire မဖြစ်မချင်း သုံးလို့ရနေပါတယ်။ အသုံးများတဲ့ ပေါင်းစပ်မှုက သက်တမ်းတို (မိနစ်ပိုင်း) access token နဲ့ server ပေါ်မှာ revoke လုပ်လို့ရတဲ့ သက်တမ်းရှည် refresh token ပါ။

သက်တမ်းတို access token နဲ့ လုံခြုံစွာ သိမ်းထားတဲ့ refresh token ကို ထုတ်ပေးပါ — web မှာ HttpOnly၊ Secure၊ SameSite cookie၊ mobile မှာ iOS Keychain ဒါမှမဟုတ် Android Keystore (ဥပမာ expo-secure-store နဲ့)။ သုံးတိုင်း refresh token ကို rotate လုပ်ပြီး hash ကို database ထဲ သိမ်းထားရင် token ဟောင်းကို ပြန်သုံးတာက ခိုးယူခံရတာကို ဖော်ပြပြီး family တစ်ခုလုံးကို revoke လုပ်နိုင်ပါတယ်။ Client ဘက်မှာ refresh တစ်ခု လုပ်နေတုန်း request တွေကို queue ထဲထားပါ၊ ဒါမှ ပြိုင်တူ 401 ဆယ်ခုက refresh ဆယ်ခါ မဖြစ်စေမှာပါ။

Mobile app နဲ့ SPA လို public client တွေက client secret ကို လျှို့ဝှက်မထားနိုင်လို့ PKCE ပါတဲ့ Authorization Code flow ကို သုံးပါတယ် —

Token တွေကို platform ရဲ့ secure storage — iOS မှာ Keychain၊ Android မှာ Keystore နဲ့ encrypt လုပ်ထားတဲ့ storage — ထဲ သိမ်းပါ၊ plain AsyncStorage ဒါမှမဟုတ် SharedPreferences ထဲ ဘယ်တော့မှ မထားပါနဲ့။ Payment provider ရဲ့ secret key ဒါမှမဟုတ် database password လို တကယ့် secret တွေကို app ထဲ ဘယ်တော့မှ ထည့်မပို့ပါနဲ့ — app bundle ကို download လုပ်ပြီး decompile လုပ်လို့ရပါတယ်။ Secret လိုတဲ့ အရာမှန်သမျှ backend ကနေ ဖြတ်သွားရပါမယ်။

Resource နာမည်ကို အများကိန်း noun နဲ့ ပေးပြီး filter၊ sort နဲ့ pagination အတွက် query parameter တွေ သုံးကာ data နဲ့ paging အချက်အလက်ပါတဲ့ တသမတ်တည်း response envelope ပေးပါ။ Client က row တစ်သန်း မတောင်းနိုင်အောင် input တွေကို validate လုပ်ပြီး ကန့်သတ်ပါ (ဥပမာ limit ကို အများဆုံး 100)။

Offset pagination (?page=3&limit=20) က ရိုးရှင်းပြီး user ကို page 10 ကို ခုန်သွားခွင့်ပေးပေမဲ့ database က ကျော်သွားတဲ့ row တွေကို scan လုပ်နေရတာမို့ table ကြီးတွေမှာ နှေးလာပြီး row အသစ်ဝင်လာရင် item တွေ နေရာရွေ့ပါတယ်။ Cursor pagination (?after=<last id>) က index ပါတဲ့ column ကို သုံးပြီး နောက်ဆုံး item ကနေ ဆက်တာမို့ မြန်ပြီး တည်ငြိမ်ပါတယ် — mobile app ရဲ့ infinite scroll feed တွေအတွက် အကောင်းဆုံးပါ။

Request body၊ query နဲ့ path parameter တိုင်းကို API boundary မှာ Zod၊ Joi ဒါမှမဟုတ် class-validator လို schema library နဲ့ validate လုပ်ပြီး input မှားရင် field error ရှင်းရှင်းနဲ့ 400 ပြန်ပါ။ Web form ဒါမှမဟုတ် mobile screen ထဲက client-side validation က user experience အတွက်ပဲ ဖြစ်ပါတယ်၊ ဘယ်သူမဆို API ကို တိုက်ရိုက်ခေါ်နိုင်လို့ server က ပြန်စစ်ရပါမယ်။ Monorepo ထဲမှာ Zod schema တစ်ခုတည်းကို web၊ mobile နဲ့ API ကြား မျှသုံးရင် စည်းမျဉ်းတွေ တသမတ်တည်း ဖြစ်ပါတယ်။

မှန်ကန်တဲ့ status code နဲ့ error တိုင်းအတွက် JSON ပုံစံ တစ်ခုတည်းကို သုံးပါ — client တွေ ခွဲခြားလို့ရတဲ့ မပြောင်းလဲတဲ့ machine-readable code၊ လူဖတ်လို့ရတဲ့ message နဲ့ လိုရင် field အသေးစိတ်။ Server ပေါ်မှာ error အပြည့်အစုံကို request ID နဲ့ log လုပ်ပါ၊ ဒါပေမဲ့ stack trace ဒါမှမဟုတ် SQL error တွေကို client ဆီ ဘယ်တော့မှ မပို့ပါနဲ့။ App version ဟောင်းတွေကို လပေါင်းများစွာ သုံးနေကြတာမို့ mobile app တွေက မပြောင်းလဲတဲ့ error code တွေကို အထူး အားကိုးပါတယ်။

Index က database ကို table တစ်ခုလုံး scan မလုပ်ဘဲ row တွေရှာနိုင်စေတဲ့ စီထားတဲ့ data structure (များသောအားဖြင့် B-tree) ပါ၊ စာအုပ်ရဲ့ index လိုပါပဲ။ မကြာခဏ filter၊ join ဒါမှမဟုတ် sort လုပ်တဲ့ column တွေမှာ index ထည့်ပြီး query အစဉ်နဲ့ ကိုက်တဲ့ compound index တွေ သုံးပါ။ Index တွေက read ကို မြန်စေပေမဲ့ write ကို နှေးစေပြီး နေရာယူတာမို့ column တိုင်းကို index မလုပ်ဘဲ EXPLAIN နဲ့ စစ်ပါ။

Transaction က operation အများကြီးကို အုပ်စုဖွဲ့ပြီး အားလုံးအတူ အောင်မြင်ရမယ် ဒါမှမဟုတ် အားလုံးအတူ ကျရှုံးရမယ် — ဥပမာ order ဖန်တီးတာနဲ့ stock လျှော့တာ။ ACID ဆိုတာ Atomicity (အားလုံး ဒါမှမဟုတ် ဘာမှမဖြစ်)၊ Consistency (စည်းမျဉ်းနဲ့ constraint တွေ မှန်နေဆဲ)၊ Isolation (ပြိုင်တူ transaction တွေက တစ်ယောက်ရဲ့ တစ်ဝက်တစ်ပျက် အလုပ်ကို တစ်ယောက် မမြင်ရ) နဲ့ Durability (commit လုပ်ပြီးရင် crash ဖြစ်လည်း ကျန်နေ) ပါ။ Lock တွေကို ကြာကြာမကိုင်ထားအောင် transaction တွေကို တိုတိုထားပါ။

List တစ်ခုကို query တစ်ခုနဲ့ load လုပ်ပြီးမှ item တစ်ခုချင်းအတွက် query တစ်ခုစီ ထပ် run တဲ့အခါ ဖြစ်ပါတယ် — ဥပမာ post 50 ခုနဲ့ သူတို့ author တွေအတွက် သီးခြား query 50 ခု။ ORM နဲ့ GraphQL resolver တွေမှာ ဖြစ်လွယ်ပါတယ်။ Join ဒါမှမဟုတ် eager loading (Prisma မှာ include၊ Mongoose မှာ populate)၊ WHERE id IN (...) query တစ်ခုတည်း ဒါမှမဟုတ် DataLoader နဲ့ batch လုပ်ပြီး ပြင်ပါ။

Prisma၊ Drizzle၊ TypeORM ဒါမှမဟုတ် Mongoose လို ORM တွေက type ပါတဲ့ model၊ migration၊ ပိုလုံခြုံတဲ့ parameterised query နဲ့ ပိုမြန်တဲ့ development ကို ပေးပါတယ်။ အားနည်းချက်တွေက (N+1 လို) ဖုံးကွယ်နေတဲ့ ထိရောက်မှုမရှိတဲ့ query တွေ၊ ရှုပ်ထွေးတဲ့ report တွေအတွက် ပေါက်ကြားတဲ့ abstraction တွေနဲ့ တခါတလေ ကိုယ်ပိုင် learning curve ပါ။ ချိန်ခွင်လျှာညီတဲ့ နည်းက နေ့စဉ် CRUD အတွက် ORM သုံးပြီး လေးလံတဲ့ query အနည်းငယ်အတွက် raw SQL ရေးကာ EXPLAIN နဲ့ စစ်တာပါ။

Git ထဲ commit လုပ်ထားပြီး deploy pipeline ထဲမှာ အလိုလို run တဲ့ version ပါ migration file တွေကို သုံးပါ၊ production console ထဲမှာ လက်နဲ့ ဘယ်တော့မှ မပြင်ပါနဲ့။ Migration တစ်ခုချင်းက သေးပြီး ဖြစ်နိုင်ရင် ပြန်ပြောင်းလို့ ရသင့်ပါတယ်။ Column နာမည်ပြောင်းတာလို run နေတဲ့ code ကို ပျက်စေနိုင်တဲ့ ပြောင်းလဲမှုတွေအတွက် rollout လုပ်နေစဉ် server ဟောင်းတွေနဲ့ mobile app version ဟောင်းတွေ ဆက်အလုပ်လုပ်အောင် backwards-compatible အဆင့်တွေ ခွဲလုပ်ပါ။

User နဲ့ အနီးဆုံးဖြစ်ပြီး မှန်ကန်နေဆဲ layer မှာ cache လုပ်ပါ —

Cache တိုင်းမှာ invalidation အစီအစဉ် လိုပါတယ် — TTL၊ data ပြောင်းတဲ့အခါ တိုက်ရိုက်ဖျက်တာ ဒါမှမဟုတ် version ပါတဲ့ key။

Server state က backend ပိုင်တဲ့ data — user၊ order၊ post — ဖြစ်ပြီး ဟောင်းသွားနိုင်လို့ fetch၊ cache နဲ့ refetch လုပ်ရပါတယ်၊ TanStack Query ဒါမှမဟုတ် SWR လို tool တွေက React ရော React Native မှာပါ ကောင်းကောင်း ကိုင်တွယ်ပေးပါတယ်။ Client state က local UI state — modal ဖွင့်ထားတာ၊ draft form၊ ရွေးထားတဲ့ tab — ဖြစ်ပြီး useState၊ context ဒါမှမဟုတ် Zustand လို store သေးလေးက ကိုင်တွယ်ပါတယ်။ နှစ်ခုကို global store ကြီးတစ်ခုထဲ ရောထည့်တာက bug တွေရဲ့ အဖြစ်များတဲ့ အရင်းအမြစ်ပါ။

Optimistic UI က server request အောင်မြင်ပြီးသားလို screen ကို ချက်ချင်း update လုပ်ပါတယ် — like နှိပ်တာနဲ့ ချက်ချင်း အနီရောင်ပြောင်းတယ် — request ကျရှုံးရင် ပြန်ပြောင်းပါတယ်။ အထူးသဖြင့် နှေးတဲ့ mobile network တွေမှာ app ကို ချက်ချင်းတုံ့ပြန်သလို ခံစားရစေပါတယ်။ Like ဒါမှမဟုတ် အစီအစဉ်ပြန်စီတာလို အန္တရာယ်နည်းပြီး အောင်မြင်ဖို့ များတဲ့ action တွေအတွက် သုံးပါ၊ ငွေပေးချေမှုလို အောင်မြင်တယ်လို့ မှားပြရင် ထိခိုက်နိုင်တဲ့ အရာတွေမှာ ရှောင်ပါ။

HTML ကို ဘယ်မှာ ဘယ်အချိန် ထုတ်လဲဆိုတာမှာ ကွာပါတယ် —

တကယ့် user တွေဆီကနေ တိုင်းတဲ့ Google ရဲ့ user-experience metric တွေပါ — LCP (Largest Contentful Paint၊ loading — 2.5 s အောက်)၊ INP (Interaction to Next Paint၊ တုံ့ပြန်မှု — 200 ms အောက်) နဲ့ CLS (Cumulative Layout Shift၊ မြင်ကွင်းတည်ငြိမ်မှု — 0.1 အောက်)။ Optimise လုပ်ထားတဲ့ ပုံ၊ JavaScript နည်းနည်း၊ server rendering ဒါမှမဟုတ် static page၊ layout မရွေ့စေတဲ့ font နဲ့ ပုံနဲ့ ကြော်ငြာတွေအတွက် နေရာကြိုချန်ထားတာတွေနဲ့ တိုးတက်အောင် လုပ်ပါ။

Bundle analyser နဲ့ အရင်တိုင်းပြီးမှ မလိုတာတွေ ဖယ်ပါ — လေးလံတဲ့ library တွေကို ပေါ့တာနဲ့ အစားထိုး၊ tree-shaking အလုပ်လုပ်အောင် သုံးတာကိုပဲ import လုပ်၊ route နဲ့ လေးလံတဲ့ component (chart၊ editor၊ map) တွေကို dynamic import() နဲ့ lazy-load လုပ်၊ framework က support လုပ်ရင် interactive မဟုတ်တဲ့ အပိုင်းတွေကို server component ထဲ ရွှေ့ပြီး ပြန်မကြီးလာအောင် CI မှာ size budget သတ်မှတ်ပါ။

ရှည်တဲ့ array ကို ScrollView ထဲမှာ ဘယ်တော့မှ map မလုပ်ပါနဲ့၊ row တိုင်းကို တစ်ခါတည်း render လုပ်လို့ပါ။ Screen ပေါ်မှာ ရှိတာကိုပဲ render လုပ်တဲ့ FlatList၊ SectionList ဒါမှမဟုတ် Shopify ရဲ့ FlashList လို virtualised list ကို သုံးပါ။ Row တွေကို မပြောင်းလဲတဲ့ keyExtractor ပေး၊ row component တွေကို memoise လုပ်၊ renderItem ထဲမှာ လေးလံတဲ့ အလုပ်တွေ မလုပ်ဘဲ size မှန်ပြီး cache လုပ်ထားတဲ့ ပုံတွေ သုံးပါ။

Web က URL နဲ့ browser ရဲ့ history ကို သုံးပါတယ်၊ mobile app တွေကတော့ screen stack၊ tab နဲ့ modal တွေကို native transition နဲ့ Android back button ပါ စီမံတဲ့ navigator တွေကို သုံးပါတယ်။ React Native မှာ React Navigation ဒါမှမဟုတ် Expo Router (Next.js နဲ့ ဆင်တူတဲ့ file-based) က ဒါကို ကိုင်တွယ်ပြီး Flutter က Navigator ဒါမှမဟုတ် go_router လို package တွေ သုံးပါတယ်။ Deep link နဲ့ notification တွေက တိုက်ရိုက်ဖွင့်နိုင်အောင် အရေးကြီးတဲ့ screen တိုင်းကို route တစ်ခုနဲ့ ချိတ်ထားပါ။

Deep link က myapp://orders/42 လို app ထဲက screen တစ်ခုကို တိုက်ရိုက်ဖွင့်ပေးပါတယ်။ Custom scheme တွေက လွယ်ပေမဲ့ ဘယ် app မဆို သူတို့ကို claim လုပ်နိုင်ပါတယ်။ Universal Links (iOS) နဲ့ App Links (Android) က ကိုယ့် website ပေါ်က file (apple-app-site-association ဒါမှမဟုတ် assetlinks.json) နဲ့ verify လုပ်ထားတဲ့ ပုံမှန် https:// URL တွေကို သုံးတာမို့ link တစ်ခုတည်းက app install ထားရင် app ကို၊ မထားရင် website ကို ဖွင့်ပါတယ် — share လုပ်တဲ့ link၊ email နဲ့ password-reset flow တွေအတွက် အကောင်းဆုံးပါ။

App က user ဆီ permission တောင်းပြီး Apple Push Notification service (APNs) ဒါမှမဟုတ် Firebase Cloud Messaging (FCM) ဆီက device token ကို ရယူကာ backend ဆီ ပို့ပါတယ်။ တစ်ခုခုဖြစ်တဲ့အခါ server က APNs/FCM ဆီ (တိုက်ရိုက် ဒါမှမဟုတ် Expo Push၊ OneSignal လို service ကနေ) message ပို့ပြီး သူတို့က device ဆီ ပို့ပေးပါတယ်။ Device တစ်ခုချင်းအလိုက် token သိမ်း၊ မမှန်တော့တာတွေ ဖယ်ရှား၊ user တွေကို category ရွေးခွင့်ပေးပြီး နှိပ်လိုက်ရင် screen မှန်ကို ဖွင့်အောင် deep link ထည့်ပါ။

User က feature ကို လိုအပ်တဲ့ အချိန်မှာ အခြေအနေနဲ့ ကိုက်အောင် တောင်းပါ — app ပထမဆုံး ဖွင့်ချိန်မှာ မဟုတ်ဘဲ "Scan receipt" နှိပ်တဲ့အခါမှ camera တောင်းပါ — system prompt ကို user က ငြင်းလိုက်ရင် ပြန်ပြလို့ မရတတ်တာမို့ ကိုယ်ပိုင် screen တိုလေးနဲ့ ဘာကြောင့်လဲ အရင်ရှင်းပြပါ။ အလုပ်ဖြစ်တဲ့ အသေးဆုံး permission (ခန့်မှန်း location၊ "app သုံးနေစဉ်") ကို တောင်းပြီး ငြင်းရင် fallback နဲ့ ယဉ်ကျေးစွာ ကိုင်တွယ်ကာ စိတ်ပြောင်းရင် system settings ဆီ link ပေးပါ။ Permission ဖော်ပြချက် မရှင်းတဲ့ app တွေကို store နှစ်ခုလုံးက ငြင်းပါတယ်။

User လိုအပ်တဲ့ data ကို local storage (SQLite၊ WatermelonDB၊ MMKV ဒါမှမဟုတ် Flutter မှာ Hive/Drift) ထဲ cache လုပ်ပြီး ချက်ချင်းပြကာ online ဖြစ်ရင် background ထဲမှာ refresh လုပ်ပါ။ Offline မှာ လုပ်ခဲ့တဲ့ write တွေကို unique ID တွေနဲ့ local outbox ထဲ queue လုပ်ထားပြီး connection ပြန်ရရင် ပို့ပါ။ Offline နဲ့ "syncing" state တွေကို ရှင်းရှင်းပြပြီး record တစ်ခုတည်းကို တခြားနေရာမှာ ပြောင်းထားရင် conflict ကို ဘယ်လို ကိုင်တွယ်မလဲ ဆုံးဖြတ်ပါ။

File ကြီးတွေကို API server ကနေ stream မလုပ်ပါနဲ့။ Client က API ဆီ pre-signed upload URL (S3၊ R2 ဒါမှမဟုတ် GCS အတွက်) တောင်းပြီး storage ဆီ တိုက်ရိုက် upload လုပ်ကာ file key ကို API ကို ပြောပါတယ်။ Server ပေါ်မှာ type နဲ့ size ကို validate လုပ်၊ ပုံတွေကို resize ဒါမှမဟုတ် compress လုပ် (mobile မှာ data သက်သာအောင် upload မလုပ်ခင် device ပေါ်မှာ)၊ URL အပြည့်အစုံအစား key ကို သိမ်းပြီး file တွေကို CDN ကနေ serve လုပ်ပါ။

Chat နဲ့ typing indicator လို နှစ်ဘက်သွား၊ latency နည်းတဲ့ message တွေအတွက် WebSocket (တိုက်ရိုက် ဒါမှမဟုတ် Socket.IO ကနေ) သုံးပါ၊ notification ဒါမှမဟုတ် progress လို server ဘက်ကပဲ တစ်ဘက်သွား update တွေအတွက် Server-Sent Events၊ update ရှားမှပဲ polling သုံးပါ။ Mobile မှာ app က background ရောက်ရင် socket ပိတ်သွားတာမို့ ပြန်ဖွင့်ရင် reconnect လုပ်၊ လွတ်သွားတဲ့ message တွေကို "last seen ID" နဲ့ ပြန် fetch လုပ်ပြီး app ပိတ်ထားစဉ် ရောက်လာတဲ့ message တွေအတွက် push notification သုံးပါ။

ဒါတွေက ဂန္ထဝင် web attack သုံးမျိုးဖြစ်ပြီး တစ်ခုချင်းမှာ စံ ကာကွယ်နည်း ရှိပါတယ် —

Rate limiting က client တစ်ခုက အချိန်ကာလ တစ်ခုအတွင်း request ဘယ်နှခု လုပ်နိုင်လဲ ကန့်သတ်ပြီး ကျော်ရင် Retry-After header နဲ့ 429 Too Many Requests ပြန်ပါတယ်။ Login နဲ့ OTP endpoint တွေကို brute force ကနေ ကာကွယ်တယ်၊ scraper တွေနဲ့ bug ရှိတဲ့ client တွေ (retry loop ထဲ ပိတ်မိနေတဲ့ mobile app လို) server ကို ဝန်ပိမသွားအောင် တားပြီး ကုန်ကျစရိတ်ကို ထိန်းပါတယ်။ Server instance တစ်ခုထက် ပိုရင် counter တွေကို Redis လို မျှသုံးတဲ့ store ထဲ ထားပါ။

Idempotent operation က တစ်ကြိမ် run ရင်ဖြစ်ဖြစ် အကြိမ်ကြိမ် run ရင်ဖြစ်ဖြစ် ရလဒ်တူတူ ပေးပါတယ်။ Mobile network တွေက connection ခဏခဏ ပြတ်တာမို့ client က တကယ်တော့ အောင်မြင်ပြီးသား "create payment" request ကို ပြန် retry လုပ်နိုင်ပါတယ်။ Client ကို unique Idempotency-Key header ပို့ခိုင်းပါ၊ server က key ကို ရလဒ်နဲ့အတူ သိမ်းထားပြီး ထပ်လာရင် နှစ်ခါ ငွေမဖြတ်ဘဲ ရလဒ်အတူတူကို ပြန်ပေးပါတယ်။

နှေးတဲ့ ဒါမှမဟုတ် ယုံကြည်ရမှုနည်းတဲ့ အလုပ်တွေကို request ထဲကနေ ထုတ်ပါ — email နဲ့ push notification ပို့တာ၊ PDF ထုတ်တာ၊ ပုံ ဒါမှမဟုတ် video process လုပ်တာ၊ မတည်ငြိမ်တဲ့ third-party API ခေါ်တာနဲ့ ညစဉ် report တွေ။ API က job ကို queue (Redis နဲ့ BullMQ၊ SQS၊ RabbitMQ) ထဲ သိမ်းပြီး မြန်မြန်ပြန်ဖြေကာ worker တွေက retry နဲ့ backoff ပါ job တွေကို process လုပ်ပါတယ်။ Job တစ်ခုက တစ်ကြိမ်ထက်ပို run နိုင်လို့ job တွေကို idempotent ဖြစ်အောင် လုပ်ပါ။

နည်းပညာ အမျိုးအစားအလိုက်ချည်း မဟုတ်ဘဲ feature ဒါမှမဟုတ် domain (order၊ user၊ payment) အလိုက် ခွဲပြီး layer တွေကို ရှင်းရှင်းထားပါ — route ဒါမှမဟုတ် controller တွေက HTTP ကို ကိုင်တွယ်၊ service တွေက business logic ကို ကိုင်ထား၊ repository ဒါမှမဟုတ် ORM က data ကို ကိုင်တွယ်ပါတယ်။ Business logic က Express ဒါမှမဟုတ် request object ကို မမှီခိုသင့်ပါဘူး၊ ဒါမှ test လုပ်ရလွယ်ပြီး job ဒါမှမဟုတ် တခြား entry point တွေကနေ ပြန်သုံးလို့ရပါတယ်။ အစွန်းတွေမှာ validate လုပ်ပြီး configuration ကို နေရာတစ်ခုတည်းမှာ ထားပါ။

Monorepo (pnpm/Bun workspace နဲ့ Turborepo ဒါမှမဟုတ် Nx လို tool) ကို သုံးပြီး platform မမှီခိုတဲ့ အရာတွေအတွက် shared package တွေ ထားပါ — TypeScript type၊ API client၊ validation schema၊ business rule၊ formatting နဲ့ i18n string တွေ။ Web နဲ့ native က render လုပ်ပုံ ကွာလို့ UI component တွေကို မျှသုံးရ ပိုခက်ပါတယ်၊ ရွေးချယ်စရာတွေက shared design-token package ဒါမှမဟုတ် team က component set တစ်ခုတည်း လိုချင်ရင် React Native Web / Tamagui / NativeWind ပါ။ Platform တစ်ခုခုကို ပိုဆိုးစေမယ့် နေရာမှာ အတင်းမျှမသုံးပါနဲ့။

မြန်တဲ့ unit test အများကြီး၊ integration test နည်းနည်းနဲ့ sign-up၊ checkout လို အရေးကြီးတဲ့ journey တွေအတွက် end-to-end test အနည်းငယ်ပဲ ထားပါ။ ပုံမှန် tool တွေ —

Unit test တွေမှာ boundary မှာ mock လုပ်ပါ — ကိုယ့် API client module ဒါမှမဟုတ် browser၊ Node နဲ့ React Native test တွေမှာ အလုပ်လုပ်တဲ့ MSW (Mock Service Worker) လို tool နဲ့ network layer ကို။ Error path တွေကိုပါ test လုပ်ပါ — timeout၊ 500၊ ပုံစံမှားတဲ့ response နဲ့ rate limit တွေ။ တကယ့် provider နဲ့ contract ဒါမှမဟုတ် sandbox test အနည်းငယ်ကို သီးခြား၊ ခဏခဏ မ run တဲ့ pipeline ထဲမှာ ထားပါ။

Pull request တိုင်းမှာ — install၊ lint၊ type-check၊ unit နဲ့ integration test run ပြီး app အားလုံး build လုပ်ပါ၊ web အတွက် preview deployment ပေးပါ။ Main ကို merge လုပ်ရင် — migration run၊ API နဲ့ web app ကို deploy လုပ်ပြီး mobile build ကို trigger လုပ်ပါ။ Mobile release တွေက ပိုနှေးပါတယ် — sign လုပ်ထားတဲ့ binary တွေ build (EAS Build၊ Fastlane၊ Codemagic)၊ TestFlight နဲ့ Play internal testing ဆီ ပို့ပြီး စစ်ဆေးပြီးမှ store တွေဆီ promote လုပ်ပါ။

Docker က application ကို runtime နဲ့ dependency တွေနဲ့အတူ ဘယ်စက်မှာမဆို အတူတူ run တဲ့ image တစ်ခုအဖြစ် ထုပ်ပိုးပေးပါတယ်။ "ငါ့စက်မှာတော့ အလုပ်လုပ်တယ်" ပြဿနာတွေကို ဖယ်ရှားတယ်၊ Docker Compose နဲ့ API၊ database နဲ့ Redis ကို local မှာ လွယ်လွယ် run နိုင်ပြီး deploy လုပ်ဖို့ တသမတ်တည်း artifact ပေးပါတယ်။ Multi-stage build နဲ့ image တွေကို သေးအောင်ထားပြီး secret တွေကို image ထဲ ဘယ်တော့မှ မထည့်ပါနဲ့။

Web client တွေက နောက် page load မှာ update ဖြစ်ပေမဲ့ mobile user တွေက app version ဟောင်းကို လပေါင်းများစွာ ဆက်သုံးနိုင်ပါတယ်။ ထပ်ထည့်တဲ့၊ backwards-compatible ပြောင်းလဲမှုတွေကို ဦးစားပေးပါ — field အသစ်ထည့်ပါ၊ ရှိပြီးသားတွေကို နာမည်မပြောင်း မဖျက်ပါနဲ့။ Breaking change ကို ရှောင်မရရင် version အသစ် (/v2/ ဒါမှမဟုတ် header) မိတ်ဆက်၊ ဟောင်းကို ဆက် run ထားပြီး app version အလိုက် အသုံးပြုမှုကို ခြေရာခံကာ traffic သုညနီးပါး ဖြစ်မှ ဖယ်ပါ — အရမ်းဟောင်းတဲ့ app တွေကို update လုပ်ခိုင်းတဲ့ minimum-supported-version စစ်ဆေးချက်နဲ့ဆိုရင် ပိုကောင်းပါတယ်။

OTA update က React Native app ကို app store ကနေ မဖြတ်ဘဲ EAS Update လို tool တွေနဲ့ JavaScript bundle နဲ့ asset အသစ်ကို download လုပ်ခွင့်ပေးပါတယ်။ Bug fix မြန်မြန်လုပ်တာနဲ့ စာသားပြောင်းတာတွေအတွက် ကောင်းပါတယ်။ Native code ဒါမှမဟုတ် permission တွေကို မပြောင်းနိုင်လို့ update က install ထားတဲ့ native "runtime version" နဲ့ ကိုက်ရပြီး store စည်းမျဉ်းတွေ ဆက်သက်ရောက်ပါတယ် — app ရဲ့ အဓိက ရည်ရွယ်ချက်ကို OTA နဲ့ မပြောင်းရပါဘူး။ Flutter က native code အဖြစ် compile လုပ်တာမို့ store release ဒါမှမဟုတ် Shorebird လို third-party tool တွေကို မှီခိုပါတယ်။

Release တိုင်းမှာ user မြင်ရတဲ့ version (2.4.0 လို၊ semantic versioning အတိုင်း) နဲ့ အမြဲတိုးနေတဲ့ build number (Android မှာ versionCode၊ iOS မှာ CFBundleVersion) ရှိပါတယ်။ နှစ်ခုလုံးကို CI မှာ automate လုပ်၊ Git မှာ release တွေကို tag လုပ်၊ release note ထားပြီး staged rollout သုံးပါ — user 5–10% ဆီ အရင် release လုပ်ပြီး crash rate ကို ကြည့်ပြီးမှ 100% ကို တက်ပါ။

App တိုင်းမှာ Sentry၊ Crashlytics ဒါမှမဟုတ် Bugsnag လို error-tracking tool သုံးပါ။ Stack trace တွေ ဖတ်လို့ရအောင် source map (web) နဲ့ debug symbol / dSYM (mobile) တွေ upload လုပ်၊ event တွေကို release version နဲ့ environment နဲ့ tag လုပ်ပြီး mobile crash ကို ကိုက်ညီတဲ့ API log တွေနဲ့ ချိတ်ဖို့ breadcrumb နဲ့ request ID ထည့်ပါ။ Event တိုင်းအတွက် မဟုတ်ဘဲ error အသစ် ဒါမှမဟုတ် ရုတ်တရက်များလာတာတွေအတွက် alert လုပ်ပါ။

Timestamp၊ level၊ message၊ request ID၊ user ဒါမှမဟုတ် tenant ID နဲ့ ဆက်စပ် context ပါတဲ့ structured JSON log (pino လို library နဲ့) တွေ ရေးပါ၊ ဒါမှ ရှာဖွေ filter လုပ်လို့ရပါမယ်။ Execution လိုင်းတိုင်းကို မဟုတ်ဘဲ အရေးကြီးတဲ့ event နဲ့ error တွေကို log လုပ်ပါ။ Password၊ token၊ ကတ်နံပါတ် ဒါမှမဟုတ် ကိုယ်ရေးကိုယ်တာ data အပြည့်အစုံကို ဘယ်တော့မှ log မလုပ်ပါနဲ့၊ အလိုလို redact လုပ်ပါ။

Feature flag တွေက deploy မလုပ်ဘဲ runtime မှာ feature တွေကို ဖွင့်ပိတ်ပေးပါတယ်၊ ဥပမာ user၊ ရာခိုင်နှုန်း ဒါမှမဟုတ် app version အလိုက်။ မပြီးသေးတဲ့ code ကို flag နောက်ကွယ်မှာ ဘေးကင်းစွာ merge လုပ်တာ၊ တဖြည်းဖြည်း rollout လုပ်တာ၊ A/B test run တာနဲ့ ပျက်နေတဲ့ feature ကို ချက်ချင်းပိတ်တာတွေ လုပ်နိုင်ပါတယ် — store ကနေ fix လုပ်ရင် ရက်ပိုင်းကြာတဲ့ mobile အတွက် အရမ်းတန်ဖိုးရှိပါတယ်။ Code ထဲမှာ အသုံးမဝင်တော့တဲ့ branch တွေ မပြည့်အောင် flag ဟောင်းတွေကို ရှင်းပါ။

User မြင်ရတဲ့ စာသားကို ဘယ်တော့မှ hardcode မလုပ်ပါနဲ့၊ ဘာသာပြန်တွေကို ID နဲ့ key လုပ်ထားတဲ့ message file တွေထဲ ထားပါ (i18next၊ react-intl၊ next-intl ဒါမှမဟုတ် Flutter ရဲ့ intl/ARB file လို library တွေနဲ့)။ Plural rule၊ ရက်စွဲ၊ ဂဏန်းနဲ့ ငွေကြေးတွေအတွက် Intl API တွေကနေ locale ကို သုံး၊ layout တွေမှာ စာသားပိုရှည်တာနဲ့ font ကွဲတာကို ခွင့်ပြုပါ (ဥပမာ မြန်မာစာက line height ပိုလိုပါတယ်)၊ ညာမှဘယ် ဘာသာစကားတွေကို ပစ်မှတ်ထားရင် support လုပ်ပါ။

Interactive element တွေကို label နဲ့ role ပေးပါ (React Native မှာ accessibilityLabel နဲ့ accessibilityRole၊ Flutter မှာ Semantics)၊ touch target တွေကို အနည်းဆုံး 44–48 point လောက်ထား၊ system font size (iOS မှာ Dynamic Type၊ Android မှာ font scale) ကို layout မပျက်ဘဲ support လုပ်၊ contrast ကောင်းကောင်းထားပြီး gesture တစ်ခုတည်းကို အားမကိုးပါနဲ့။ VoiceOver နဲ့ TalkBack ကို ကိုယ်တိုင် စမ်းသုံးကြည့်ပါ။

Generic တွေက function ဒါမှမဟုတ် type ကို တစ်ခါရေးပြီး data ပုံစံ အများကြီးအတွက် type-safe ဖြစ်နေအောင် လုပ်ပေးပါတယ်။ ဥပမာ typed API helper တစ်ခုက web ရော mobile client ပါ response type အတိအကျကို ပြန်ပေးနိုင်တာမို့ မကိုက်ညီမှုတွေကို runtime မှာ မဟုတ်ဘဲ compile time မှာ ဖမ်းမိပါတယ်။ TypeScript type တွေက runtime မှာ ပျောက်သွားတာမို့ network boundary မှာ runtime validation (Zod လို) နဲ့ တွဲသုံးပါ။

ပုံမှန် သံသယရှိရသူတွေက index မရှိတာ၊ N+1 query၊ data အများကြီး ပြန်ပို့တာ၊ နှေးတဲ့ third-party ခေါ်ဆိုမှုတွေကို တစ်ခုပြီးတစ်ခု ခေါ်တာ၊ caching မရှိတာနဲ့ request လမ်းကြောင်းပေါ်မှာ CPU အလုပ်လေးလေး လုပ်တာတွေပါ။ ခန့်မှန်းမယ့်အစား တိုင်းပြီး ရှာပါ — monitoring ထဲက request timing နဲ့ p95/p99 latency၊ slow-query log နဲ့ EXPLAIN၊ database ဒါမှမဟုတ် HTTP ခေါ်ဆိုမှု တစ်ခုချင်း ဘယ်လောက်ကြာလဲ ပြတဲ့ tracing။

အရင်ဆုံး ပြဿနာမှန်ကို ဖြေရှင်းလား၊ edge case နဲ့ error path တွေအပါအဝင် မှန်လား။ ပြီးရင် security (auth စစ်ဆေးချက်၊ input validation၊ secret)၊ data ပြောင်းလဲမှု (migration၊ mobile version ဟောင်းတွေနဲ့ backwards compatibility)၊ test၊ performance နဲ့ ဖတ်ရလွယ်မှု။ အမိန့်ပေးမယ့်အစား မေးခွန်းမေးပါ၊ ပိတ်ဆို့တဲ့ ပြဿနာတွေကို အကြံပြုချက် သေးသေးလေးတွေနဲ့ ခွဲပြီး လုံလောက်ပြီဆိုရင် မြန်မြန် approve လုပ်ပါ။

Data — unique (user_id, post_id) ပါတဲ့ likes table နဲ့ transaction တစ်ခုတည်းထဲမှာ update လုပ်တဲ့ post ပေါ်က like_count (scale ကြီးရင် asynchronous ရေတွက်)။ API — authenticate လုပ်ပြီး rate-limit ထားတဲ့ idempotent PUT /posts/:id/like နဲ့ DELETE /posts/:id/like။ Client — web နဲ့ mobile UI မှာ error ဖြစ်ရင် ပြန်ပြောင်းတဲ့ optimistic toggle၊ query library ကနေ cache update နဲ့ label ရှင်းတဲ့ accessible button။ Test — service အတွက် unit test၊ like နှစ်ခါ နှိပ်တာအတွက် API integration test နဲ့ E2E စစ်ဆေးချက် တစ်ခု။

Senior full-stack interview တွေမှာ "ဆောက်နိုင်လား?" ကနေ "ကြီးထွားလာတာ၊ ကျရှုံးမှုတွေ၊ app version ဟောင်းတွေနဲ့ ပြောင်းလဲနေတဲ့ team တွေကို ခံနိုင်အောင် ဒီဇိုင်းဆွဲနိုင်လား?" ဆီ ရွှေ့သွားပါတယ်။ System design၊ data consistency၊ web နဲ့ mobile တစ်လျှောက် performance၊ security architecture နဲ့ observability တွေကို မျှော်လင့်ထားပါ။ အဖြေကောင်းတွေက trade-off တွေကို ပြောတယ်၊ ဖြစ်နိုင်ရင် ကိန်းဂဏန်းတွေ ပေးပြီး ကိုယ်တိုင် ကိုင်တွယ်ခဲ့တဲ့ incident တွေကို ကိုးကားပါတယ်။

အစဉ်ရှင်းရှင်းနဲ့ လုပ်သွားပြီး ယူဆချက်တွေကို အသံထွက် ပြောပါ —

Product နဲ့ team အများစုအတွက် modular monolith နဲ့ စပါ — domain တွေ (order၊ billing၊ user) ကြား တင်းကျပ်တဲ့ အတွင်းပိုင်း နယ်နိမိတ်တွေနဲ့ deploy လုပ်လို့ရတဲ့ app တစ်ခုတည်း၊ domain တစ်ခုချင်းက ကိုယ်ပိုင် table တွေကို ပိုင်ပါတယ်။ Deploy၊ debug နဲ့ refactor လုပ်ရ ရိုးရှင်းပါတယ်။ အကြောင်းပြချက် ရှင်းရှင်းရှိမှ service တစ်ခုကို ခွဲထုတ်ပါ — scale လိုအပ်ချက် အရမ်းကွာတဲ့ အပိုင်း၊ သီးခြား release လိုတဲ့ team သီးခြား ဒါမှမဟုတ် ခိုင်မာတဲ့ isolation လိုအပ်ချက်။ Microservices က network failure၊ ဖြန့်ကျက်ထားတဲ့ data နဲ့ အများကြီး ပိုလေးတဲ့ operation တွေကို ယူလာတာမို့ နည်းပညာ tool သာမက အဖွဲ့အစည်းဆိုင်ရာ tool လည်း ဖြစ်ပါတယ်။

BFF က client အမျိုးအစား တစ်ခုအတွက် — web အတွက် တစ်ခု၊ mobile app တွေအတွက် တစ်ခု — ဆောက်ထားတဲ့ ပါးလွှာတဲ့ API layer ဖြစ်ပြီး အောက်က service တွေကို ခေါ်ကာ response တွေကို အဲဒီ client ရဲ့ screen တွေနဲ့ အတိအကျ ကိုက်အောင် ပုံဖော်ပေးပါတယ်။ နှေးတဲ့ mobile network ပေါ်မှာ round trip အရေအတွက်ကို လျှော့တယ်၊ client-specific logic ကို core service တွေထဲ မရောက်အောင် ထားပြီး client team တစ်ခုချင်းကို ပိုမြန်မြန် သွားနိုင်စေပါတယ်။ အန္တရာယ်က BFF တွေကြား logic ထပ်နေတာမို့ business rule တွေကို core service ထဲထားပြီး BFF တွေကို ပါးပါးလေးပဲ ထားပါ။

API ကို stateless ဖြစ်အောင် လုပ်ပါ — local memory ဒါမှမဟုတ် disk ထဲမှာ session ဒါမှမဟုတ် upload လုပ်ထားတဲ့ file တွေ မထားပါနဲ့ — ဒါမှ instance ဘယ်ဟာမဆို request ဘယ်ဟာမဆို ကိုင်တွယ်နိုင်ပါမယ်။ ရှေ့မှာ load balancer ထား၊ CPU၊ latency ဒါမှမဟုတ် queue depth ပေါ်မူတည်တဲ့ autoscaling နဲ့ instance အများကြီး run၊ မျှသုံးတဲ့ state ကို Redis နဲ့ database ထဲထားပြီး file တွေကို object storage ထဲ သိမ်းပါ။ ပြီးရင် များသောအားဖြင့် database က bottleneck ဖြစ်လာပြီး index၊ caching၊ read replica နဲ့ အများကြီး နောက်ကျမှ partitioning နဲ့ ကိုင်တွယ်ပါတယ်။

Primary database က write တွေကို ကိုင်တွယ်ပြီး ပြောင်းလဲမှုတွေကို read query တွေ serve လုပ်တဲ့ replica တစ်ခု ဒါမှမဟုတ် အများကြီးဆီ stream လုပ်ကာ load ကို ခွဲပေးပါတယ်။ ထောင်ချောက်က replication lag ပါ — profile ကို ခုပဲ update လုပ်ခဲ့တဲ့ user က replica ကနေ value ဟောင်းကို ဖတ်မိနိုင်ပါတယ်။ Read-your-own-writes routing နဲ့ ကိုင်တွယ်ပါ (user write လုပ်ပြီး ခဏအတွင်း ဒါမှမဟုတ် အဲဒီ user ရဲ့ ကိုယ်ပိုင် data အတွက် primary ကနေ ဖတ်ပါ)၊ balance လို အရေးကြီးတဲ့ read တွေကို primary ပေါ်မှာ ထားပါ။

Partitioning က table ကြီးတစ်ခုကို database တစ်ခုတည်းအတွင်းမှာ အပိုင်းတွေ ခွဲပါတယ် — ဥပမာ လအလိုက် — ဒါက query နဲ့ data retention ကို ပိုလွယ်စေပါတယ်။ Sharding က tenant_id ဒါမှမဟုတ် user_id လို shard key နဲ့ data ကို database server အများကြီးပေါ် ဖြန့်ပါတယ်။ Load ကို ညီညီဖြန့်ပြီး ဆက်စပ် data တွေကို အတူထားတဲ့ key ရွေးတာ အရမ်းအရေးကြီးပါတယ်၊ shard ကျော် query၊ transaction နဲ့ re-sharding တွေက ခက်တာမို့ ပိုရိုးရှင်းတဲ့ ရွေးချယ်စရာတွေ ကုန်မှ shard လုပ်ပါ။

Distributed system မှာ network partition ဖြစ်တဲ့အခါ consistency (read တိုင်းက နောက်ဆုံး write ကို မြင်ရတယ်၊ request တွေ ငြင်းရရင်တောင်) နဲ့ availability (request တိုင်း အဖြေရတယ်၊ data ဟောင်းဖြစ်နိုင်ပေမဲ့) ကြား ရွေးရပါတယ်။ လက်တွေ့မှာ feature အလိုက် ရွေးပါတယ် — account balance ဒါမှမဟုတ် stock count က consistency ကို ဦးစားပေးသင့်ပြီး like counter၊ feed ဒါမှမဟုတ် analytics က eventual consistency ကို လက်ခံနိုင်ပါတယ်။ PACELC က partition မရှိရင်တောင် latency နဲ့ consistency ကြား trade-off လုပ်ရတယ်လို့ ထပ်ဖြည့်ပါတယ်။

အသုံးများတဲ့ pattern တွေက cache-aside (cache ကနေ ဖတ်၊ မရှိရင် database ကနေ load လုပ်ပြီး သိမ်း)၊ write-through (cache နဲ့ database ကို အတူ write) နဲ့ write-behind (cache ကို write ပြီး နောက်မှ flush) ပါ။ Invalidation ရွေးချယ်စရာတွေက TTL၊ write လုပ်တဲ့အခါ key ဖျက်တာ၊ change event publish လုပ်တာ ဒါမှမဟုတ် version ပါတဲ့ key တွေပါ။ Stampede — expire ဖြစ်သွားတဲ့ key တစ်ခုတည်းကို request အများကြီးက ပြန်ဆောက်တာ — ကို request coalescing၊ lock ဒါမှမဟုတ် request တစ်ခု refresh လုပ်နေစဉ် data ဟောင်းကို serve လုပ်တာနဲ့ ကာကွယ်ပါ။

Static asset တွေကို cache အချိန်ရှည်နဲ့ content-hash ပါတဲ့ filename တွေနဲ့ serve လုပ်ပါ၊ ဒါမှ deploy လုပ်တိုင်း file ဟောင်း မ serve မိမှာပါ။ Public page နဲ့ API response တွေကို s-maxage နဲ့ stale-while-revalidate နဲ့ edge မှာ cache လုပ်ပြီး content ပြောင်းရင် tag နဲ့ purge လုပ်ပါ။ ဖုန်းနဲ့ desktop တွေကို size မှန်တဲ့ WebP/AVIF ပုံတွေ serve လုပ်ဖို့ CDN ရဲ့ image resizing ကို သုံးပါ။ Personalised response တွေကို public cache ဘယ်တော့မှ မလုပ်ပါနဲ့ — private ဒါမှမဟုတ် no-store လို့ သတ်မှတ်ပါ။

Service တွေက OrderPlaced လို event တွေကို publish လုပ်ပြီး တခြား service တွေက တုံ့ပြန်ပါတယ် — billing က ငွေဖြတ်၊ email က ပြေစာပို့၊ analytics က မှတ်တမ်းတင် — publisher က သူတို့အကြောင်း မသိရပါဘူး။ Team တွေကို ခွဲထုတ်ပေးပြီး traffic ရုတ်တရက်တက်တာကို ချောမွေ့စေပါတယ်။ ကုန်ကျစရိတ်တွေက eventual consistency၊ service တွေကြား debug လုပ်ရ ပိုခက်တာ၊ ထပ်နေတဲ့ နဲ့ အစဉ်မမှန်တဲ့ event တွေနဲ့ event schema ပြောင်းလဲမှုပါ။ Consumer တွေ idempotent ဖြစ်ရပြီး flow တစ်ခုကို လိုက်ဖို့ correlation ID နဲ့ tracing လိုပါတယ်။

"Dual write" ပြဿနာကို ဖြေရှင်းပါတယ် — database ထဲ သိမ်းတာနဲ့ message publish လုပ်တာက သီးခြား action နှစ်ခုဖြစ်ပြီး တစ်ခုအောင်မြင်ပြီးနောက် တစ်ခု ကျရှုံးနိုင်ပါတယ်။ Outbox နဲ့ဆိုရင် business ပြောင်းလဲမှုနဲ့ event row ကို database transaction တစ်ခုတည်းထဲမှာ outbox table ထဲ ရေးပါတယ်။ သီးခြား relay (poller ဒါမှမဟုတ် change-data-capture) က outbox ကို ဖတ်ပြီး message broker ဆီ အောင်မြင်တဲ့အထိ retry လုပ်ကာ publish လုပ်ပါတယ်။ Consumer တွေက event ID နဲ့ ထပ်နေတာတွေကို ဖယ်ပါတယ်။

Distributed two-phase commit ကို ရှောင်ပြီး saga သုံးပါ။ Saga က local transaction တွေရဲ့ အစဉ်တစ်ခုဖြစ်ပြီး အဆင့်တစ်ခုချင်းမှာ ပြန်ပြင်ပေးတဲ့ compensating action ရှိပါတယ် — stock ကြိုယူ၊ ကတ်ကနေ ငွေဖြတ်၊ shipment ဖန်တီး၊ ငွေဖြတ်တာ ကျရှုံးရင် stock ကို ပြန်လွှတ်ပါ။ Choreograph (service တွေက တစ်ခုနဲ့တစ်ခု event တွေကို တုံ့ပြန်) ဒါမှမဟုတ် orchestrate (coordinator တစ်ခု၊ များသောအားဖြင့် Temporal လို workflow engine က အဆင့်တွေကို မောင်း) လုပ်နိုင်ပါတယ်။ အဆင့်တိုင်းကို idempotent ဖြစ်အောင် ဒီဇိုင်းဆွဲပြီး ကြားခံ state တွေကို user မြင်အောင် ပြပါ ("payment pending")။

Expand နဲ့ contract ကို သုံးပါ၊ ဒါမှ အဆင့်တိုင်းမှာ code ဟောင်းရော အသစ်ရော (mobile version ဟောင်းတွေပါ) အလုပ်လုပ်ပါမယ် —

Load balancer နောက်မှာ rolling၊ blue-green ဒါမှမဟုတ် canary deployment တွေကို health နဲ့ readiness check တွေနဲ့ သုံးပါ၊ ဒါမှ အဆင်သင့်ဖြစ်တဲ့ instance တွေဆီပဲ traffic ရောက်ပါမယ်။ SIGTERM ကို ယဉ်ကျေးစွာ ကိုင်တွယ်ပါ — request အသစ် လက်ခံတာ ရပ်၊ လုပ်နေဆဲ request တွေကို ပြီးအောင်လုပ်ပြီး database connection တွေ ပိတ်ပါ။ Release တိုင်းကို အရင် release နဲ့ backwards compatible ဖြစ်အောင်ထား၊ အန္တရာယ်ရှိတဲ့ ပြောင်းလဲမှုတွေကို feature flag နဲ့ ခွဲပြီး rollback ကို click တစ်ချက်တည်းနဲ့ လုပ်ရတဲ့၊ လေ့ကျင့်ထားပြီးသား action ဖြစ်အောင် လုပ်ပါ။

Request တိုင်းမှာ app version နဲ့ platform ကို (X-App-Version လို header နဲ့) ခြေရာခံပြီး version အလိုက် အသုံးပြုမှုကို စောင့်ကြည့်ပါ။ API ပြောင်းလဲမှုတွေကို ထပ်ထည့်တဲ့ ပုံစံထားပါ၊ release မလုပ်ဘဲ behaviour ကို ညှိဖို့ server-driven configuration နဲ့ feature flag တွေသုံးပြီး minimum-supported version ကို ထိန်းထားပါ — API က သီးခြား error ပြန်ပေးတာ ဒါမှမဟုတ် app က config endpoint ကို စစ်ပြီး "update လုပ်ပါ" screen ပြတာ (အရင်ဆုံး ညင်ညင်သာသာ တောင်းဆို၊ security fix လို တကယ်လိုမှ force update)။

Record တစ်ခုချင်းကို client က ထုတ်ပေးတဲ့ ID (UUID) နဲ့ server ဆီက version ဒါမှမဟုတ် updatedAt ပေးပါ။ Client က local database နဲ့ ဆိုင်းငံ့ထားတဲ့ ပြောင်းလဲမှုတွေရဲ့ outbox ကို ထားပြီး sync လုပ်တဲ့အခါ outbox ကို ပို့ကာ နောက်ဆုံး sync token ကတည်းက ပြောင်းလဲမှုတွေကို ဆွဲယူပါတယ်။ Conflict အတွက် data အမျိုးအစားအလိုက် ရွေးပါ — ရိုးရှင်းတဲ့ field တွေအတွက် last-write-wins၊ field-level merge၊ ငွေနဲ့ stock အတွက် server-wins ဒါမှမဟုတ် အရေးကြီးတဲ့ document တွေအတွက် user ကို မေးပါ။ Collaborative editing အတွက် CRDT (Yjs ဒါမှမဟုတ် Automerge လို) တွေက ပြိုင်တူ ပြောင်းလဲမှုတွေကို အလိုလို merge လုပ်ပေးပါတယ်။

Architecture ဟောင်းက JavaScript နဲ့ native code ကြား serialize လုပ်ထားတဲ့ JSON message တွေကို asynchronous "bridge" ပေါ်ကနေ ပို့တာမို့ latency ထပ်ပေါင်းပါတယ်။ React Native 0.76 ကစပြီး default ဖြစ်လာတဲ့ New Architecture က အဲဒါကို အစားထိုးပါတယ် — JSI က JavaScript ကို C++ object တွေကို တိုက်ရိုက် reference ကိုင်ပြီး synchronous ခေါ်ခွင့်ပေးတယ်၊ Fabric က concurrent React feature တွေကို support လုပ်တဲ့ renderer အသစ်ပါ၊ TurboModules က Codegen ထုတ်ပေးတဲ့ typed interface တွေနဲ့ native module တွေကို lazy load လုပ်ပြီး bridgeless mode က bridge ကို လုံးဝ ဖယ်ရှားပါတယ်။ Hermes က default JavaScript engine ဖြစ်ပြီး startup မြန်အောင် JS ကို bytecode အဖြစ် ကြိုတင် compile လုပ်ပါတယ်။

Flutter က platform ရဲ့ native widget တွေကို မသုံးပါဘူး — widget tree ဆောက်ပြီး element နဲ့ render-object tree တွေအဖြစ် ပြောင်းကာ pixel တိုင်းကို ကိုယ်ပိုင် engine (ခေတ်သစ် iOS နဲ့ Android မှာ Impeller) နဲ့ canvas ပေါ် ဆွဲပါတယ်။ ဒါက platform တွေတစ်လျှောက် UI တစ်ပုံစံတည်းနဲ့ ချောမွေ့တဲ့ animation တွေ ပေးပေမဲ့ platform-specific ပုံပန်းနဲ့ accessibility behaviour တွေကို framework က ပြန်ဖန်တီးရပါတယ်။ React Native က တကယ့် native view တွေကို render လုပ်တာမို့ default အနေနဲ့ native ဆန်ပြီး React သုံးပြီးသား team တွေနဲ့ ကိုက်ပါတယ်၊ ဒါပေမဲ့ pixel အဆင့် ထိန်းချုပ်မှု နည်းနည်း လျော့ပါတယ်။

Framework ဒါမှမဟုတ် community package တွေက ကောင်းကောင်း မဖုံးနိုင်တဲ့ အရာ လိုတဲ့အခါပါ — platform SDK အသစ်၊ hardware feature (Bluetooth device၊ NFC payment၊ background location)၊ audio ဒါမှမဟုတ် video လို လေးလံတဲ့ processing၊ home-screen widget ဒါမှမဟုတ် performance hotspot။ React Native မှာ Swift နဲ့ Kotlin နဲ့ Turbo Module ဒါမှမဟုတ် Expo Module ရေးပြီး Flutter မှာ platform channel ဒါမှမဟုတ် FFI သုံးပါတယ်။ Platform နှစ်ခုအတွက် skill လိုတာမို့ native အပိုင်းကို သေးသေးနဲ့ test ကောင်းကောင်း လုပ်ထားပါ။

Cold start ကို debug မဟုတ်ဘဲ release build နဲ့ တကယ့် အလယ်အလတ်တန်းစား Android device ပေါ်မှာ တိုင်းပါ။ ပြီးရင် ပထမ screen အတွက် မလိုတာ အားလုံးကို နောက်ဆုတ်ပါ — screen နဲ့ module တွေကို lazy-load လုပ်၊ SDK initialisation (analytics၊ ads၊ chat) ကို ရွှေ့ဆိုင်း၊ launch မှာ synchronous storage read ကြီးကြီး ရှောင်၊ React Native မှာ Hermes bytecode သုံး၊ bundle ကို သေးအောင်ထားပြီး data အသစ် load လုပ်နေစဉ် cache လုပ်ထားတဲ့ content ကို ချက်ချင်းပြပါ။ Startup budget သတ်မှတ်ပြီး release တိုင်း ခြေရာခံပါ။

ပုံမှန် အကြောင်းရင်းတွေက cleanup မလုပ်တဲ့ listener၊ timer နဲ့ subscription တွေ၊ object ကြီးတွေကို ကိုင်ထားတဲ့ closure တွေ၊ အဆုံးမရှိ ကြီးလာတဲ့ global cache တွေနဲ့ mobile app တွေမှာ memory ထဲ ကိုင်ထားတဲ့ ပုံကြီးတွေပါ။ Chrome DevTools heap snapshot (action တစ်ခုကို ထပ်ခါထပ်ခါ မလုပ်ခင်နဲ့ လုပ်ပြီး နှိုင်းယှဉ်)၊ Xcode Instruments နဲ့ Android Studio ရဲ့ Memory Profiler နဲ့ Flutter DevTools ကို သုံးပါ။ Effect ထဲက cleanup function ဒါမှမဟုတ် Flutter ရဲ့ dispose()၊ ကန့်သတ်ထားတဲ့ cache နဲ့ size မှန်တဲ့ ပုံတွေနဲ့ ပြင်ပါ။

60 Hz မှာ frame တစ်ခုအတွက် 16 ms လောက်ပဲ ရပြီး 120 Hz မှာ 8 ms လောက်ပဲ ရပါတယ်။ Animation တွေကို JavaScript thread မဟုတ်ဘဲ UI thread ပေါ်မှာ run ပါ — React Native မှာ react-native-reanimated worklet ဒါမှမဟုတ် native driver၊ Flutter မှာ built-in animation system။ Layout property တွေအစား transform နဲ့ opacity ကို animate လုပ်၊ gesture လုပ်နေစဉ် tree ကြီးတွေ ပြန် render မလုပ်ပါနဲ့၊ release ဒါမှမဟုတ် profile mode မှာ performance monitor နဲ့ Flutter DevTools နဲ့ profile လုပ်ပါ။

OAuth 2.0 / OpenID Connect ပြောတဲ့ identity service တစ်ခုတည်း (ကိုယ်ပိုင် ဒါမှမဟုတ် Auth0၊ Clerk၊ Cognito၊ Firebase Auth လို provider) ကို သုံးပါ။ Web က HttpOnly cookie session ဒါမှမဟုတ် token တွေကို server ဘက်မှာ ကိုင်ထားတဲ့ BFF ကို သုံးပြီး mobile app တွေက system browser ကနေ PKCE ပါတဲ့ Authorization Code ကို သုံးကာ token တွေကို secure storage ထဲ ထားပါတယ်။ သက်တမ်းတို access token၊ rotate လုပ်တဲ့ refresh token၊ user တွေ တခြား device တွေကို sign out လုပ်နိုင်အောင် device/session list နဲ့ passkey၊ Sign in with Apple (iOS မှာ တခြား social login ပေးရင် မဖြစ်မနေ လိုအပ်) နဲ့ Google ကို support လုပ်ပါ။

App ကို decompile လုပ်ပြီး API ကို script တွေနဲ့ ခေါ်နိုင်တယ်လို့ ယူဆပါ။ User တွေကို သေချာ authenticate လုပ်၊ request တိုင်းကို server ပေါ်မှာ authorize လုပ်၊ user၊ device နဲ့ IP အလိုက် rate-limit လုပ်ပြီး အရာအားလုံးကို validate လုပ်ပါ။ Script နဲ့ အလွဲသုံးတာကို ပိုခက်အောင် app attestation (Apple App Attest / DeviceCheck နဲ့ Google Play Integrity)၊ sign-up နဲ့ login မှာ bot detection နဲ့ ပုံမှန်မဟုတ်မှု alert တွေ ထည့်ပါ။ Certificate pinning က ရိုးရိုး ကြားဖြတ်တာကို တားနိုင်ပေမဲ့ backup pin တွေနဲ့ ကြိုစီစဉ်ရပါမယ်၊ မဟုတ်ရင် certificate လဲတဲ့အခါ user အားလုံး ဝင်လို့မရ ဖြစ်သွားနိုင်ပါတယ်။

OWASP က web app တွေအတွက် Top 10 နဲ့ Mobile Top 10 အပါအဝင် ကျယ်ကျယ်ပြန့်ပြန့် သုံးတဲ့ security လမ်းညွှန်တွေကို ထုတ်ဝေပါတယ်။ တကယ့် project တွေမှာ အဖြစ်များဆုံး ပြဿနာတွေက broken access control (ID ပြောင်းလိုက်ရုံနဲ့ user က တခြားသူရဲ့ order ကို ဖတ်နိုင်တာ)၊ injection၊ security misconfiguration၊ vulnerable dependency၊ weak authentication နဲ့ sensitive data ပေါက်ကြားတာ၊ ပြီးတော့ mobile device ပေါ်မှာ data ကို မလုံခြုံစွာ သိမ်းတာပါ။ Process ထဲမှာ စစ်ဆေးချက်တွေ ထည့်ပါ — threat modelling၊ dependency scanning၊ authorisation test နဲ့ sensitive ပြောင်းလဲမှုတွေအတွက် security review။

Client ဆီက ID တစ်ခုတည်းကို ဘယ်တော့မှ မယုံပါနဲ့။ Resource load လုပ်တဲ့ query တိုင်းကို user မြင်ခွင့်ရှိတာနဲ့ ကန့်သတ်ရပါမယ် — များသောအားဖြင့် owner ဒါမှမဟုတ် tenant အလိုက် — access rule တွေကို route တစ်ခုချင်းထဲမှာ မဟုတ်ဘဲ test လုပ်ထားတဲ့ ဗဟိုနေရာ တစ်ခုတည်းမှာ ထားသင့်ပါတယ်။ တခြား user ရဲ့ data ကို access လုပ်ဖို့ ကြိုးစားပြီး 404 ဒါမှမဟုတ် 403 ကို မျှော်တဲ့ test တွေ ရေးပါ။

Git ထဲနဲ့ client bundle ထဲ မရောက်အောင် ထားပါ။ Secret manager (AWS Secrets Manager၊ GCP Secret Manager၊ Vault၊ Doppler ဒါမှမဟုတ် platform ရဲ့ encrypt လုပ်ထားတဲ့ env var) ထဲ သိမ်း၊ service တစ်ခုချင်းကို လိုတဲ့ secret ကိုပဲ ပေး၊ environment တစ်ခုချင်းအတွက် secret သီးခြားသုံးပြီး ပုံမှန် နဲ့ ပေါက်ကြားပြီးရင် ချက်ချင်း rotate လုပ်ပါ။ မတော်တဆ commit လုပ်မိတဲ့ key ကို မိနစ်ပိုင်းအတွင်း ဖမ်းမိအောင် CI နဲ့ repository မှာ secret scanning ထည့်ပါ။

Isolation model တစ်ခု ရွေးပါ — row တိုင်းမှာ tenant_id ပါတဲ့ shared database (အသက်သာဆုံး၊ တင်းကျပ်တဲ့ scoping လိုတယ်၊ PostgreSQL row-level security နဲ့ အတင်းကျင့်သုံးနိုင်တယ်)၊ tenant တစ်ခုချင်းအတွက် schema ဒါမှမဟုတ် tenant တစ်ခုချင်းအတွက် database (isolation အခိုင်မာဆုံး၊ operation ကုန်ကျစရိတ် အများဆုံး)။ Tenant ကို auth token ထဲထည့်၊ query နဲ့ cache key တိုင်းကို tenant အလိုက် scope လုပ်၊ ဆူညံတဲ့ tenant တစ်ခုက တခြားသူတွေကို မထိခိုက်အောင် tenant အလိုက် rate limit ထားပြီး tenant အလိုက် data export နဲ့ ဖျက်ခြင်းအတွက် စီစဉ်ပါ။

Log တွေက ဘာဖြစ်ခဲ့လဲကို အသေးစိတ်ပြောပြတယ်၊ metric တွေက ဘယ်လောက်နဲ့ ဘယ်နှကြိမ် (request rate၊ error rate၊ latency percentile၊ saturation) ကို ပြောပြပြီး trace တွေက request တစ်ခုတည်းရဲ့ service တွေ၊ database နဲ့ third party တွေကို ဖြတ်သွားတဲ့ လမ်းကြောင်းကို ပြပါတယ်။ OpenTelemetry နဲ့ တစ်ခါ instrument လုပ်ပြီး သုံးခုလုံးကို Grafana၊ Datadog ဒါမှမဟုတ် Honeycomb လို tool တွေဆီ ပို့နိုင်ပါတယ်။ Mobile app ကနေ API အထိပါ မျှသုံးတဲ့ trace ဒါမှမဟုတ် request ID နဲ့ သူတို့ကို ချိတ်ဆက်ပါ။

SLI က user experience ကို တိုင်းတာချက်ပါ၊ ဥပမာ "500 ms အောက်မှာ အောင်မြင်တဲ့ checkout request ရာခိုင်နှုန်း"။ SLO က ပစ်မှတ်ပါ၊ ဥပမာ ရက် 30 မှာ 99.9%။ Error budget က ကျန်တာပါ — 0.1% ကျရှုံးခွင့်ရှိတယ် — ပြီးတော့ ဆုံးဖြတ်ချက်တွေကို လမ်းပြပါတယ် — budget ကျန်နေသရွေ့ team က feature တွေ ship လုပ်ပြီး ကုန်သွားရင် reliability အလုပ်က ဦးစားပေး ဖြစ်လာပါတယ်။ ခဏတာ spike တိုင်းအတွက် မဟုတ်ဘဲ budget မြန်မြန်ကုန်တာအတွက် alert လုပ်ပါ။

အရင်ဆုံး သက်သာအောင် လုပ်ပါ — incident ကြေညာ၊ incident lead တစ်ယောက် သတ်မှတ်၊ stakeholder နဲ့ user တွေဆီ status ပြောပြပြီး root cause မရှာခင် service ကို မြန်မြန် ပြန်ကောင်းအောင် လုပ်ပါ — rollback၊ flag ပိတ်၊ scale up။ ပြီးရင် log၊ metric နဲ့ trace တွေနဲ့ စုံစမ်းပြီး ပြန်ကောင်းကြောင်း အတည်ပြုပါ။ နောက်ပိုင်း timeline၊ ပါဝင်ခဲ့တဲ့ အကြောင်းရင်းတွေနဲ့ owner နဲ့ ရက်စွဲပါတဲ့ ခိုင်မာတဲ့ action item တွေပါတဲ့ အပြစ်မတင်တဲ့ post-incident review ကို ရေးပါ။

WebSocket server တွေကို ကြာရှည် connection တွေ support လုပ်တဲ့ load balancer နောက်မှာ horizontally scale လုပ်ထားတဲ့ သီးခြား tier အဖြစ် run ပါ။ User ရဲ့ connection က node တစ်ခုပေါ်မှာပဲ ရှိတာမို့ message တွေကို node မှန်ဆီ ပို့ဖို့ pub/sub backbone (Redis၊ NATS ဒါမှမဟုတ် Kafka) ကို သုံးပါ။ Connection server တွေကို ပေါ့ပေါ့ပါးပါးထား၊ fan out မလုပ်ခင် message တွေကို ခိုင်ခိုင်မာမာ သိမ်း၊ reconnect ဖြစ်ရင် နောက်ဆုံး message ID ကနေ ဆက်၊ backpressure အသုံးချပြီး offline mobile user တွေအတွက် push notification ကို fallback အဖြစ် သုံးပါ။

Service တွေက တိုက်ရိုက် မပို့ဘဲ notification request (ဘယ်သူ့ကို၊ ဘာအမျိုးအစား၊ data) ကို queue ထဲ publish လုပ်ပါတယ်။ Notification service က user တစ်ယောက်ချင်းရဲ့ preference နဲ့ quiet hour တွေကို စစ်၊ channel နဲ့ ဘာသာစကားအလိုက် template တွေကို render လုပ်ပြီး APNs/FCM၊ email နဲ့ database ထဲ သိမ်းထားတဲ့ in-app inbox အတွက် channel worker တွေဆီ လွှဲပေးပါတယ်။ User အလိုက် ထပ်နေတာ ဖယ်ပြီး rate-limit လုပ်၊ backoff နဲ့ retry လုပ်၊ အသုံးမဝင်တော့တဲ့ device token တွေ ရှင်းပြီး channel အလိုက် delivery နဲ့ open rate ကို ခြေရာခံပါ။

Database နဲ့ စပါ — PostgreSQL full-text search ဒါမှမဟုတ် MongoDB Atlas Search က အများကြီး ဖုံးနိုင်ပါတယ်။ စာလုံးပေါင်းမှားတာကို ခံနိုင်ရည်၊ relevance tuning၊ facet ဒါမှမဟုတ် volume များတာ လိုလာမှ dedicated engine (Elasticsearch၊ OpenSearch၊ Meilisearch၊ Typesense ဒါမှမဟုတ် Algolia) ဆီ ပြောင်းပါ။ Database ကို source of truth အဖြစ်ထားပြီး index ကို event ဒါမှမဟုတ် change-data-capture နဲ့ sync လုပ်ကာ ခဏတာ lag ကို လက်ခံပြီး index alias တွေသုံးကာ downtime မရှိဘဲ အစကနေ reindex လုပ်နိုင်အောင် ထားပါ။

Card data က ကိုယ့် server တွေကို ဘယ်တော့မှ မထိအောင် Stripe လို payment provider ကို သုံးပြီး platform စည်းမျဉ်းတွေကို လိုက်နာပါ — iOS နဲ့ Android app တွေထဲက digital goods တွေက ယေဘုယျအားဖြင့် in-app purchase ကို သုံးရပြီး ခြွင်းချက်နဲ့ စည်းမျဉ်းတွေက ဒေသအလိုက် ကွဲပြားကာ ပြောင်းလဲနေတာမို့ လက်ရှိ store policy ကို စစ်ပါ၊ physical goods နဲ့ service တွေကတော့ ပုံမှန် payment provider ကို သုံးနိုင်ပါတယ်။ Payment ကို server ပေါ်မှာ ဖန်တီး၊ idempotency key သုံး၊ webhook တွေကို source of truth အဖြစ် ယူ (signature စစ်၊ ထပ်နေတဲ့ နဲ့ အစဉ်မမှန်တဲ့ event တွေကို ကိုင်တွယ်) ပြီး ပုံမှန် reconcile လုပ်ပါ။

Raw request body ကို သုံးပြီး signature ကို verify လုပ်ကာ replay ကို တားဖို့ timestamp ဟောင်းတွေကို ငြင်းပါ။ Provider တွေက timeout ဖြစ်ပြီး retry လုပ်တာမို့ 2xx ကို မြန်မြန်ပြန်ပြီး တကယ့်အလုပ်ကို background job ထဲမှာ လုပ်ပါ။ Event ID တစ်ခုချင်းကို သိမ်းပြီး ထပ်နေတာတွေကို လျစ်လျူရှု၊ event တွေ အစဉ်လိုက် ရောက်မယ်လို့ မယူဆပါနဲ့ (အရေးကြီးရင် object ရဲ့ နောက်ဆုံး state ကို fetch လုပ်ပါ) ပြီး processing ထပ်ခါထပ်ခါ ကျရှုံးရင် alert လုပ်ပါ။

API ကို contract ပါတဲ့ product တစ်ခုလို ဆက်ဆံပါ — implement မလုပ်ခင် review လုပ်ထားတဲ့ OpenAPI ဒါမှမဟုတ် GraphQL schema၊ web နဲ့ mobile အတွက် generate လုပ်ထားတဲ့ typed client၊ တသမတ်တည်း naming၊ pagination၊ error နဲ့ ရက်စွဲ ပုံစံ၊ ပြီးတော့ changelog။ Mobile က round trip အများကြီး မလိုအောင် screen နဲ့ use case တွေကို ဗဟိုပြုပြီး ဒီဇိုင်းဆွဲ၊ အသုံးဝင်ရင် partial response ဒါမှမဟုတ် field selection ကို support လုပ်ပြီး ပြောင်းလဲမှုက client ကို ပျက်စေမယ်ဆိုရင် fail ဖြစ်တဲ့ contract test တွေကို CI မှာ ထည့်ပါ။

Component တွေကို မဖြစ်မနေ မဟုတ်ဘဲ ဆုံးဖြတ်ချက်တွေကို မျှသုံးပါ — design token တွေ (အရောင်၊ spacing၊ typography၊ radius၊ motion) ကို တစ်ခါသတ်မှတ်ပြီး CSS variable၊ Tailwind theme၊ React Native style နဲ့ Flutter ThemeData တွေအဖြစ် generate လုပ်ပါ။ နာမည်နဲ့ behaviour တူတဲ့ component တွေကို platform အလိုက် ဆောက်၊ Storybook မှာ document လုပ်ပြီး platform ဓလေ့တွေကို လေးစားပါ — navigation၊ date picker နဲ့ haptic တွေက iOS နဲ့ Android မှာ native ဆန်ဆန် ခံစားရသင့်ပါတယ်။ Design system ကို version လုပ်ပြီး သူ့ test တွေထဲမှာ accessibility စစ်ဆေးချက်တွေ ထည့်ပါ။

Micro-frontend တွေက web front end ကြီးတစ်ခုကို team အမျိုးမျိုးက သီးခြား ပိုင်ဆိုင်ပြီး deploy လုပ်တဲ့ အပိုင်းတွေ ခွဲကာ build time မှာ၊ server ပေါ်မှာ ဒါမှမဟုတ် browser ထဲမှာ (ဥပမာ Module Federation နဲ့) ပေါင်းစပ်ပါတယ်။ Front-end repo တစ်ခုတည်းမှာ team အများကြီး တစ်ခုနဲ့တစ်ခု ပိတ်ဆို့နေတဲ့ အရမ်းကြီးတဲ့ အဖွဲ့အစည်းတွေကို အထောက်အကူဖြစ်ပါတယ်။ Team အများစုအတွက်တော့ bundle ထပ်နေတာ၊ UX မညီတာနဲ့ ရှုပ်ထွေးတဲ့ tooling တွေ ထပ်ပေါင်းပါတယ်၊ ownership ရှင်းတဲ့ ဖွဲ့စည်းပုံကောင်းတဲ့ monorepo က တူညီတဲ့ ပြဿနာကို ပိုသက်သာစွာ ဖြေရှင်းတတ်ပါတယ်။

Team ရဲ့ လက်ရှိ skill (React web team က React Native မှာ မြန်မြန် ထုတ်လုပ်နိုင်တယ်)၊ web နဲ့ code ဘယ်လောက် မျှသုံးချင်လဲ၊ app က ဘယ်လောက် platform-specific ဒါမှမဟုတ် performance လေးလဲ (AR၊ ရှုပ်ထွေးတဲ့ camera ဒါမှမဟုတ် audio အလုပ်က native ကို ဦးစားပေးနိုင်)၊ custom ဆန်ပြီး တစ်ပုံစံတည်း UI လိုအပ်ချက် (Flutter ကို ဦးစားပေး)၊ ကိုယ့် integration တွေအတွက် library တွေရဲ့ ရင့်ကျက်မှုနဲ့ ရေရှည် hiring ကို ထည့်စဉ်းစားပါ။ မဆုံးဖြတ်ခင် အန္တရာယ်အများဆုံး screen ကို ထိပ်ဆုံး ရွေးချယ်စရာနဲ့ prototype လုပ်ကြည့်ပါ။

Test အများစုကို unit နဲ့ integration အဆင့်မှာထားပြီး အရေးကြီးတဲ့ journey တွေကိုပဲ E2E မှာ ထားပါ။ Test တွေကို parallel run ပြီး CI မှာ shard လုပ်၊ monorepo ထဲမှာ ထိခိုက်တဲ့ project တွေကိုပဲ run၊ container ထဲမှာ တကယ့်ပေမဲ့ ပစ်လို့ရတဲ့ database တွေသုံးပြီး test တစ်ခုချင်းအလိုက် data seed လုပ်ပါ။ Flaky test တွေကို bug အဖြစ် ဆက်ဆံပါ — owner နဲ့ deadline နဲ့ quarantine လုပ်၊ timing နဲ့ shared state လို root cause တွေကို ပြင်ပြီး flakiness ကို အချိန်နဲ့အမျှ ခြေရာခံပါ။

User experience ကို ထင်ဟပ်တဲ့ budget တွေကို သဘောတူပါ — LCP နဲ့ INP ပစ်မှတ်၊ route တစ်ခုချင်းအတွက် JavaScript၊ API p95 latency၊ mobile cold-start time၊ app download size နဲ့ crash-free session။ အလိုအလျောက် အတင်းကျင့်သုံးပါ — pull request တွေမှာ bundle size စစ်ဆေးချက်နဲ့ Lighthouse CI၊ launch ကြီးတွေမတိုင်ခင် load test နဲ့ real-user monitoring ဆီက alert ပါတဲ့ dashboard တွေ။ Regression တွေကို functional bug တွေလိုပဲ review လုပ်ပါ။

Production traffic ကနေ လက်တွေ့ကျတဲ့ scenario တွေ — endpoint ရောစပ်မှု၊ think time နဲ့ data size — ကို သတ်မှတ်ပြီး production နဲ့ ဆင်တူတဲ့ environment ပေါ်မှာ k6၊ Gatling ဒါမှမဟုတ် Artillery လို tool နဲ့ run ပါ။ ချိုးဖောက်တဲ့ အမှတ်ကို ရှာဖို့ load ကို တစ်ဆင့်ချင်း တိုးပြီး latency percentile၊ error rate၊ database CPU၊ connection pool နဲ့ queue depth ကို ကြည့်ပါ။ ရည်မှန်းချက်က တကယ့် traffic က မလုပ်ခင် ပထမဆုံး bottleneck ကို ရှာပြီး ဘေးကင်းမှု margin နဲ့ capacity ကို အတည်ပြုဖို့ပါ။

Request အသစ်တွေက connection ကို စောင့်၊ timeout ဖြစ်ပြီး error တွေအဖြစ် ဆင့်ကဲ ပျံ့ပါတယ်၊ autoscaling က ကိုယ်ပိုင် pool ပါတဲ့ app instance တွေ ထပ်ထည့်ပြီးနောက် ဖြစ်တတ်ပါတယ်။ Database ရဲ့ limit ကို instance တွေကြား ခွဲပြီး pool size သတ်မှတ်၊ PgBouncer လို pooler ဒါမှမဟုတ် provider ရဲ့ pooling ကို သုံး (serverless function တွေနဲ့ဆို မဖြစ်မနေ)၊ transaction တွေကို တိုတိုထား၊ query နဲ့ acquire timeout သတ်မှတ်ပြီး pool ပြည့်တာအတွက် alert လုပ်ပါ။

အပြင်ဘက် ခေါ်ဆိုမှုတိုင်းမှာ timeout သတ်မှတ်၊ ဘေးကင်းတဲ့ ဒါမှမဟုတ် idempotent operation တွေကိုပဲ exponential backoff နဲ့ jitter ပါ retry လုပ်ပြီး ပျက်နေမှန်း ထင်ရှားတဲ့ service ကို ခေါ်တာ ရပ်ဖို့ circuit breaker သုံးပါ။ Cache လုပ်ထားတဲ့ data ဒါမှမဟုတ် လျော့ချထားတဲ့ feature လို fallback တွေ ထည့်၊ နှေးတဲ့ dependency တစ်ခုက အားလုံးကို မကုန်စေအောင် bulkhead (pool ဒါမှမဟုတ် queue သီးခြား) သုံးပြီး အရေးမကြီးတဲ့ ခေါ်ဆိုမှုတွေကို background job တွေဆီ ရွှေ့ပါ။

လိုတဲ့ data ကိုပဲ စုဆောင်း၊ ဘာကြောင့်နဲ့ ဘယ်မှာ သိမ်းလဲ မှတ်တမ်းတင်၊ ပို့နေစဉ်နဲ့ သိမ်းထားစဉ် encrypt လုပ်ပြီး audit log နဲ့ role အလိုက် access ကို ကန့်သတ်ပါ။ User အခွင့်အရေးတွေကို support လုပ်ပါ — database၊ backup policy၊ analytics၊ log နဲ့ third party တွေတစ်လျှောက် export နဲ့ ဖျက်ခြင်း — လိုအပ်ရင် consent ယူပါ။ Mobile မှာ Apple ရဲ့ privacy nutrition label နဲ့ Google Play ရဲ့ Data safety form ကို တိကျစွာ ဖြည့်ပြီး data စုဆောင်းတဲ့ third-party SDK တွေကို စာရင်းပြုစုပါ။

Technical debt က shortcut တွေနဲ့ ခေတ်နောက်ကျတဲ့ ဆုံးဖြတ်ချက်တွေရဲ့ အနာဂတ် ကုန်ကျစရိတ်ပါ — တခါတလေ တမင်လုပ်ပြီး တန်တယ်၊ တခါတလေ မတော်တဆ ဖြစ်တယ်။ မြင်သာအောင် လုပ်ပါ — ခိုင်မာတဲ့ နာကျင်မှု (delivery နှေးတာ၊ incident၊ onboarding အချိန်) နဲ့ ချိတ်ထားတဲ့ debt register ထား၊ item တွေကို impact နဲ့ effort အလိုက် ဦးစားပေးပြီး စဉ်ဆက်မပြတ် ပြန်ဆပ်ပါ — "boy scout rule"၊ sprint တိုင်းရဲ့ တစ်စိတ်တစ်ပိုင်း သီးသန့်ထားတာ ဒါမှမဟုတ် တူညီတဲ့ နေရာက feature အလုပ်နဲ့ refactor တွေကို တွဲလုပ်တာ။ Big-bang rewrite တွေကို ရှောင်ပါ။

ADR က အရေးကြီးတဲ့ နည်းပညာ ဆုံးဖြတ်ချက်ကို မှတ်တမ်းတင်ထားတဲ့ code နဲ့အတူ သိမ်းထားတဲ့ စာတမ်းတိုလေးပါ — context၊ စဉ်းစားခဲ့တဲ့ ရွေးချယ်စရာတွေ၊ ဆုံးဖြတ်ချက်နဲ့ သူ့အကျိုးဆက်တွေ။ ADR တွေက team member အသစ်တွေကို အရာတွေ ဘာကြောင့် ဒီလိုဖြစ်နေလဲ နားလည်စေတယ်၊ တူညီတဲ့ ငြင်းခုံမှုတွေ ထပ်မဖြစ်အောင် တားပြီး context ပြောင်းတဲ့အခါ ဆုံးဖြတ်ချက်ကို ပြန်သုံးသပ်ဖို့ ပိုလွယ်စေပါတယ်။

Lecture ပေးမယ့်အစား တကယ့်အလုပ်ပေါ်မှာ pair လုပ်ပါ၊ သူတို့ လက်ရှိအဆင့်ထက် နည်းနည်းကျော်တဲ့ ပြဿနာတွေကို အကူအညီနဲ့ ပေးပြီး feature တွေကို အစအဆုံး ပိုင်ဆိုင်ခွင့် ပေးပါ။ Fix တွေချည်း မဟုတ်ဘဲ ရှင်းပြချက်နဲ့ link တွေနဲ့ code review လုပ်ပြီး သူတို့ ကိုယ်တိုင် တွေးတောနိုင်အောင် မေးခွန်းတွေ မေးပါ ("ဒီ request ကို retry လုပ်ရင် ဘာဖြစ်မလဲ?")။ Product နဲ့ business အကြောင်း context ကို မျှဝေ၊ တိကျတဲ့ feedback ကို ပုံမှန်ပေးပြီး သူတို့ တိုးတက်မှုကို လူသိရှင်ကြား ဂုဏ်ပြုပါ။

STAR — Situation၊ Task၊ Action၊ Result — လို ရှင်းလင်းတဲ့ ဖွဲ့စည်းပုံကို သုံးပါ။ ဥပမာ — ကျွန်တော်တို့ mobile app ရဲ့ offline order တွေ တခါတလေ ထပ်နေတယ် (situation)၊ fix ကို ကျွန်တော် ပိုင်ဆိုင်ခဲ့တယ် (task)၊ client ထုတ်ပေးတဲ့ ID၊ idempotency key နဲ့ device ပေါ်မှာ outbox ကို မိတ်ဆက်ပြီး user 10% ဆီ flag နောက်ကွယ်ကနေ rollout လုပ်ကာ ထပ်နေတာတွေကို စောင့်ကြည့်ခဲ့တယ် (action)၊ ထပ်နေတာ သုညဖြစ်သွားပြီး support ticket တွေ သုံးပုံတစ်ပုံ ကျသွားတယ် (result)။ ဘာကို ကွဲပြားစွာ လုပ်မလဲ ပြောပြပါ၊ ဒါက ပြန်လည်သုံးသပ်နိုင်မှုကို ပြပါတယ်။

Tech lead က နည်းပညာပိုင်းမှာ ဆက်ရှိနေပေမဲ့ အလုပ်က team ကို အဆများစွာ တိုးစေဖို့ ဖြစ်လာပါပြီ — ဦးတည်ချက် သတ်မှတ်တယ်၊ ဆုံးဖြတ်ချက်တွေ ချပြီး ရှင်းပြတယ်၊ web၊ mobile နဲ့ backend တစ်လျှောက် delivery ကို ခန့်မှန်းလို့ရအောင် ထိန်းတယ်၊ quality နဲ့ reliability ကို ကာကွယ်ပြီး လူတွေကို ကြီးထွားစေတယ်။ Interviewer တွေက ဆင်ခြင်ဉာဏ်၊ engineer မဟုတ်သူတွေနဲ့ ဆက်သွယ်ပုံနဲ့ ဆုံးဖြတ်ချက်၊ ပဋိပက္ခနဲ့ ကျရှုံးမှုတွေအကြောင်း ခိုင်မာတဲ့ ဇာတ်လမ်းတွေကို ရှာပါတယ်။

Senior engineer ကို သူ့ကိုယ်ပိုင် နည်းပညာ output နဲ့ အဓိက တိုင်းတာပြီး tech lead ကိုတော့ team ရဲ့ ရလဒ်တွေနဲ့ တိုင်းတာပါတယ်။ Lead က နည်းပညာ ဦးတည်ချက်ကို ပိုင်ဆိုင်တယ်၊ အလုပ်တွေကို ခွဲပြီး အစဉ်စီတယ်၊ ဆုံးဖြတ်ချက်တွေ ချတာ ဒါမှမဟုတ် ချနိုင်အောင် ကူညီတယ်၊ လူတွေရဲ့ အတားအဆီးတွေ ဖယ်ရှားတယ်၊ product၊ design နဲ့ တခြား team တွေနဲ့ ညှိနှိုင်းပြီး quality နဲ့ reliability ကို မြင့်မားအောင် ထိန်းပါတယ်။ Code ဆက်ရေးပါတယ် — များသောအားဖြင့် critical path ပေါ်မှာ ဒါမှမဟုတ် အခြေခံ အလုပ်တွေမှာ — ဒါပေမဲ့ အရင်ကထက် နည်းပြီး bottleneck မဖြစ်အောင် ရှောင်ပါတယ်။

နောက်တစ်နှစ်ကနေ နှစ်နှစ်အတွက် business ရည်မှန်းချက်တွေကနေ စပြီး သူတို့ကို ထောက်ပံ့မယ့် ပစ်မှတ် architecture နဲ့ ဒီနေ့ကနေ ကွာဟချက်ကို ဖော်ပြပါ — ဥပမာ client အားလုံးအတွက် typed API contract တစ်ခုတည်း၊ မျှသုံးတဲ့ design-token system၊ mobile ကို အပတ်စဉ် ship လုပ်တဲ့ release process နဲ့ ဖုန်းကနေ database အထိ observability။ Milestone တွေပါတဲ့ ရေးသားထားတဲ့ strategy တိုလေးအဖြစ် ပြောင်း၊ team ကိုယ်တိုင် ပုံဖော်ကူညီနိုင်အောင် သူတို့နဲ့ review လုပ်ပြီး သုံးလတစ်ကြိမ် ပြန်သုံးသပ်ပါ။

Tool အသစ်က အဟောင်းက မဖြေရှင်းနိုင်တဲ့ တကယ့်ပြဿနာကို မဖြေရှင်းမချင်း team ကောင်းကောင်းသိတဲ့၊ သက်သေပြပြီးသား "ပျင်းစရာကောင်းတဲ့" နည်းပညာကို ရွေးပါ။ Team skill နဲ့ hiring၊ web နဲ့ mobile code ဘယ်လောက် မျှသုံးနိုင်လဲ၊ ကိုယ့် integration (payment၊ map၊ auth) တွေအတွက် ecosystem၊ hosting နဲ့ run ရတဲ့ ကုန်ကျစရိတ်နဲ့ ရေရှည် ထိန်းသိမ်းမှုကို ချိန်ဆပါ။ TypeScript stack — ဥပမာ web မှာ Next.js၊ mobile အတွက် Expo နဲ့ PostgreSQL ပါတဲ့ Node.js API — က language တစ်ခုတည်းနဲ့ အားလုံးကို ဖုံးနိုင်လို့ အသုံးများတဲ့ ရွေးချယ်မှုပါ၊ အကြောင်းပြချက်တွေကို ADR ထဲ ရေးမှတ်ထားပါ။

ကိုယ့် product ကို ထူးခြားစေတာကို ဆောက်ပြီး မထူးခြားစေတာကို ဝယ်ပါ။ Authentication၊ payment၊ email ပို့တာ၊ error tracking၊ feature flag နဲ့ search တွေကို များသောအားဖြင့် ဝယ်တာ ဒါမှမဟုတ် managed service အဖြစ် ယူသုံးတာ ပိုကောင်းပါတယ်။ စုစုပေါင်း ပိုင်ဆိုင်မှု ကုန်ကျစရိတ် — licence တစ်ခုတည်း မဟုတ်ဘဲ နှစ်ပေါင်းများစွာ ဆောက်ဖို့၊ run ဖို့၊ လုံခြုံအောင်လုပ်ဖို့နဲ့ ထိန်းသိမ်းဖို့ engineering အချိန် — ကို vendor ကုန်ကျစရိတ်၊ lock-in အန္တရာယ်၊ data residency နဲ့ နောင်မှာ ဘယ်လောက် လွယ်လွယ် ပြောင်းထွက်နိုင်လဲ နဲ့ နှိုင်းယှဉ်ပါ။

"Backend အရင်၊ ပြီးမှ web၊ ပြီးမှ mobile" မဟုတ်ဘဲ user journey ကနေ စပြီး တစ်ခုချင်းက test လုပ်လို့ရတဲ့ အရာတစ်ခုခု ပေးပို့တဲ့ ပါးလွှာတဲ့ end-to-end အပိုင်းလေးတွေအဖြစ် ဒေါင်လိုက် ခွဲပါ။ Web နဲ့ mobile က mock တွေပေါ်မှာ ပြိုင်တူ ဆောက်နိုင်အောင် API contract ကို စောစောသဘောတူ၊ မပြီးသေးတဲ့ အပိုင်းတွေကို feature flag နောက်ကွယ်မှာထား၊ အန္တရာယ်အများဆုံး မသိသေးတာတွေကို ရှာပြီး အရင် spike လုပ်ကာ mobile store review နဲ့ release timeline ကို schedule ထဲ ထည့်စီစဉ်ပါ။

အပိုင်းတွေ သေးပြီး ရင်းနှီးတဲ့အထိ အလုပ်ကို ခွဲ၊ team အနေနဲ့ ခန့်မှန်းပြီး အလားတူ အလုပ်က အရင်က ဘယ်လောက်ကြာခဲ့လဲ နှိုင်းယှဉ်ပါ။ ရက်စွဲ တစ်ခုတည်းအစား ယုံကြည်မှုနဲ့ range ပေးပါ ("3–5 ပတ်၊ ဖြစ်နိုင်ခြေအများဆုံး 4 ပတ်")၊ ယူဆချက်နဲ့ အန္တရာယ်တွေကို ထုတ်ပြောပြီး testing၊ review၊ app-store review နဲ့ bug fix အတွက် အချိန် ထည့်ပါ။ ပြီးရင် သိလာတာနဲ့အမျှ ပုံမှန် ပြန်ခန့်မှန်းပြီး ပြောင်းလဲမှုတွေကို စောစော မျှဝေပါ — စောစောပြောတဲ့ သတင်းဆိုးက planning input ပါ၊ နောက်ကျမှ ပြောရင်တော့ အကျပ်အတည်း ဖြစ်ပါတယ်။

သုံးခုလုံးကို backlog တစ်ခုတည်းထဲမှာ မြင်သာအောင်ထားပြီး business ဝေါဟာရ — အန္တရာယ်၊ နှောင့်နှေးမှုရဲ့ ကုန်ကျစရိတ်နဲ့ user တွေအပေါ် သက်ရောက်မှု — နဲ့ ပြောပါ။ Product manager နဲ့ capacity ခွဲဝေပုံ အကြမ်း (ဥပမာ feature 70%၊ debt နဲ့ platform 20%၊ bug 10%) ကို သဘောတူပြီး လက်တွေ့ ပြောင်းလဲတဲ့အခါ ညှိပါ — incident ဖြစ်ပြီးရင် reliability ကို ပိုပေးပါ။ အရေးကြီးတဲ့ bug နဲ့ security ပြဿနာတွေက ကြားဖြတ်ပြီး ကျန်တာတွေကို ဦးစားပေးအလိုက် စီပါ။ Debt အလုပ်ကို ပိုမြန်တဲ့ release ဒါမှမဟုတ် incident နည်းတာလို သူဖွင့်ပေးမယ့် ရလဒ်တွေနဲ့ ချိတ်ပါ။

သူတို့ ဂရုစိုက်တဲ့ ရလဒ်တွေအဖြစ် ဘာသာပြန်ပါ — "ဒီ migration က ကျွန်တော်တို့ mobile release time ကို နှစ်ပတ်ကနေ သုံးရက်အထိ လျှော့ပေးမယ်"၊ "ဒီ fix က နောက်ဆုံး outage နှစ်ခုရဲ့ အကြောင်းရင်းကို ဖယ်ရှားပေးမယ်၊ အဲဒါတွေက refund အနေနဲ့ X ကုန်ခဲ့တယ်"။ Data — lead time၊ incident အရေအတွက်၊ cloud ကုန်ကျစရိတ်၊ support ticket — ယူလာပြီး တိုင်းတာလို့ရတဲ့ ရလဒ်ပါ အချိန်ကန့်သတ်ထားတဲ့ ပထမခြေလှမ်း သေးသေးလေး အဆိုပြုကာ နောက် တောင်းဆိုမှုအတွက် ယုံကြည်မှု တည်ဆောက်ဖို့ ဘာရခဲ့လဲ ပြန်တင်ပြပါ။

သဘောထားကွဲလွဲမှု အများစုက တကယ်တော့ ရည်မှန်းချက်ကွဲတာ ဖြစ်တတ်လို့ ပြဿနာနဲ့ ဆုံးဖြတ်ချက် စံနှုန်းတွေကို အရင် သဘောတူကြောင်း သေချာအောင်လုပ်ပါ။ ဘက်တစ်ဘက်ချင်းကို trade-off တွေနဲ့ ကိုယ့်ရွေးချယ်စရာကို ရေးခိုင်း၊ အချက်အလက်က ဆုံးဖြတ်ပေးနိုင်ရင် prototype ဒါမှမဟုတ် တိုင်းတာမှု မြန်မြန်လုပ်ပြီး ထိန်းသိမ်းမယ့်သူတွေကို ပါဝင်စေပါ။ သဘောတူညီမှု မရရင် ဆုံးဖြတ်ပြီး ADR ထဲမှာ ဘာကြောင့်လဲ ရှင်းပြကာ "disagree and commit" ကို တောင်းပါ။ အထောက်အထားအသစ် ပေါ်လာရင် ပြန်သုံးသပ်ပါ — ပြီးတော့ ဘယ်တော့မှ ပုဂ္ဂိုလ်ရေး မဖြစ်စေပါနဲ့။

မျှော်လင့်ချက်တွေကို ရှင်းရှင်းသတ်မှတ်ပါ — pull request သေးသေး၊ အလုပ်ချိန် တစ်ရက်အတွင်း review၊ formatting၊ linting၊ type နဲ့ test အတွက် automated check တွေထားလို့ လူတွေက design၊ မှန်ကန်မှုနဲ့ security ကို အာရုံစိုက်နိုင်ပါတယ်။ အန္တရာယ်ရှိတဲ့ နေရာတွေ (migration၊ auth၊ payment၊ mobile version ဟောင်းတွေကို ထိခိုက်တဲ့ API ပြောင်းလဲမှု) အတွက် checklist သုံးပါ။ ကြင်နာပြီး တိကျတဲ့ comment တွေကို အားပေး၊ nit တွေကို optional လို့ label တပ်ပြီး အားလုံး lead ကို စောင့်နေမယ့်အစား အသိပညာ ပျံ့နှံ့အောင် reviewer တွေကို အလှည့်ကျ ပြောင်းပါ။

ရေးထားတဲ့ စည်းမျဉ်းတွေကို တိုတိုထားပြီး တတ်နိုင်သမျှ automate လုပ်ပါ — မျှသုံးတဲ့ ESLint၊ Prettier နဲ့ TypeScript config တွေ၊ package အသစ်တွေအတွက် monorepo template၊ commit နဲ့ branch ဓလေ့တွေနဲ့ API design၊ error handling၊ logging နဲ့ testing အတွက် standard တွေ။ "ဘာကြောင့်" ကို တိုတိုရှင်းရှင်း မှတ်တမ်းတင်၊ team ကို pull request တွေကနေ ပြောင်းလဲမှုတွေ အဆိုပြုခွင့်ပေးပြီး codebase တစ်ခုလုံးကို တစ်ခါတည်း reformat မလုပ်ဘဲ စည်းမျဉ်းအသစ်တွေကို တဖြည်းဖြည်း အသုံးချပါ။

သူတို့ကို ခွဲထုတ်ပါ။ API က အမြဲ backwards compatible ဖြစ်ပြီး စဉ်ဆက်မပြတ် deploy လုပ်တယ်၊ web က feature flag နောက်ကွယ်ကနေ တစ်ရက်ကို အကြိမ်ကြိမ် deploy လုပ်တယ်၊ mobile က code freeze၊ QA၊ staged rollout နဲ့ hotfix လမ်းကြောင်းပါတဲ့ ပုံမှန် release train (ဥပမာ အပတ်စဉ် ဒါမှမဟုတ် နှစ်ပတ်တစ်ခါ) ကို လိုက်ပါတယ်။ လိုအပ်တဲ့ client တိုင်း live ဖြစ်ပြီးမှ feature တွေကို flag နဲ့ ဖွင့်ပြီး API စွမ်းရည်အသစ်တွေကို သူတို့ကို သုံးမယ့် client တွေထက် အရင် ship လုပ်ပါ။

Release train က mobile version တွေကို ပုံသေ schedule နဲ့ ship လုပ်ပါတယ် — အဆင်သင့်ဖြစ်ပြီး test ပြီးတာက train ပေါ်တက်ပြီး ကျန်တာတွေက နောက် train ကို စောင့်ပါတယ်။ Business အတွက် release တွေကို ခန့်မှန်းလို့ရစေတယ်၊ feature တွေကို အလျင်စလို လုပ်ရတဲ့ ဖိအားကို လျှော့ပြီး release လုပ်တာကို ပုံမှန်အလုပ် ဖြစ်စေပါတယ်။ Release captain အလှည့်ကျ၊ automated build နဲ့ store upload၊ release checklist၊ staged rollout နဲ့ rollout ကို ရပ်ဖို့ crash-rate gate တွေနဲ့ တွဲသုံးပါ။

DORA metric တွေ — deployment frequency၊ lead time for changes၊ change failure rate နဲ့ time to restore service — က မြန်နှုန်းနဲ့ တည်ငြိမ်မှုကို ချိန်ခွင်လျှာညီညီ မြင်စေပြီး crash-free session၊ SLO လိုက်နာမှုနဲ့ developer-experience survey တွေနဲ့ ဖြည့်စွက်နိုင်ပါတယ်။ Team အတွက် system ပြဿနာနဲ့ trend တွေကို မြင်ဖို့ သုံးပါ၊ တစ်ဦးချင်းကို အဆင့်ခွဲဖို့ ဘယ်တော့မှ မသုံးပါနဲ့၊ လူတွေ လှည့်စားနိုင်တဲ့ ပစ်မှတ်တွေ အဖြစ်လည်း မပြောင်းပါနဲ့။ Code လိုင်းအရေအတွက်နဲ့ တစ်ယောက်ချင်း story point တွေက productivity metric မဟုတ်ပါဘူး။

မှန်တာကို လုပ်ရလွယ်အောင် လုပ်ပါ — မြန်တဲ့ CI၊ ကောင်းတဲ့ test helper နဲ့ fixture၊ preview environment၊ template နဲ့ automated check တွေ။ Test၊ accessibility၊ analytics နဲ့ monitoring ပါဝင်တဲ့ definition of done ကို သဘောတူပါ။ Production ပိုင်ဆိုင်မှုကို မျှဝေပါ — feature ဆောက်တဲ့ team က release ပြီးနောက် သူ့ dashboard တွေကို စောင့်ကြည့်ပါတယ်။ Bug နဲ့ incident နည်းရင် ပြန်လုပ်ရတာ နည်းတာမို့ quality က အချိန်ကြာလာတာနဲ့အမျှ delivery မြန်နှုန်းကို တိုးစေပါတယ်။

အပြစ်မတင်ပါနဲ့ — ဘယ်သူ မှားခဲ့လဲ မဟုတ်ဘဲ system နဲ့ process က ကျရှုံးမှုကို ဘယ်လို ခွင့်ပြုခဲ့လဲကို အာရုံစိုက်ပါ၊ ဒါမှ လူတွေက ဇာတ်လမ်း အပြည့်အစုံကို မျှဝေပါမယ်။ တိကျတဲ့ timeline ဆောက်၊ ပါဝင်ခဲ့တဲ့ အကြောင်းရင်းတွေ (ရှာဖွေတွေ့ရှိမှုနဲ့ တုံ့ပြန်မှု နှောင့်နှေးတာအပါအဝင်) ကို ဖော်ထုတ်ပြီး owner နဲ့ due date ပါတဲ့ ခိုင်မာတဲ့ action item အနည်းငယ်ကို တခြားအလုပ်တွေနဲ့ ယှဉ်ပြီး ဦးစားပေး သဘောတူပါ။ ရေးထားတာကို ကျယ်ကျယ်ပြန့်ပြန့် မျှဝေပြီး action item တွေ ပြီးဆုံးတဲ့အထိ ခြေရာခံပါ — ဆက်မလုပ်တဲ့ postmortem က စာတမ်းတစ်ခုသာ ဖြစ်ပါတယ်။

Rotation ထဲမှာ လူလုံလောက်စွာ ထား (ဖြစ်နိုင်ရင် ခြောက်ယောက်နဲ့အထက်)၊ ရှင်းလင်းတဲ့ runbook နဲ့ escalation လမ်းကြောင်းတွေ ထားပြီး alert တွေကို လုပ်ဆောင်လို့ရပြီး user ထိခိုက်မှုနဲ့ ချိတ်ထားပါ၊ ဒါမှ ညတွေကို ဆူညံသံအတွက် မဖြုန်းမှာပါ။ On-call အချိန်ကို လျော်ကြေးပေး၊ ခက်ခဲတဲ့ညတွေနောက်မှာ အနားပေးပြီး page တိုင်းကို အပတ်စဉ် review လုပ်ကာ ဆူညံတဲ့ alert တွေကို ဖျက် ဒါမှမဟုတ် ပြင်ပါ။ Page လျှော့ချတာကို team ရည်မှန်းချက် လုပ်ပါ — on-call က နာကျင်ရင် ဒါက reliability backlog item ပါ၊ ကိုယ်ပိုင် ခံနိုင်ရည် စမ်းသပ်မှု မဟုတ်ပါဘူး။

Team တကယ်လိုအပ်တာကို သတ်မှတ်ပါ — generalist တစ်ယောက်ထက် mobile engineer ကောင်းကောင်း ပိုလိုနိုင်တယ် — ပြီးတော့ ရှင်းလင်းပြီး ရိုးသားတဲ့ job description ရေးပါ။ Candidate တိုင်းအတွက် မေးခွန်းတူတူနဲ့ scoring rubric ပါတဲ့ structured process သုံးပါ — တကယ့်အလုပ်နဲ့ နီးစပ်တဲ့ လက်တွေ့ လေ့ကျင့်ခန်း (feature သေးလေး ဒါမှမဟုတ် pull request ကို code review)၊ အဆင့်နဲ့ ကိုက်အောင် ညှိထားတဲ့ system-design ဆွေးနွေးမှုနဲ့ behavioural interview။ Interviewer တွေကို လေ့ကျင့်ပေး၊ ဖွဲ့စည်းပုံနဲ့ bias ကို လျှော့ပြီး candidate တွေကို မြန်ဆန်ပြီး လေးစားတဲ့ feedback ပေးပါ။

ပထမနေ့ မတိုင်ခင် ပြင်ဆင်ပါ — account တွေ၊ laptop နဲ့ ပထမနေ့မှာပဲ web app၊ mobile app နဲ့ API ကို local မှာ run နိုင်အောင် setup script။ Onboarding buddy တစ်ယောက်၊ architecture overview၊ business ဝေါဟာရ glossary နဲ့ stack ရဲ့ အပိုင်းတိုင်းကို ထိတဲ့ "good first ticket" စာရင်း ပေးပါ။ ပထမအပတ်မှာ merge လုပ်ပြီးသား pull request တစ်ခုနဲ့ ပထမလမှာ ship လုပ်ပြီးသား feature သေးလေး တစ်ခုကို ရည်မှန်းပြီး သွားရင်းနဲ့ onboarding doc တွေကို ပိုကောင်းအောင် ပြင်ခိုင်းပါ။

Status ချည်း မဟုတ်ဘဲ ရည်မှန်းချက်တွေအကြောင်း ပြောတဲ့ ပုံမှန် one-to-one တွေ ထားပါ။ အလုပ်ကို ကြီးထွားမှု ရည်မှန်းချက်နဲ့ ကိုက်အောင် ပေးပါ — senior ဖြစ်ချင်တဲ့ mid-level developer က နောက် feature ရဲ့ design ကို ဦးဆောင်ပြီး ကိုယ်က safety net အဖြစ် နေပါ။ အပြုသဘောနဲ့ ပြုပြင်ဖို့ feedback နှစ်မျိုးလုံးကို တိကျပြီး အချိန်မီပေး၊ မျှော်လင့်ချက်တွေ ရှင်းအောင် career ladder ကို သုံးပြီး လူတွေကို မြင်သာတဲ့ အခွင့်အလမ်းနဲ့ credit ပေးကာ sponsor လုပ်ပါ။

နားလည်ဖို့နဲ့ စပါ — သီးသန့် စကားပြော၊ အတားအဆီး၊ အလုပ်ဝန်၊ မရှင်းတဲ့ မျှော်လင့်ချက် ဒါမှမဟုတ် ကိုယ်ရေးကိုယ်တာ ပြဿနာတွေအကြောင်း မေးပြီး ပြဿနာက skill လား၊ စိတ်ဆန္ဒလား ဒါမှမဟုတ် ပတ်ဝန်းကျင်လား စစ်ပါ။ ပြီးရင် ဥပမာတွေနဲ့ ရှင်းလင်းတိကျတဲ့ မျှော်လင့်ချက်တွေ သတ်မှတ်၊ အကူအညီ (pairing၊ training၊ task သေးသေး) ကို သဘောတူပြီး မှတ်တမ်းတင်ထားတဲ့ feedback နဲ့ ပုံမှန် follow up လုပ်ပါ။ Case အများစုက ရှင်းလင်းမှုနဲ့ အကူအညီနဲ့ တိုးတက်ပါတယ်၊ မတိုးတက်ရင် ကိုယ့် manager နဲ့ HR ကို စောစောပါဝင်စေပြီး တရားမျှတစွာ လေးစားစွာ ကိုင်တွယ်ပါ။

တစ်ဆင့်ချင်း task တွေ မဟုတ်ဘဲ ရလဒ်တွေကို လွှဲအပ်ပါ — ရည်မှန်းချက်၊ ကန့်သတ်ချက်တွေနဲ့ "ပြီးပြီ" ဆိုတာ ဘယ်လိုလဲ ရှင်းပြပြီး ချဉ်းကပ်ပုံကို သူတို့ကို ရွေးခွင့်ပေးပါ။ အကူအညီ အဆင့်ကို သူတို့ အတွေ့အကြုံနဲ့ ကိုက်အောင် ညှိ — နယ်ပယ်အသစ်ဖြစ်တဲ့သူကို check-in ပိုလုပ် — ပြီးဆုံးတဲ့ code ကိုချည်း မဟုတ်ဘဲ design ကို စောစော review လုပ်ပါ။ သူတို့ solution က ကိုယ့်ဟာနဲ့ ကွဲနိုင်တာကို လက်ခံပါ၊ တကယ်အရေးကြီးတာကိုပဲ ပြင်ပါ။

တစ်ယောက်တည်းပဲ နားလည်တဲ့ နေရာတွေ — များသောအားဖြင့် mobile build setup၊ payment ဒါမှမဟုတ် ရှုပ်ထွေးတဲ့ integration — ကို ဖော်ထုတ်ပြီး အဲဒီ အသိပညာကို တမင် ပျံ့နှံ့စေပါ — pair programming၊ အဲဒီနေရာတွေမှာ ဘယ်သူ အလုပ်လုပ်လဲ အလှည့်ကျပြောင်းတာ၊ recorded walkthrough၊ runbook နဲ့ ADR တွေ။ အရေးကြီးတဲ့ system တွေမှာ ဒုတိယလူရဲ့ review ကို မဖြစ်မနေ လိုအပ်စေပြီး "မနက် 2 နာရီမှာ တခြားတစ်ယောက်က ဒါကို ပြင်နိုင်မလား?" ကို ပုံမှန်မေးခွန်း လုပ်ပါ။ Lead အနေနဲ့ ကိုယ့်ကိုယ်ပိုင် အသိပညာလည်း ထည့်တွက်ပါတယ်။

Feasibility၊ ကုန်ကျစရိတ်နဲ့ နည်းပညာ အခွင့်အလမ်းတွေက ခန့်မှန်းချက်ကိုချည်း မဟုတ်ဘဲ solution ကို ပုံဖော်နိုင်အောင် discovery မှာ engineering ကို စောစော ပါဝင်စေပါ။ Trade-off တွေကို ပွင့်ပွင့်လင်းလင်း မျှဝေ ("web version ကို နှစ်ပတ်နဲ့ ship လုပ်နိုင်တယ်၊ mobile က store release လိုလို့ လေးပတ်")၊ empty၊ error၊ offline နဲ့ loading state လို edge case တွေအတွက် design တွေကို review လုပ်ပြီး အောင်မြင်မှုကို ဘယ်လို တိုင်းမလဲ သဘောတူပါ။ လွှဲပြောင်းကွင်းဆက် မဟုတ်ဘဲ ရည်မှန်းချက်တူတဲ့ team တစ်ခုတည်းအဖြစ် ဆက်ဆံပါ။

ပြောင်းလဲမှုတွေက ပုံမှန်ပါ၊ မစီမံတဲ့ ပြောင်းလဲမှုတွေက ပြဿနာပါ။ တောင်းဆိုမှုအသစ် ရောက်လာရင် trade-off ကို မြင်သာအောင်လုပ်ပါ — ဘာကို အစားထိုးမလဲ၊ ရက်စွဲနဲ့ အန္တရာယ်ကို ဘယ်လို ထိခိုက်မလဲ။ တောင်းဆိုမှုတွေကို product manager နဲ့ planning ကနေ ဖြတ်စေပြီး team ကို အဆက်မပြတ် ကြားဖြတ်ခံရတာကနေ ကာကွယ်၊ အရေးပေါ်အလုပ်အတွက် buffer ကို ရှင်းရှင်းထားပြီး ရက်စွဲ ပုံသေဖြစ်နေရင် quality မဟုတ်ဘဲ scope ကို ဖြတ်ပါ — version သေးသေးကို ship လုပ်ပြီး နောက်မှ ဆက်လုပ်ပါ။

ခံစားချက် မဟုတ်ဘဲ အချက်အလက်တွေနဲ့ စောစော ထုတ်ပြောပါ — ဘာပြီးပြီလဲ၊ ဘာကျန်လဲ၊ ခန့်မှန်းချက် ဘာကြောင့် ပြောင်းသွားလဲ။ ပြဿနာချည်း မဟုတ်ဘဲ ရွေးချယ်စရာတွေကို တင်ပြပါ — scope လျှော့၊ web ကို အရင် ship ပြီး mobile ကို နောက် release train မှာ၊ သီးခြားအပိုင်းတစ်ခုမှာ လူထပ်ထည့် (တကယ် ခွဲလို့ရမှ) ဒါမှမဟုတ် ရက်စွဲ ရွှေ့ — တစ်ခုချင်းရဲ့ အကျိုးဆက်တွေနဲ့အတူ။ Stakeholder တွေကို ရွေးခိုင်းပြီး plan ကို update လုပ်ကာ ဆက်သွယ်မှု ဆက်ထိန်းပါ။ Team ကို အပတ်ပေါင်းများစွာ တိတ်တဆိတ် အချိန်ပို အလုပ်လုပ်ခိုင်းတာကို ရှောင်ပါ။

အခန်းကဏ္ဍတွေ ခွဲပါ — incident lead က ညှိနှိုင်း၊ engineer တွေက စုံစမ်းပြီး လူတစ်ယောက်က ဆက်သွယ်ရေးကို ကိုင်တွယ်ပါတယ်။ Internal channel တွေနဲ့ public status page ဆီ ခန့်မှန်းလို့ရတဲ့ အချိန်ကာလနဲ့ update တိုတိုလေးတွေ ပုံမှန်တင်ပါ — ဘာထိခိုက်လဲ၊ ဘာသိပြီလဲ၊ ဘာလုပ်နေလဲ၊ နောက် update ဘယ်အချိန်လာမလဲ — ဘာမှ မပြောင်းရင်တောင်။ Mobile user တွေအတွက် in-app banner ဒါမှမဟုတ် server-driven message သုံးပါ။ နောက်ပိုင်း ရှင်းလင်းတဲ့ အနှစ်ချုပ်နဲ့ follow-up action တွေကို မျှဝေပါ။

Big-bang rewrite တွေကို ရှောင်ပြီး strangler fig pattern ကို သုံးပါ။ System ဟောင်းရှေ့မှာ routing layer ထား၊ စွမ်းရည်တစ်ခုချင်းကို system အသစ်မှာ ပြန်ဆောက်ပြီး flag နောက်ကွယ်ကနေ traffic ကို တဖြည်းဖြည်း လမ်းကြောင်းပြောင်းကာ အပြည့်မပြောင်းခင် ရလဒ်တွေကို နှိုင်းယှဉ်ပါ (shadow traffic ဒါမှမဟုတ် dual read)။ Data ကို verification နဲ့ တဖြည်းဖြည်း migrate လုပ်၊ အဆင့်တိုင်းအတွက် rollback လမ်းကြောင်း ထား၊ တစ်ခုချင်းက တန်ဖိုးပေးတဲ့ milestone တွေ သတ်မှတ်ပြီး အပိုင်းဟောင်းတွေ ပိတ်သိမ်းမှုကို စီစဉ်ပါ — မဟုတ်ရင် နှစ်ခုလုံးကို ထာဝရ run နေရပါလိမ့်မယ်။

Tag တွေနဲ့ လစဉ် review နဲ့ service နဲ့ environment အလိုက် ကုန်ကျစရိတ်ကို မြင်သာအောင်လုပ်ပြီး budget နဲ့ alert တွေ သတ်မှတ်ပါ။ အဖြစ်များတဲ့ အောင်မြင်မှုတွေက လိုတာထက်ပိုထားတဲ့ instance နဲ့ database တွေကို size မှန်အောင်လုပ်တာ၊ autoscaling၊ အသုံးမပြုတဲ့ preview နဲ့ staging environment တွေ ပိတ်တာ၊ egress နဲ့ compute လျှော့ဖို့ caching နဲ့ CDN သုံးတာ၊ storage lifecycle rule တွေနဲ့ ဈေးကြီးတဲ့ third-party SaaS seat နဲ့ အသုံးပြုမှုကို review လုပ်တာပါ။ Design ဆုံးဖြတ်ချက်တွေမှာ ကုန်ကျစရိတ်ကို ထည့်စဉ်းစားပါ၊ ဒါပေမဲ့ ချွေတာမှု သေးသေးလေးအတွက် engineer အပတ်ပေါင်းများစွာ မလဲပါနဲ့။

Managed service က တကယ့် မြန်နှုန်း ပေးတဲ့နေရာမှာ lock-in တချို့ကို လက်ခံပါ — များသောအားဖြင့် တန်ပါတယ် — ဒါပေမဲ့ အရေးကြီးတဲ့ အပိုင်းတွေအတွက် ထွက်ပေါက် ထားပါ။ Vendor တွေကို ကိုယ်ပိုင် interface (payment ဒါမှမဟုတ် email module) နောက်ကွယ်မှာ ထုပ်ထား၊ open standard နဲ့ ရွှေ့ပြောင်းလို့ရတဲ့ နည်းပညာ (PostgreSQL၊ OpenTelemetry၊ container၊ OAuth/OIDC) ကို ဦးစားပေး၊ data ကို export လုပ်လို့ရအောင်ထားပြီး migration တစ်ခု ဘယ်လောက်ကုန်မလဲ အကြမ်းဖျင်း သိထားပါ။ Contract သက်တမ်းတိုးတဲ့အခါ ပြန်အကဲဖြတ်ပါ။

Workflow ထဲ ထည့်ဆောက်ပါ — sensitive data ပါတဲ့ feature အသစ်တွေကို threat-model လုပ်၊ review တွေမှာ secure-coding checklist လိုက်၊ CI မှာ dependency နဲ့ secret တွေကို scan လုပ်၊ dependency တွေကို အလိုအလျောက် update လုပ်ပြီး authorisation rule တွေကို test လုပ်ပါ။ Security ခေါင်းစဉ်တွေအတွက် owner ရှင်းရှင်း သတ်မှတ်၊ ကိုယ့် codebase ထဲက တကယ့် ဥပမာတွေနဲ့ ပုံမှန် security training လုပ်ပြီး launch ကြီးတွေ မတိုင်ခင် penetration test စီစဉ်ပါ။ Web၊ API နဲ့ mobile မှာ အရေးကြီးတဲ့ vulnerability တွေကို patch လုပ်ဖို့ မြန်တဲ့ လမ်းကြောင်း ထားပါ။

မြန်မြန် အကဲဖြတ်ပါ — ထိခိုက်တဲ့ code လမ်းကြောင်းကို တကယ် သုံးနေလား၊ ပေါ်လွင်နေလား၊ တက်တက်ကြွကြွ exploit လုပ်နေကြလား။ ဟုတ်ရင် incident အဖြစ် ဆက်ဆံပါ — patch ဒါမှမဟုတ် upgrade လုပ်ပါ၊ fix မရှိသေးရင် ယာယီ ကာကွယ်ချက် (WAF rule၊ feature ပိတ်) ထည့်ပါ။ API နဲ့ web ကို ချက်ချင်း deploy လုပ်ပါ၊ mobile အတွက် hotfix build ship လုပ် (fix က JavaScript သက်သက်ဆိုရင် OTA update) ပြီး အန္တရာယ်မြင့်ရင် force update ကို စဉ်းစားပါ။ နောက်ပိုင်း ဘယ်လောက် မြန်မြန် ရှာတွေ့ခဲ့လဲ review လုပ်ပါ။

တခြား tool တွေလိုပဲ ဆက်ဆံပါ — ရည်မှန်းချက် ရှင်းရှင်းနဲ့ စမ်းသပ်ကာလ run၊ လမ်းညွှန်ချက်တွေ သဘောတူပြီး delivery နဲ့ quality အပေါ် သက်ရောက်မှုကို တိုင်းပါ။ လမ်းညွှန်ချက်တွေမှာ ကိုယ့် code နဲ့ data အတွက် ဘယ် tool တွေ ခွင့်ပြုထားလဲ၊ ခွင့်မပြုထားတဲ့ service တွေထဲ secret ဒါမှမဟုတ် customer data ဘယ်တော့မှ မထည့်ရ၊ တင်သွင်းတဲ့ လိုင်းတိုင်းကို author က ပိုင်ဆိုင်ပြီး နားလည်ရ၊ generate လုပ်ထားတဲ့ code အတွက် review နဲ့ testing standard အတူတူ၊ licence နဲ့ security စစ်ဆေးချက်တွေ ပါသင့်ပါတယ်။ ကောင်းတဲ့ prompt နဲ့ workflow တွေကို team တစ်ခုလုံး မျှဝေပါ။

ရေးသားထားတဲ့ asynchronous ဆက်သွယ်မှုကို ဦးစားပေးပါ — design doc၊ ADR၊ ရှင်းလင်းတဲ့ ticket၊ recorded demo နဲ့ decision log တွေ၊ ဒါမှ လူတွေက တစ်ချိန်တည်း online ဖြစ်ဖို့ မမှီခိုရပါဘူး။ တကယ် လူတိုင်းလိုတဲ့ meeting တွေအတွက် overlap window သေးသေးလေး ထား၊ meeting အချိန်တွေကို တရားမျှတစွာ အလှည့်ကျပြောင်းပြီး call တွေထဲ ချတဲ့ ဆုံးဖြတ်ချက်တွေကို ရေးမှတ်ထားကြောင်း သေချာပါစေ။ ဆက်ဆံရေးမှာ တမင် ရင်းနှီးမြှုပ်နှံပါ — remote ဖြစ်တဲ့အခါ အလွတ်သဘော call တွေနဲ့ ရံဖန်ရံခါ မျက်နှာချင်းဆိုင် တွေ့ဆုံမှုတွေက ပိုအရေးကြီးပါတယ်။

Planning က meeting မတိုင်ခင် ပြင်ဆင်ပြီးသား အလုပ်တွေနဲ့ ရလဒ်တွေနဲ့ အရင် capacity ပေါ် အခြေခံတဲ့ လက်တွေ့ကျတဲ့ ကတိကဝတ်အကြောင်း ဖြစ်သင့်ပါတယ်။ Retrospective တွေက တိုင်ကြားချက် စာရင်းရှည်ကြီး မဟုတ်ဘဲ owner ပါတဲ့ ခိုင်မာတဲ့ စမ်းသပ်မှု တစ်ခု နှစ်ခု ထုတ်ပေးသင့်ပါတယ်၊ အရင်ကြိမ်ရဲ့ action တွေကို အရင် review လုပ်ပါ။ လူတွေ စိတ်ဝင်စားနေအောင် format ကို ပြောင်းလဲ၊ meeting တွေကို တိုတိုထားပြီး ပြဿနာတွေ — lead အကြောင်းပါ — ထုတ်ပြောဖို့ ဘေးကင်းအောင် လုပ်ပါ။

Default အနေနဲ့ တဖြည်းဖြည်း refactor လုပ်ပါ — တန်ဖိုး ဆက်ပေးနေပြီး အန္တရာယ် လျော့ပါတယ်။ ရှိပြီးသား code က အရေးကြီးတဲ့ business ရည်မှန်းချက်တွေကို ပိတ်ဆို့နေတယ်၊ ခြေလှမ်းသေးသေးလေးတွေနဲ့ ဘေးကင်းစွာ မပြောင်းနိုင်ဘူး၊ team က domain ကို ပြန်ဆောက်နိုင်လောက်အောင် နားလည်တယ် ဆိုမှသာ rewrite ကို စဉ်းစားပါ — အဲဒီအခါမှာတောင် system ဟောင်း run နေဆဲမှာ module တစ်ခုချင်း တဖြည်းဖြည်း လုပ်ပါ။ Rewrite မှာ ဘာမပါဘူးဆိုတာကို ရှင်းရှင်း ပြောထားပါ၊ မဟုတ်ရင် ဘယ်တော့မှ မပြီးပါဘူး။

API contract ကို မျှသုံးတဲ့ source of truth လုပ်ပါ — implement မလုပ်ခင် client team အားလုံး review လုပ်ထားတဲ့ OpenAPI ဒါမှမဟုတ် GraphQL schema၊ generate လုပ်ထားတဲ့ typed client၊ client တွေ ချက်ချင်း စနိုင်အောင် mock server နဲ့ CI မှာ contract test။ ဖြတ်ကျော်ဆိုင်ရာ ဓလေ့တွေ — authentication၊ error၊ pagination၊ ရက်စွဲ၊ versioning၊ deprecation timeline — ကို တစ်ခါ သဘောတူပြီး changelog ထုတ်ဝေပါ။ Mobile version ဟောင်းတွေကို ပျက်စေနိုင်တဲ့ ပြောင်းလဲမှုတွေမှာ တိုက်ရိုက် sign-off လိုပါတယ်။

ဆုံးဖြတ်ချက်တွေ ပွင့်လင်း၊ ရေးသားပြီး မှတ်တမ်းတင်ထားအောင် ပေါ့ပါးတဲ့ RFC (request for comments) process ကို သုံးပါ —

Product team အများကြီးက တူညီတဲ့ infrastructure ပြဿနာတွေ — CI pipeline၊ deployment၊ observability၊ mobile build signing၊ မျှသုံးတဲ့ component library — ကို ထပ်ခါထပ်ခါ ဖြေရှင်းနေရပြီး အဲဒီအလုပ်က feature delivery ကို နှေးစေနေတဲ့အခါပါ။ Platform team က paved road တွေ ဆောက်ပါတယ် — product team တွေ သုံးချင်တဲ့ template၊ internal tool နဲ့ self-service infrastructure။ အဲဒီ scale မရောက်ခင် platform အလုပ်ကို team တွေအတွင်း အလှည့်ကျလုပ်ပြီး owner ရှင်းရှင်း သတ်မှတ်ပါ။

နောက်ဆုံး audit တစ်ခုတည်း မဟုတ်ဘဲ definition of done နဲ့ design review ထဲ ထည့်ပါ။ Design system ထဲက accessible component တွေ၊ CI မှာ automated check တွေ (web အတွက် axe နဲ့ accessibility lint rule လို) နဲ့ release တိုင်း အဓိက flow တွေမှာ screen reader — VoiceOver၊ TalkBack နဲ့ NVDA — နဲ့ manual testing လုပ်ပါ။ Team ကို လေ့ကျင့်ပေး၊ accessibility bug တွေကို တခြား bug တွေလို ခြေရာခံပြီး ကိုယ့် ဥပဒေရေးရာ လိုအပ်ချက်တွေ (ဈေးကွက်အများစုမှာ WCAG 2.2 AA လို) ကို သိထားပါ။

မဆောက်ခင် အောင်မြင်မှုဆိုတာ ဘာလဲ၊ ဘယ်လို တိုင်းမလဲ ဆုံးဖြတ်ပါ — အဓိက metric (conversion၊ retention၊ task ပြီးဆုံးချိန်) နဲ့ guardrail metric တွေ (error၊ crash rate၊ performance)။ Web နဲ့ mobile မှာ မျှသုံးတဲ့ event နာမည်ပေး အစီအစဉ်နဲ့ analytics event တွေကို တသမတ်တည်း instrument လုပ်၊ A/B test ဒါမှမဟုတ် တဖြည်းဖြည်း rollout နှိုင်းယှဉ်မှုအတွက် feature flag သုံးပြီး release ပြီးနောက် product နဲ့ ရလဒ်တွေကို review လုပ်ပါ — ပြီးရင် ဆက်ပြင်ပါ၊ မအထောက်အကူဖြစ်ရင် feature ကို ဖယ်ပါ။

ကောင်းတဲ့ ဆုံးဖြတ်ချက်တွေ ချနိုင်ပြီး ယုံကြည်မှု ထိန်းထားနိုင်လောက်အောင် နည်းပညာပိုင်း ဆက်ရှိနေပါ၊ ဒါပေမဲ့ meeting တွေထဲ ရောက်နေချိန်မှာ team ကို ပိတ်ဆို့မယ့် critical-path task တွေကို မပိုင်ပါနဲ့။ Lead အတွက် ကောင်းတဲ့ coding အလုပ်တွေက prototype နဲ့ spike၊ အခြေခံ အလုပ် (tooling၊ shared library)၊ နာကျင်စရာ နေရာတွေကို ပြင်တာနဲ့ review တွေပါ။ Calendar မှာ focus time ပိတ်ထား၊ တခြားသူတွေ ကြီးထွားနိုင်မယ့် အလုပ်တွေကို လွှဲအပ်ပြီး ပိုခက်တဲ့ leadership အလုပ်ကို ရှောင်ဖို့ code ရေးနေမိတဲ့အခါ သတိပြုပါ။

ပြတ်ပြတ် "no" အစား "no, but" ဒါမှမဟုတ် "yes, if" လို့ ပြောပါ — trade-off ကို ရှင်းရှင်းရှင်းပြပြီး ရွေးချယ်စရာတွေ ပေးပါ — version သေးသေး၊ နောက်ကျတဲ့ ရက်စွဲ ဒါမှမဟုတ် နေရာရဖို့ ဘာကို ရပ်မလဲ။ ကိုယ့်သဘောကျမှုပေါ် မဟုတ်ဘဲ မျှသုံးတဲ့ ရည်မှန်းချက်နဲ့ data ပေါ် အခြေခံပါ။ Business အတွက် တကယ်အရေးကြီးရင် team ကို တိတ်တဆိတ် ဝန်ပိမယ့်အစား ဦးစားပေး ပဋိပက္ခကို ပွင့်ပွင့်လင်းလင်း escalate လုပ်ပြီး သင့်တော်တဲ့ လူတွေကို ဆုံးဖြတ်ခိုင်းပါ။

Team နဲ့အတူ အန္တရာယ်တွေကို စောစော ဖော်ထုတ်ပါ — နည်းပညာ မသိသေးတာတွေ၊ တခြား team ဒါမှမဟုတ် vendor တွေအပေါ် မှီခိုမှု၊ app store review၊ data migration၊ performance နဲ့ လူ ရရှိနိုင်မှု — ပြီးတော့ ဖြစ်နိုင်ခြေနဲ့ သက်ရောက်မှုအလိုက် အဆင့်သတ်မှတ်ပါ။ အကြီးဆုံး မသိသေးတာတွေကို spike နဲ့ prototype နဲ့ အရင်ကိုင်တွယ်၊ ကာကွယ်ချက်နဲ့ အရန်အစီအစဉ်တွေ ထည့်ပြီး planning မှာ review လုပ်တဲ့ မြင်သာတဲ့ risk list ထားပါ။ ထိပ်ဆုံး အန္တရာယ်တွေကို ပြဿနာ မဖြစ်ခင် stakeholder တွေနဲ့ မျှဝေပါ။

Code နဲ့ နီးနီးမှာ documentation နည်းနည်းပေမဲ့ ပိုကောင်းတာ ရေးပါ — app နဲ့ package တစ်ခုချင်းအတွက် README၊ command တစ်ခုတည်းနဲ့ setup၊ diagram ပါတဲ့ architecture overview၊ ADR၊ operation အတွက် runbook နဲ့ onboarding guide။ Doc update လုပ်တာကို definition of done ရဲ့ အစိတ်အပိုင်း လုပ်၊ pull request တွေမှာ review လုပ်ပြီး ခေတ်နောက်ကျတဲ့ page တွေကို ဖျက်ပါ — မှားတဲ့ documentation က မရှိတာထက် ဆိုးပါတယ်။ ဝင်လာတဲ့ လူသစ်တိုင်းကို သူတို့ ရှုပ်ထွေးခဲ့တာကို ပြင်ခိုင်းပါ။

အရင်ဆုံး တစ်ယောက်ချင်းနဲ့ သီးသန့် စကားပြောပြီး သူတို့ အမြင်ကို နားလည်အောင်လုပ်ပါ၊ ပြီးမှ ပုဂ္ဂိုလ်ရေး မဟုတ်ဘဲ မျှသုံးတဲ့ ရည်မှန်းချက်နဲ့ တိကျတဲ့ အပြုအမူတွေကို အာရုံစိုက်ဖို့ နှစ်ယောက်ကို အတူခေါ်ပါ။ ပဋိပက္ခက ownership မရှင်းတာကနေ လာရင် role နဲ့ ဆုံးဖြတ်ချက်ချပုံကို ရှင်းပါ။ ခိုင်မာတဲ့ အလုပ်လုပ်ပုံတွေကို သဘောတူ၊ follow up လုပ်ပြီး တိုးတက်မှုတွေကို အသိအမှတ်ပြုပါ။ အပြုအမူက နယ်နိမိတ် ကျော်သွားရင် — မလေးစားမှု၊ နှောင့်ယှက်မှု — ချက်ချင်း အရေးယူပြီး ကိုယ့် manager ဒါမှမဟုတ် HR ကို ပါဝင်စေပါ။

အလုပ်ကို သူ့သက်ရောက်မှုနဲ့ ချိတ်ပါ — user feedback၊ metric နဲ့ team ship လုပ်ခဲ့တာတွေရဲ့ ဇာတ်လမ်းတွေကို မျှဝေပါ။ ပြဿနာတွေကို ဘယ်လို ဖြေရှင်းမလဲမှာ လွတ်လပ်ခွင့်၊ skill အသစ်တွေ ကျွမ်းကျင်ဖို့ အခွင့်အလမ်း (ဥပမာ web developer ကို mobile သင်ခွင့်ပေးတာ) နဲ့ ရေရှည်ထိန်းနိုင်တဲ့ အရှိန်ကို ပေးပါ။ အောင်မြင်မှုတွေနဲ့ သင်ယူမှုတွေကို ဂုဏ်ပြု၊ နှေးတဲ့ build နဲ့ flaky test လို စိတ်ပျက်စရာ friction တွေ ဖယ်ရှားပြီး ခက်ခဲတဲ့ သတင်းတွေကို ရိုးရိုးသားသား ပြောပါ။ ကိုယ့်အလုပ် အရေးမပါဘူး ဒါမှမဟုတ် ကိုယ့်စကား ဘယ်သူမှ နားမထောင်ဘူးလို့ ခံစားရတဲ့အခါ စိတ်အားထက်သန်မှု အမြန်ဆုံး ကျပါတယ်။

တကယ့် အကျိုးဆက်တွေပါတဲ့ တကယ့် ကျရှုံးမှုကို ရွေးပြီး ကိုယ့်အပိုင်းကို ကိုယ်တိုင် တာဝန်ယူပါ။ ဥပမာ — store review နဲ့ payment-provider certification အတွက် အချိန်မချန်ဘဲ mobile checkout အသစ်ရဲ့ launch ရက်ကို သဘောတူခဲ့ပြီး နှစ်ပတ် လွဲသွားခဲ့တယ်။ ပြန်ကောင်းအောင် ဘာလုပ်ခဲ့လဲ (ရွေးချယ်စရာတွေနဲ့ ပြန်စီစဉ်၊ စောစော ဆက်သွယ်ပြော၊ web ကို အရင် ship) နဲ့ နောက်ပိုင်း ဘာပြောင်းခဲ့လဲ (အခု ပြင်ပ မှီခိုမှုတွေပါ ပါဝင်တဲ့ release checklist နဲ့ risk review) ကို ရှင်းပြပါ။ Interviewer တွေက ပြီးပြည့်စုံတဲ့ မှတ်တမ်းထက် ကိုယ့်ကိုယ်ကို သိမြင်မှုကို ပိုတန်ဖိုးထားပါတယ်။

ယုံကြည်ရတဲ့ source အနည်းငယ်ကို လိုက်ပါ — ကိုယ့် core stack (React၊ React Native၊ Flutter၊ Node.js၊ ကိုယ့် database) ရဲ့ တရားဝင် release note တွေ၊ newsletter နဲ့ conference talk အနည်းငယ် — ပြီးတော့ သင်ယူတာတွေကို team ထဲ မျှဝေပါ။ Tool အသစ်တွေကို တကယ့်ပြဿနာတစ်ခုပေါ်မှာ အချိန်ကန့်သတ်ထားတဲ့ spike နဲ့ ရှင်းလင်းတဲ့ စံနှုန်းတွေနဲ့ အကဲဖြတ်၊ အန္တရာယ်နည်းတဲ့ နေရာတွေမှာ အရင် ယူသုံးပြီး ဘာကို adopt၊ trial၊ assess ဒါမှမဟုတ် hold လုပ်မလဲဆိုတဲ့ technology radar ထားပါ။

ပထမ ရက် 30 — နားထောင်ပြီး သင်ယူပါ — engineer တိုင်း၊ product နဲ့ design partner တွေနဲ့ one-to-one၊ web၊ mobile နဲ့ API အတွက် code၊ architecture၊ incident နဲ့ release process တွေကို ဖတ်ပြီး ပြောင်းလဲမှု သေးသေးလေးတစ်ခု ကိုယ်တိုင် ship လုပ်ပါ။ ရက် 30–60 — မြင်သာတဲ့ နာကျင်စရာ အနည်းငယ် (နှေးတဲ့ CI job၊ ဆူညံတဲ့ alert၊ နာကျင်စရာ release အဆင့်) ကို ပြင်ပြီး team နဲ့ အလုပ်လုပ်ပုံ သဘောတူညီချက်တွေ ချပါ။ ရက် 60–90 — delivery၊ reliability၊ architecture နဲ့ လူတွေ ကြီးထွားမှုကို ဖုံးတဲ့၊ team နဲ့ stakeholder တွေနဲ့ ညှိထားတဲ့ ရေးသားထားတဲ့ နည်းပညာ strategy နဲ့ roadmap ကို မျှဝေပါ။