At intern level nobody expects production experience. Interviewers want to see that your fundamentals are solid — how the web works, semantic HTML, the CSS layout model and core JavaScript — and that you can explain what you know clearly and say "I'm not sure, but here's how I'd find out" when you don't.

The browser resolves the domain to an IP address through DNS, opens a TCP connection (plus a TLS handshake for HTTPS) and sends an HTTP request. The server answers with HTML, which the browser parses into the DOM while fetching CSS, JavaScript and images it references. It then builds the CSSOM, computes layout, paints pixels and composites them on screen.

GET reads a resource, POST creates one or triggers an action, PUT replaces a resource, PATCH updates part of it and DELETE removes it. GET, PUT and DELETE are meant to be idempotent — repeating them has the same effect as doing them once — while POST is not.

The first digit tells you the category of the response.

HTTPS is HTTP sent over an encrypted TLS connection. It keeps data private, protects it from being changed in transit and proves the server's identity with a certificate. Browsers mark HTTP pages as not secure, and many modern features (service workers, geolocation, camera) only work over HTTPS.

Semantic HTML means choosing elements for their meaning — <header>, <nav>, <main>, <article>, <button> — instead of generic <div>s for everything. It gives screen readers a structure to navigate, helps search engines understand the page and makes the code easier to read. A <button> is also focusable and keyboard-operable for free, which a clickable <div> is not.

Block elements (<div>, <p>, <h1>) start on a new line and stretch to the full width of their container; they accept width, height and vertical margins. Inline elements (<span>, <a>, <strong>) flow within a line of text and ignore width and height. inline-block sits in the line like inline but accepts box dimensions like block.

alt text describes an image for screen-reader users and appears if the image fails to load; decorative images should use an empty alt="" so they are skipped. A <label> tied to an input (with for and id, or by wrapping it) tells assistive technology what the field is, and clicking the label focuses the input — a bigger target for everyone.

<meta name="viewport" content="width=device-width, initial-scale=1"> tells mobile browsers to use the device's real width instead of pretending to be a ~980px desktop screen and zooming out. Without it, media queries and responsive layouts don't behave as expected on phones. You should never disable user zoom with it.

A plain <script> blocks HTML parsing while it downloads and runs. async downloads in parallel and runs as soon as it arrives, in any order — good for independent scripts like analytics. defer downloads in parallel but runs in order after the HTML is parsed, which is usually what you want for app code. type="module" scripts are deferred by default.

Accessibility (a11y) means people with disabilities — visual, motor, hearing or cognitive — can use your site. Basics you can apply on day one:

Every element is a rectangular box made of four layers: the content, then padding around it, then the border, then the margin outside that separates it from other boxes. Width and height normally apply only to the content area, so padding and border are added on top — unless you change box-sizing.

With border-box, the width and height you set include padding and border, so a 200px wide box stays 200px no matter how much padding you add. Most projects apply it globally because it makes sizing predictable.

When several rules target the same element, the browser picks the one with the highest specificity: inline styles beat IDs, IDs beat classes/attributes/pseudo-classes, and those beat element selectors. If specificity is equal, the rule that comes later wins. !important overrides normal rules and should be a last resort because it makes styles hard to override later.

The cascade is the algorithm that decides which declaration wins when several apply. It considers origin and importance (user-agent, user, author, !important), cascade layers, specificity, and finally source order. Inheritance is separate: some properties like color and font pass from parent to child by default, while others like margin do not.

Each value changes how an element is placed.

display: none removes the element from the layout entirely — it takes no space and is hidden from screen readers. visibility: hidden hides it visually but it still occupies its space. To hide something visually but keep it available to screen readers, use a "visually hidden" (sr-only) utility class instead.

Flexbox is one-dimensional: it lays items out in a row or a column and is great for navbars, button groups and aligning items inside a component. Grid is two-dimensional: rows and columns at once, ideal for page layouts and card grids. They work well together — a Grid page layout with Flexbox inside each card.

The simplest modern ways are Flexbox or Grid on the parent. For a single child, Grid's place-items: center is the shortest. For absolutely positioned elements you can use inset: 0 with margin: auto and a fixed size.

px is a fixed unit. em is relative to the element's own font size (or its parent's for font-size), so it compounds when nested. rem is relative to the root <html> font size, which makes it predictable and respects the user's browser settings. % is relative to the parent, and vw/vh are 1% of the viewport width or height.

Responsive design makes one layout adapt to any screen size using fluid widths, flexible images and media queries. Mobile-first means you write the base styles for small screens, then add min-width media queries to enhance the layout as space grows. It keeps the base CSS simple and makes you prioritise the most important content.

A pseudo-class selects an element in a particular state — :hover, :focus-visible, :nth-child(2), :disabled. A pseudo-element styles a part of an element or inserts generated content — ::before, ::after, ::placeholder, ::first-line. Pseudo-classes use one colon, pseudo-elements use two.

There are seven primitive types — string, number, bigint, boolean, undefined, null and symbol — and one non-primitive type, object, which includes arrays, functions, dates and so on. Primitives are immutable and compared by value; objects are compared by reference. Note the historical quirk: typeof null returns "object".

=== (strict equality) compares value and type with no conversion, so 1 === "1" is false. == (loose equality) converts types first, so 1 == "1" is true and 0 == "" is true, which causes subtle bugs. Use === by default; the one common exception some teams allow is value == null to check for both null and undefined.

var is function-scoped, hoisted and initialised to undefined, and can be redeclared. let and const are block-scoped and can't be used before their declaration. const can't be reassigned — but the object it points to can still be mutated. Prefer const by default and use let only when the value must change.

Before code runs, JavaScript registers declarations in their scope. Function declarations are hoisted completely, so you can call them before they appear. var is hoisted but set to undefined. let, const and class are hoisted too but stay in the "temporal dead zone" until their line runs, so touching them early throws a ReferenceError.

Scope decides where a variable can be accessed. There is global scope, function scope and block scope (anything inside {} for let/const). Scopes are nested lexically — inner code can read variables from outer scopes, but not the other way around. This chain of lookups is called the scope chain.

A closure is a function that remembers the variables from the scope where it was created, even after that outer function has finished. It's how you get private state and factories in JavaScript, and it's behind callbacks, event handlers and React hooks.

this is decided by how a function is called, not where it's written. As a method (obj.fn()) it's the object; as a plain call it's undefined in strict mode (the global object otherwise); with new it's the new instance; and call, apply and bind set it explicitly. Arrow functions don't have their own this — they use the this of the surrounding scope.

Arrow functions are shorter and have no own this, arguments or super — they inherit them from the enclosing scope, which is why they're handy for callbacks. They can't be used as constructors with new, and they have no prototype. Don't use them as object methods that need this to point at the object.

All three loop over an array and return a new value without mutating the original. map transforms each item into a new array of the same length, filter keeps the items that pass a test, and reduce combines all items into a single value such as a sum or an object.

Both use .... Spread expands an iterable or object into individual elements — copying arrays, merging objects, passing array items as arguments. Rest does the opposite: it collects the remaining items into an array, in function parameters or destructuring.

Destructuring pulls values out of arrays or properties out of objects into variables in one line. You can rename, set defaults and nest. It's especially common in function parameters and React props.

In a boolean context JavaScript converts every value to true or false. The falsy values are false, 0, -0, 0n, "", null, undefined and NaN; everything else is truthy — including "0", [] and {}. This is why if (items.length) works but if (items) is always true for an array.

undefined means a value hasn't been assigned — an uninitialised variable, a missing property or a function with no return. null is an intentional "no value" that a developer sets. null == undefined is true but null === undefined is false. The ?? operator treats both as "missing".

Template literals are strings written with backticks. They support interpolation with ${expression}, multi-line strings without \n, and tagged templates where a function processes the parts (used by libraries like styled-components and GraphQL clients).

A callback is a function passed to another function to be called later — when an event fires, a timer ends or data arrives. Array methods like map take callbacks too. Deeply nested asynchronous callbacks ("callback hell") are hard to read, which is one reason promises and async/await were introduced.

A Promise represents a value that will be available later. It starts pending and settles once as either fulfilled with a value or rejected with an error. You handle results with .then(), errors with .catch() and cleanup with .finally(), and you can chain them instead of nesting callbacks.

An async function always returns a Promise. Inside it, await pauses that function until a Promise settles, letting you write asynchronous code that reads top to bottom. Errors from awaited Promises are thrown, so you handle them with try/catch.

Call fetch(url, options), await the response, check res.ok, then parse it with res.json(). One common gotcha: fetch only rejects on network failure — a 404 or 500 still resolves, so you must check the status yourself. For POST requests, set the method, a Content-Type header and a JSON body.

JSON.stringify turns a JavaScript value into a JSON string — for sending to an API or saving in localStorage. JSON.parse turns a JSON string back into a value. JSON can't represent functions, undefined, Date objects (they become strings) or circular references, and JSON.parse throws on invalid input, so wrap untrusted data in try/catch.

The DOM (Document Object Model) is the browser's tree of objects representing the page, which JavaScript can read and change. You select elements with document.querySelector / querySelectorAll, then change them with properties like textContent, classList and setAttribute, or create new ones with createElement and append.

textContent reads or sets plain text, so any < characters stay as text. innerHTML parses a string as HTML. Setting innerHTML with user input is dangerous because it can inject scripts (XSS) — use textContent for text, and only use innerHTML with trusted or sanitised content.

Attach a listener with element.addEventListener("click", handler). The handler receives an event object with details like target and key. You can stop default browser behaviour with event.preventDefault() (for example, a form submitting) and remove the listener later with removeEventListener using the same function reference.

When an event fires on an element, it bubbles up through its ancestors, triggering their listeners too. Event delegation uses this: instead of a listener on every list item, you put one on the parent and check event.target. It's efficient and works for items added later.

All three store data in the browser, but differently.

Synchronous code runs line by line, and each line waits for the previous one to finish. Asynchronous code starts a task — a network request, a timer — and lets the rest of the program keep running, handling the result later through callbacks, promises or await. Because JavaScript runs on a single main thread, async code keeps the page responsive.

A typical day uses a small set of commands.

npm is Node's package manager for installing libraries and running scripts. package.json lists your dependencies (with version ranges), dev dependencies and scripts like dev and build. The lock file (package-lock.json, pnpm-lock.yaml, bun.lock) records the exact versions installed so every machine and the CI get the same tree.

The Elements panel inspects and live-edits HTML and CSS, including computed styles and the box model. The Console shows errors and lets you run code. Sources lets you set breakpoints and step through JavaScript. Network shows every request with status, timing and payload, and Lighthouse/Performance help with speed and accessibility.

Start with the official docs and build something tiny that uses the core idea, rather than watching hours of tutorials. Read error messages carefully, search them, and check how others solved the same problem. When stuck for a while, ask a specific question with what you tried — interviewers value a clear learning process more than knowing everything already.

A mid-level developer ships features on their own. Interviewers dig into how JavaScript really works under the hood, how you structure React components and state, and whether you think about performance, security, accessibility and tests as part of the job — not as extras. Expect "why" and "what are the trade-offs" after every answer.

JavaScript runs on one thread with a call stack. Async work — timers, network, events — is handled by the browser, and when it's done its callback is queued. The event loop takes a task from the queue only when the call stack is empty, then runs all queued microtasks (promise callbacks) before the next task or a render. That's why a long synchronous loop freezes the page.

Macrotasks (just "tasks") include setTimeout, setInterval, I/O and UI events. Microtasks include promise .then callbacks, await continuations and queueMicrotask. After each task, the engine drains the entire microtask queue before moving on, so microtasks always run first.

Closures power data privacy, memoisation and once-only functions. The classic bug is using var in a loop with async callbacks: every callback shares one function-scoped variable and sees its final value. let creates a fresh binding per iteration and fixes it.

Every object has an internal link to another object, its prototype. When you read a property that isn't on the object, JavaScript walks up this prototype chain until it finds it or reaches null. class syntax is sugar over this: methods live on ClassName.prototype and instances link to it.

All three set this explicitly. call(thisArg, a, b) invokes the function immediately with arguments listed; apply(thisArg, [a, b]) does the same with an array; bind(thisArg) returns a new function with this permanently fixed, which is useful for callbacks and event handlers.

All take an array of promises but resolve differently.

Wrap awaited calls in try/catch at the level where you can actually do something — show a message, retry or fall back — rather than swallowing errors everywhere. Remember that fetch doesn't reject on HTTP errors, so check res.ok. Add a global handler (unhandledrejection, an error boundary or monitoring) for anything that slips through.

Awaiting independent requests one after another makes their times add up. If they don't depend on each other, start them together and await them with Promise.all, so the total time is the slowest request rather than the sum.

Both limit how often a function runs during rapid events. Debounce waits until the events stop for a set time, then runs once — ideal for search-as-you-type. Throttle runs at most once per interval while events continue — ideal for scroll or resize handlers.

A shallow copy ({...obj}, [...arr], Object.assign) copies only the top level; nested objects are still shared, so changing them affects both. A deep copy duplicates everything. Use the built-in structuredClone(obj) for deep copies — it handles dates, maps, sets and cycles, unlike the old JSON.parse(JSON.stringify()) trick.

CommonJS (require/module.exports) is Node's original, synchronous system. ES modules (import/export) are the standard: they're static, so bundlers can tree-shake unused code, they support top-level await, and they work natively in browsers. New code should use ES modules.

When you create new objects instead of mutating existing ones, change detection becomes a cheap reference check (prev !== next). React, Redux and memoisation all rely on this, so mutating state in place leads to UI that doesn't update. It also makes code easier to reason about and enables features like undo.

Both describe object shapes and are mostly interchangeable. Interfaces can be extended with extends and merged by declaring them twice, which suits public APIs. Type aliases can also express unions, intersections, tuples and mapped or conditional types. Many teams use type by default and interface for extendable object contracts.

Generics let you write a function or type that works with many types while keeping the link between input and output. Instead of returning any, a generic function returns exactly the type it was given.

Narrowing is TypeScript refining a broad type to a specific one inside a branch, using checks like typeof, instanceof, in or comparing a discriminant field. A custom type guard is a function returning value is Type, which teaches the compiler your own check.

any turns type checking off — you can do anything with it, and errors slip through silently. unknown means "could be anything" but forces you to narrow it before use. Use unknown for untrusted data like JSON.parse results or caught errors, and validate it (for example with Zod).

Built-in utility types transform existing types instead of rewriting them.

When state changes, React re-renders the component to get a new element tree and compares it with the previous one — reconciliation. Elements of a different type are replaced; elements of the same type keep their DOM node and only changed props are applied. Then React commits the minimal set of DOM changes.

Keys tell React which item is which between renders so it can keep the right state and DOM node for each one. If you use the array index and the list is reordered, filtered or has items inserted, state (like input text or checkbox state) attaches to the wrong item. Use a stable, unique id from your data.

A controlled input gets its value from React state and updates it through onChange, so React is the single source of truth — good for validation and dependent fields. An uncontrolled input keeps its own value in the DOM and you read it with a ref or FormData on submit, which is simpler and faster for big forms. React 19 form Actions make the uncontrolled approach very convenient.

Most bugs come from using effects for things that aren't side effects.

Return a function from the effect. React runs it before the effect runs again (when dependencies change) and when the component unmounts. In development Strict Mode, React deliberately mounts, cleans up and mounts again to catch missing cleanups.

useMemo caches an expensive computed value, useCallback caches a function identity, and React.memo skips re-rendering a component when its props haven't changed. They only help when something actually depends on reference equality or the work is measurably expensive, so profile first. The React Compiler can now add most of this memoisation automatically.

useRef gives you a mutable box (ref.current) that survives re-renders without causing one when it changes. Use it to reach DOM nodes (focus an input, measure size), and to keep values like timer ids or the previous value that shouldn't trigger a render. Don't read or write refs during render for anything that affects output.

Every component that reads a context re-renders whenever its value changes, so one big context with frequently changing data can re-render large parts of the app. Split contexts by how often they change, memoise the value object, keep fast-changing state local, or use a store with selectors (Zustand, Redux) for global state that changes often.

A custom hook is a function starting with use that calls other hooks to package reusable stateful logic — useDebounce, useMediaQuery, useFetch. Write one when two components share the same logic, or to give a complex component's logic a clear name. Each component calling the hook gets its own independent state.

When two sibling components need the same data, you move that state to their closest common parent and pass it down as props, with callbacks to change it. It keeps a single source of truth. If you end up passing props through many layers, consider composition (passing components as children) or context.

Start with local state and lift it only as far as needed. Server data belongs in a data-fetching cache like TanStack Query or SWR, not a global store. URL state (filters, tabs, pages) belongs in the URL. Reach for a global store such as Zustand or Redux Toolkit only for genuinely shared client state like a cart, auth session or editor state.

Hand-written effect fetching misses a lot: caching, deduplicating identical requests, retries, background refetching, stale-while-revalidate, pagination and race conditions. A server-state library handles all of that, gives you isLoading/isError states and makes mutations with cache invalidation straightforward.

An error boundary is a component that catches errors thrown while rendering its children and shows a fallback UI instead of unmounting the whole app. It doesn't catch errors in event handlers or async code — handle those with try/catch. Libraries like react-error-boundary provide a ready-made component with reset support.

Pick one approach and use it consistently: a naming convention like BEM, scoped CSS Modules, utility-first Tailwind, or CSS-in-JS. Build on design tokens (CSS custom properties) for colours, spacing and type. Modern CSS helps too — cascade layers (@layer) control order, and :where() keeps specificity low.

Pros: fast to build with, a consistent design scale, no naming, tiny production CSS and styles that live next to the markup. Cons: long class lists that can hurt readability, a learning curve, and complex states or animations can be awkward. Extracting components (not @apply everywhere) keeps it maintainable.

z-index only compares elements within the same stacking context. Properties like position with a z-index, opacity below 1, transform, filter and isolation: isolate create a new context, and children can never escape their parent's context no matter how high their z-index. Check the ancestors, not just the element.

Use srcset with width descriptors and sizes so the browser downloads the right size for the screen, and <picture> for art direction or modern formats like AVIF and WebP with fallbacks. Always set width and height (or aspect-ratio) to avoid layout shift, and lazy-load images below the fold.

Google's three user-centred metrics, measured on real users at the 75th percentile.

Code splitting breaks the JavaScript bundle into chunks so users download only what the current page needs. In React you split with React.lazy plus Suspense or a framework's dynamic import, typically per route or for heavy, rarely used components like charts and editors. Images and iframes can be lazy-loaded with loading="lazy".

Cache-Control tells browsers and CDNs how long to keep a response. Hashed static files (app.3f9a.js) can be cached for a year with immutable, because a new build gets a new filename. HTML should be revalidated — no-cache with an ETag lets the browser get a cheap 304 Not Modified when nothing changed.

CORS is a browser rule that blocks a page from reading responses from another origin unless that server allows it with headers like Access-Control-Allow-Origin. Requests with custom headers or methods first send an OPTIONS preflight. The fix belongs on the server (or a proxy/BFF on your own origin) — the front end alone can't bypass it.

Cross-site scripting is when attacker-controlled input runs as script in your page, letting it steal sessions or act as the user. Frameworks like React escape text by default, so the risks are dangerouslySetInnerHTML, innerHTML, href="javascript:..." and unsafe third-party HTML. Sanitise any HTML you must render (DOMPurify), and add a Content Security Policy as a second layer.

Cross-site request forgery tricks a logged-in user's browser into sending a request to your site from another site, riding on their cookies. Defences are SameSite=Lax or Strict cookies, anti-CSRF tokens for state-changing requests, checking the Origin header, and never changing data on GET requests.

The first rule of ARIA is: don't use it if a native element does the job — a <button> beats <div role="button">. Use ARIA to fill real gaps: aria-label for icon-only buttons, aria-expanded and aria-controls for disclosures, aria-live for announcements and correct roles for custom widgets like tabs or comboboxes. Wrong ARIA is worse than none.

When the modal opens, move focus into it; trap Tab and Shift+Tab inside it; close it on Escape; and return focus to the button that opened it when it closes. The native <dialog> element with showModal() handles most of this, including making the page behind it inert.

Unit tests check one function or component in isolation and are fast. Integration tests check several pieces working together — a form with validation and an API mock. End-to-end tests drive a real browser through a full user flow and are slow but give the most confidence. A healthy suite has many fast tests and a few critical E2E flows.

"The more your tests resemble the way your software is used, the more confidence they give you." So you query the screen the way users and assistive tech do — getByRole, getByLabelText, getByText — interact with user-event, and assert on visible output, not internal state or implementation details. Tests then survive refactors.

Mock at the network level rather than mocking fetch or your API module, so your real data-fetching code runs. Mock Service Worker (MSW) intercepts requests in tests and in the browser and returns fixtures you define, letting you test loading, success and error states realistically.

A bundler (Vite, webpack, Rspack, Turbopack) follows your imports, transforms code (TypeScript, JSX, modern syntax), bundles modules into optimised chunks and handles CSS and assets. Tree shaking removes exports nobody imports; it works with ES modules and side-effect-free packages, so prefer named imports from libraries that support it.

Offset pagination (?page=3) is simple but can skip or repeat items when data changes. Cursor pagination (?after=abc) is stable and suits infinite feeds. For infinite scroll, use an IntersectionObserver on a sentinel element to load the next page, keep a visible "Load more" fallback, and virtualise very long lists.

Use native HTML validation attributes (required, type="email", pattern) as a base, validate with a schema (Zod, Valibot) shared with the server if possible, and show errors next to the field after the user leaves it, not on every keystroke. Always validate again on the server, since client checks can be bypassed.

Both bring changes from one branch into another. merge adds a merge commit and keeps the true history; rebase replays your commits on top of the target for a linear history. Rebasing your own feature branch before a pull request keeps history clean, but never rebase shared commits that others have pulled.

Keep it small and focused on one change, with a clear title and description of what and why, screenshots for UI changes and notes on how it was tested. Self-review the diff first, make sure CI passes, and respond to review comments with reasons rather than defensiveness.

Senior interviews move from "how does this work" to "how would you design, measure and fix it". Expect open questions about rendering strategies, performance at scale, security, testing strategy and system boundaries. Good answers name the trade-offs, say what you would measure, and show you have hit these problems in production.

HTML is parsed into the DOM and CSS into the CSSOM; together they form the render tree. Style resolves computed styles, Layout calculates each box's geometry, Paint records drawing commands into layers, and Composite assembles those layers on the GPU. Changing geometry re-runs layout and paint; changing only transform or opacity can skip straight to compositing.

Layout thrashing is forcing the browser to recalculate layout repeatedly in one frame by alternating DOM writes and layout reads such as offsetHeight or getBoundingClientRect. Batch all reads first, then all writes, or schedule writes in requestAnimationFrame.

Animate only transform and opacity, which the compositor can handle off the main thread, instead of width, top or box-shadow. Use CSS transitions, the Web Animations API or requestAnimationFrame, never setInterval. Apply will-change sparingly to elements about to animate, and respect prefers-reduced-motion.

Each strategy trades freshness, speed and server cost differently.

Hydration is the client re-running component code over server-rendered HTML to attach event handlers and state. Until it finishes, the page looks ready but may not respond, which hurts INP. Costs grow with the amount of JavaScript and components; remedies include shipping less client code (Server Components, islands), streaming with Suspense so parts hydrate independently, and lazy-loading below-the-fold widgets.

