Junior software engineer interview questions: how to answer with understanding

1. What happens when a user submits a form?

Explain how the browser sends a request to the application, how the server validates and authorises it, how a relevant database operation runs, and how the response becomes visible to the user. MDN’s HTTP overview describes the request-response model; actual application steps depend on the design.

A stronger answer includes failure: validation can reject an input, an expired session can require login, and a timeout can leave the client unsure whether the server completed the operation. Do not claim that disabling a button alone prevents duplicates. It improves the interface but does not enforce a server-side rule.

Sources: MDN: overview of HTTP ↗

2. What is the difference between authentication and authorisation?

Authentication establishes the identity associated with a request. Authorisation determines what that identity may do. A logged-in user may still be forbidden from viewing another customer’s invoice. Explain where the application checks both, rather than presenting them as interchangeable words.

A useful example is an administrator action: verify a valid session, then check the relevant permission and resource boundary on the server. Hiding an admin link does not protect the API. Mention that the exact response and disclosure policy depend on the application.

3. How do you stop two users from taking the last booking?

Do not rely on both requests first reading “one seat available.” They could both read the same state before either writes. Describe an atomic database operation or an appropriate transaction and locking approach that enforces the invariant for concurrent requests.

A seat-per-record design might use a suitable uniqueness constraint; a remaining-capacity design needs a conditional update or another justified concurrency control. PostgreSQL documents constraints as a way to enforce restrictions on stored data. The correct implementation depends on the schema and isolation behaviour, so explain the design before claiming one universal fix.

Sources: PostgreSQL: database constraints ↗

4. What do async and await actually do?

Explain that an async function returns a promise, and await pauses the continuation of that function until the awaited value settles. It does not mean the whole program stops. A fulfilled promise supplies a result; a rejection needs appropriate error handling. MDN’s promise guide is a useful reference for practising the mechanism.

Then consider independence: two unrelated network requests may run concurrently, while a second request requiring the first request’s result must wait. Do not wrap every operation in concurrency without understanding dependencies. Explain how failure is handled when more than one request is active.

Sources: MDN: using promises ↗

5. Can you solve a small problem and explain why it works?

Practice finding two distinct indices whose values sum to a target. Clarify whether multiple answers are possible, what to return when none exist, and whether values are integers or involve floating-point considerations. The example below assumes ordinary finite integer inputs within JavaScript’s safe arithmetic range.

The map holds only previously visited values. Checking for the complement before storing the current value prevents reuse of one element. For [3, 3] and target 6, the second value finds the first. For [3], no pair exists. Expected time is linear with typical hash-map operations, and additional storage is linear; explain the assumptions rather than calling every operation universally constant-time.

function findPair(values: number[], target: number): [number, number] | null {
  const seen = new Map<number, number>();
  for (let index = 0; index < values.length; index++) {
    const previous = seen.get(target - values[index]);
    if (previous !== undefined) return [previous, index];
    seen.set(values[index], index);
  }
  return null;
}

findPair([3, 3], 6); // [0, 1]
findPair([3], 6);    // null: cannot reuse one element

6. How would you investigate a slow endpoint?

Start with a repeatable request and measured timings. Determine whether time is spent before the database call, inside it, in an external service, or while processing the response. Inspect relevant logs and query evidence while avoiding sensitive-data exposure. Ask whether the slowdown affects every request or a specific input.

A weak answer immediately adds caching. A better answer checks the cause and the consistency requirements before choosing a change. If you add an index, inspect the query plan and measure the result; also consider write and storage costs. State what would verify that the fix worked.

7. What makes a test useful?

A useful test checks a user or system promise and would fail if that promise broke. For a booking rule, test a valid booking, rejected over-capacity booking, and permission failure. Choose the appropriate layer for each concern. Do not assume a high test count proves useful coverage.

Explain what mocks hide. A unit test may verify local logic while missing an integration failure or concurrency problem. You do not need to test every method with the same technique, but you should know which evidence is still missing when you call the change complete.

8. How do you describe a project or a mistake?

Explain the problem, your responsibility, a consequential choice, how you checked it, and what you learned. If it was a student project with synthetic users, say so. If another person designed the architecture, distinguish that work from your contribution.

For a mistake, describe an actual event and the improvement it prompted. For example, discovering a missing authorisation check in your own demo can lead to server-side tests and a review checklist. Honest learning is stronger than a polished story claiming that you have never made an error.

Your next steps

• Answer with a mechanism, example, and failure case.
• Trace one form request through browser, API, and database.
• Practise a concurrent booking scenario.
• Explain promise fulfilment and rejection in your own words.
• Trace the coding example with duplicates, zero indices, and no pair.
• Use an actual project decision and mistake in your stories.

Frequently asked questions