Backend Engineer interview prep

Short answer: SELECT retrieves rows from tables. The logical execution order does NOT match the written order: first FROM, then WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY, LIMIT.

In depth:

Written (syntactic) order:

SELECT   DISTINCT col1, agg(col2)
FROM     t
WHERE    cond
GROUP BY col1
HAVING   agg_cond
ORDER BY col1
LIMIT    10 OFFSET 20;

Logical execution order:

1. FROM / JOIN      -- which tables, how to join
2. WHERE            -- row filter BEFORE grouping
3. GROUP BY         -- grouping
4. HAVING           -- group filter AFTER aggregation
5. SELECT           -- evaluate expressions, aliases
6. DISTINCT         -- remove duplicates
7. ORDER BY         -- sorting
8. LIMIT / OFFSET   -- slice

⚠️ Gotcha: an alias from SELECT cannot be used in WHERE (since WHERE runs before SELECT), but it can be used in ORDER BY and often in GROUP BY (depends on the DBMS). Example of the error:

SELECT salary * 12 AS annual FROM emp WHERE annual > 100000; -- ERROR
SELECT salary * 12 AS annual FROM emp ORDER BY annual;        -- OK

Short answer: HTTP (HyperText Transfer Protocol) is a text-based application-layer client-server protocol on top of TCP (in HTTP/3 — on top of QUIC/UDP). The client sends a request, the server returns a response; the connection holds no state between requests (stateless).

In depth:

A request consists of a start line (method + path + version), headers, and an optional body:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Content-Length: 38

{"name": "Anna", "email": "a@ex.com"}

A response consists of a status line (version + code + reason phrase), headers, and a body:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/v1/users/42

{"id": 42, "name": "Anna", "email": "a@ex.com"}

⚠️ Gotcha: "HTTP only works over TCP" is incorrect for HTTP/3, which uses QUIC over UDP. And the reason phrase ("OK", "Created") is purely informational — clients should rely on the numeric code, not the text.

Short answer: Big O describes how an algorithm's running time or memory usage grows as the input size n increases, dropping constants and lower-order terms. It's an upper bound on the growth rate.

In detail:

Big O answers the question "what happens when n becomes very large?". We're not interested in the exact number of operations, only the nature of the growth. That's why O(2n + 100) simplifies to O(n), and O(3n² + n) — to O(n²).

The main growth classes (from best to worst):

# O(1) — constant: doesn't depend on n
def first(arr):
    return arr[0] if arr else None

# O(log n) — logarithmic: each step halves the problem (binary search)
def binary_search(arr, target):
    lo, hi = 0, len(arr) - 1
    while lo <= hi:
        mid = (lo + hi) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            lo = mid + 1
        else:
            hi = mid - 1
    return -1

# O(n) — linear: a single pass
def total(arr):
    s = 0
    for x in arr:        # n iterations
        s += x
    return s

# O(n log n) — efficient sorts (merge, quick, Timsort)
def sort_it(arr):
    return sorted(arr)

# O(n^2) — quadratic: a nested loop
def has_dup_naive(arr):
    for i in range(len(arr)):
        for j in range(i + 1, len(arr)):
            if arr[i] == arr[j]:
                return True
    return False

# O(2^n) — exponential: naive Fibonacci, enumerating subsets
def fib_naive(n):
    if n < 2:
        return n
    return fib_naive(n - 1) + fib_naive(n - 2)

A rough guide to growth at n = 1,000,000: O(1) — 1 operation, O(log n) — ~20, O(n) — a million, O(n log n) — ~20 million, O(n²) — a trillion (already too much), O(2^n) — infeasible even at n = 50.

⚠️ Gotcha: Big O is about asymptotics (behavior at large n), not about actual time. An O(n) algorithm can be slower than an O(n²) one on small data because of large constants. People also confuse: Big O (upper bound), Ω (lower bound), Θ (tight bound); in interviews "O" usually means Θ.

Short answer: Docker packages an application and its user-space dependencies in an image, then runs an isolated process from that image. This reduces differences between development, CI and production.

For a Go service, the image can contain the compiled binary, CA certificates and any needed shared libraries. The host still supplies a compatible kernel and CPU architecture; configuration, credentials, resource limits and external services are supplied separately.

docker build -t myapp:1.0 .
docker run -d -p 127.0.0.1:8000:8000 --name myapp myapp:1.0
docker logs -f myapp

The application must listen on the container interface, such as :8000. This example publishes only to the host loopback address for local use.

Limit: the same image does not guarantee identical behavior on every machine. Linux containers on macOS/Windows normally run inside a Linux VM; CPU architecture, kernel features, networking and external configuration still matter. Build the required platform variants and test the actual deployment environment.

Sources: Reference 1, Reference 2.

Short answer: Event sourcing: the event log is authoritative; current state is derived as state = fold(events). CQRS: the write model and the read models are separated. You get a full audit trail, temporal queries ('what did the order look like yesterday'), and rebuildable projections. The price is steep: event versioning, snapshots, potential projection lag, expensive tooling. It is not a default architecture.

In depth:

events:  OrderCreated → ItemAdded → ItemAdded → OrderPaid
state  = fold(events)   — always derivable from scratch
projections: 'orders per day', 'top items' — separate read
             models, rebuildable from the log at any time

1. When justified — money movements, ledgers, audit-heavy and compliance-bound domains; 'why did the balance end up like this' is a business question, not a log-digging exercise.
2. Price #1: versioning — an event lives forever; when the schema changes you must read every old version (upcasters) or migrate the whole log.
3. Price #2: reads — if read models update asynchronously, a projection can lag after a command; the UI, tests, and support must handle that consistency model.
4. CQRS without ES — legitimate and far cheaper: a regular write DB + denormalized read projections.

⚠️ Common mistake: proposing event sourcing for a CRUD app 'for future growth'. If audit is not a business requirement, you pay the full ES price and gain nothing a table plus a change log would not give you.

The event log is authoritative, but implementations can store snapshots and materialized state. CQRS separates read and write models; it need not use separate databases, and asynchronous projection lag is a design choice rather than a requirement of every CQRS implementation.