They happen when the HTML rendered on the server differs from the client's first render — using Date.now(), Math.random(), window or localStorage during render, locale-dependent formatting, or invalid HTML nesting like a <div> inside a <p>. Render the same thing on both sides, and move browser-only values into an effect or useSyncExternalStore with a server snapshot.

Server Components run only on the server (at build or request time), can read databases or secrets directly, and send their rendered result to the client with zero JavaScript for themselves. Client Components, marked with "use client", are the interactive leaves. The skill is drawing the boundary: keep data-heavy, static parts on the server and push interactivity down into small client components.

Props passed from a Server Component to a Client Component must be serialisable: plain objects, arrays, strings, numbers, dates, promises and JSX. Functions can't be passed unless they are Server Actions marked "use server". A Client Component can't import a Server Component, but it can receive one as children, which keeps server-rendered content inside interactive wrappers.

The server sends the page shell immediately, with Suspense fallbacks where slow data is still loading. As each piece of data resolves, React streams the finished HTML into the same response and swaps it in, then hydrates sections independently. Users see content sooner and slow queries no longer block the whole page.

They mark some updates as non-urgent so React can keep urgent ones — typing, clicking — responsive. startTransition wraps a state update (like switching a tab or filtering a big list) so it can be interrupted; useDeferredValue lets a heavy part of the UI lag behind a fast-changing value. Both are tools for improving INP.

React 19 made async UI first-class.

Update the UI immediately as if the request succeeded, send the request, and roll back with an error message if it fails. In React 19, useOptimistic keeps the temporary state tied to the pending action and drops it automatically when the action settles; TanStack Query supports the same pattern with onMutate and rollback in onError.

Find the LCP element in field data or DevTools, then break the time into phases: server response (TTFB), resource load delay, load time and render delay. Typical fixes: make the LCP image discoverable in the HTML (not lazy-loaded, fetchpriority="high", preloaded if needed), serve it in modern formats at the right size, reduce render-blocking CSS and JS, and cache HTML at the CDN.

INP measures the delay from a user interaction to the next frame. Break long tasks so the main thread can respond (scheduler.yield() or chunking), do the minimum work before painting feedback, move heavy computation to a Web Worker, cut hydration and third-party script cost, and avoid large synchronous re-renders — transitions help in React. Measure with real-user data and the Performance panel.

CLS comes from content that moves after first paint: images and embeds without dimensions, ads and banners inserted above content, web fonts swapping with different metrics, and content injected late. Reserve space with width/height or aspect-ratio, use skeletons of the right size, match fallback font metrics (size-adjust), and animate with transform rather than layout properties.

