GraphQL is a query language for APIs and a runtime for executing those queries. Instead of calling multiple REST endpoints, you send one query to a single endpoint and describe exactly the shape of data you need — the server returns precisely that, nothing more or less. This removes over-fetching and under-fetching, cuts round trips on slow mobile networks, and gives you a strongly typed schema that acts as a contract between frontend and backend. Teams usually adopt it when multiple clients (web, mobile) consume the same data, or when a screen needs data from several sources in one request. It pairs naturally with Node.js on the backend and React on the frontend.

A classic example is fetching a user along with their posts in a single request: query { user(id: "1") { name email posts { title likes } } } The server responds with JSON that matches this exact shape. In REST, you would typically need two calls (/users/1 and /users/1/posts) and then stitch the data together on the client. Similarly, a mutation like createUser lets you send data to the server and specify exactly which fields you want back after the operation.

The best starting point is the official GraphQL documentation's learn section, followed by free hands-on courses where you build an actual API rather than just watch videos. Many beginners also like following a GraphQL tutorial on YouTube to watch the schema and resolvers come together in real time. Whichever you pick, make sure it has you build something small — a to-do or movie API with a schema, a few resolvers, and a React page querying it — because GraphQL only makes sense once you have written a query and seen the response yourself.

Look for tutorials built around Apollo Server — the official Apollo docs walk you through creating a GraphQL server in Node step by step: defining your schema with the GraphQL schema language, writing resolvers in JavaScript, connecting a database like MongoDB, and testing queries in a built-in playground. If you already know Express, you can also mount GraphQL onto an existing Express server. Once the API is running, consume it from a React app using Apollo Client or a simple fetch call — that full loop (schema → resolver → query → UI) is what turns theory into skill.

Hooks are ready-made functions that let your function components remember things and react to changes — abilities that earlier required class components. useState lets a component store a value (like an input text or a counter) and re-render when it changes; useEffect lets a component perform actions after rendering, such as fetching data or subscribing to events. In short, hooks let you "hook into" React's state and lifecycle features from plain JavaScript functions, which keeps components smaller and makes logic easier to reuse and test.

Import the hook you need and call it at the top level of your component. For example, const [count, setCount] = useState(0) gives you a state variable and a function to update it, and calling setCount re-renders the component with the new value. useEffect(() => { ... }, [dependencies]) runs side effects after render and re-runs whenever its dependency array changes. Two rules to always follow: call hooks only at the top level (never inside conditions, loops, or nested functions) and only inside React function components or custom hooks.

You create a custom hook by writing a function whose name starts with "use" that calls other hooks inside it. For example, a useLocalStorage hook can use useState internally, read the initial value from localStorage, and save back to it on every update — and then any component can reuse it like a built-in hook. Custom hooks are the standard way to share logic such as data fetching, form handling, timers, or window size across components without duplicating code or resorting to wrapper components.

Use React Testing Library together with Jest or Vitest. The renderHook() utility mounts your hook inside a test wrapper, and act() ensures all state updates are applied before you assert anything. The typical flow is: render the hook → trigger a change with act(() => result.current.increment()) → assert the updated value. For hooks that fetch data, mock the API layer or stub fetch so tests stay fast and deterministic. Focus on testing observable behaviour — returned values and re-renders — rather than internal implementation details.

exhaustive-deps refers to the react-hooks/exhaustive-deps linting rule that comes with the official React hooks ESLint plugin. It warns you whenever a useEffect, useCallback, or useMemo dependency array is missing a value the callback actually reads — such as a prop, state variable, or another reactive value. Missing dependencies are the most common cause of stale-closure bugs, where an effect silently keeps using old data. The right fix is usually to add the missing dependency; if you intentionally want the effect to run only once, handle it explicitly rather than blindly disabling the warning.

Expect questions like: What are the Rules of Hooks and why do they exist? What is the difference between useState and useReducer? When exactly does useEffect re-run, and how does cleanup work? What is the difference between useMemo and useCallback? How do custom hooks help share logic? Why were hooks introduced at all when classes already worked? Interviewers increasingly present a broken useEffect — usually a stale closure or a missing dependency — and ask you to fix it, so practise explaining what your dependency array actually controls instead of memorising definitions.

Here's a quick list of React Hooks with examples of when each is used: useState (local state like inputs or counters), useEffect (side effects such as data fetching or subscriptions), useContext (reading context without a wrapper component), useReducer (complex state transitions in one place), useRef (mutable values or direct DOM access without re-rendering), useMemo (caching expensive calculations), useCallback (memoising functions passed to child components), useLayoutEffect (measuring or mutating the DOM before paint), useId (generating stable unique IDs), and useImperativeHandle (customising what a ref exposes). Anything you write yourself starting with "use" is a custom hook.

React Hook Form is a popular third-party library for building forms in React — it is not one of React's built-in hooks, despite the similar name. It manages form state through uncontrolled inputs registered via a register() function, which keeps re-renders minimal and makes validation (including schema-based validation with libraries like Zod) straightforward. You can absolutely build forms with useState alone, but React Hook Form becomes worth adopting once your forms need validation rules, error messages, dirty-field tracking, and multi-step submission logic.

Start with MongoDB's official documentation and the free MongoDB University courses — they stay current and cover CRUD operations, documents and collections, schema design, and indexes in a sensible order. If you prefer watching, a project-based MongoDB tutorial on YouTube that builds a small full-stack app works well too. Whichever route you choose, make sure the tutorial has you practising queries in the shell or Compass first and then connecting MongoDB to a Node.js application using Mongoose — that is the workflow you will actually use in real projects.

For most freshers, the practical answer is sequencing, not choosing one. Build foundational DSA (arrays, strings, hashing, recursion, then trees and graphs) alongside your first full-stack project instead of finishing one completely before touching the other — projects teach you where data structures genuinely matter. If you are targeting product-based companies, weight DSA earlier because their interviews test problem solving heavily; for startup and service-company roles, a strong React/Node project portfolio often gets you the interview faster. Either way, start applying early and actively ask for referrals, since a large share of interview calls come through people rather than portals. If you want this sequence mapped around your semester or current job, a short 1:1 career guidance call can give you a week-by-week plan.

In the first scan, recruiters check a clean one-page structure (two pages only with real experience), a summary that says what you build, and quantified impact — "reduced API response time by 40%" beats "worked on backend". ATS filters and recruiters both scan for keywords matching the job description, so mirror only the stack you have genuinely used (React, Node, MongoDB, GraphQL, etc.). Include two or three projects with live links and GitHub repos, keep the formatting simple and machine-readable, and cut generic coursework filler. Also remember that referrals and genuine LinkedIn outreach move applications faster than cold submissions — and if you are not getting shortlisted despite applying, a structured resume review that goes line by line usually uncovers the problem faster than another solo rewrite.