Run a bundle analyser (rollup-plugin-visualizer, webpack-bundle-analyzer, or your framework's) to see each module's size, and check what lands in the first-load chunk. Common culprits are whole-library imports, moment-style date libraries, duplicated versions of a dependency and polyfills for browsers you don't support. Add a size budget to CI so regressions fail the build.

Reproduce the suspect flow several times, take heap snapshots in DevTools and compare them to see which objects keep growing, then follow their retainers. Usual causes are event listeners, intervals and subscriptions that are never cleaned up, detached DOM nodes still referenced from JavaScript, unbounded caches and closures holding large objects.

For CPU-heavy work that would otherwise block the main thread: parsing large files, image processing, search indexing, diffing or complex calculations. Workers can't touch the DOM and communicate by messages, so the data copied back and forth matters — use transferable objects for big buffers, and a helper like Comlink to make the API feel like normal function calls.

A service worker is a script that sits between your app and the network: it can cache assets for offline use, apply caching strategies, handle push notifications and background sync. The risk is caching too aggressively — users can get stuck on an old version — so version your caches, choose strategies carefully and have a plan to update or unregister.

These are caching strategies for service workers and data layers.

Make the common case simple and the rare case possible. Prefer composition (children, compound components like <Tabs.List>) over long lists of boolean props, support both controlled and uncontrolled use, forward refs and extra HTML attributes, and keep names consistent across the library. Accessibility — keyboard support and roles — must be built in, not optional.

Start from design tokens (colour, spacing, type, radius, motion) as the single source of truth, then build accessible primitives and compose larger components from them. Document every component with live examples (Storybook), test visually and for accessibility, version it with semantic versioning and changelogs, and treat product teams as customers with a contribution process.

Build it into the system rather than auditing at the end: accessible components in the design system, linting (eslint-plugin-jsx-a11y), automated checks with axe in unit and E2E tests, and keyboard plus screen-reader testing of key flows. Automated tools catch only part of the issues, so include manual audits and clear ownership in the definition of done.

Server state is a cached copy of data owned by the backend — it can be stale, shared and refetched — so it belongs in a query cache (TanStack Query, SWR, RTK Query, or the framework's server data layer). Client state is owned by the UI: open panels, form drafts, selections. Mixing them in one global store creates manual cache-invalidation bugs.

When the same entities appear in several places — a user shown in a list, a sidebar and a detail page — store them once by id and reference them elsewhere, so one update reaches every view and there is no duplication. Redux Toolkit's createEntityAdapter helps. If a query cache already owns that data, normalisation is often unnecessary.

REST is simple, cacheable at the HTTP level and works for any client. GraphQL lets clients ask for exactly the fields they need across many resources, which suits complex UIs and many client types, at the cost of server complexity and harder caching. tRPC gives end-to-end type safety with almost no ceremony but only when client and server are both TypeScript in one codebase.

A BFF is a thin server layer owned by the front-end team that sits between the UI and backend services. It aggregates several calls into one, reshapes data for the screen, keeps secrets and tokens off the client, and handles auth cookies. It's worth it when the UI talks to many services or when different clients (web, mobile) need different shapes.

Prefer HttpOnly, Secure, SameSite cookies set by the server: JavaScript can't read them, so an XSS bug can't steal them. Storing tokens in localStorage exposes them to any injected script. If you must hold an access token in JavaScript, keep it short-lived in memory and refresh it through an HttpOnly refresh cookie.

Use short-lived access tokens and a refresh token in an HttpOnly cookie. When a request gets a 401, start one refresh and make all other failing requests wait for that same refresh promise, then retry them once with the new token. If the refresh fails, log the user out cleanly.

CSP is an HTTP header that tells the browser which sources of scripts, styles, images and connections are allowed, so injected scripts are blocked even if an XSS bug exists. A strict policy uses nonces or hashes for scripts (script-src 'nonce-…' 'strict-dynamic') instead of allow-listing domains. Roll it out in Report-Only mode first to find violations.

Beyond CSP, a few headers close common attack paths.

SRI adds an integrity hash to a <script> or <link> loaded from a CDN, and the browser refuses to run the file if its content doesn't match. It protects you if the third-party host is compromised. It only works for files that don't change, so use it with pinned versions.

Keep all user-facing text in message catalogues with keys and ICU message syntax for plurals and variables, never by concatenating strings. Format dates, numbers and currencies with the Intl APIs for the user's locale, plan for text that grows 30% or more and scripts like Burmese that need more line height, and set the lang attribute so fonts and screen readers behave.

Set dir="rtl" on the document, and use CSS logical properties — margin-inline-start, padding-inline, inset-inline-end, text-align: start — instead of left/right so the layout mirrors automatically. Mirror directional icons like arrows, but not things like play buttons or logos, and test with real RTL content.

Follow the "testing trophy": static analysis (TypeScript, ESLint) as the base, lots of integration tests for components and features, unit tests for tricky pure logic, and a small number of end-to-end tests on critical paths like sign-up and checkout. Add visual regression and accessibility checks for the design system, and keep the suite fast enough that people run it.

Use resilient, user-facing locators (roles, labels) instead of CSS selectors; rely on auto-waiting assertions instead of fixed sleeps; seed and isolate test data so tests don't depend on each other; mock only external third parties; and run in parallel with traces and videos on failure. Playwright is the common choice for these features.

It renders components or pages, takes screenshots and compares them with approved baselines, flagging pixel differences for review. It catches CSS regressions that functional tests miss. To reduce noise, run it in a consistent environment, freeze animations and dates, and focus on the design system and key pages.

On every pull request: install with a lock file, type-check, lint, run tests, build, check bundle size budgets and deploy a preview URL for review. On merge: deploy to production behind feature flags, with automatic rollback or quick redeploy if monitoring shows errors. Cache dependencies and builds so the pipeline stays fast.

Pros: shared code and types without publishing packages, atomic changes across apps and libraries, one set of tooling and consistent versions. Cons: CI can get slow without task caching and affected-only builds (Turborepo, Nx), ownership can blur, and repository size grows. It pays off when several apps share a lot of code.

They make sense when many independent teams must deploy parts of one large product separately — the benefit is organisational. The costs are real: duplicated dependencies and bigger bundles, inconsistent UX, shared-state and routing complexity, and harder testing. For most companies a well-structured monorepo with clear ownership is the simpler choice.

Use error tracking (Sentry or similar) with uploaded source maps so stack traces point to your real code, real-user monitoring (RUM) for Core Web Vitals by page and device, and logging of key business events. Tag everything with release version and set alerts on error rates and vitals regressions so you hear about problems before users report them.

Flags decouple deploying code from releasing a feature: you can merge unfinished work behind a flag, roll out to a percentage of users, run A/B tests and switch a feature off instantly without redeploying. The cost is complexity, so give every flag an owner and remove it once the rollout is complete.

A discriminated union is a union of object types that share a literal field, like status. Checking that field narrows the type, so impossible states — data and an error at once — can't be represented, and an exhaustive switch with a never check makes the compiler flag any case you forget.

A mapped type builds a new type by transforming each key of another type; a conditional type picks a type based on a test (T extends U ? X : Y) and can extract parts with infer. Together they power utilities like Partial and ReturnType.

Self-host WOFF2 files, subset them to the characters you need, preload only the one or two critical faces and use font-display: swap (or optional for non-essential fonts). Match the fallback font's metrics with size-adjust and ascent-override to avoid layout shift, and prefer variable fonts to many separate weights.

A CDN serves files from servers close to users, cutting latency, and absorbs traffic spikes. Cache hashed static assets for a long time, cache HTML briefly or with stale-while-revalidate and purge on deploy, and keep personalised responses private. Edge functions can also handle redirects, A/B splits and auth checks close to the user.

Virtualise it: render only the rows in and near the viewport and use spacers to keep the scrollbar correct (TanStack Virtual, react-window). Keep row components cheap and memoised, give rows stable keys, and avoid measuring layout on scroll. For simpler cases, CSS content-visibility: auto lets the browser skip rendering off-screen sections.

Split it into steps with their own validation using a shared schema, keep the data in one form store (React Hook Form or a reducer) rather than per-step state, and save drafts so a refresh doesn't lose work. Make it navigable by keyboard, announce errors to screen readers, allow going back without losing data and validate everything again on the server.

Choose the simplest transport that fits: polling for rare updates, Server-Sent Events for one-way server-to-client streams, and WebSockets for two-way, low-latency features like chat or collaboration. Plan for reconnection with backoff, missed messages (resume from a last-seen id), merging updates into the client cache and scaling the connections on the server.

Incrementally, never in one big rewrite. For TypeScript, enable allowJs, convert files leaf-first starting with shared utilities, and tighten strict options over time. For a framework, use the strangler pattern — new routes in the new stack, old ones migrated piece by piece behind the same domain — with metrics showing progress and no freeze on feature work.

A tech lead is judged less on what they can build alone and more on what the team ships, how well, and how sustainably. These questions are mostly scenarios: interviewers listen for structured thinking, clear communication, sensible trade-offs, and evidence that you grow people and make decisions others can follow.

Start from the product's needs — SEO, interactivity, team size, hosting, how long it must live — not from what's fashionable. Shortlist two or three options, build a small spike of the hardest feature in each, and weigh ecosystem maturity, hiring, performance, upgrade path and lock-in. Write the decision down with the alternatives you rejected and why.

An ADR is a short document capturing one significant decision: the context, the options considered, the decision and its consequences. Stored in the repo, ADRs let new people understand why things are the way they are, stop the team re-arguing settled questions, and make it obvious when the original context has changed and the decision should be revisited.

Make it visible first: keep a debt register tied to real costs — slow delivery, bugs, incidents, onboarding pain. Pay it down continuously (a fixed share of each sprint, or fixing as you touch code) rather than waiting for a mythical cleanup quarter, and prioritise debt in the areas that change most. Explain it to the business in terms of speed and risk, not code quality.

Translate it into outcomes they care about: "this checkout code causes a third of our incidents and makes every payment feature take twice as long." Bring data — cycle time, bug counts, incident history — propose a scoped, incremental plan with checkpoints, and tie it to an upcoming feature that will be cheaper afterwards.

Reviews are fast (within a working day), small and kind, and focus on correctness, design and maintainability rather than style, which linters and formatters handle. Comments explain why and separate blocking issues from suggestions ("nit:"). Everyone reviews, including seniors' code, and reviews are treated as knowledge sharing, not gatekeeping.

Move it from opinions to criteria: what problem are we optimising for, and what evidence do we have? Talk synchronously if comments go back and forth more than twice. If both options are reasonable, the author's choice usually wins; if it's a recurring debate, settle it once as a team guideline or ADR so it doesn't come up again.

Give them real, well-scoped work with a clear definition of done, pair with them early, and ask questions that lead them to answers instead of handing over solutions. Review their code with explanations, have regular one-to-ones about growth, and gradually increase scope and ownership. Make it safe to ask questions — the fastest learners are the ones who aren't afraid to look new.

Have the local setup work in under an hour with one documented command, give them a buddy, and let them ship a small real change in the first week. Provide an architecture overview, a glossary and a map of who owns what. Ask them to fix the onboarding docs as they go — new people spot the gaps everyone else has stopped seeing.

Use a structured process with the same questions and a written rubric for every candidate, focused on skills the job actually needs. Favour realistic exercises — building or debugging a small component, a design discussion, a code review — over trivia and puzzles. Let candidates think aloud, give hints, and assess communication and collaboration as well as code.

Break the work into small pieces, give ranges rather than single numbers, and call out the unknowns explicitly. For the riskiest part, time-box a spike to reduce uncertainty before committing. Re-estimate as you learn, and track actual against estimate to calibrate the team over time.

Raise it early with options, not just a problem. Work with product to cut or simplify scope — find the smallest version that delivers the core value, defer nice-to-haves behind flags, and agree on which quality bars won't be compromised (security, accessibility, data integrity). Never quietly drop tests or cut corners without making the trade-off and its follow-up visible.

Define the goal and how you'll measure progress, then migrate incrementally with both systems running side by side (the strangler pattern). Start with a pilot area to prove the approach, provide codemods and docs so other teams can migrate themselves, add lint rules that block new code in the old pattern, and set a date for removing the old path.

Build what differentiates your product; buy or adopt what's a commodity — auth, payments, analytics, rich-text editing. Compare total cost of ownership (maintenance, security updates, on-call), how well each option fits, vendor or maintainer health, data and compliance requirements, and the exit cost if you need to switch later.

Agree on budgets tied to user experience — LCP and INP targets, JavaScript per route, image weight — based on your users' devices and networks. Enforce them automatically: bundle-size checks and Lighthouse CI in pull requests, plus real-user monitoring dashboards with alerts. A budget only works if a failing check blocks the merge or triggers a conversation.

Ship small changes continuously from the main branch, behind feature flags when they're not ready. Roll out gradually — internal users, then a small percentage, then everyone — while watching error rates and vitals, with one-click rollback. Keep preview deployments for every pull request so product and design can review before merge.

Stabilise first: roll back or turn off the feature flag rather than debugging live. Communicate early in one channel with an owner, impact and next update time. Once users are safe, find the root cause, fix it with a test, and hold a blameless post-mortem with concrete actions so the same class of problem can't happen again.

It's blameless — it asks how the system allowed the mistake, not who made it. It has a clear timeline, impact, root cause and contributing factors, what went well, and a short list of actions with owners and dates. Then the team actually follows up on those actions and shares what it learned.

Measure where time is lost — slow builds, flaky tests, long review waits, painful local setup — by asking the team and looking at CI data. Then fix the biggest pains: fast dev servers, caching in CI, reliable tests, good defaults, generators for common code and clear docs. Small DX wins compound across every engineer, every day.

Anything objective should be a tool, not a review comment: Prettier for formatting, ESLint for correctness and accessibility rules, TypeScript in strict mode, import ordering and boundaries between modules, commit message conventions and pre-commit hooks for fast checks. Keep the rule set small, explain each rule, and auto-fix where possible.

Keep docs close to the code — READMEs, ADRs, Storybook and typed APIs — and make updating them part of the definition of done. Prefer a few high-value documents (getting started, architecture overview, how to deploy, runbooks) over a sprawling wiki, give each an owner, and delete docs that are wrong rather than leaving them to mislead people.

Use team-level flow and outcome metrics, never individual output like lines of code. The DORA metrics — deployment frequency, lead time for changes, change failure rate and time to restore — show delivery health; pair them with product outcomes and developer-experience surveys. Use the numbers to find bottlenecks, not to rank people.

Treat accessibility as a requirement with a target — usually WCAG 2.2 AA, which laws such as the European Accessibility Act increasingly demand. Bake it into the design system, design reviews, acceptance criteria and automated tests, train the team, and run periodic expert and user testing. Make someone accountable for it, or it slips.

Keep dependencies few and current with automated update PRs (Renovate, Dependabot) and audit them in CI. Pin versions with a lock file, review new packages before adding them, and watch for supply-chain attacks. Add security headers and CSP, keep secrets out of client bundles and environment variables exposed to the browser, and run periodic security reviews.

Involve engineers early in design, not just at hand-off, to flag feasibility, performance and accessibility issues while changes are cheap. Share one source of truth — tokens and components in both the design tool and the code — and review work in progress together. Agree on how responsive behaviour, empty, loading and error states will be specified.

Design the API together around what the screens need, write the contract first (OpenAPI or a GraphQL schema) and generate types and mocks from it so both sides can work in parallel. Version or evolve changes in a backwards-compatible way, and add contract tests so a breaking change fails CI instead of production.

Lead with the outcome and the decision, then the reason in terms of user impact, cost, risk and time — not implementation details. Offer two or three options with their trade-offs and your recommendation, use concrete examples or numbers, and check understanding. Follow up in writing so the decision is recorded.

Talk to each one separately to understand their concerns, then bring them together to agree on the goal and the criteria for deciding. If evidence can settle it, run a time-boxed spike. If it's still split, make the call yourself, explain why, and ask both to commit. Afterwards check in so the disagreement doesn't turn personal.

Start with curiosity, not judgement: talk privately, share specific examples and ask what's getting in the way — unclear expectations, personal issues, skills or the wrong role. Agree on clear goals, support and a timeline, check in regularly and document progress. Involve your manager early if it doesn't improve.

Stay close enough to the code to make good decisions and keep credibility — review pull requests, pair, build prototypes and take non-critical tasks — but avoid owning work on the critical path, because your time is interrupted. Your main output is the team's output: unblocking people, clarifying direction and improving the system they work in.

Delegate the outcome, not the steps: explain the goal, constraints and what good looks like, then let the person choose the approach. Match the task to their growth, agree on check-in points, and be available for questions. Accept that it may be done differently from how you'd do it — that's how people grow and how the team scales beyond you.

Start from business goals and the product roadmap, then add the technical work that enables them — platform changes, debt that slows key areas, scalability, security and developer experience. Prioritise by impact and risk, give each item a measurable outcome, and plan in quarters with room for the unexpected. Review and adjust it regularly with product.

Use one shared backlog and judge everything by impact and urgency: user and business impact, risk and cost of delay. Critical bugs and security issues jump the queue; for the rest, reserve a steady share of capacity for debt and quality so it isn't always pushed out by features. Make the trade-offs visible to product rather than deciding silently.

Align ownership with product domains — checkout, search, account — so each team can deliver end to end. Enforce module boundaries in code (separate packages, import rules), keep a shared platform team or guild for the design system, tooling and cross-cutting concerns, and make ownership explicit with a CODEOWNERS file.

It builds the paved road other teams use: the design system, build and deploy tooling, shared libraries, performance and accessibility monitoring, and standards. It treats product teams as customers, measures adoption and satisfaction, and avoids becoming a bottleneck by enabling self-service rather than doing the work for everyone.

Make the right thing the easy thing: good components that cover real needs, clear docs and examples, and lint rules or codemods that steer people to them. Run a contribution model so teams can propose additions instead of forking, release with semantic versioning and migration guides, and track adoption so you know where drift is happening.

Avoid them when you can; when you can't, announce them early, deprecate first with warnings, and publish a major version with a migration guide and, ideally, codemods. Support the previous major for a while, help the biggest consumers migrate, and collect feedback before the next breaking change.

Make learning part of the work: time for exploration, short internal talks, reading groups and spikes on real problems. Evaluate new tools against concrete pain points with small, reversible experiments, and adopt them only when the benefit clearly beats the cost of change. Being deliberately a little behind the hype curve is usually healthy.

Most front-end scale is about the backend and delivery: cache aggressively at the CDN, keep pages static or cached where possible, protect APIs with rate limits and request de-duplication, and load-test critical flows. On the client, watch performance on low-end devices and slow networks, and make sure monitoring and alerts will tell you when something degrades.

Make sure important pages render meaningful HTML on the server (SSR or SSG), with unique titles, meta descriptions, canonical URLs and structured data. Keep pages fast, since Core Web Vitals affect ranking, provide a sitemap and sensible robots rules, use real links for navigation, and avoid hiding content that only appears after client-side interaction.

Collect only the data you need, document what you collect and why, and respect consent laws like GDPR — no non-essential tracking before consent, and an easy way to withdraw it. Prefer privacy-friendly or first-party analytics, keep personal data out of logs and error reports, and review third-party scripts, since each one is also a performance and security risk.

Define the question it must answer and the success criteria up front, time-box it (often a few days), and build only enough to answer the question — it's throwaway code. Finish with a short written summary: what you learned, the recommendation and the remaining risks, so the team can decide.

Keep it short and decision-focused: the problem and goals (and non-goals), the proposed solution with diagrams, alternatives considered and why they were rejected, risks, rollout plan and how success will be measured. Share it early as a draft, invite reviewers from affected teams and record the final decision.

Rotate people across areas, pair on complex work, require reviews from more than one person for critical code, and write down runbooks and architecture decisions. Make sure at least two people can deploy, debug and on-call each critical system — and notice when one person has become the only answer to too many questions, including you.

Cache dependencies and build outputs, run only what a change affects (Turborepo, Nx), parallelise and shard test suites, and move slow suites to scheduled runs where safe. Track flaky tests, quarantine and fix them quickly instead of letting people retry until green, and set a target time for the pull-request pipeline that the team protects.

Standardise what's costly to vary — the build and deploy platform, the design system, security and accessibility practices, core libraries — and leave teams free in how they organise their own code and work. Explain the reasons behind each standard, offer a way to propose exceptions, and revisit standards when they stop serving people.

Make issues detectable and actionable: alerts on error rates, failed deploys and vitals regressions that point to dashboards, plus runbooks for common problems like rollback and turning off a flag. Keep the rotation fair, make sure everyone on it has been trained and shadowed first, and review alerts regularly to remove noise.

Model it yourself: admit your mistakes, say "I don't know", and thank people for raising problems and bad news. Run blameless reviews, invite quieter people to speak in meetings, and react to questions with interest, not impatience. People do their best work and surface risks early when they aren't afraid of looking wrong.

Pick a real example and use the STAR structure: the situation, the decision and your reasoning at the time, what went wrong, and what you did to recover. Spend most of the time on what you learned and changed in your process afterwards — for example, running spikes earlier or writing ADRs. Interviewers want honesty and growth, not a perfect record.

A good answer is about multiplying impact: you enjoy helping a team make good decisions, growing people and improving how things are built, not just writing code yourself or having authority. Be honest about what you'll miss and how you'll stay technical, and give an example where you already did lead-like work — mentoring, driving a decision or improving a process.

First 30 days: listen and learn — meet everyone one-to-one, understand the product, the architecture, the pain points and how work flows. Next 30: pick a few high-impact, low-risk improvements and deliver them to build trust. By 90 days: share a written view of the strengths, risks and a technical roadmap agreed with the team and stakeholders.

Intern အဆင့်မှာ production experience ရှိဖို့ ဘယ်သူမှ မမျှော်လင့်ပါဘူး။ Interviewer တွေ သိချင်တာက web ဘယ်လိုအလုပ်လုပ်လဲ၊ semantic HTML၊ CSS layout နဲ့ JavaScript အခြေခံတွေ ခိုင်ခိုင်မာမာ နားလည်ထားလား၊ ကိုယ်သိတာကို ရှင်းရှင်းလင်းလင်း ပြောပြနိုင်လား ဆိုတာပါ။ မသိတဲ့အခါ "သေချာမသိပါဘူး၊ ဒါပေမဲ့ ဒီလိုရှာကြည့်ပါမယ်" လို့ ပြောနိုင်တာကလည်း အမှတ်ပေးခံရပါတယ်။

Browser က DNS ကနေတစ်ဆင့် domain ကို IP address အဖြစ် ရှာပြီး TCP connection ဖွင့်ပါတယ် (HTTPS ဆိုရင် TLS handshake ပါ လုပ်ပါတယ်)၊ ပြီးမှ HTTP request ပို့ပါတယ်။ Server က HTML ပြန်ပို့ရင် browser က အဲ့ဒါကို DOM အဖြစ် parse လုပ်ရင်း ချိတ်ထားတဲ့ CSS၊ JavaScript နဲ့ image တွေကို ဆွဲယူပါတယ်။ ပြီးရင် CSSOM တည်ဆောက်၊ layout တွက်၊ pixel တွေ paint လုပ်ပြီး screen ပေါ်မှာ composite လုပ်ပြပါတယ်။

GET က resource ကို ဖတ်ဖို့၊ POST က အသစ်ဖန်တီးဖို့ ဒါမှမဟုတ် action တစ်ခုလုပ်ဖို့၊ PUT က resource တစ်ခုလုံးကို အစားထိုးဖို့၊ PATCH က တစ်စိတ်တစ်ပိုင်း update လုပ်ဖို့၊ DELETE က ဖျက်ဖို့ပါ။ GET၊ PUT၊ DELETE တွေက idempotent ဖြစ်ရပါမယ် — အကြိမ်ကြိမ်လုပ်လည်း တစ်ကြိမ်လုပ်တာနဲ့ ရလဒ်အတူတူပါပဲ၊ POST ကတော့ မဟုတ်ပါဘူး။

ပထမဆုံး digit က response အမျိုးအစားကို ပြောပါတယ်။

HTTPS ဆိုတာ encrypt လုပ်ထားတဲ့ TLS connection ပေါ်ကနေ ပို့တဲ့ HTTP ပါ။ Data ကို လျှို့ဝှက်ထားပေးတယ်၊ လမ်းမှာ ပြင်ဆင်ခံရတာကို ကာကွယ်ပေးတယ်၊ certificate နဲ့ server ရဲ့ identity ကို သက်သေပြပေးတယ်။ Browser တွေက HTTP page တွေကို not secure လို့ ပြပြီး service worker၊ geolocation၊ camera လို modern feature အများစုက HTTPS မှာပဲ အလုပ်လုပ်ပါတယ်။

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

Block element (<div>၊ <p>၊ <h1>) တွေက line အသစ်ကနေ စပြီး container အကျယ်အပြည့် ယူပါတယ်၊ width၊ height နဲ့ အပေါ်အောက် margin တွေ သတ်မှတ်လို့ရပါတယ်။ Inline element (<span>၊ <a>၊ <strong>) တွေက စာကြောင်းထဲမှာ စီးဆင်းသွားပြီး width၊ height ကို လျစ်လျူရှုပါတယ်။ inline-block ကတော့ inline လို line ထဲမှာ နေပေမဲ့ block လို box size တွေ လက်ခံပါတယ်။

alt text က screen reader သုံးသူတွေအတွက် image ကို ဖော်ပြပေးပြီး image load မဖြစ်ရင်လည်း ပေါ်လာပါတယ်၊ အလှအတွက်ပဲ ထည့်ထားတဲ့ image တွေမှာတော့ ကျော်သွားအောင် alt="" အလွတ်ထားရပါမယ်။ Input နဲ့ ချိတ်ထားတဲ့ <label> (for နဲ့ id၊ ဒါမှမဟုတ် wrap လုပ်ပြီး) က assistive technology ကို field က ဘာလဲဆိုတာ ပြောပြပေးပြီး label ကို နှိပ်ရင် input ကို focus ဖြစ်စေလို့ လူတိုင်းအတွက် နှိပ်ရပိုလွယ်ပါတယ်။

<meta name="viewport" content="width=device-width, initial-scale=1"> က mobile browser တွေကို ~980px desktop screen လို ဟန်ဆောင်ပြီး zoom out မလုပ်ဘဲ device ရဲ့ အကျယ်အစစ်ကို သုံးဖို့ ပြောပါတယ်။ ဒါမပါရင် media query တွေ၊ responsive layout တွေ phone ပေါ်မှာ မျှော်လင့်သလို အလုပ်မလုပ်ပါဘူး။ User zoom ကိုတော့ ဒီ tag နဲ့ ဘယ်တော့မှ ပိတ်မထားသင့်ပါဘူး။

ရိုးရိုး <script> က download လုပ်ပြီး run နေတုန်း HTML parse လုပ်တာကို ရပ်ထားပါတယ်။ async က parallel download လုပ်ပြီး ရောက်တာနဲ့ order မရွေး run ပါတယ် — analytics လို သီးခြား script တွေအတွက် ကောင်းပါတယ်။ defer က parallel download လုပ်ပေမဲ့ HTML parse ပြီးမှ order အတိုင်း run တာမို့ app code အတွက် များသောအားဖြင့် ဒါကို သုံးသင့်ပါတယ်။ type="module" script တွေက default အနေနဲ့ defer ဖြစ်ပြီးသားပါ။

Accessibility (a11y) ဆိုတာ မျက်စိ၊ ကိုယ်လက်လှုပ်ရှားမှု၊ အကြား ဒါမှမဟုတ် cognitive ဆိုင်ရာ အားနည်းချက်ရှိသူတွေလည်း site ကို သုံးနိုင်အောင် လုပ်တာပါ။ ပထမနေ့ကတည်းက လုပ်လို့ရတဲ့ အခြေခံတွေက —

Element တိုင်းက layer လေးခုပါတဲ့ စတုဂံ box တစ်ခုပါ — content၊ အဲ့ဒါကို ဝန်းရံထားတဲ့ padding၊ ပြီးတော့ border၊ အပြင်ဘက်မှာ တခြား box တွေနဲ့ ခွဲပေးတဲ့ margin ပါ။ ပုံမှန်အားဖြင့် width နဲ့ height က content area ကိုပဲ သက်ဆိုင်တာမို့ padding နဲ့ border က အပေါ်ကနေ ထပ်ပေါင်းသွားပါတယ် — box-sizing ကို မပြောင်းထားရင်ပေါ့။

border-box သုံးရင် သတ်မှတ်တဲ့ width နဲ့ height ထဲမှာ padding နဲ့ border ပါ ပါသွားလို့ 200px box က padding ဘယ်လောက်ထည့်ထည့် 200px ပဲ ရှိနေပါတယ်။ Size တွက်ရ ခန့်မှန်းရလွယ်လို့ project အများစုက global အနေနဲ့ apply လုပ်ကြပါတယ်။

Rule အများကြီးက element တစ်ခုတည်းကို target လုပ်တဲ့အခါ browser က specificity အမြင့်ဆုံးကို ရွေးပါတယ် — inline style က ID ကိုနိုင်တယ်၊ ID က class/attribute/pseudo-class ကိုနိုင်တယ်၊ အဲ့ဒါတွေက element selector ကိုနိုင်ပါတယ်။ Specificity တူရင် နောက်မှရေးတဲ့ rule က နိုင်ပါတယ်။ !important က ပုံမှန် rule တွေကို override လုပ်ပေမဲ့ နောက်ပိုင်း override လုပ်ရခက်စေလို့ နောက်ဆုံးနည်းလမ်းအနေနဲ့ပဲ သုံးသင့်ပါတယ်။

Cascade ဆိုတာ declaration အများကြီး apply ဖြစ်တဲ့အခါ ဘယ်ဟာနိုင်မလဲ ဆုံးဖြတ်တဲ့ algorithm ပါ။ Origin နဲ့ importance (user-agent၊ user၊ author၊ !important)၊ cascade layer၊ specificity၊ နောက်ဆုံးမှ source order ကို ကြည့်ပါတယ်။ Inheritance ကတော့ သီးခြားပါ — color၊ font လို property တချို့က parent ကနေ child ကို default အနေနဲ့ လက်ဆင့်ကမ်းပေမဲ့ margin လိုဟာတွေ မကမ်းပါဘူး။

Value တစ်ခုချင်းက element ကို နေရာချပုံ ပြောင်းစေပါတယ်။

display: none က element ကို layout ထဲက လုံးဝ ဖယ်လိုက်တာမို့ နေရာမယူတော့သလို screen reader တွေကနေလည်း ဖျောက်ထားပါတယ်။ visibility: hidden ကတော့ မမြင်ရအောင် ဖျောက်ပေမဲ့ နေရာကိုတော့ ယူထားဆဲပါ။ မျက်စိနဲ့မမြင်ရပေမဲ့ screen reader အတွက်တော့ ရှိနေစေချင်ရင် "visually hidden" (sr-only) utility class ကို သုံးပါ။

Flexbox က one-dimensional ပါ — item တွေကို row ဒါမှမဟုတ် column တစ်ခုထဲမှာ စီပေးလို့ navbar၊ button group၊ component ထဲမှာ item align လုပ်တာတွေအတွက် ကောင်းပါတယ်။ Grid က two-dimensional ပါ — row နဲ့ column ကို တစ်ပြိုင်နက် ထိန်းလို့ page layout နဲ့ card grid တွေအတွက် အကောင်းဆုံးပါ။ နှစ်ခုတွဲသုံးလို့လည်း ကောင်းပါတယ် — page layout ကို Grid နဲ့၊ card တစ်ခုချင်းထဲကို Flexbox နဲ့ပေါ့။

အလွယ်ဆုံး modern နည်းက parent မှာ Flexbox ဒါမှမဟုတ် Grid သုံးတာပါ။ Child တစ်ခုတည်းဆိုရင် Grid ရဲ့ place-items: center က အတိုဆုံးပါ။ Absolute positioned element တွေအတွက်တော့ fixed size နဲ့ inset: 0 ကို margin: auto နဲ့ တွဲသုံးလို့ရပါတယ်။

px က fixed unit ပါ။ em က element ကိုယ်တိုင်ရဲ့ font size (font-size အတွက်ဆို parent ရဲ့) ကို အခြေခံလို့ nest လုပ်ရင် ထပ်ကာထပ်ကာ မြှောက်သွားပါတယ်။ rem က root <html> ရဲ့ font size ကို အခြေခံလို့ ခန့်မှန်းရလွယ်ပြီး user ရဲ့ browser setting ကိုလည်း လေးစားပါတယ်။ % က parent ကို အခြေခံပြီး vw/vh က viewport အကျယ်/အမြင့်ရဲ့ 1% ပါ။

Responsive design ဆိုတာ fluid width၊ flexible image နဲ့ media query တွေသုံးပြီး layout တစ်ခုတည်းကို screen size အားလုံးနဲ့ ကိုက်ညီအောင် လုပ်တာပါ။ Mobile-first ဆိုတာ base style ကို screen သေးသေးအတွက် အရင်ရေးပြီး နေရာကျယ်လာတာနဲ့အမျှ min-width media query တွေနဲ့ layout ကို တိုးချဲ့တာပါ။ Base CSS ကို ရိုးရှင်းစေပြီး အရေးအကြီးဆုံး content ကို ဦးစားပေးစေပါတယ်။

Pseudo-class က element ကို သတ်မှတ်ထားတဲ့ state တစ်ခုမှာ select လုပ်တာပါ — :hover၊ :focus-visible၊ :nth-child(2)၊ :disabled။ Pseudo-element ကတော့ element ရဲ့ အစိတ်အပိုင်း တစ်ခုကို style လုပ်တာ ဒါမှမဟုတ် content အသစ်ထည့်တာပါ — ::before၊ ::after၊ ::placeholder၊ ::first-line။ Pseudo-class က colon တစ်ခု၊ pseudo-element က colon နှစ်ခု သုံးပါတယ်။

Primitive type ခုနစ်မျိုး — string၊ number၊ bigint၊ boolean၊ undefined၊ null၊ symbol — နဲ့ non-primitive type တစ်မျိုးဖြစ်တဲ့ object ရှိပါတယ်၊ array၊ function၊ date စတာတွေက object ထဲမှာ ပါပါတယ်။ Primitive တွေက immutable ဖြစ်ပြီး value နဲ့ နှိုင်းယှဉ်ပေမဲ့ object တွေကိုတော့ reference နဲ့ နှိုင်းယှဉ်ပါတယ်။ သမိုင်းကြောင်းအရ ထူးဆန်းချက်တစ်ခုက typeof null က "object" ပြန်ပေးတာပါ။

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

var က function-scoped ဖြစ်ပြီး hoist ဖြစ်ကာ undefined နဲ့ initialize ဖြစ်တယ်၊ ထပ်ကြေညာလို့လည်း ရပါတယ်။ let နဲ့ const က block-scoped ဖြစ်ပြီး ကြေညာတဲ့ line မတိုင်ခင် သုံးလို့မရပါဘူး။ const ကို reassign လုပ်လို့မရပေမဲ့ သူညွှန်ထားတဲ့ object ကိုတော့ mutate လုပ်လို့ရပါသေးတယ်။ Default အနေနဲ့ const သုံးပြီး value ပြောင်းဖို့လိုမှ let သုံးပါ။

Code မ run ခင် JavaScript က declaration တွေကို သူ့ scope ထဲမှာ မှတ်ထားပါတယ်။ Function declaration တွေက အပြည့်အဝ hoist ဖြစ်လို့ မရေးခင်ကတည်းက ခေါ်လို့ရပါတယ်။ var က hoist ဖြစ်ပေမဲ့ undefined ဖြစ်နေပါတယ်။ let၊ const၊ class တွေလည်း hoist ဖြစ်ပေမဲ့ သူတို့ line မ run မချင်း "temporal dead zone" ထဲမှာ ရှိနေလို့ စောစောသုံးရင် ReferenceError ဖြစ်ပါတယ်။

Scope က variable ကို ဘယ်နေရာကနေ access လုပ်လို့ရလဲ ဆုံးဖြတ်ပါတယ်။ Global scope၊ function scope နဲ့ block scope (let/const အတွက် {} ထဲက အရာအားလုံး) ရှိပါတယ်။ Scope တွေက lexical အနေနဲ့ အဆင့်ဆင့် nest ဖြစ်နေလို့ အတွင်းက code က အပြင် scope က variable တွေကို ဖတ်လို့ရပေမဲ့ ပြောင်းပြန်တော့ မရပါဘူး။ ဒီရှာဖွေတဲ့ ကွင်းဆက်ကို scope chain လို့ ခေါ်ပါတယ်။

Closure ဆိုတာ function တစ်ခုက သူ့ကိုဖန်တီးခဲ့တဲ့ scope ထဲက variable တွေကို အပြင် function ပြီးသွားတဲ့နောက်မှာတောင် မှတ်ထားနိုင်တာပါ။ JavaScript မှာ private state နဲ့ factory function တွေ ရနိုင်တာ ဒီကြောင့်ပါ၊ callback၊ event handler နဲ့ React hook တွေရဲ့ နောက်ကွယ်မှာလည်း closure ရှိပါတယ်။

this ကို function ဘယ်မှာရေးထားလဲ မဟုတ်ဘဲ ဘယ်လိုခေါ်လဲ နဲ့ ဆုံးဖြတ်ပါတယ်။ Method အနေနဲ့ (obj.fn()) ခေါ်ရင် object ဖြစ်ပြီး၊ ရိုးရိုးခေါ်ရင် strict mode မှာ undefined (မဟုတ်ရင် global object) ဖြစ်တယ်၊ new နဲ့ဆို instance အသစ်ဖြစ်ပြီး call၊ apply၊ bind တွေက တိုက်ရိုက်သတ်မှတ်ပေးပါတယ်။ Arrow function တွေမှာ ကိုယ်ပိုင် this မရှိဘဲ ဝန်းရံထားတဲ့ scope ရဲ့ this ကို သုံးပါတယ်။

Arrow function တွေက ပိုတိုပြီး ကိုယ်ပိုင် this၊ arguments၊ super မရှိပါဘူး — ဝန်းရံထားတဲ့ scope ကနေ ယူသုံးလို့ callback တွေအတွက် အဆင်ပြေပါတယ်။ new နဲ့ constructor အဖြစ် သုံးလို့မရသလို prototype လည်း မရှိပါဘူး။ this က object ကို ညွှန်ဖို့လိုတဲ့ object method တွေအဖြစ်တော့ မသုံးပါနဲ့။

သုံးခုစလုံးက array ကို loop ပတ်ပြီး မူလ array ကို မပြောင်းဘဲ value အသစ်ပြန်ပေးပါတယ်။ map က item တစ်ခုချင်းကို ပြောင်းပြီး အရှည်တူ array အသစ်ပေးတယ်၊ filter က စစ်ဆေးချက်ကို အောင်တဲ့ item တွေကိုပဲ ထားတယ်၊ reduce က item အားလုံးကို ပေါင်းပြီး sum ဒါမှမဟုတ် object လို value တစ်ခုတည်း ဖြစ်အောင်လုပ်ပါတယ်။

နှစ်ခုစလုံးက ... ကို သုံးပါတယ်။ Spread က iterable ဒါမှမဟုတ် object ကို element တစ်ခုချင်းအဖြစ် ဖြန့်ပေးတာပါ — array copy လုပ်တာ၊ object ပေါင်းတာ၊ array item တွေကို argument အဖြစ်ပေးတာ။ Rest က ပြောင်းပြန်ပါ — ကျန်တဲ့ item တွေကို function parameter ဒါမှမဟုတ် destructuring ထဲမှာ array တစ်ခုအဖြစ် စုပေးပါတယ်။

Destructuring ဆိုတာ array ထဲက value တွေ ဒါမှမဟုတ် object ထဲက property တွေကို line တစ်ကြောင်းတည်းနဲ့ variable တွေထဲ ထုတ်ယူတာပါ။ နာမည်ပြောင်းတာ၊ default value ထားတာ၊ nest လုပ်တာတွေ လုပ်လို့ရပါတယ်။ Function parameter နဲ့ React props တွေမှာ အထူးသဖြင့် အသုံးများပါတယ်။

Boolean context မှာ JavaScript က value တိုင်းကို true ဒါမှမဟုတ် false အဖြစ် ပြောင်းပါတယ်။ Falsy value တွေက false၊ 0၊ -0၊ 0n၊ ""၊ null၊ undefined နဲ့ NaN ပါ၊ ကျန်တာအားလုံး truthy ဖြစ်ပါတယ် — "0"၊ []၊ {} တွေပါ အပါအဝင်ပေါ့။ ဒါကြောင့် if (items.length) က အလုပ်လုပ်ပေမဲ့ array အတွက် if (items) ကတော့ အမြဲ true ဖြစ်နေပါတယ်။

undefined ဆိုတာ value မထည့်ရသေးတာကို ဆိုလိုပါတယ် — initialize မလုပ်ရသေးတဲ့ variable၊ မရှိတဲ့ property ဒါမှမဟုတ် return မပါတဲ့ function လိုမျိုးပါ။ null ကတော့ developer က ရည်ရွယ်ချက်ရှိရှိ ထည့်ထားတဲ့ "value မရှိ" ပါ။ null == undefined က true ဖြစ်ပေမဲ့ null === undefined က false ပါ။ ?? operator က နှစ်ခုစလုံးကို "မရှိ" လို့ သဘောထားပါတယ်။

Template literal တွေက backtick နဲ့ ရေးတဲ့ string တွေပါ။ ${expression} နဲ့ interpolation လုပ်လို့ရတယ်၊ \n မလိုဘဲ multi-line string ရေးလို့ရတယ်၊ function တစ်ခုက အစိတ်အပိုင်းတွေကို process လုပ်တဲ့ tagged template တွေလည်း ရှိပါတယ် (styled-components နဲ့ GraphQL client လို library တွေက သုံးပါတယ်)။

Callback ဆိုတာ နောက်မှ ခေါ်ဖို့ function တစ်ခုထဲကို ထည့်ပေးလိုက်တဲ့ function ပါ — event ဖြစ်တဲ့အခါ၊ timer ပြီးတဲ့အခါ ဒါမှမဟုတ် data ရောက်လာတဲ့အခါမှာ ခေါ်ပါတယ်။ map လို array method တွေကလည်း callback ယူပါတယ်။ Asynchronous callback တွေ အထပ်ထပ် nest ဖြစ်နေတာ ("callback hell") က ဖတ်ရခက်လို့ promise နဲ့ async/await ကို မိတ်ဆက်လာခဲ့တာပါ။

Promise ဆိုတာ နောက်မှ ရလာမယ့် value ကို ကိုယ်စားပြုပါတယ်။ pending နဲ့ စပြီး value နဲ့ fulfilled ဒါမှမဟုတ် error နဲ့ rejected အဖြစ် တစ်ကြိမ်ပဲ settle ဖြစ်ပါတယ်။ ရလဒ်ကို .then()၊ error ကို .catch()၊ cleanup ကို .finally() နဲ့ handle လုပ်ပြီး callback တွေ nest လုပ်မယ့်အစား chain လုပ်လို့ရပါတယ်။

async function က အမြဲ Promise ပြန်ပေးပါတယ်။ အထဲမှာ await က Promise settle မဖြစ်မချင်း အဲ့ function ကို ခဏရပ်ထားလို့ asynchronous code ကို အပေါ်ကနေ အောက် ဖတ်သလို ရေးလို့ရပါတယ်။ Await လုပ်ထားတဲ့ Promise က error ဖြစ်ရင် throw ဖြစ်လာလို့ try/catch နဲ့ handle လုပ်ပါတယ်။

fetch(url, options) ကိုခေါ်၊ response ကို await လုပ်၊ res.ok ကိုစစ်ပြီးမှ res.json() နဲ့ parse လုပ်ပါ။ အဖြစ်များတဲ့ အမှားတစ်ခုက fetch က network failure မှာပဲ reject ဖြစ်တာပါ — 404 ဒါမှမဟုတ် 500 ဖြစ်လည်း resolve ဖြစ်နေလို့ status ကို ကိုယ်တိုင်စစ်ရပါမယ်။ POST request အတွက်ဆို method၊ Content-Type header နဲ့ JSON body ကို သတ်မှတ်ပါ။

JSON.stringify က JavaScript value ကို JSON string အဖြစ် ပြောင်းပေးတာပါ — API ကိုပို့ဖို့ ဒါမှမဟုတ် localStorage မှာ သိမ်းဖို့။ JSON.parse က JSON string ကို value အဖြစ် ပြန်ပြောင်းပေးပါတယ်။ JSON က function၊ undefined၊ Date object (string ဖြစ်သွားတယ်) နဲ့ circular reference တွေကို ကိုယ်စားမပြုနိုင်ပါဘူး၊ JSON.parse က input မှားရင် throw လုပ်လို့ ယုံကြည်ရမယ့် data မဟုတ်ရင် try/catch နဲ့ ထုပ်ပါ။

DOM (Document Object Model) ဆိုတာ browser က page ကို ကိုယ်စားပြုထားတဲ့ object tree ဖြစ်ပြီး JavaScript က ဖတ်လို့ရော ပြောင်းလို့ပါ ရပါတယ်။ Element တွေကို document.querySelector / querySelectorAll နဲ့ select လုပ်ပြီး textContent၊ classList၊ setAttribute လို property တွေနဲ့ ပြောင်းတာ ဒါမှမဟုတ် createElement နဲ့ append သုံးပြီး အသစ်ဖန်တီးတာ လုပ်လို့ရပါတယ်။

textContent က plain text ကို ဖတ်/ထည့်တာမို့ < character တွေက text အနေနဲ့ပဲ ရှိနေပါတယ်။ innerHTML က string ကို HTML အဖြစ် parse လုပ်ပါတယ်။ User input ကို innerHTML ထဲ ထည့်တာက script တွေ inject ဖြစ်နိုင်လို့ (XSS) အန္တရာယ်ရှိပါတယ် — text အတွက် textContent ကိုသုံးပြီး innerHTML ကိုတော့ ယုံကြည်ရတဲ့ ဒါမှမဟုတ် sanitize လုပ်ထားတဲ့ content နဲ့ပဲ သုံးပါ။

element.addEventListener("click", handler) နဲ့ listener တပ်ပါ။ Handler က target၊ key လို အသေးစိတ်တွေပါတဲ့ event object ကို လက်ခံရပါတယ်။ Browser ရဲ့ default behaviour (ဥပမာ form submit ဖြစ်တာ) ကို event.preventDefault() နဲ့ ရပ်လို့ရပြီး listener ကို function reference အတူတူနဲ့ removeEventListener သုံးပြီး နောက်မှ ဖြုတ်လို့ရပါတယ်။

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

သုံးခုစလုံး browser ထဲမှာ data သိမ်းပေမဲ့ ပုံစံကွာပါတယ်။

Synchronous code က line တစ်ကြောင်းချင်း run ပြီး line တိုင်းက အရင် line ပြီးတာကို စောင့်ပါတယ်။ Asynchronous code ကတော့ network request၊ timer လို task တစ်ခုကို စလိုက်ပြီး ကျန်တဲ့ program ကို ဆက် run စေကာ ရလဒ်ကို callback၊ promise ဒါမှမဟုတ် await နဲ့ နောက်မှ handle လုပ်ပါတယ်။ JavaScript က main thread တစ်ခုတည်းပေါ်မှာ run တာမို့ async code က page ကို responsive ဖြစ်နေစေပါတယ်။

ပုံမှန်တစ်နေ့မှာ command အနည်းငယ်ပဲ သုံးပါတယ်။

npm ဆိုတာ library တွေ install လုပ်ဖို့နဲ့ script တွေ run ဖို့ Node ရဲ့ package manager ပါ။ package.json မှာ dependency တွေ (version range နဲ့)၊ dev dependency တွေနဲ့ dev၊ build လို script တွေကို ရေးထားပါတယ်။ Lock file (package-lock.json၊ pnpm-lock.yaml၊ bun.lock) က install လုပ်ခဲ့တဲ့ version အတိအကျကို မှတ်ထားလို့ machine တိုင်းနဲ့ CI မှာ tree အတူတူ ရစေပါတယ်။

Elements panel က HTML နဲ့ CSS ကို inspect လုပ်ပြီး live ပြင်လို့ရတယ်၊ computed style နဲ့ box model ပါ ကြည့်လို့ရတယ်။ Console က error တွေပြပြီး code run လို့ရတယ်။ Sources မှာ breakpoint တွေထားပြီး JavaScript ကို တစ်ဆင့်ချင်း လိုက်ကြည့်လို့ရတယ်။ Network က request တိုင်းရဲ့ status၊ timing နဲ့ payload ကိုပြပြီး Lighthouse/Performance က speed နဲ့ accessibility အတွက် ကူညီပါတယ်။

Tutorial တွေ နာရီပေါင်းများစွာ ထိုင်ကြည့်မယ့်အစား official docs ကနေစပြီး core idea ကိုသုံးတဲ့ အသေးလေးတစ်ခု ကိုယ်တိုင်တည်ဆောက်ပါ။ Error message တွေကို သေချာဖတ်၊ ရှာကြည့်ပြီး တခြားသူတွေ ဘယ်လိုဖြေရှင်းခဲ့လဲ စစ်ကြည့်ပါ။ အချိန်အတော်ကြာ ပိတ်မိနေရင် ဘာတွေ စမ်းပြီးပြီဆိုတာနဲ့အတူ တိကျတဲ့ မေးခွန်းမေးပါ — interviewer တွေက အရာအားလုံးကို သိပြီးသားဖြစ်တာထက် ရှင်းလင်းတဲ့ learning process ကို ပိုတန်ဖိုးထားပါတယ်။

Mid-level developer တစ်ယောက်က feature တွေကို ကိုယ်တိုင် ship လုပ်နိုင်ရပါမယ်။ Interviewer တွေက JavaScript ရဲ့ နောက်ကွယ်မှာ တကယ်ဘယ်လိုအလုပ်လုပ်လဲ၊ React component နဲ့ state တွေကို ဘယ်လို structure လုပ်လဲ၊ performance၊ security၊ accessibility နဲ့ test တွေကို အပိုမဟုတ်ဘဲ အလုပ်ရဲ့ တစ်စိတ်တစ်ပိုင်းအဖြစ် စဉ်းစားလား ဆိုတာကို နက်နက်နဲနဲ မေးပါလိမ့်မယ်။ အဖြေတိုင်းရဲ့ နောက်မှာ "ဘာကြောင့်လဲ"၊ "trade-off တွေက ဘာလဲ" ဆိုတာ ထပ်မေးမယ်လို့ မျှော်လင့်ထားပါ။

JavaScript က call stack ပါတဲ့ thread တစ်ခုတည်းပေါ်မှာ run ပါတယ်။ Timer၊ network၊ event လို async အလုပ်တွေကို browser က ကိုင်တွယ်ပြီး ပြီးသွားရင် callback ကို queue ထဲထည့်ပါတယ်။ Event loop က call stack အလွတ်ဖြစ်မှပဲ queue ထဲက task တစ်ခုကို ယူပြီး နောက် task ဒါမှမဟုတ် render မလုပ်ခင် queue ထဲက microtask (promise callback) အားလုံး ကို run ပါတယ်။ Synchronous loop အရှည်ကြီးက page ကို ရပ်သွားစေတာ ဒါကြောင့်ပါ။

Macrotask ("task") ထဲမှာ setTimeout၊ setInterval၊ I/O နဲ့ UI event တွေ ပါပါတယ်။ Microtask ထဲမှာ promise .then callback၊ await ပြီးနောက် ဆက်လုပ်တဲ့အပိုင်း နဲ့ queueMicrotask တွေ ပါပါတယ်။ Task တစ်ခုပြီးတိုင်း engine က microtask queue တစ်ခုလုံးကို ကုန်အောင် run ပြီးမှ ရှေ့ဆက်တာမို့ microtask တွေက အမြဲ အရင် run ပါတယ်။

Closure တွေက data privacy၊ memoisation နဲ့ တစ်ကြိမ်ပဲ run တဲ့ function တွေကို ဖြစ်စေပါတယ်။ ထင်ရှားတဲ့ bug က async callback တွေပါတဲ့ loop မှာ var သုံးတာပါ — callback အားလုံးက function-scoped variable တစ်ခုတည်းကို မျှသုံးလို့ နောက်ဆုံး value ကိုပဲ မြင်ရပါတယ်။ let က iteration တိုင်းအတွက် binding အသစ်ဖန်တီးပေးလို့ ဒါကို ဖြေရှင်းပေးပါတယ်။

Object တိုင်းမှာ prototype လို့ခေါ်တဲ့ တခြား object တစ်ခုနဲ့ internal link ရှိပါတယ်။ Object ပေါ်မှာ မရှိတဲ့ property ကို ဖတ်တဲ့အခါ JavaScript က တွေ့တဲ့အထိ ဒါမှမဟုတ် null ရောက်တဲ့အထိ ဒီ prototype chain အတိုင်း အပေါ်တက်ရှာပါတယ်။ class syntax က ဒါရဲ့ အပေါ်ယံ sugar ပါ — method တွေက ClassName.prototype ပေါ်မှာ ရှိပြီး instance တွေက အဲ့ဒါကို link လုပ်ထားပါတယ်။

သုံးခုစလုံးက this ကို တိုက်ရိုက် သတ်မှတ်ပေးပါတယ်။ call(thisArg, a, b) က argument တွေကို စီပြီး function ကို ချက်ချင်းခေါ်တယ်၊ apply(thisArg, [a, b]) က array နဲ့ အတူတူလုပ်တယ်၊ bind(thisArg) ကတော့ this ကို အမြဲတမ်း fix လုပ်ထားတဲ့ function အသစ် ကို ပြန်ပေးလို့ callback နဲ့ event handler တွေအတွက် အသုံးဝင်ပါတယ်။

အားလုံး promise array ကို လက်ခံပေမဲ့ resolve ဖြစ်ပုံ ကွာပါတယ်။

Error ကို နေရာတိုင်းမှာ မျိုချမယ့်အစား တကယ်တစ်ခုခု လုပ်နိုင်တဲ့ အဆင့် — message ပြတာ၊ retry လုပ်တာ၊ fallback သုံးတာ — မှာ await call တွေကို try/catch နဲ့ ထုပ်ပါ။ fetch က HTTP error မှာ reject မဖြစ်လို့ res.ok ကို စစ်ဖို့ မမေ့ပါနဲ့။ လွတ်သွားတာတွေအတွက် global handler (unhandledrejection၊ error boundary ဒါမှမဟုတ် monitoring) ထည့်ထားပါ။

တစ်ခုနဲ့တစ်ခု မဆိုင်တဲ့ request တွေကို တစ်ခုပြီးမှ တစ်ခု await လုပ်ရင် အချိန်တွေ ပေါင်းသွားပါတယ်။ မှီခိုမှုမရှိရင် တစ်ပြိုင်နက် စလိုက်ပြီး Promise.all နဲ့ await လုပ်ပါ၊ ဒါဆို စုစုပေါင်းအချိန်က ပေါင်းလဒ် မဟုတ်တော့ဘဲ အနှေးဆုံး request ရဲ့ အချိန်ပဲ ဖြစ်ပါတယ်။

နှစ်ခုစလုံးက event တွေ မြန်မြန်ဆန်ဆန် ဖြစ်နေတဲ့အခါ function run တဲ့ အကြိမ်ရေကို ကန့်သတ်ပါတယ်။ Debounce က event တွေ သတ်မှတ်ချိန်တစ်ခု ရပ်သွားတဲ့အထိ စောင့်ပြီးမှ တစ်ကြိမ် run တာမို့ search-as-you-type အတွက် အကောင်းဆုံးပါ။ Throttle က event တွေ ဆက်ဖြစ်နေစဉ် interval တစ်ခုမှာ အများဆုံး တစ်ကြိမ် run တာမို့ scroll ဒါမှမဟုတ် resize handler တွေအတွက် ကောင်းပါတယ်။

Shallow copy ({...obj}၊ [...arr]၊ Object.assign) က အပေါ်ဆုံးအဆင့်ကိုပဲ copy လုပ်တာမို့ nested object တွေကို မျှသုံးနေဆဲဖြစ်ပြီး ပြင်လိုက်ရင် နှစ်ဘက်လုံး သက်ရောက်ပါတယ်။ Deep copy ကတော့ အရာအားလုံးကို ပွားပါတယ်။ Deep copy အတွက် built-in structuredClone(obj) ကို သုံးပါ — ဟောင်းတဲ့ JSON.parse(JSON.stringify()) နည်းနဲ့မတူဘဲ date၊ map၊ set နဲ့ cycle တွေကိုပါ ကိုင်တွယ်ပေးပါတယ်။

CommonJS (require/module.exports) က Node ရဲ့ မူလ synchronous system ပါ။ ES modules (import/export) က standard ဖြစ်ပြီး static ဖြစ်လို့ bundler တွေက မသုံးတဲ့ code ကို tree-shake လုပ်နိုင်တယ်၊ top-level await ကို support လုပ်တယ်၊ browser တွေမှာ native အလုပ်လုပ်တယ်။ Code အသစ်တွေမှာ ES modules ကို သုံးသင့်ပါတယ်။

ရှိပြီးသား object ကို mutate မလုပ်ဘဲ object အသစ်ဖန်တီးရင် ပြောင်းလဲမှုကို reference check (prev !== next) တစ်ခုတည်းနဲ့ စျေးပေါပေါ သိနိုင်ပါတယ်။ React၊ Redux နဲ့ memoisation အားလုံး ဒါကို အားကိုးတာမို့ state ကို နေရာမှာတင် mutate လုပ်ရင် UI က update မဖြစ်ပါဘူး။ Code ကို နားလည်ရ ပိုလွယ်စေပြီး undo လို feature တွေကိုလည်း ဖြစ်နိုင်စေပါတယ်။

နှစ်ခုစလုံးက object shape ကို ဖော်ပြပြီး အများစုမှာ အပြန်အလှန် သုံးလို့ရပါတယ်။ Interface ကို extends နဲ့ တိုးချဲ့လို့ရပြီး နှစ်ခါကြေညာရင် merge ဖြစ်တာမို့ public API တွေနဲ့ သင့်တော်ပါတယ်။ Type alias ကတော့ union၊ intersection၊ tuple နဲ့ mapped/conditional type တွေကိုပါ ဖော်ပြနိုင်ပါတယ်။ Team အများစုက default အနေနဲ့ type ကိုသုံးပြီး တိုးချဲ့ရမယ့် object contract တွေအတွက် interface ကို သုံးကြပါတယ်။

Generics က input နဲ့ output ကြားက ဆက်စပ်မှုကို ထိန်းထားရင်း type အမျိုးမျိုးနဲ့ အလုပ်လုပ်တဲ့ function ဒါမှမဟုတ် type ကို ရေးနိုင်စေပါတယ်။ any ပြန်ပေးမယ့်အစား generic function က ပေးလိုက်တဲ့ type အတိအကျကို ပြန်ပေးပါတယ်။

Narrowing ဆိုတာ typeof၊ instanceof၊ in ဒါမှမဟုတ် discriminant field ကို နှိုင်းယှဉ်တာလို စစ်ဆေးချက်တွေနဲ့ TypeScript က branch တစ်ခုထဲမှာ ကျယ်တဲ့ type ကို တိကျတဲ့ type အဖြစ် ချုံ့ပေးတာပါ။ Custom type guard ဆိုတာ value is Type ကို ပြန်ပေးတဲ့ function ဖြစ်ပြီး ကိုယ်ပိုင် စစ်ဆေးချက်ကို compiler ကို သင်ပေးတာပါ။

any က type checking ကို ပိတ်လိုက်တာမို့ ဘာမဆိုလုပ်လို့ရပြီး error တွေက တိတ်တိတ်လေး လွတ်သွားပါတယ်။ unknown က "ဘာမဆိုဖြစ်နိုင်တယ်" လို့ ဆိုလိုပေမဲ့ မသုံးခင် narrow လုပ်ဖို့ အတင်းခိုင်းပါတယ်။ JSON.parse ရလဒ် ဒါမှမဟုတ် catch လုပ်ထားတဲ့ error လို ယုံကြည်ရမယ့် data မဟုတ်တာတွေအတွက် unknown ကိုသုံးပြီး (ဥပမာ Zod နဲ့) validate လုပ်ပါ။

Built-in utility type တွေက type တွေကို ပြန်ရေးမယ့်အစား ရှိပြီးသား type ကို ပြောင်းပေးပါတယ်။

State ပြောင်းတဲ့အခါ React က component ကို re-render လုပ်ပြီး element tree အသစ်ရယူကာ အရင်ဟာနဲ့ နှိုင်းယှဉ်ပါတယ် — ဒါကို reconciliation လို့ခေါ်ပါတယ်။ Type မတူတဲ့ element တွေကို အစားထိုးပြီး type တူတဲ့ element တွေကတော့ DOM node ကို ဆက်ထားကာ ပြောင်းသွားတဲ့ prop တွေကိုပဲ apply လုပ်ပါတယ်။ ပြီးမှ လိုအပ်သလောက် အနည်းဆုံး DOM ပြောင်းလဲမှုတွေကို commit လုပ်ပါတယ်။

Key တွေက render တစ်ခုနဲ့တစ်ခုကြားမှာ item ဘယ်ဟာက ဘယ်ဟာလဲဆိုတာ React ကို ပြောပြလို့ item တစ်ခုချင်းအတွက် မှန်ကန်တဲ့ state နဲ့ DOM node ကို ထိန်းထားနိုင်ပါတယ်။ Array index ကို သုံးပြီး list ကို ပြန်စီတာ၊ filter လုပ်တာ ဒါမှမဟုတ် item ထပ်ထည့်တာ လုပ်ရင် state (input text၊ checkbox state လိုမျိုး) က မှားတဲ့ item ဆီ ကပ်သွားပါတယ်။ Data ထဲက တည်ငြိမ်ပြီး unique ဖြစ်တဲ့ id ကို သုံးပါ။

Controlled input က သူ့ value ကို React state ကနေ ယူပြီး onChange နဲ့ update လုပ်တာမို့ React က single source of truth ဖြစ်ပါတယ် — validation နဲ့ တစ်ခုနဲ့တစ်ခု မှီခိုတဲ့ field တွေအတွက် ကောင်းပါတယ်။ Uncontrolled input ကတော့ value ကို DOM ထဲမှာ ကိုယ်တိုင်ထားပြီး submit လုပ်ချိန်မှာ ref ဒါမှမဟုတ် FormData နဲ့ ဖတ်တာမို့ form ကြီးတွေအတွက် ပိုရိုးရှင်းပြီး ပိုမြန်ပါတယ်။ React 19 ရဲ့ form Actions တွေက uncontrolled နည်းကို အရမ်းအဆင်ပြေစေပါတယ်။

Bug အများစုက side effect မဟုတ်တဲ့ အရာတွေအတွက် effect ကို သုံးတာကနေ လာပါတယ်။

Effect ထဲကနေ function တစ်ခု return ပြန်ပါ။ React က dependency ပြောင်းလို့ effect ကို ထပ် run မယ့်အခါ မတိုင်ခင်နဲ့ component unmount ဖြစ်တဲ့အခါမှာ အဲ့ဒါကို run ပါတယ်။ Development မှာ Strict Mode က cleanup မေ့နေတာတွေကို ဖမ်းဖို့ ရည်ရွယ်ပြီး mount၊ cleanup၊ ပြန် mount လုပ်ပါတယ်။

useMemo က တွက်ရခက်တဲ့ value ကို cache လုပ်တယ်၊ useCallback က function identity ကို cache လုပ်တယ်၊ React.memo က prop မပြောင်းရင် component ကို re-render မလုပ်ဘဲ ကျော်ပါတယ်။ တစ်ခုခုက reference equality ကို တကယ်မှီခိုနေမှ ဒါမှမဟုတ် အလုပ်က တိုင်းတာလို့ရလောက်အောင် လေးမှပဲ အကျိုးရှိတာမို့ profile အရင်လုပ်ပါ။ အခု React Compiler က memoisation အများစုကို အလိုအလျောက် ထည့်ပေးနိုင်ပါပြီ။

useRef က re-render ကြားမှာ ဆက်ရှိနေပြီး ပြောင်းလဲရင်လည်း re-render မဖြစ်စေတဲ့ mutable box (ref.current) တစ်ခုကို ပေးပါတယ်။ DOM node တွေဆီ ရောက်ဖို့ (input ကို focus လုပ်တာ၊ size တိုင်းတာ) နဲ့ timer id ဒါမှမဟုတ် အရင် value လို render မဖြစ်စေသင့်တဲ့ value တွေ သိမ်းဖို့ သုံးပါ။ Output ကို သက်ရောက်တဲ့ အရာတွေအတွက် render လုပ်နေချိန်မှာ ref ကို မဖတ်ပါနဲ့၊ မရေးပါနဲ့။

Context ကို ဖတ်တဲ့ component တိုင်းက သူ့ value ပြောင်းတိုင်း re-render ဖြစ်တာမို့ မကြာခဏ ပြောင်းတဲ့ data ပါတဲ့ context ကြီးတစ်ခုက app ရဲ့ အစိတ်အပိုင်း အများကြီးကို re-render ဖြစ်စေနိုင်ပါတယ်။ ပြောင်းလဲနှုန်းအလိုက် context တွေကို ခွဲပါ၊ value object ကို memoise လုပ်ပါ၊ မြန်မြန်ပြောင်းတဲ့ state ကို local ထားပါ၊ ဒါမှမဟုတ် မကြာခဏပြောင်းတဲ့ global state အတွက် selector ပါတဲ့ store (Zustand၊ Redux) ကို သုံးပါ။

Custom hook ဆိုတာ use နဲ့စပြီး ပြန်သုံးလို့ရတဲ့ stateful logic ကို ထုပ်ပိုးဖို့ တခြား hook တွေကို ခေါ်တဲ့ function ပါ — useDebounce၊ useMediaQuery၊ useFetch လိုမျိုး။ Component နှစ်ခုက logic အတူတူကို မျှသုံးတဲ့အခါ ဒါမှမဟုတ် ရှုပ်ထွေးတဲ့ component ရဲ့ logic ကို နာမည်ရှင်းရှင်း ပေးချင်တဲ့အခါ ရေးပါ။ Hook ကိုခေါ်တဲ့ component တိုင်းက ကိုယ်ပိုင် သီးခြား state ရပါတယ်။

Sibling component နှစ်ခုက data အတူတူ လိုတဲ့အခါ အဲ့ state ကို သူတို့ရဲ့ အနီးဆုံး common parent ဆီ ရွှေ့ပြီး props အဖြစ် ပြန်ပေးကာ ပြောင်းဖို့ callback တွေပါ ပေးတာပါ။ Single source of truth ကို ထိန်းထားပေးပါတယ်။ Props တွေကို အဆင့်အများကြီး ဖြတ်ပို့နေရရင် composition (component တွေကို children အဖြစ်ပေးတာ) ဒါမှမဟုတ် context ကို စဉ်းစားပါ။

Local state နဲ့စပြီး လိုသလောက်ပဲ lift လုပ်ပါ။ Server data က global store ထဲမဟုတ်ဘဲ TanStack Query ဒါမှမဟုတ် SWR လို data-fetching cache ထဲမှာ ရှိသင့်ပါတယ်။ URL state (filter၊ tab၊ page) က URL ထဲမှာ ရှိသင့်ပါတယ်။ Zustand ဒါမှမဟုတ် Redux Toolkit လို global store ကိုတော့ cart၊ auth session ဒါမှမဟုတ် editor state လို တကယ်မျှသုံးရတဲ့ client state အတွက်ပဲ သုံးပါ။

Effect ထဲမှာ ကိုယ်တိုင်ရေးတဲ့ fetching က အများကြီး လွတ်သွားပါတယ် — caching၊ request အတူတူတွေကို တစ်ခုတည်းဖြစ်အောင်လုပ်တာ၊ retry၊ background refetch၊ stale-while-revalidate၊ pagination နဲ့ race condition တွေပါ။ Server-state library က ဒါတွေအားလုံးကို ကိုင်တွယ်ပေးပြီး isLoading/isError state တွေပေးကာ cache invalidation ပါတဲ့ mutation တွေကို လွယ်ကူစေပါတယ်။

Error boundary ဆိုတာ သူ့ children တွေ render လုပ်နေစဉ် throw ဖြစ်တဲ့ error တွေကို ဖမ်းပြီး app တစ်ခုလုံး unmount မဖြစ်စေဘဲ fallback UI ပြပေးတဲ့ component ပါ။ Event handler ဒါမှမဟုတ် async code ထဲက error တွေကိုတော့ မဖမ်းပါဘူး — ဒါတွေကို try/catch နဲ့ handle လုပ်ပါ။ react-error-boundary လို library တွေက reset support ပါတဲ့ အသင့်သုံး component ပေးပါတယ်။

နည်းလမ်းတစ်ခုကို ရွေးပြီး တသမတ်တည်း သုံးပါ — BEM လို naming convention၊ scope ပါတဲ့ CSS Modules၊ utility-first Tailwind ဒါမှမဟုတ် CSS-in-JS။ Color၊ spacing နဲ့ typography အတွက် design token (CSS custom property) တွေပေါ်မှာ အခြေခံပါ။ Modern CSS ကလည်း ကူညီပါတယ် — cascade layer (@layer) တွေက order ကို ထိန်းပေးပြီး :where() က specificity ကို နိမ့်နေစေပါတယ်။

အားသာချက် — မြန်မြန်တည်ဆောက်လို့ရတယ်၊ design scale တသမတ်တည်းရှိတယ်၊ နာမည်ပေးစရာမလိုဘူး၊ production CSS သေးတယ်၊ style တွေက markup နားမှာပဲ ရှိတယ်။ အားနည်းချက် — class list ရှည်လို့ ဖတ်ရခက်နိုင်တယ်၊ သင်ယူရမယ့် အချိန်ရှိတယ်၊ ရှုပ်ထွေးတဲ့ state ဒါမှမဟုတ် animation တွေမှာ အဆင်မပြေနိုင်ဘူး။ နေရာတိုင်း @apply မသုံးဘဲ component တွေ ခွဲထုတ်တာက maintain လုပ်ရလွယ်စေပါတယ်။

z-index က stacking context တစ်ခုတည်းထဲက element တွေကိုပဲ နှိုင်းယှဉ်ပါတယ်။ z-index ပါတဲ့ position၊ 1 ထက်နည်းတဲ့ opacity၊ transform၊ filter နဲ့ isolation: isolate လို property တွေက context အသစ် ဖန်တီးပြီး children တွေက z-index ဘယ်လောက်မြင့်မြင့် parent ရဲ့ context ထဲကနေ ဘယ်တော့မှ မလွတ်နိုင်ပါဘူး။ Element ကိုပဲ မကြည့်ဘဲ ancestor တွေကို စစ်ပါ။

Browser က screen နဲ့ကိုက်တဲ့ size ကို download လုပ်နိုင်အောင် width descriptor ပါတဲ့ srcset နဲ့ sizes ကို သုံးပြီး art direction ဒါမှမဟုတ် AVIF၊ WebP လို modern format တွေကို fallback နဲ့တကွ ပေးဖို့ <picture> ကို သုံးပါ။ Layout shift မဖြစ်အောင် width နဲ့ height (ဒါမှမဟုတ် aspect-ratio) ကို အမြဲထည့်ပြီး fold အောက်က image တွေကို lazy-load လုပ်ပါ။

User အစစ်တွေပေါ်မှာ 75th percentile နဲ့ တိုင်းတာတဲ့ Google ရဲ့ user-centred metric သုံးခုပါ။

Code splitting က JavaScript bundle ကို chunk တွေအဖြစ် ခွဲလိုက်လို့ user တွေက လက်ရှိ page အတွက် လိုတာကိုပဲ download လုပ်ရပါတယ်။ React မှာ React.lazy နဲ့ Suspense ဒါမှမဟုတ် framework ရဲ့ dynamic import နဲ့ ခွဲပြီး များသောအားဖြင့် route အလိုက် ဒါမှမဟုတ် chart၊ editor လို လေးပြီး ရှားရှားပါးပါးသုံးတဲ့ component တွေအတွက် ခွဲပါတယ်။ Image နဲ့ iframe တွေကို loading="lazy" နဲ့ lazy-load လုပ်လို့ရပါတယ်။

Cache-Control က browser နဲ့ CDN တွေကို response ကို ဘယ်လောက်ကြာကြာ သိမ်းထားရမလဲ ပြောပါတယ်။ Hash ပါတဲ့ static file (app.3f9a.js) တွေကို build အသစ်တိုင်း filename အသစ်ရလို့ immutable နဲ့ တစ်နှစ်လုံး cache လုပ်လို့ရပါတယ်။ HTML ကိုတော့ revalidate လုပ်သင့်ပါတယ် — ETag ပါတဲ့ no-cache က ဘာမှမပြောင်းရင် browser ကို စျေးပေါတဲ့ 304 Not Modified ရစေပါတယ်။

CORS ဆိုတာ တခြား origin က server က Access-Control-Allow-Origin လို header တွေနဲ့ ခွင့်မပြုရင် page က အဲ့ဒီ response ကို ဖတ်ခွင့်မပေးတဲ့ browser rule ပါ။ Custom header ဒါမှမဟုတ် method ပါတဲ့ request တွေက OPTIONS preflight ကို အရင်ပို့ပါတယ်။ ပြင်ရမှာက server ဘက်မှာပါ (ဒါမှမဟုတ် ကိုယ့် origin ပေါ်က proxy/BFF) — front end တစ်ခုတည်းနဲ့ ကျော်လို့မရပါဘူး။

Cross-site scripting ဆိုတာ attacker ထိန်းချုပ်တဲ့ input က page ထဲမှာ script အဖြစ် run သွားပြီး session ခိုးတာ ဒါမှမဟုတ် user အယောင်ဆောင်ပြီး လုပ်ဆောင်တာပါ။ React လို framework တွေက text ကို default အနေနဲ့ escape လုပ်တာမို့ အန္တရာယ်တွေက dangerouslySetInnerHTML၊ innerHTML၊ href="javascript:..." နဲ့ မလုံခြုံတဲ့ third-party HTML တွေပါ။ Render လုပ်ရမယ့် HTML မှန်သမျှကို sanitise လုပ်ပါ (DOMPurify)၊ ဒုတိယအလွှာအဖြစ် Content Security Policy ထည့်ပါ။

Cross-site request forgery ဆိုတာ login ဝင်ထားတဲ့ user ရဲ့ browser ကို တခြား site ကနေ ကိုယ့် site ဆီ request ပို့စေပြီး သူ့ cookie တွေကို အသုံးချတာပါ။ ကာကွယ်နည်းတွေက SameSite=Lax ဒါမှမဟုတ် Strict cookie၊ state ပြောင်းတဲ့ request တွေအတွက် anti-CSRF token၊ Origin header ကို စစ်တာ နဲ့ GET request တွေမှာ data ဘယ်တော့မှ မပြောင်းတာ ပါ။

ARIA ရဲ့ ပထမဆုံး rule က native element နဲ့ ရရင် ARIA မသုံးပါနဲ့ ဆိုတာပါ — <button> က <div role="button"> ထက် သာပါတယ်။ ARIA ကို တကယ့်ကွက်လပ်တွေ ဖြည့်ဖို့ သုံးပါ — icon သီးသန့် button တွေအတွက် aria-label၊ disclosure တွေအတွက် aria-expanded နဲ့ aria-controls၊ announcement တွေအတွက် aria-live နဲ့ tab ဒါမှမဟုတ် combobox လို custom widget တွေအတွက် မှန်ကန်တဲ့ role တွေ။ မှားတဲ့ ARIA က ARIA လုံးဝမရှိတာထက် ဆိုးပါတယ်။

Modal ပွင့်တဲ့အခါ focus ကို အထဲကို ရွှေ့ပါ၊ Tab နဲ့ Shift+Tab ကို အထဲမှာပဲ ပိတ်ထားပါ၊ Escape နဲ့ ပိတ်လို့ရအောင်လုပ်ပြီး ပိတ်တဲ့အခါ ဖွင့်ခဲ့တဲ့ button ဆီ focus ပြန်ပို့ပါ။ showModal() နဲ့ သုံးတဲ့ native <dialog> element က နောက်က page ကို inert ဖြစ်စေတာ အပါအဝင် ဒါအများစုကို ကိုင်တွယ်ပေးပါတယ်။

Unit test က function ဒါမှမဟုတ် component တစ်ခုကို သီးခြားစစ်ပြီး မြန်ပါတယ်။ Integration test က အစိတ်အပိုင်း အများအပြား အတူတကွ အလုပ်လုပ်တာကို စစ်ပါတယ် — validation နဲ့ API mock ပါတဲ့ form လိုမျိုး။ End-to-end test က browser အစစ်ကို user flow တစ်ခုလုံး ဖြတ်မောင်းတာမို့ နှေးပေမဲ့ ယုံကြည်မှုအများဆုံး ပေးပါတယ်။ ကျန်းမာတဲ့ test suite မှာ မြန်တဲ့ test အများကြီးနဲ့ အရေးကြီးတဲ့ E2E flow အနည်းငယ် ရှိပါတယ်။

"Test တွေက software ကို သုံးပုံနဲ့ တူလေ ယုံကြည်မှု ပိုပေးလေ" ဆိုတာပါ။ ဒါကြောင့် user တွေနဲ့ assistive tech တွေ ရှာသလို screen ကို query လုပ်ပါတယ် — getByRole၊ getByLabelText၊ getByText၊ user-event နဲ့ interact လုပ်ပြီး internal state ဒါမှမဟုတ် implementation detail တွေကို မဟုတ်ဘဲ မြင်ရတဲ့ output ကို assert လုပ်ပါတယ်။ ဒါဆို refactor လုပ်လည်း test တွေ ဆက်အောင်ပါတယ်။

fetch ဒါမှမဟုတ် ကိုယ့် API module ကို mock လုပ်မယ့်အစား network level မှာ mock လုပ်လို့ ကိုယ့်ရဲ့ data-fetching code အစစ်က run ပါတယ်။ Mock Service Worker (MSW) က test ထဲမှာရော browser ထဲမှာပါ request တွေကို ကြားဖြတ်ပြီး ကိုယ်သတ်မှတ်ထားတဲ့ fixture တွေ ပြန်ပေးလို့ loading၊ success နဲ့ error state တွေကို လက်တွေ့ကျကျ စစ်လို့ရပါတယ်။

Bundler (Vite၊ webpack၊ Rspack၊ Turbopack) က import တွေကို လိုက်ပြီး code (TypeScript၊ JSX၊ modern syntax) ကို transform လုပ်၊ module တွေကို optimise လုပ်ထားတဲ့ chunk တွေအဖြစ် bundle လုပ်ကာ CSS နဲ့ asset တွေကိုပါ ကိုင်တွယ်ပါတယ်။ Tree shaking က ဘယ်သူမှ import မလုပ်တဲ့ export တွေကို ဖယ်ရှားတာပါ၊ ES modules နဲ့ side effect မရှိတဲ့ package တွေမှာ အလုပ်လုပ်တာမို့ support လုပ်တဲ့ library တွေကနေ named import ကို ဦးစားပေးသုံးပါ။

Offset pagination (?page=3) က ရိုးရှင်းပေမဲ့ data ပြောင်းတဲ့အခါ item တွေ ကျော်သွားတာ ဒါမှမဟုတ် ထပ်နေတာ ဖြစ်နိုင်ပါတယ်။ Cursor pagination (?after=abc) က တည်ငြိမ်ပြီး infinite feed တွေနဲ့ သင့်တော်ပါတယ်။ Infinite scroll အတွက် sentinel element ပေါ်မှာ IntersectionObserver သုံးပြီး နောက် page ကို load လုပ်ပါ၊ မြင်ရတဲ့ "Load more" fallback ကို ထားပါ၊ list အရှည်ကြီးတွေကို virtualise လုပ်ပါ။

Native HTML validation attribute (required၊ type="email"၊ pattern) တွေကို အခြေခံအဖြစ် သုံးပြီး ဖြစ်နိုင်ရင် server နဲ့ မျှသုံးတဲ့ schema (Zod၊ Valibot) နဲ့ validate လုပ်ပါ၊ error တွေကို keystroke တိုင်းမှာ မဟုတ်ဘဲ user က field ကနေ ထွက်သွားမှ field ဘေးမှာ ပြပါ။ Client check တွေကို ကျော်လို့ရတာမို့ server မှာ အမြဲ ပြန် validate လုပ်ပါ။

နှစ်ခုစလုံးက branch တစ်ခုက ပြောင်းလဲမှုတွေကို တခြား branch ထဲ ယူလာပါတယ်။ merge က merge commit ထည့်ပြီး history အစစ်ကို ထိန်းထားပါတယ်၊ rebase ကတော့ ကိုယ့် commit တွေကို target ရဲ့ အပေါ်မှာ ပြန် replay လုပ်လို့ history က တန်းတန်းလေး ဖြစ်ပါတယ်။ Pull request မတင်ခင် ကိုယ့် feature branch ကို rebase လုပ်တာက history ကို သန့်ရှင်းစေပေမဲ့ တခြားသူတွေ pull လုပ်ပြီးသား shared commit တွေကိုတော့ ဘယ်တော့မှ rebase မလုပ်ပါနဲ့။

ပြောင်းလဲမှု တစ်ခုတည်းကို အာရုံစိုက်ပြီး သေးသေးလေးထားပါ၊ ဘာလုပ်လဲ ဘာကြောင့်လဲ ဆိုတာ ရှင်းတဲ့ title နဲ့ description၊ UI ပြောင်းလဲမှုတွေအတွက် screenshot နဲ့ ဘယ်လို test လုပ်ခဲ့လဲ ဆိုတဲ့ မှတ်ချက်တွေ ထည့်ပါ။ Diff ကို ကိုယ်တိုင် အရင် review လုပ်ပါ၊ CI အောင်အောင်လုပ်ပြီး review comment တွေကို ခုခံကာကွယ်တဲ့ပုံစံမဟုတ်ဘဲ အကြောင်းပြချက်နဲ့ တုံ့ပြန်ပါ။

Senior interview တွေမှာ "ဒါဘယ်လိုအလုပ်လုပ်လဲ" ကနေ "ဒါကို ဘယ်လို design လုပ်မလဲ၊ ဘယ်လိုတိုင်းတာမလဲ၊ ဘယ်လိုပြင်မလဲ" ဆီ ပြောင်းသွားပါတယ်။ Rendering strategy၊ scale ကြီးတဲ့ performance၊ security၊ testing strategy နဲ့ system boundary တွေအကြောင်း open question တွေ မျှော်လင့်ထားပါ။ အဖြေကောင်းတွေက trade-off တွေကို ဖော်ပြတယ်၊ ဘာကို တိုင်းတာမလဲ ပြောတယ်၊ ဒီပြဿနာတွေကို production မှာ တကယ်ကြုံဖူးကြောင်း ပြနိုင်ပါတယ်။

HTML ကို DOM အဖြစ်၊ CSS ကို CSSOM အဖြစ် parse လုပ်ပြီး နှစ်ခုပေါင်းကာ render tree ဖြစ်လာပါတယ်။ Style က computed style တွေကို ဆုံးဖြတ်တယ်၊ Layout က box တစ်ခုချင်းရဲ့ geometry ကို တွက်တယ်၊ Paint က drawing command တွေကို layer တွေထဲ မှတ်တမ်းတင်တယ်၊ Composite က အဲ့ layer တွေကို GPU ပေါ်မှာ စုစည်းပါတယ်။ Geometry ပြောင်းရင် layout နဲ့ paint ပြန် run ရပေမဲ့ transform ဒါမှမဟုတ် opacity လောက်ပဲ ပြောင်းရင် compositing ဆီ တိုက်ရိုက်ကျော်သွားနိုင်ပါတယ်။

Layout thrashing ဆိုတာ DOM ကို ရေးတာနဲ့ offsetHeight ဒါမှမဟုတ် getBoundingClientRect လို layout ဖတ်တာကို အလှည့်ကျလုပ်ပြီး frame တစ်ခုထဲမှာ browser ကို layout အကြိမ်ကြိမ် ပြန်တွက်ခိုင်းတာပါ။ ဖတ်တာအားလုံးကို အရင်လုပ်ပြီးမှ ရေးတာအားလုံးကို လုပ်ပါ၊ ဒါမှမဟုတ် ရေးတာတွေကို requestAnimationFrame ထဲမှာ schedule လုပ်ပါ။

width၊ top ဒါမှမဟုတ် box-shadow အစား main thread ကို မထိဘဲ compositor က ကိုင်တွယ်နိုင်တဲ့ transform နဲ့ opacity ကိုပဲ animate လုပ်ပါ။ setInterval ကို ဘယ်တော့မှ မသုံးဘဲ CSS transition၊ Web Animations API ဒါမှမဟုတ် requestAnimationFrame ကို သုံးပါ။ Animate လုပ်တော့မယ့် element တွေမှာပဲ will-change ကို ချင့်ချင့်ချိန်ချိန် ထည့်ပြီး prefers-reduced-motion ကို လေးစားပါ။

Strategy တစ်ခုချင်းက freshness၊ speed နဲ့ server cost ကို မတူတဲ့ပုံစံနဲ့ ချိန်ခွင်လျှာညှိပါတယ်။

Hydration ဆိုတာ server က render လုပ်ထားတဲ့ HTML ပေါ်မှာ client က component code ကို ပြန် run ပြီး event handler နဲ့ state တွေ ချိတ်ပေးတာပါ။ ပြီးဆုံးတဲ့အထိ page က အဆင်သင့်ဖြစ်နေသလို မြင်ရပေမဲ့ တုံ့ပြန်မှုမရှိနိုင်လို့ INP ကို ထိခိုက်ပါတယ်။ JavaScript နဲ့ component ပမာဏ များလေ စျေးကြီးလေဖြစ်လို့ client code နည်းနည်းပဲ ပို့တာ (Server Components၊ islands)၊ အပိုင်းတွေ သီးခြား hydrate ဖြစ်အောင် Suspense နဲ့ stream လုပ်တာ၊ fold အောက်က widget တွေကို lazy-load လုပ်တာတွေက ဖြေရှင်းနည်းတွေပါ။

Server က render လုပ်တဲ့ HTML နဲ့ client ရဲ့ ပထမဆုံး render မတူတဲ့အခါ ဖြစ်ပါတယ် — render လုပ်ချိန်မှာ Date.now()၊ Math.random()၊ window ဒါမှမဟုတ် localStorage သုံးတာ၊ locale ပေါ်မူတည်တဲ့ formatting နဲ့ <p> ထဲမှာ <div> ထည့်တာလို မှားတဲ့ HTML nesting တွေကြောင့်ပါ။ နှစ်ဘက်လုံးမှာ အတူတူ render လုပ်ပြီး browser-only value တွေကို effect ထဲ ဒါမှမဟုတ် server snapshot ပါတဲ့ useSyncExternalStore ထဲ ရွှေ့ပါ။

Server Components တွေက server ပေါ်မှာပဲ (build time ဒါမှမဟုတ် request time) run ပြီး database ဒါမှမဟုတ် secret တွေကို တိုက်ရိုက်ဖတ်နိုင်ကာ render လုပ်ပြီးသား ရလဒ်ကို သူတို့အတွက် JavaScript လုံးဝမပါဘဲ client ဆီ ပို့ပါတယ်။ "use client" နဲ့ မှတ်ထားတဲ့ Client Components တွေက interactive ဖြစ်တဲ့ အရွက်လေးတွေပါ။ အဓိကကျွမ်းကျင်မှုက boundary ကို ဆွဲတာပါ — data များပြီး static ဖြစ်တဲ့ အပိုင်းတွေကို server မှာထားပြီး interactivity ကို client component သေးသေးလေးတွေဆီ ချပေးပါ။

Server Component ကနေ Client Component ကို ပေးတဲ့ prop တွေက serialisable ဖြစ်ရပါမယ် — plain object၊ array၊ string၊ number၊ date၊ promise နဲ့ JSX တွေပါ။ "use server" နဲ့ မှတ်ထားတဲ့ Server Action မဟုတ်ရင် function တွေကို ပေးလို့မရပါဘူး။ Client Component က Server Component ကို import လုပ်လို့မရပေမဲ့ children အဖြစ် လက်ခံလို့ရတာမို့ server က render လုပ်ထားတဲ့ content ကို interactive wrapper တွေထဲမှာ ထားလို့ရပါတယ်။

Server က data နှေးနေတဲ့နေရာတွေမှာ Suspense fallback တွေနဲ့ page shell ကို ချက်ချင်းပို့ပါတယ်။ Data တစ်ခုချင်း resolve ဖြစ်လာတာနဲ့အမျှ React က ပြီးသွားတဲ့ HTML ကို response တစ်ခုတည်းထဲ stream လုပ်ပြီး အစားထိုးကာ အပိုင်းတွေကို သီးခြား hydrate လုပ်ပါတယ်။ User တွေက content ကို ပိုစောစော မြင်ရပြီး နှေးတဲ့ query တွေက page တစ်ခုလုံးကို မပိတ်ဆို့တော့ပါဘူး။

သူတို့က update တချို့ကို အရေးမကြီးဘူးလို့ မှတ်လိုက်လို့ React က typing၊ click လို အရေးကြီးတဲ့ update တွေကို responsive ဖြစ်အောင် ထိန်းထားနိုင်ပါတယ်။ startTransition က state update (tab ပြောင်းတာ ဒါမှမဟုတ် list ကြီးကို filter လုပ်တာလို) ကို ကြားဖြတ်လို့ရအောင် ထုပ်ပေးပြီး useDeferredValue က UI ရဲ့ လေးတဲ့ အပိုင်းကို မြန်မြန်ပြောင်းနေတဲ့ value နောက်ကို နောက်ကျပြီး လိုက်ခွင့်ပေးပါတယ်။ နှစ်ခုစလုံး INP ကို တိုးတက်စေတဲ့ ကိရိယာတွေပါ။

React 19 က async UI ကို first-class ဖြစ်စေခဲ့ပါတယ်။

Request အောင်မြင်ပြီးသားလို UI ကို ချက်ချင်း update လုပ်၊ request ပို့၊ fail ဖြစ်ရင် error message နဲ့ ပြန် rollback လုပ်ပါ။ React 19 မှာ useOptimistic က ယာယီ state ကို pending action နဲ့ ချိတ်ထားပြီး action settle ဖြစ်တာနဲ့ အလိုအလျောက် ဖယ်ပေးပါတယ်၊ TanStack Query ကလည်း onMutate နဲ့ onError ထဲက rollback သုံးပြီး ပုံစံအတူတူကို support လုပ်ပါတယ်။

Field data ဒါမှမဟုတ် DevTools ထဲမှာ LCP element ကိုရှာပြီး အချိန်ကို အဆင့်တွေခွဲပါ — server response (TTFB)၊ resource load delay၊ load time နဲ့ render delay။ အဖြစ်များတဲ့ ပြင်ဆင်ချက်တွေက LCP image ကို HTML ထဲမှာ တွေ့နိုင်အောင်လုပ်တာ (lazy-load မလုပ်ဘဲ fetchpriority="high"၊ လိုရင် preload)၊ မှန်ကန်တဲ့ size နဲ့ modern format နဲ့ serve လုပ်တာ၊ render-blocking CSS နဲ့ JS ကို လျှော့တာနဲ့ HTML ကို CDN မှာ cache လုပ်တာတွေပါ။

INP က user interaction ကနေ နောက် frame အထိ delay ကို တိုင်းတာပါတယ်။ Main thread က တုံ့ပြန်နိုင်အောင် long task တွေကို ခွဲပါ (scheduler.yield() ဒါမှမဟုတ် chunking)၊ feedback ကို paint မလုပ်ခင် အလုပ်အနည်းဆုံးပဲ လုပ်ပါ၊ လေးတဲ့ တွက်ချက်မှုကို Web Worker ဆီ ရွှေ့ပါ၊ hydration နဲ့ third-party script cost ကို လျှော့ပါ၊ synchronous re-render ကြီးတွေကို ရှောင်ပါ — React မှာ transition တွေက ကူညီပါတယ်။ Real-user data နဲ့ Performance panel နဲ့ တိုင်းတာပါ။

CLS က first paint ပြီးမှ ရွေ့သွားတဲ့ content ကနေ လာပါတယ် — dimension မပါတဲ့ image နဲ့ embed တွေ၊ content အပေါ်မှာ ထည့်လိုက်တဲ့ ad နဲ့ banner တွေ၊ metric မတူတဲ့ web font တွေ swap ဖြစ်တာနဲ့ နောက်ကျမှ inject လုပ်တဲ့ content တွေပါ။ width/height ဒါမှမဟုတ် aspect-ratio နဲ့ နေရာကြိုယူထားပါ၊ size မှန်တဲ့ skeleton တွေ သုံးပါ၊ fallback font metric ကို ကိုက်ညီအောင်လုပ်ပါ (size-adjust)၊ layout property အစား transform နဲ့ animate လုပ်ပါ။

Module တစ်ခုချင်းရဲ့ size ကိုကြည့်ဖို့ bundle analyser (rollup-plugin-visualizer၊ webpack-bundle-analyzer ဒါမှမဟုတ် framework ရဲ့ကိုယ်ပိုင်) ကို run ပြီး first-load chunk ထဲ ဘာရောက်နေလဲ စစ်ပါ။ အဖြစ်များတဲ့ တရားခံတွေက library တစ်ခုလုံးကို import လုပ်တာ၊ moment လို date library တွေ၊ dependency တစ်ခုရဲ့ version ထပ်နေတာနဲ့ support မလုပ်တဲ့ browser တွေအတွက် polyfill တွေပါ။ Regression ဖြစ်ရင် build fail ဖြစ်အောင် CI မှာ size budget ထည့်ပါ။

သံသယရှိတဲ့ flow ကို အကြိမ်ကြိမ် ပြန်လုပ်ပြီး DevTools မှာ heap snapshot တွေယူကာ နှိုင်းယှဉ်ပြီး ဘယ် object တွေ ဆက်ကြီးလာနေလဲ ကြည့်ပါ၊ ပြီးရင် သူတို့ရဲ့ retainer တွေကို လိုက်ပါ။ ပုံမှန်အကြောင်းရင်းတွေက ဘယ်တော့မှ cleanup မလုပ်တဲ့ event listener၊ interval နဲ့ subscription တွေ၊ JavaScript က reference ဆက်ကိုင်ထားတဲ့ detached DOM node တွေ၊ အကန့်အသတ်မရှိတဲ့ cache တွေနဲ့ object ကြီးတွေကို ကိုင်ထားတဲ့ closure တွေပါ။

မဟုတ်ရင် main thread ကို ပိတ်ဆို့မယ့် CPU လေးတဲ့ အလုပ်တွေအတွက်ပါ — file ကြီးတွေ parse လုပ်တာ၊ image processing၊ search indexing၊ diffing ဒါမှမဟုတ် ရှုပ်ထွေးတဲ့ တွက်ချက်မှုတွေ။ Worker တွေက DOM ကို မထိနိုင်ဘဲ message နဲ့ ဆက်သွယ်တာမို့ အပြန်အလှန် copy ကူးတဲ့ data ပမာဏ အရေးကြီးပါတယ် — buffer ကြီးတွေအတွက် transferable object တွေသုံးပြီး API ကို ပုံမှန် function call လို ခံစားရအောင် Comlink လို helper ကို သုံးပါ။

Service worker ဆိုတာ app နဲ့ network ကြားမှာ ရှိတဲ့ script ပါ — offline သုံးဖို့ asset တွေကို cache လုပ်တာ၊ caching strategy တွေ apply လုပ်တာ၊ push notification နဲ့ background sync တွေကို ကိုင်တွယ်တာ လုပ်နိုင်ပါတယ်။ အန္တရာယ်က အလွန်အကျွံ cache လုပ်တာပါ — user တွေ version ဟောင်းမှာ ပိတ်မိနေနိုင်တာမို့ cache တွေကို version ထားပါ၊ strategy တွေကို သေချာရွေးပါ၊ update ဒါမှမဟုတ် unregister လုပ်ဖို့ အစီအစဉ်ရှိပါစေ။

ဒါတွေက service worker နဲ့ data layer တွေအတွက် caching strategy တွေပါ။

အဖြစ်များတဲ့ case ကို ရိုးရှင်းစေပြီး ရှားတဲ့ case ကို ဖြစ်နိုင်စေပါ။ Boolean prop အရှည်ကြီးတွေထက် composition (children၊ <Tabs.List> လို compound component) ကို ဦးစားပေးပါ၊ controlled ရော uncontrolled ပါ သုံးလို့ရအောင်လုပ်ပါ၊ ref နဲ့ အပို HTML attribute တွေကို forward လုပ်ပါ၊ library တစ်ခုလုံးမှာ နာမည်တွေကို တသမတ်တည်း ထားပါ။ Keyboard support နဲ့ role တွေလို accessibility ကတော့ ရွေးချယ်စရာမဟုတ်ဘဲ မူလကတည်းက ပါရပါမယ်။

Design token (color၊ spacing၊ type၊ radius၊ motion) တွေကို single source of truth အဖြစ်ထားပြီး စတင်ပါ၊ ပြီးမှ accessible primitive တွေတည်ဆောက်ကာ component ကြီးတွေကို အဲ့ဒါတွေနဲ့ ပေါင်းဖွဲ့ပါ။ Component တိုင်းကို live example တွေနဲ့ document လုပ်ပါ (Storybook)၊ visual နဲ့ accessibility test လုပ်ပါ၊ semantic versioning နဲ့ changelog တွေနဲ့ version ထားပါ၊ product team တွေကို contribution process ပါတဲ့ customer အဖြစ် ဆက်ဆံပါ။

အဆုံးမှ audit လုပ်မယ့်အစား system ထဲမှာ ထည့်သွင်းတည်ဆောက်ပါ — design system ထဲက accessible component တွေ၊ linting (eslint-plugin-jsx-a11y)၊ unit နဲ့ E2E test ထဲမှာ axe နဲ့ automated check တွေ၊ အဓိက flow တွေကို keyboard နဲ့ screen reader နဲ့ စစ်ဆေးတာ။ Automated tool တွေက ပြဿနာတချို့ကိုပဲ ဖမ်းနိုင်တာမို့ manual audit တွေနဲ့ definition of done ထဲမှာ ရှင်းလင်းတဲ့ ownership ကို ထည့်ပါ။

Server state ဆိုတာ backend ပိုင်တဲ့ data ရဲ့ cache copy ပါ — ဟောင်းနိုင်တယ်၊ မျှသုံးတယ်၊ ပြန် fetch လုပ်ရတယ် — ဒါကြောင့် query cache (TanStack Query၊ SWR၊ RTK Query ဒါမှမဟုတ် framework ရဲ့ server data layer) ထဲမှာ ရှိသင့်ပါတယ်။ Client state ကိုတော့ UI ကပိုင်ပါတယ် — ဖွင့်ထားတဲ့ panel၊ form draft၊ selection တွေ။ နှစ်ခုကို global store တစ်ခုတည်းထဲ ရောထားရင် cache invalidation bug တွေကို ကိုယ်တိုင်ဖြေရှင်းရပါတယ်။

Entity အတူတူက နေရာအများကြီးမှာ ပေါ်တဲ့အခါပါ — list၊ sidebar နဲ့ detail page မှာ ပြတဲ့ user တစ်ယောက်လိုမျိုး၊ id နဲ့ တစ်ကြိမ်ပဲ သိမ်းပြီး တခြားနေရာတွေမှာ reference လုပ်လို့ update တစ်ခုက view အားလုံးဆီ ရောက်ပြီး ထပ်နေတာ မရှိတော့ပါဘူး။ Redux Toolkit ရဲ့ createEntityAdapter က ကူညီပါတယ်။ Query cache က အဲ့ data ကို ပိုင်ထားပြီးသားဆိုရင် normalisation က များသောအားဖြင့် မလိုပါဘူး။

REST က ရိုးရှင်းတယ်၊ HTTP level မှာ cache လုပ်လို့ရပြီး client မျိုးစုံနဲ့ အလုပ်လုပ်တယ်။ GraphQL က client တွေကို resource အများကြီးကနေ လိုတဲ့ field အတိအကျကိုပဲ တောင်းခွင့်ပေးလို့ ရှုပ်ထွေးတဲ့ UI နဲ့ client အမျိုးအစား အများကြီးအတွက် သင့်တော်ပေမဲ့ server ရှုပ်ထွေးမှုနဲ့ cache လုပ်ရခက်တာကို ပေးဆပ်ရပါတယ်။ tRPC က ceremony မရှိသလောက်နဲ့ end-to-end type safety ပေးပေမဲ့ client ရော server ပါ codebase တစ်ခုတည်းထဲမှာ TypeScript ဖြစ်မှပဲ ရပါတယ်။

BFF ဆိုတာ front-end team ပိုင်တဲ့ UI နဲ့ backend service တွေကြားက server layer ပါးပါးလေးပါ။ Call အများကြီးကို တစ်ခုတည်းဖြစ်အောင် စုတယ်၊ screen အတွက် data ကို ပုံဖော်ပေးတယ်၊ secret နဲ့ token တွေကို client ဆီ မရောက်အောင် ထိန်းတယ်၊ auth cookie တွေကို ကိုင်တွယ်တယ်။ UI က service အများကြီးနဲ့ ဆက်သွယ်ရတဲ့အခါ ဒါမှမဟုတ် client အမျိုးမျိုး (web၊ mobile) က ပုံစံမတူတာ လိုတဲ့အခါ တန်ပါတယ်။

Server က သတ်မှတ်ပေးတဲ့ HttpOnly၊ Secure၊ SameSite cookie တွေကို ဦးစားပေးပါ — JavaScript က ဖတ်လို့မရလို့ XSS bug တစ်ခုက ခိုးလို့မရပါဘူး။ Token တွေကို localStorage မှာ သိမ်းရင် inject လုပ်ခံရတဲ့ script မှန်သမျှ ဖတ်နိုင်ပါတယ်။ Access token ကို JavaScript ထဲမှာ မဖြစ်မနေ ကိုင်ထားရမယ်ဆိုရင် memory ထဲမှာ သက်တမ်းတိုတိုပဲ ထားပြီး HttpOnly refresh cookie နဲ့ refresh လုပ်ပါ။

သက်တမ်းတိုတဲ့ access token နဲ့ HttpOnly cookie ထဲက refresh token ကို သုံးပါ။ Request တစ်ခု 401 ရတဲ့အခါ refresh တစ်ခုတည်းကို စပြီး fail ဖြစ်နေတဲ့ တခြား request အားလုံးကို အဲ့ refresh promise အတူတူကို စောင့်ခိုင်းကာ token အသစ်နဲ့ တစ်ကြိမ် ပြန်ကြိုးစားပါ။ Refresh fail ဖြစ်ရင် user ကို သေသေသပ်သပ် logout လုပ်ပါ။

CSP ဆိုတာ ဘယ် source က script၊ style၊ image နဲ့ connection တွေကို ခွင့်ပြုလဲ browser ကို ပြောတဲ့ HTTP header ဖြစ်လို့ XSS bug ရှိနေရင်တောင် inject လုပ်ထားတဲ့ script တွေ ပိတ်ဆို့ခံရပါတယ်။ Strict policy က domain တွေကို allow-list လုပ်မယ့်အစား script အတွက် nonce ဒါမှမဟုတ် hash တွေကို သုံးပါတယ် (script-src 'nonce-…' 'strict-dynamic')။ Violation တွေ ရှာဖို့ Report-Only mode နဲ့ အရင် စတင်ပါ။

CSP အပြင် header အနည်းငယ်က အဖြစ်များတဲ့ တိုက်ခိုက်မှု လမ်းကြောင်းတွေကို ပိတ်ပေးပါတယ်။

SRI က CDN ကနေ load လုပ်တဲ့ <script> ဒါမှမဟုတ် <link> မှာ integrity hash ထည့်ပေးပြီး file ရဲ့ content က မကိုက်ရင် browser က run ဖို့ ငြင်းပါတယ်။ Third-party host က compromise ဖြစ်သွားရင် ကိုယ့်ကို ကာကွယ်ပေးပါတယ်။ မပြောင်းလဲတဲ့ file တွေမှာပဲ အလုပ်လုပ်တာမို့ pin လုပ်ထားတဲ့ version တွေနဲ့ သုံးပါ။

User မြင်ရတဲ့ text အားလုံးကို string တွေ ဆက်ပေါင်းတာနဲ့ ဘယ်တော့မှ မလုပ်ဘဲ key ပါတဲ့ message catalogue တွေထဲမှာ ထားပြီး plural နဲ့ variable တွေအတွက် ICU message syntax သုံးပါ။ Date၊ number နဲ့ currency တွေကို user ရဲ့ locale အတွက် Intl API တွေနဲ့ format လုပ်ပါ၊ 30% နဲ့ အထက် ရှည်လာတဲ့ text နဲ့ line height ပိုလိုတဲ့ မြန်မာစာလို script တွေအတွက် ကြိုစီစဉ်ပါ၊ font နဲ့ screen reader တွေ မှန်ကန်စွာ အလုပ်လုပ်အောင် lang attribute ကို သတ်မှတ်ပါ။

Document မှာ dir="rtl" သတ်မှတ်ပြီး left/right အစား CSS logical property တွေ — margin-inline-start၊ padding-inline၊ inset-inline-end၊ text-align: start — ကို သုံးလို့ layout က အလိုအလျောက် mirror ဖြစ်ပါတယ်။ Arrow လို ဦးတည်ချက်ပြ icon တွေကို mirror လုပ်ပေမဲ့ play button ဒါမှမဟုတ် logo လိုဟာတွေကို မလုပ်ပါနဲ့၊ RTL content အစစ်နဲ့ စမ်းသပ်ပါ။

"Testing trophy" ကို လိုက်နာပါ — အခြေခံအဖြစ် static analysis (TypeScript၊ ESLint)၊ component နဲ့ feature တွေအတွက် integration test အများကြီး၊ ရှုပ်ထွေးတဲ့ pure logic အတွက် unit test တွေနဲ့ sign-up၊ checkout လို အရေးကြီးတဲ့ လမ်းကြောင်းတွေမှာ end-to-end test အနည်းငယ်။ Design system အတွက် visual regression နဲ့ accessibility check တွေ ထည့်ပြီး လူတွေ တကယ် run ချင်လောက်အောင် suite ကို မြန်မြန်ထားပါ။

CSS selector အစား user မြင်ရတဲ့ ခိုင်မာတဲ့ locator (role၊ label) တွေ သုံးပါ၊ fixed sleep အစား auto-waiting assertion တွေကို အားကိုးပါ၊ test တွေ တစ်ခုနဲ့တစ်ခု မမှီခိုအောင် test data ကို seed လုပ်ပြီး isolate လုပ်ပါ၊ ပြင်ပ third party တွေကိုပဲ mock လုပ်ပါ၊ fail ဖြစ်ရင် trace နဲ့ video ပါအောင် parallel run ပါ။ ဒီ feature တွေအတွက် Playwright က အသုံးများတဲ့ ရွေးချယ်မှုပါ။

Component ဒါမှမဟုတ် page တွေကို render လုပ်၊ screenshot ယူပြီး အတည်ပြုထားတဲ့ baseline တွေနဲ့ နှိုင်းယှဉ်ကာ pixel ကွာခြားချက်တွေကို review လုပ်ဖို့ ပြပေးပါတယ်။ Functional test တွေ လွတ်သွားတဲ့ CSS regression တွေကို ဖမ်းပေးပါတယ်။ Noise လျှော့ဖို့ တသမတ်တည်းရှိတဲ့ environment မှာ run ပါ၊ animation နဲ့ date တွေကို freeze လုပ်ပါ၊ design system နဲ့ အဓိက page တွေကို အာရုံစိုက်ပါ။

Pull request တိုင်းမှာ — lock file နဲ့ install လုပ်၊ type-check၊ lint၊ test run၊ build၊ bundle size budget စစ်ပြီး review အတွက် preview URL ကို deploy လုပ်ပါ။ Merge လုပ်တဲ့အခါ — feature flag နောက်ကွယ်မှာ production ကို deploy လုပ်ပြီး monitoring က error တွေပြရင် အလိုအလျောက် rollback ဒါမှမဟုတ် မြန်မြန် redeploy လုပ်ပါ။ Pipeline မြန်နေအောင် dependency နဲ့ build တွေကို cache လုပ်ပါ။

အားသာချက် — package publish မလုပ်ဘဲ code နဲ့ type တွေ မျှသုံးလို့ရတယ်၊ app နဲ့ library တွေကို တစ်ပြိုင်နက် atomic ပြောင်းလို့ရတယ်၊ tooling တစ်စုံတည်းနဲ့ version တွေ တသမတ်တည်းဖြစ်တယ်။ အားနည်းချက် — task caching နဲ့ ထိခိုက်တာကိုပဲ build လုပ်တာ (Turborepo၊ Nx) မရှိရင် CI နှေးလာနိုင်တယ်၊ ownership မှုန်ဝါးလာနိုင်ပြီး repo size ကြီးလာတယ်။ App အများကြီးက code အများကြီး မျှသုံးတဲ့အခါ တန်ပါတယ်။

သီးခြား team အများကြီးက product ကြီးတစ်ခုရဲ့ အစိတ်အပိုင်းတွေကို သီးခြား deploy လုပ်ရတဲ့အခါ အဓိပ္ပာယ်ရှိပါတယ် — အကျိုးကျေးဇူးက organisation ဆိုင်ရာပါ။ ပေးဆပ်ရတာတွေက အစစ်ပါ — dependency ထပ်နေတာနဲ့ bundle ကြီးလာတာ၊ UX မညီညွတ်တာ၊ shared state နဲ့ routing ရှုပ်ထွေးတာ၊ test လုပ်ရ ပိုခက်တာ။ ကုမ္ပဏီအများစုအတွက်တော့ ownership ရှင်းတဲ့ structure ကောင်းတဲ့ monorepo က ပိုရိုးရှင်းတဲ့ ရွေးချယ်မှုပါ။

Stack trace တွေက ကိုယ့် code အစစ်ကို ညွှန်ပြအောင် source map တင်ထားတဲ့ error tracking (Sentry လိုမျိုး)၊ page နဲ့ device အလိုက် Core Web Vitals အတွက် real-user monitoring (RUM) နဲ့ အဓိက business event တွေရဲ့ logging ကို သုံးပါ။ အရာအားလုံးကို release version နဲ့ tag လုပ်ပြီး error rate နဲ့ vitals regression တွေအပေါ် alert ထားလို့ user တွေ report မလုပ်ခင် ပြဿနာကို သိရပါတယ်။

Flag တွေက code ကို deploy လုပ်တာနဲ့ feature ကို release လုပ်တာကို ခွဲထုတ်ပေးပါတယ် — မပြီးသေးတဲ့ အလုပ်ကို flag နောက်ကွယ်မှာ merge လုပ်လို့ရတယ်၊ user ရာခိုင်နှုန်းတစ်ခုဆီ rollout လုပ်တယ်၊ A/B test run တယ်၊ redeploy မလုပ်ဘဲ feature ကို ချက်ချင်း ပိတ်လို့ရတယ်။ ရှုပ်ထွေးမှုကို ပေးဆပ်ရတာမို့ flag တိုင်းကို owner တစ်ယောက်ပေးပြီး rollout ပြီးတာနဲ့ ဖယ်ရှားပါ။

Discriminated union ဆိုတာ status လို literal field တစ်ခုကို မျှသုံးတဲ့ object type တွေရဲ့ union ပါ။ အဲ့ field ကို စစ်လိုက်တာနဲ့ type က narrow ဖြစ်သွားလို့ data နဲ့ error တစ်ပြိုင်နက်ရှိတာလို မဖြစ်နိုင်တဲ့ state တွေကို ကိုယ်စားမပြုနိုင်တော့ဘဲ never check ပါတဲ့ exhaustive switch က မေ့သွားတဲ့ case မှန်သမျှကို compiler က ပြပေးပါတယ်။

Mapped type က တခြား type ရဲ့ key တစ်ခုချင်းကို ပြောင်းပြီး type အသစ်တည်ဆောက်ပါတယ်၊ conditional type က စစ်ဆေးချက် (T extends U ? X : Y) အပေါ်မူတည်ပြီး type ကိုရွေးကာ infer နဲ့ အစိတ်အပိုင်းတွေ ထုတ်ယူနိုင်ပါတယ်။ နှစ်ခုပေါင်းပြီး Partial နဲ့ ReturnType လို utility တွေကို ဖြစ်စေပါတယ်။

WOFF2 file တွေကို self-host လုပ်ပြီး လိုတဲ့ character တွေပဲ ပါအောင် subset လုပ်ပါ၊ အရေးကြီးတဲ့ face တစ်ခုနှစ်ခုကိုပဲ preload လုပ်ပြီး font-display: swap (မရှိမဖြစ်မဟုတ်တဲ့ font တွေအတွက် optional) ကို သုံးပါ။ Layout shift မဖြစ်အောင် size-adjust နဲ့ ascent-override သုံးပြီး fallback font ရဲ့ metric ကို ကိုက်ညီအောင်လုပ်ကာ weight အများကြီး သီးခြားထားမယ့်အစား variable font ကို ဦးစားပေးပါ။

CDN က user တွေနဲ့ နီးတဲ့ server တွေကနေ file တွေကို serve လုပ်လို့ latency ကို လျှော့ပေးပြီး traffic ရုတ်တရက်တက်တာကို ခံပေးပါတယ်။ Hash ပါတဲ့ static asset တွေကို အကြာကြီး cache လုပ်ပါ၊ HTML ကို ခဏပဲ ဒါမှမဟုတ် stale-while-revalidate နဲ့ cache လုပ်ပြီး deploy လုပ်တိုင်း purge လုပ်ပါ၊ personalised response တွေကို private ထားပါ။ Edge function တွေက redirect၊ A/B split နဲ့ auth check တွေကို user နားမှာပဲ ကိုင်တွယ်နိုင်ပါတယ်။

Virtualise လုပ်ပါ — viewport ထဲနဲ့ အနားက row တွေကိုပဲ render လုပ်ပြီး scrollbar မှန်နေအောင် spacer တွေ သုံးပါ (TanStack Virtual၊ react-window)။ Row component တွေကို ပေါ့ပါးပြီး memoise လုပ်ထားပါ၊ row တွေကို တည်ငြိမ်တဲ့ key ပေးပါ၊ scroll လုပ်တိုင်း layout တိုင်းတာတာကို ရှောင်ပါ။ ပိုရိုးရှင်းတဲ့ case တွေအတွက် CSS content-visibility: auto က screen ပြင်ပ section တွေကို browser က render မလုပ်ဘဲ ကျော်ခွင့်ပေးပါတယ်။

Shared schema သုံးပြီး ကိုယ်ပိုင် validation ပါတဲ့ step တွေအဖြစ် ခွဲပါ၊ data ကို step တစ်ခုချင်းရဲ့ state မှာ မဟုတ်ဘဲ form store တစ်ခုတည်း (React Hook Form ဒါမှမဟုတ် reducer) ထဲမှာ ထားပါ၊ refresh လုပ်လည်း အလုပ်မပျောက်အောင် draft တွေ သိမ်းပါ။ Keyboard နဲ့ သွားလာလို့ရအောင်လုပ်ပါ၊ error တွေကို screen reader ကို announce လုပ်ပါ၊ data မပျောက်ဘဲ နောက်ပြန်သွားခွင့်ပေးပြီး server မှာ အားလုံးကို ပြန် validate လုပ်ပါ။

ကိုက်ညီတဲ့ အရိုးရှင်းဆုံး transport ကို ရွေးပါ — ရှားရှားပါးပါး update အတွက် polling၊ server ကနေ client ဆီ တစ်လမ်းသွား stream အတွက် Server-Sent Events၊ chat ဒါမှမဟုတ် collaboration လို နှစ်လမ်းသွား latency နည်းတဲ့ feature တွေအတွက် WebSockets။ Backoff ပါတဲ့ reconnection၊ လွတ်သွားတဲ့ message တွေ (နောက်ဆုံးမြင်ခဲ့တဲ့ id ကနေ ဆက်ယူတာ)၊ update တွေကို client cache ထဲ ပေါင်းတာနဲ့ server ဘက်မှာ connection တွေ scale လုပ်တာကို ကြိုစီစဉ်ပါ။

တစ်ခါတည်း အကုန်ပြန်ရေးတာ ဘယ်တော့မှ မလုပ်ဘဲ တဖြည်းဖြည်း လုပ်ပါ။ TypeScript အတွက် allowJs ကို ဖွင့်ပြီး shared utility တွေကနေစကာ အရွက်ဘက်က file တွေကို အရင်ပြောင်းပါ၊ strict option တွေကို အချိန်နဲ့အမျှ တင်းကျပ်လာအောင် လုပ်ပါ။ Framework အတွက် strangler pattern ကို သုံးပါ — route အသစ်တွေကို stack အသစ်နဲ့ ရေးပြီး ဟောင်းတာတွေကို domain တစ်ခုတည်းအောက်မှာ တစ်ပိုင်းချင်း migrate လုပ်ကာ တိုးတက်မှုကို metric နဲ့ ပြပြီး feature အလုပ်တွေကို မရပ်ထားပါနဲ့။

Tech lead တစ်ယောက်ကို သူတစ်ယောက်တည်း ဘာတည်ဆောက်နိုင်လဲ ဆိုတာထက် team က ဘာ ship လုပ်လဲ၊ ဘယ်လောက်ကောင်းလဲ၊ ဘယ်လောက် ရေရှည်တည်တံ့လဲ ဆိုတာနဲ့ ပိုအကဲဖြတ်ပါတယ်။ ဒီမေးခွန်းတွေက အများစု scenario တွေပါ — interviewer တွေက စနစ်ကျတဲ့ စဉ်းစားပုံ၊ ရှင်းလင်းတဲ့ ဆက်သွယ်ပြောဆိုမှု၊ အဓိပ္ပာယ်ရှိတဲ့ trade-off တွေနဲ့ လူတွေကို ကြီးထွားစေပြီး တခြားသူတွေ လိုက်နာနိုင်တဲ့ ဆုံးဖြတ်ချက်တွေ ချနိုင်ကြောင်း သက်သေကို နားထောင်ပါတယ်။

ခေတ်စားနေတာကနေ မစဘဲ product ရဲ့ လိုအပ်ချက် — SEO၊ interactivity၊ team size၊ hosting၊ ဘယ်လောက်ကြာကြာ ရှင်သန်ရမလဲ — ကနေ စပါ။ Option နှစ်ခုသုံးခုကို ရွေးချယ်ပြီး တစ်ခုချင်းမှာ အခက်ဆုံး feature ရဲ့ spike အသေးလေး တည်ဆောက်ကာ ecosystem ရင့်ကျက်မှု၊ hiring၊ performance၊ upgrade လမ်းကြောင်းနဲ့ lock-in ကို ချိန်ဆပါ။ ဆုံးဖြတ်ချက်ကို ငြင်းပယ်ခဲ့တဲ့ alternative တွေနဲ့ အကြောင်းပြချက်နဲ့အတူ ရေးမှတ်ထားပါ။

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

အရင်ဆုံး မြင်သာအောင်လုပ်ပါ — နှေးတဲ့ delivery၊ bug၊ incident၊ onboarding ခက်ခဲမှုလို တကယ့်ကုန်ကျစရိတ်နဲ့ ချိတ်ထားတဲ့ debt register ထားပါ။ စိတ်ကူးယဉ် cleanup quarter ကို မစောင့်ဘဲ အဆက်မပြတ် ဆပ်ပါ (sprint တိုင်းရဲ့ သတ်မှတ်ရာခိုင်နှုန်း၊ ဒါမှမဟုတ် code ကို ထိတိုင်း ပြင်တာ)၊ အပြောင်းအလဲ အများဆုံးဖြစ်တဲ့ area က debt ကို ဦးစားပေးပါ။ Business ကို code quality နဲ့ မဟုတ်ဘဲ speed နဲ့ risk နဲ့ ရှင်းပြပါ။

သူတို့ဂရုစိုက်တဲ့ ရလဒ်တွေအဖြစ် ဘာသာပြန်ပါ — "ဒီ checkout code က ကျွန်တော်တို့ incident တွေရဲ့ သုံးပုံတစ်ပုံကို ဖြစ်စေပြီး payment feature တိုင်းကို နှစ်ဆကြာစေတယ်"။ Cycle time၊ bug အရေအတွက်၊ incident history လို data တွေ ယူလာပါ၊ checkpoint တွေပါတဲ့ scope ကန့်သတ်ထားတဲ့ တဖြည်းဖြည်း plan ကို အဆိုပြုပြီး နောက်မှ ပိုစျေးပေါသွားမယ့် လာမယ့် feature တစ်ခုနဲ့ ချိတ်ပါ။

Review တွေက မြန်တယ် (အလုပ်ချိန်တစ်ရက်အတွင်း)၊ သေးတယ်၊ ကြင်နာတယ်၊ linter နဲ့ formatter တွေ ကိုင်တွယ်ပြီးသား style ထက် မှန်ကန်မှု၊ design နဲ့ maintainability ကို အာရုံစိုက်ပါတယ်။ Comment တွေက ဘာကြောင့်လဲ ရှင်းပြပြီး blocking issue တွေကို suggestion ("nit:") တွေနဲ့ ခွဲပါတယ်။ Senior တွေရဲ့ code အပါအဝင် လူတိုင်း review လုပ်ပြီး review ကို ဂိတ်စောင့်တာမဟုတ်ဘဲ အသိပညာမျှဝေမှုအဖြစ် ဆက်ဆံပါတယ်။

ထင်မြင်ချက်ကနေ စံနှုန်းဆီ ရွှေ့ပါ — ဘယ်ပြဿနာအတွက် optimise လုပ်နေတာလဲ၊ ဘယ်လို သက်သေရှိလဲ။ Comment တွေ နှစ်ကြိမ်ထက်ပို အပြန်အလှန် ဖြစ်နေရင် တိုက်ရိုက် စကားပြောပါ။ Option နှစ်ခုစလုံး အဓိပ္ပာယ်ရှိရင် များသောအားဖြင့် author ရဲ့ ရွေးချယ်မှုက နိုင်ပါတယ်၊ ထပ်ခါထပ်ခါ ငြင်းခုံရတဲ့ အကြောင်းဆိုရင် ထပ်မပေါ်လာအောင် team guideline ဒါမှမဟုတ် ADR အဖြစ် တစ်ကြိမ်တည်း ဖြေရှင်းလိုက်ပါ။

Definition of done ရှင်းတဲ့ scope ကောင်းကောင်း သတ်မှတ်ထားတဲ့ အလုပ်အစစ်တွေ ပေးပါ၊ အစောပိုင်းမှာ pair လုပ်ပါ၊ အဖြေကို တိုက်ရိုက်ပေးမယ့်အစား အဖြေဆီ ရောက်အောင် လမ်းပြတဲ့ မေးခွန်းတွေ မေးပါ။ သူတို့ code ကို ရှင်းပြချက်နဲ့ review လုပ်ပါ၊ ကြီးထွားမှုအကြောင်း one-to-one ပုံမှန်လုပ်ပါ၊ scope နဲ့ ownership ကို တဖြည်းဖြည်း တိုးပေးပါ။ မေးခွန်းမေးရတာ စိတ်လုံခြုံပါစေ — အမြန်ဆုံး သင်ယူသူတွေက အသစ်လို့ ထင်ခံရမှာ မကြောက်သူတွေပါ။

Document လုပ်ထားတဲ့ command တစ်ခုနဲ့ local setup ကို တစ်နာရီအတွင်း အလုပ်လုပ်အောင်လုပ်ပါ၊ buddy တစ်ယောက်ပေးပြီး ပထမအပတ်မှာ ပြောင်းလဲမှု အစစ်အသေးလေးတစ်ခု ship လုပ်ခွင့်ပေးပါ။ Architecture overview၊ glossary နဲ့ ဘယ်သူက ဘာပိုင်လဲ map ကို ပေးပါ။ လုပ်ရင်းနဲ့ onboarding docs ကို ပြင်ခိုင်းပါ — လူသစ်တွေက တခြားသူတွေ မမြင်တော့တဲ့ ကွက်လပ်တွေကို တွေ့ပါတယ်။

Candidate တိုင်းအတွက် မေးခွန်းအတူတူနဲ့ ရေးထားတဲ့ rubric ပါတဲ့ structured process ကို အလုပ်က တကယ်လိုတဲ့ skill တွေကို အာရုံစိုက်ပြီး သုံးပါ။ Trivia နဲ့ puzzle တွေထက် လက်တွေ့ကျတဲ့ exercise တွေ — component အသေးတစ်ခု တည်ဆောက်တာ ဒါမှမဟုတ် debug လုပ်တာ၊ design discussion၊ code review — ကို ဦးစားပေးပါ။ Candidate တွေကို အသံထွက်စဉ်းစားခွင့်ပေးပါ၊ hint ပေးပါ၊ code အပြင် communication နဲ့ collaboration ကိုပါ အကဲဖြတ်ပါ။

အလုပ်ကို အပိုင်းသေးသေးလေးတွေ ခွဲပါ၊ နံပါတ်တစ်ခုတည်း မပေးဘဲ range ပေးပါ၊ မသိတဲ့အရာတွေကို ရှင်းရှင်းလင်းလင်း ဖော်ပြပါ။ အန္တရာယ်အများဆုံး အပိုင်းအတွက် commit မလုပ်ခင် မသေချာမှုကို လျှော့ဖို့ spike ကို အချိန်ကန့်သတ်ပြီး လုပ်ပါ။ သိလာတာနဲ့အမျှ ပြန် estimate လုပ်ပြီး team ကို အချိန်နဲ့အမျှ ချိန်ညှိနိုင်အောင် အမှန်တကယ်ကြာချိန်နဲ့ estimate ကို နှိုင်းယှဉ်မှတ်တမ်းတင်ပါ။

ပြဿနာတစ်ခုတည်း မဟုတ်ဘဲ option တွေနဲ့အတူ စောစော ပြောပါ။ Product နဲ့ ပူးပေါင်းပြီး scope ကို ဖြတ်တာ ဒါမှမဟုတ် ရိုးရှင်းအောင်လုပ်ပါ — core value ပေးတဲ့ အသေးဆုံး version ကိုရှာ၊ nice-to-have တွေကို flag နောက်ကွယ် ရွှေ့ဆိုင်းပြီး ဘယ် quality bar တွေကို လျှော့မှာမဟုတ်ဘူးဆိုတာ (security၊ accessibility၊ data integrity) သဘောတူပါ။ Trade-off နဲ့ နောက်ဆက်တွဲ အလုပ်ကို မြင်သာအောင်မလုပ်ဘဲ test တွေကို တိတ်တိတ်လေး ဖြုတ်တာ ဒါမှမဟုတ် ဖြတ်လမ်းလိုက်တာ ဘယ်တော့မှ မလုပ်ပါနဲ့။

ရည်မှန်းချက်နဲ့ တိုးတက်မှုကို ဘယ်လိုတိုင်းမလဲ သတ်မှတ်ပါ၊ ပြီးရင် system နှစ်ခုစလုံး ဘေးချင်းယှဉ် run နေစဉ် တဖြည်းဖြည်း migrate လုပ်ပါ (strangler pattern)။ နည်းလမ်းကို သက်သေပြဖို့ pilot area တစ်ခုနဲ့ စပါ၊ တခြား team တွေ ကိုယ်တိုင် migrate လုပ်နိုင်အောင် codemod နဲ့ docs တွေ ပေးပါ၊ pattern ဟောင်းနဲ့ code အသစ်ရေးတာကို ပိတ်တဲ့ lint rule ထည့်ပြီး လမ်းကြောင်းဟောင်းကို ဖယ်ရှားမယ့် ရက်စွဲ သတ်မှတ်ပါ။

ကိုယ့် product ကို ထူးခြားစေတာကို တည်ဆောက်ပါ၊ commodity ဖြစ်တာတွေ — auth၊ payment၊ analytics၊ rich-text editing — ကို ဝယ်ပါ ဒါမှမဟုတ် ယူသုံးပါ။ ပိုင်ဆိုင်မှုရဲ့ စုစုပေါင်းကုန်ကျစရိတ် (maintenance၊ security update၊ on-call)၊ option တစ်ခုချင်း ဘယ်လောက်ကိုက်ညီလဲ၊ vendor ဒါမှမဟုတ် maintainer ကျန်းမာရေး၊ data နဲ့ compliance လိုအပ်ချက်တွေနဲ့ နောက်ပိုင်း ပြောင်းဖို့လိုရင် ထွက်ရမယ့် ကုန်ကျစရိတ်ကို နှိုင်းယှဉ်ပါ။

User တွေရဲ့ device နဲ့ network ကို အခြေခံပြီး user experience နဲ့ ချိတ်ထားတဲ့ budget တွေ — LCP နဲ့ INP target၊ route တစ်ခုချင်းရဲ့ JavaScript၊ image weight — ကို သဘောတူပါ။ Pull request တွေမှာ bundle-size check နဲ့ Lighthouse CI၊ alert ပါတဲ့ real-user monitoring dashboard တွေနဲ့ အလိုအလျောက် အကောင်အထည်ဖော်ပါ။ Fail ဖြစ်တဲ့ check က merge ကို ပိတ်တာ ဒါမှမဟုတ် ဆွေးနွေးမှုကို စတင်စေမှပဲ budget က အလုပ်ဖြစ်ပါတယ်။

Main branch ကနေ ပြောင်းလဲမှု သေးသေးလေးတွေကို အဆက်မပြတ် ship လုပ်ပါ၊ အဆင်သင့်မဖြစ်သေးရင် feature flag နောက်ကွယ်မှာ ထားပါ။ Error rate နဲ့ vitals ကို စောင့်ကြည့်ရင်း တဖြည်းဖြည်း rollout လုပ်ပါ — internal user၊ ပြီးရင် ရာခိုင်နှုန်းအနည်းငယ်၊ ပြီးမှ အားလုံး — click တစ်ချက်နဲ့ rollback လုပ်လို့ရအောင် ထားပါ။ Product နဲ့ design က merge မလုပ်ခင် review လုပ်နိုင်အောင် pull request တိုင်းအတွက် preview deployment ထားပါ။

အရင်ဆုံး တည်ငြိမ်အောင်လုပ်ပါ — live debug မလုပ်ဘဲ rollback လုပ်တာ ဒါမှမဟုတ် feature flag ကို ပိတ်တာ လုပ်ပါ။ Owner၊ သက်ရောက်မှုနဲ့ နောက် update အချိန်ပါအောင် channel တစ်ခုတည်းမှာ စောစော ဆက်သွယ်ပါ။ User တွေ လုံခြုံသွားတာနဲ့ root cause ကိုရှာ၊ test နဲ့အတူ ပြင်ပြီး ဒီလိုပြဿနာမျိုး ထပ်မဖြစ်နိုင်အောင် တိကျတဲ့ action တွေပါတဲ့ blameless post-mortem ကို ကျင်းပပါ။

Blameless ဖြစ်ပါတယ် — ဘယ်သူ အမှားလုပ်လဲ မဟုတ်ဘဲ system က အမှားကို ဘယ်လိုခွင့်ပြုခဲ့လဲ မေးပါတယ်။ ရှင်းလင်းတဲ့ timeline၊ သက်ရောက်မှု၊ root cause နဲ့ ပံ့ပိုးခဲ့တဲ့ အကြောင်းရင်းတွေ၊ ဘာကောင်းခဲ့လဲ နဲ့ owner နဲ့ ရက်စွဲပါတဲ့ action စာရင်းတိုလေး ပါပါတယ်။ ပြီးရင် team က အဲ့ action တွေကို တကယ်လိုက်လုပ်ပြီး သင်ယူခဲ့တာကို မျှဝေပါတယ်။

Team ကို မေးပြီး CI data ကိုကြည့်ကာ အချိန်ဘယ်မှာ ပျောက်နေလဲ တိုင်းတာပါ — နှေးတဲ့ build၊ flaky test၊ review စောင့်ရတာကြာတာ၊ ခက်ခဲတဲ့ local setup။ ပြီးရင် အကြီးဆုံး ဝေဒနာတွေကို ပြင်ပါ — မြန်တဲ့ dev server၊ CI မှာ caching၊ ယုံကြည်ရတဲ့ test၊ ကောင်းတဲ့ default၊ အဖြစ်များတဲ့ code အတွက် generator နဲ့ ရှင်းလင်းတဲ့ docs။ DX အောင်မြင်မှု သေးသေးလေးတွေက engineer တိုင်း နေ့တိုင်း ပေါင်းစုသွားပါတယ်။

Objective ဖြစ်တဲ့ အရာမှန်သမျှက review comment မဟုတ်ဘဲ tool ဖြစ်သင့်ပါတယ် — formatting အတွက် Prettier၊ မှန်ကန်မှုနဲ့ accessibility rule တွေအတွက် ESLint၊ strict mode နဲ့ TypeScript၊ import ordering နဲ့ module ကြားက boundary တွေ၊ commit message convention နဲ့ မြန်တဲ့ check တွေအတွက် pre-commit hook တွေ။ Rule set ကို သေးသေးထားပါ၊ rule တစ်ခုချင်းကို ရှင်းပြပါ၊ ဖြစ်နိုင်ရင် auto-fix လုပ်ပါ။

Docs တွေကို code နားမှာထားပါ — README၊ ADR၊ Storybook နဲ့ type ပါတဲ့ API တွေ — ပြီး update လုပ်တာကို definition of done ရဲ့ အစိတ်အပိုင်း ဖြစ်စေပါ။ ပျံ့နှံ့နေတဲ့ wiki ထက် တန်ဖိုးမြင့် document အနည်းငယ် (getting started၊ architecture overview၊ deploy လုပ်နည်း၊ runbook) ကို ဦးစားပေးပါ၊ တစ်ခုချင်းကို owner ပေးပြီး မှားနေတဲ့ docs တွေကို လူတွေကို လမ်းလွဲစေအောင် ထားမယ့်အစား ဖျက်ပါ။

Lines of code လို တစ်ဦးချင်း output ကို ဘယ်တော့မှ မသုံးဘဲ team-level flow နဲ့ outcome metric တွေကို သုံးပါ။ DORA metric တွေ — deployment frequency၊ change တွေရဲ့ lead time၊ change failure rate နဲ့ ပြန်ကောင်းဖို့ကြာချိန် — က delivery ကျန်းမာရေးကို ပြပြီး product outcome နဲ့ developer-experience survey တွေနဲ့ တွဲသုံးပါ။ နံပါတ်တွေကို လူတွေ အဆင့်သတ်မှတ်ဖို့ မဟုတ်ဘဲ bottleneck ရှာဖို့ သုံးပါ။

Accessibility ကို target ပါတဲ့ လိုအပ်ချက်တစ်ခုအဖြစ် ဆက်ဆံပါ — များသောအားဖြင့် European Accessibility Act လို ဥပဒေတွေက ပိုပိုတောင်းဆိုလာတဲ့ WCAG 2.2 AA ပါ။ Design system၊ design review၊ acceptance criteria နဲ့ automated test တွေထဲ ထည့်သွင်းပါ၊ team ကို လေ့ကျင့်ပေးပါ၊ ကျွမ်းကျင်သူနဲ့ user testing ကို အခါအားလျော်စွာ လုပ်ပါ။ တစ်ယောက်ယောက်ကို တာဝန်ယူခိုင်းပါ၊ မဟုတ်ရင် လွတ်သွားတတ်ပါတယ်။

Automated update PR (Renovate၊ Dependabot) တွေနဲ့ dependency တွေကို နည်းနည်းပဲ ထားပြီး ခေတ်မီနေအောင်လုပ်ကာ CI မှာ audit လုပ်ပါ။ Lock file နဲ့ version တွေကို pin လုပ်ပါ၊ package အသစ်ထည့်ခင် review လုပ်ပါ၊ supply-chain attack တွေကို သတိထားပါ။ Security header နဲ့ CSP ထည့်ပါ၊ secret တွေကို client bundle နဲ့ browser ကို ထုတ်ပြတဲ့ environment variable တွေထဲ မထည့်ပါနဲ့၊ security review ကို အခါအားလျော်စွာ လုပ်ပါ။

ပြောင်းလဲရ စျေးပေါတုန်း feasibility၊ performance နဲ့ accessibility ပြဿနာတွေကို ပြနိုင်အောင် engineer တွေကို hand-off မှာတင်မဟုတ်ဘဲ design ရဲ့ အစောပိုင်းကတည်းက ပါဝင်စေပါ။ Source of truth တစ်ခုတည်းကို မျှသုံးပါ — design tool ရော code ထဲမှာပါ token နဲ့ component တွေ — ပြီး လုပ်နေဆဲ အလုပ်ကို အတူ review လုပ်ပါ။ Responsive behaviour၊ empty၊ loading နဲ့ error state တွေကို ဘယ်လို သတ်မှတ်မလဲ သဘောတူပါ။

Screen တွေ လိုအပ်တာကို အခြေခံပြီး API ကို အတူ design လုပ်ပါ၊ contract ကို အရင်ရေးပါ (OpenAPI ဒါမှမဟုတ် GraphQL schema)၊ အဲ့ဒါကနေ type နဲ့ mock တွေ generate လုပ်လို့ နှစ်ဘက်စလုံး parallel အလုပ်လုပ်နိုင်ပါတယ်။ ပြောင်းလဲမှုတွေကို version ထားပါ ဒါမှမဟုတ် backwards-compatible ပုံစံနဲ့ ပြောင်းပါ၊ breaking change က production မှာမဟုတ်ဘဲ CI မှာ fail ဖြစ်အောင် contract test တွေ ထည့်ပါ။

ရလဒ်နဲ့ ဆုံးဖြတ်ချက်ကို အရင်ပြောပါ၊ ပြီးမှ implementation detail မဟုတ်ဘဲ user သက်ရောက်မှု၊ ကုန်ကျစရိတ်၊ risk နဲ့ အချိန်အရ အကြောင်းပြချက်ကို ပြောပါ။ Trade-off တွေနဲ့ ကိုယ့်အကြံပြုချက်ပါတဲ့ option နှစ်ခုသုံးခု ပေးပါ၊ တိကျတဲ့ ဥပမာ ဒါမှမဟုတ် နံပါတ်တွေ သုံးပြီး နားလည်မှုကို စစ်ပါ။ ဆုံးဖြတ်ချက် မှတ်တမ်းတင်ထားအောင် နောက်ဆက်တွဲ စာနဲ့ ရေးပို့ပါ။

သူတို့ရဲ့ စိုးရိမ်ချက်တွေ နားလည်ဖို့ တစ်ယောက်ချင်း သီးခြားစကားပြောပါ၊ ပြီးမှ ရည်မှန်းချက်နဲ့ ဆုံးဖြတ်ဖို့ စံနှုန်းတွေ သဘောတူဖို့ အတူခေါ်ပါ။ သက်သေနဲ့ ဖြေရှင်းလို့ရရင် အချိန်ကန့်သတ်ထားတဲ့ spike ကို run ပါ။ ဒါတောင် ကွဲနေသေးရင် ကိုယ်တိုင် ဆုံးဖြတ်ပါ၊ ဘာကြောင့်လဲ ရှင်းပြပြီး နှစ်ယောက်စလုံးကို commit လုပ်ဖို့ တောင်းဆိုပါ။ နောက်ပိုင်း သဘောထားကွဲလွဲမှုက ပုဂ္ဂိုလ်ရေး မဖြစ်သွားအောင် ပြန်စစ်ပါ။

စီရင်ချက်ချတာနဲ့ မစဘဲ စူးစမ်းချင်စိတ်နဲ့ စပါ — သီးသန့်စကားပြောပြီး တိကျတဲ့ ဥပမာတွေ မျှဝေကာ ဘာက အတားအဆီး ဖြစ်နေလဲ မေးပါ — မျှော်လင့်ချက် မရှင်းတာ၊ ကိုယ်ရေးကိုယ်တာ ပြဿနာ၊ skill ဒါမှမဟုတ် role မှားနေတာ။ ရှင်းလင်းတဲ့ goal၊ အကူအညီနဲ့ timeline ကို သဘောတူပါ၊ ပုံမှန် check in လုပ်ပြီး တိုးတက်မှုကို မှတ်တမ်းတင်ပါ။ မတိုးတက်ရင် ကိုယ့် manager ကို စောစော ပါဝင်စေပါ။

ဆုံးဖြတ်ချက်ကောင်းတွေ ချနိုင်ပြီး ယုံကြည်မှု ထိန်းထားနိုင်လောက်အောင် code နဲ့ နီးနီးကပ်ကပ် နေပါ — pull request review၊ pair လုပ်တာ၊ prototype တည်ဆောက်တာနဲ့ critical မဟုတ်တဲ့ task တွေယူတာ — ဒါပေမဲ့ ကိုယ့်အချိန်က ကြားဖြတ်ခံရတတ်လို့ critical path ပေါ်က အလုပ်ကို မပိုင်ပါနဲ့။ ကိုယ့်ရဲ့ အဓိက output က team ရဲ့ output ပါ — လူတွေကို unblock လုပ်ပေးတာ၊ ဦးတည်ချက်ကို ရှင်းလင်းစေတာနဲ့ သူတို့အလုပ်လုပ်တဲ့ system ကို တိုးတက်အောင်လုပ်တာ။

အဆင့်တွေကို မဟုတ်ဘဲ ရလဒ်ကို delegate လုပ်ပါ — ရည်မှန်းချက်၊ ကန့်သတ်ချက်တွေနဲ့ ကောင်းတယ်ဆိုတာ ဘယ်လိုပုံစံလဲ ရှင်းပြပြီး နည်းလမ်းကို သူ့ဘာသာ ရွေးခွင့်ပေးပါ။ Task ကို သူ့ကြီးထွားမှုနဲ့ ကိုက်အောင်ပေးပါ၊ check-in point တွေ သဘောတူပါ၊ မေးခွန်းတွေအတွက် အဆင်သင့်ရှိနေပါ။ ကိုယ်လုပ်မယ့်ပုံနဲ့ မတူဘဲ လုပ်နိုင်တာကို လက်ခံပါ — လူတွေ ကြီးထွားလာပုံနဲ့ team က ကိုယ့်ထက် ကျော်လွန်ပြီး scale ဖြစ်လာပုံ ဒါပါပဲ။

Business goal နဲ့ product roadmap ကနေ စပြီး အဲ့ဒါတွေကို ဖြစ်နိုင်စေတဲ့ technical အလုပ်တွေ ထည့်ပါ — platform ပြောင်းလဲမှု၊ အဓိက area တွေကို နှေးစေတဲ့ debt၊ scalability၊ security နဲ့ developer experience။ သက်ရောက်မှုနဲ့ risk အလိုက် ဦးစားပေးပါ၊ item တစ်ခုချင်းကို တိုင်းတာလို့ရတဲ့ outcome ပေးပါ၊ မမျှော်လင့်တာတွေအတွက် နေရာချန်ပြီး quarter အလိုက် plan ချပါ။ Product နဲ့ ပုံမှန် ပြန်သုံးသပ်ပြီး ချိန်ညှိပါ။

မျှသုံးတဲ့ backlog တစ်ခုတည်းကို သုံးပြီး အရာအားလုံးကို သက်ရောက်မှုနဲ့ အရေးပေါ်မှုနဲ့ အကဲဖြတ်ပါ — user နဲ့ business သက်ရောက်မှု၊ risk နဲ့ နောက်ကျရင် ကုန်ကျစရိတ်။ Critical bug နဲ့ security ပြဿနာတွေက တန်းစီတာကို ကျော်ပါတယ်၊ ကျန်တာတွေအတွက် feature တွေကြောင့် အမြဲ ဘေးဖယ်မခံရအောင် debt နဲ့ quality အတွက် capacity ရဲ့ တည်ငြိမ်တဲ့ ရာခိုင်နှုန်းကို ချန်ထားပါ။ တိတ်တိတ်လေး မဆုံးဖြတ်ဘဲ trade-off တွေကို product ကို မြင်သာအောင် လုပ်ပါ။

Team တစ်ခုချင်း အစအဆုံး deliver လုပ်နိုင်အောင် ownership ကို product domain — checkout၊ search၊ account — နဲ့ ကိုက်ညီအောင်လုပ်ပါ။ Code ထဲမှာ module boundary တွေကို အကောင်အထည်ဖော်ပါ (သီးခြား package၊ import rule)၊ design system၊ tooling နဲ့ အားလုံးကို ဖြတ်ကျော်တဲ့ ကိစ္စတွေအတွက် shared platform team ဒါမှမဟုတ် guild ထားပြီး CODEOWNERS file နဲ့ ownership ကို ရှင်းလင်းအောင် လုပ်ပါ။

တခြား team တွေ သုံးတဲ့ ခင်းထားတဲ့ လမ်းကို တည်ဆောက်ပါတယ် — design system၊ build နဲ့ deploy tooling၊ shared library၊ performance နဲ့ accessibility monitoring နဲ့ standard တွေ။ Product team တွေကို customer အဖြစ် ဆက်ဆံတယ်၊ adoption နဲ့ ကျေနပ်မှုကို တိုင်းတာတယ်၊ လူတိုင်းအတွက် အလုပ်ကို ကိုယ်တိုင်လုပ်ပေးမယ့်အစား self-service ဖြစ်အောင် လုပ်ပေးပြီး bottleneck မဖြစ်အောင် ရှောင်ပါတယ်။

မှန်ကန်တဲ့အရာကို လုပ်ရလွယ်တဲ့အရာ ဖြစ်စေပါ — တကယ့်လိုအပ်ချက်တွေကို ဖုံးလွှမ်းတဲ့ component ကောင်းတွေ၊ ရှင်းလင်းတဲ့ docs နဲ့ ဥပမာတွေ၊ လူတွေကို အဲ့ဒါတွေဆီ လမ်းကြောင်းပြတဲ့ lint rule ဒါမှမဟုတ် codemod တွေ။ Team တွေက fork မလုပ်ဘဲ ထပ်ထည့်တာကို အဆိုပြုနိုင်အောင် contribution model ကို run ပါ၊ semantic versioning နဲ့ migration guide တွေနဲ့ release လုပ်ပါ၊ ဘယ်မှာ လမ်းလွဲနေလဲ သိအောင် adoption ကို ခြေရာခံပါ။

ရှောင်နိုင်ရင် ရှောင်ပါ၊ မရှောင်နိုင်ရင် စောစော ကြေညာပါ၊ warning တွေနဲ့ အရင် deprecate လုပ်ပြီး migration guide နဲ့ ဖြစ်နိုင်ရင် codemod တွေပါတဲ့ major version ကို publish လုပ်ပါ။ အရင် major ကို ခဏ ဆက် support လုပ်ပါ၊ အကြီးဆုံး consumer တွေကို migrate လုပ်ဖို့ ကူညီပါ၊ နောက် breaking change မတိုင်ခင် feedback စုဆောင်းပါ။

သင်ယူမှုကို အလုပ်ရဲ့ အစိတ်အပိုင်း ဖြစ်စေပါ — စူးစမ်းဖို့ အချိန်၊ internal talk တိုလေးတွေ၊ reading group တွေနဲ့ တကယ့်ပြဿနာတွေပေါ်မှာ spike တွေ။ Tool အသစ်တွေကို တိကျတဲ့ ဝေဒနာတွေနဲ့ နှိုင်းယှဉ်ပြီး သေးငယ်ကာ ပြန်ပြောင်းလို့ရတဲ့ experiment တွေနဲ့ အကဲဖြတ်ပါ၊ အကျိုးကျေးဇူးက ပြောင်းလဲမှုကုန်ကျစရိတ်ထက် သိသိသာသာ သာမှပဲ ယူသုံးပါ။ Hype curve ရဲ့ နောက်နည်းနည်းမှာ ရည်ရွယ်ချက်ရှိရှိ နေတာက များသောအားဖြင့် ကျန်းမာပါတယ်။

Front-end scale အများစုက backend နဲ့ delivery အကြောင်းပါ — CDN မှာ ပြင်းပြင်းထန်ထန် cache လုပ်ပါ၊ ဖြစ်နိုင်ရင် page တွေကို static ဒါမှမဟုတ် cache လုပ်ထားပါ၊ API တွေကို rate limit နဲ့ request ထပ်တာကို ဖယ်ရှားခြင်းနဲ့ ကာကွယ်ပါ၊ အရေးကြီးတဲ့ flow တွေကို load-test လုပ်ပါ။ Client ဘက်မှာ low-end device နဲ့ နှေးတဲ့ network တွေပေါ်က performance ကို စောင့်ကြည့်ပြီး တစ်ခုခု ကျဆင်းလာရင် monitoring နဲ့ alert တွေက ပြောပြနိုင်အောင် သေချာလုပ်ပါ။

အရေးကြီးတဲ့ page တွေက unique title၊ meta description၊ canonical URL နဲ့ structured data တွေနဲ့အတူ server ပေါ်မှာ အဓိပ္ပာယ်ရှိတဲ့ HTML ကို render လုပ်အောင် (SSR ဒါမှမဟုတ် SSG) သေချာလုပ်ပါ။ Core Web Vitals က ranking ကို သက်ရောက်တာမို့ page တွေကို မြန်မြန်ထားပါ၊ sitemap နဲ့ သင့်တော်တဲ့ robots rule တွေ ပေးပါ၊ navigation အတွက် link အစစ်တွေ သုံးပြီး client-side interaction ပြီးမှ ပေါ်လာတဲ့ content ကို ဖုံးကွယ်ထားတာ ရှောင်ပါ။

လိုတဲ့ data ကိုပဲ စုဆောင်းပါ၊ ဘာစုလဲ ဘာကြောင့်လဲ မှတ်တမ်းတင်ပါ၊ GDPR လို consent ဥပဒေတွေကို လေးစားပါ — consent မရခင် မရှိမဖြစ်မဟုတ်တဲ့ tracking မလုပ်ပါနဲ့၊ ပြန်ရုပ်သိမ်းဖို့ လွယ်ကူတဲ့ နည်းလမ်းရှိပါစေ။ Privacy-friendly ဒါမှမဟုတ် first-party analytics ကို ဦးစားပေးပါ၊ ကိုယ်ရေးကိုယ်တာ data ကို log နဲ့ error report တွေထဲ မထည့်ပါနဲ့၊ third-party script တစ်ခုချင်းက performance နဲ့ security risk လည်းဖြစ်လို့ review လုပ်ပါ။

ဖြေရမယ့် မေးခွန်းနဲ့ အောင်မြင်မှု စံနှုန်းကို ကြိုသတ်မှတ်ပါ၊ အချိန်ကန့်သတ်ပါ (များသောအားဖြင့် ရက်အနည်းငယ်)၊ မေးခွန်းကို ဖြေနိုင်လောက်ပဲ တည်ဆောက်ပါ — လွှင့်ပစ်မယ့် code ပါ။ Team ဆုံးဖြတ်နိုင်အောင် ရေးထားတဲ့ အကျဉ်းချုပ်တိုလေးနဲ့ အဆုံးသတ်ပါ — ဘာသင်ယူခဲ့လဲ၊ အကြံပြုချက်နဲ့ ကျန်နေတဲ့ risk တွေ။

တိုတိုနဲ့ ဆုံးဖြတ်ချက်ကို အာရုံစိုက်ပါ — ပြဿနာနဲ့ goal တွေ (non-goal တွေပါ)၊ diagram ပါတဲ့ အဆိုပြု solution၊ စဉ်းစားခဲ့တဲ့ alternative တွေနဲ့ ဘာကြောင့် ငြင်းပယ်ခဲ့လဲ၊ risk တွေ၊ rollout plan နဲ့ အောင်မြင်မှုကို ဘယ်လိုတိုင်းမလဲ။ Draft အဖြစ် စောစော မျှဝေပါ၊ သက်ရောက်တဲ့ team တွေက reviewer တွေကို ဖိတ်ပြီး နောက်ဆုံး ဆုံးဖြတ်ချက်ကို မှတ်တမ်းတင်ပါ။

လူတွေကို area တွေကြား လှည့်ပါ၊ ရှုပ်ထွေးတဲ့ အလုပ်မှာ pair လုပ်ပါ၊ critical code အတွက် တစ်ယောက်ထက်ပိုတဲ့ review လိုအပ်ပါစေ၊ runbook နဲ့ architecture ဆုံးဖြတ်ချက်တွေကို ရေးမှတ်ပါ။ Critical system တစ်ခုချင်းကို အနည်းဆုံး နှစ်ယောက်က deploy၊ debug နဲ့ on-call လုပ်နိုင်အောင် သေချာလုပ်ပါ — တစ်ယောက်တည်းက မေးခွန်းအများကြီးရဲ့ တစ်ခုတည်းသော အဖြေ ဖြစ်လာတာကို သတိထားပါ၊ ကိုယ်တိုင်အပါအဝင်ပေါ့။

Dependency နဲ့ build output တွေကို cache လုပ်ပါ၊ ပြောင်းလဲမှုက ထိခိုက်တာကိုပဲ run ပါ (Turborepo၊ Nx)၊ test suite တွေကို parallel နဲ့ shard လုပ်ပါ၊ လုံခြုံရင် နှေးတဲ့ suite တွေကို schedule run တွေဆီ ရွှေ့ပါ။ Flaky test တွေကို ခြေရာခံပါ၊ လူတွေ green ဖြစ်တဲ့အထိ retry လုပ်မနေအောင် မြန်မြန် quarantine လုပ်ပြီး ပြင်ပါ၊ team က ကာကွယ်ထားတဲ့ pull-request pipeline အတွက် target time သတ်မှတ်ပါ။

ကွဲပြားရင် စျေးကြီးတဲ့ အရာတွေကို standardise လုပ်ပါ — build နဲ့ deploy platform၊ design system၊ security နဲ့ accessibility practice၊ core library — team တွေကိုတော့ ကိုယ့် code နဲ့ အလုပ်ကို ဘယ်လို စီစဉ်မလဲ လွတ်လပ်ခွင့်ပေးပါ။ Standard တစ်ခုချင်းရဲ့ နောက်က အကြောင်းပြချက်ကို ရှင်းပြပါ၊ ချွင်းချက် အဆိုပြုဖို့ နည်းလမ်းပေးပါ၊ standard တွေက လူတွေကို အကျိုးမပြုတော့ရင် ပြန်သုံးသပ်ပါ။

ပြဿနာတွေကို သိနိုင်ပြီး လုပ်ဆောင်လို့ရအောင်လုပ်ပါ — dashboard တွေကို ညွှန်ပြတဲ့ error rate၊ fail ဖြစ်တဲ့ deploy နဲ့ vitals regression အပေါ် alert တွေ၊ rollback နဲ့ flag ပိတ်တာလို အဖြစ်များတဲ့ ပြဿနာတွေအတွက် runbook တွေ။ Rotation ကို တရားမျှတအောင်ထားပါ၊ ပါဝင်သူတိုင်းကို အရင် လေ့ကျင့်ပေးပြီး shadow လုပ်ခိုင်းပါ၊ noise ဖယ်ရှားဖို့ alert တွေကို ပုံမှန် review လုပ်ပါ။

ကိုယ်တိုင် စံပြလုပ်ပါ — ကိုယ့်အမှားတွေကို ဝန်ခံပါ၊ "ကျွန်တော် မသိဘူး" လို့ ပြောပါ၊ ပြဿနာနဲ့ သတင်းဆိုးတွေ ပြောပြတဲ့သူတွေကို ကျေးဇူးတင်ပါ။ Blameless review တွေ run ပါ၊ meeting တွေမှာ စကားနည်းတဲ့သူတွေကို ပြောခွင့်ဖိတ်ပါ၊ မေးခွန်းတွေကို စိတ်မရှည်ပုံမဟုတ်ဘဲ စိတ်ဝင်စားမှုနဲ့ တုံ့ပြန်ပါ။ မှားမှာကို မကြောက်တဲ့အခါ လူတွေက အကောင်းဆုံး အလုပ်လုပ်ပြီး risk တွေကို စောစော ပြောပြပါတယ်။

ဥပမာ အစစ်တစ်ခုကို ရွေးပြီး STAR structure ကို သုံးပါ — အခြေအနေ၊ အဲ့အချိန်က ဆုံးဖြတ်ချက်နဲ့ ကိုယ့်အကြောင်းပြချက်၊ ဘာမှားသွားလဲ နဲ့ ပြန်ကောင်းအောင် ဘာလုပ်ခဲ့လဲ။ အချိန်အများစုကို နောက်ပိုင်း ဘာသင်ယူခဲ့ပြီး ကိုယ့် process ကို ဘယ်လိုပြောင်းခဲ့လဲ ဆိုတာမှာ သုံးပါ — ဥပမာ spike တွေကို ပိုစောစော run တာ ဒါမှမဟုတ် ADR ရေးတာ။ Interviewer တွေက ပြီးပြည့်စုံတဲ့ မှတ်တမ်းထက် ရိုးသားမှုနဲ့ ကြီးထွားမှုကို လိုချင်ပါတယ်။

အဖြေကောင်းက သက်ရောက်မှုကို မြှောက်ပွားဖို့ အကြောင်းပါ — code ကို ကိုယ်တိုင်ရေးတာ ဒါမှမဟုတ် အာဏာရှိတာ တစ်ခုတည်းမဟုတ်ဘဲ team ကို ဆုံးဖြတ်ချက်ကောင်းတွေ ချနိုင်အောင် ကူညီတာ၊ လူတွေကို ကြီးထွားစေတာနဲ့ အရာတွေ တည်ဆောက်ပုံကို တိုးတက်စေတာကို နှစ်သက်တာပါ။ ဘာကို လွမ်းမလဲ၊ technical ဘယ်လို ဆက်ဖြစ်နေမလဲ ရိုးရိုးသားသား ပြောပြပြီး lead လို အလုပ်တွေ — mentoring၊ ဆုံးဖြတ်ချက်တစ်ခုကို ဦးဆောင်တာ ဒါမှမဟုတ် process တစ်ခုကို တိုးတက်စေတာ — လုပ်ခဲ့ဖူးတဲ့ ဥပမာတစ်ခု ပေးပါ။

ပထမ ရက် 30 — နားထောင်ပြီး သင်ယူပါ — လူတိုင်းနဲ့ one-to-one တွေ့ပါ၊ product၊ architecture၊ ဝေဒနာတွေနဲ့ အလုပ်စီးဆင်းပုံကို နားလည်ပါ။ နောက် ရက် 30 — ယုံကြည်မှု တည်ဆောက်ဖို့ သက်ရောက်မှုမြင့်ပြီး risk နည်းတဲ့ တိုးတက်မှု အနည်းငယ်ကို ရွေးပြီး deliver လုပ်ပါ။ ရက် 90 ရောက်ရင် — အားသာချက်တွေ၊ risk တွေနဲ့ team နဲ့ stakeholder တွေ သဘောတူထားတဲ့ technical roadmap ပါတဲ့ ရေးထားတဲ့ အမြင်ကို မျှဝေပါ။