Technical Interview Questions by Stack (2026)

Python interview questions

Python interviews rarely hinge on obscure syntax. Interviewers want to know whether you write idiomatic Python — the kind a senior engineer would happily review — and whether you understand what's happening under the hood when your code runs. So the questions cluster into a predictable taxonomy, and once you see the shape of it, prep gets much simpler.

The core distinction: Knowing Python syntax gets you through a phone screen. Knowing Python's data model — mutability, iterators, decorators, the GIL — is what separates "can code" from "can engineer."

The question taxonomy

Most Python questions fall into five buckets. Prepare one strong story or example for each:

• Language idioms. Comprehensions, unpacking, generators, context managers. "Rewrite this loop as a comprehension" is a warm-up, not a trick.
• The data model. Mutable vs immutable defaults, __repr__ vs __str__, dunder methods, why is and == differ.
• Decorators and closures. The single most common "seniority signal" question.
• Concurrency. What the GIL does, when threads still help (I/O), when you need multiprocessing or asyncio.
• Standard library depth. collections, itertools, functools. Reaching for defaultdict unprompted is a quiet win.

Worked example: the decorator question

"Write a decorator that times a function." Weak candidates stall here. Strong ones write this in under two minutes and then ask whether they should preserve metadata:

import time
from functools import wraps

def timed(fn):
    @wraps(fn)  # keeps __name__ and __doc__ intact
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        result = fn(*args, **kwargs)
        print(f"{fn.__name__} took {time.perf_counter() - start:.4f}s")
        return result
    return wrapper

@timed
def slow_add(a, b):
    time.sleep(0.1)
    return a + b

Notice the follow-ups this invites: Why *args, **kwargs? Why @wraps? How would you make it take arguments (@timed(unit="ms"))? Each answer shows a layer of depth. Volunteer them before you're asked.

How answers get scored

Interviewers typically grade on three axes: correctness (does it run?), idiom (is it Pythonic — comprehension over map/filter chains, EAFP over LBYL?), and depth (can you explain the "why" — e.g., why a list comprehension beats a for-loop append in speed and readability?). A correct but unidiomatic answer usually reads as "writes Java in Python."

Common mistakes

• Using a mutable default argument (def f(x=[])) and not knowing why it bites.
• Claiming threads speed up CPU-bound work — the GIL says otherwise.
• Reaching for recursion where a generator or loop is clearer.
• Memorising answers without being able to modify them. Interviewers always tweak the prompt.

A study plan that actually works

Give yourself two tracks. Track one: thirty minutes a day writing Python by hand — not watching videos, writing. Re-implement things you normally import: a small LRU cache, a retry-with-backoff helper, a context manager that times a block. Track two: read one piece of the standard library a week and ask what problem it solves. functools.lru_cache, contextlib, dataclasses — each exists because a real pain was common enough to abstract. When an interviewer asks a design-flavoured question, you can say "in the standard library this is handled by X, and the trade-off they made was Y." That sentence is worth more than a clever one-liner, because it proves you learn from the codebase you already live inside. Close prep week by narrating three solutions out loud on a timer; fluency under narration is the actual skill being tested.

FAQ

Do I need to know Python internals like CPython bytecode? No. But you should comfortably explain the GIL, reference counting, and why small integers and strings are cached.

Are LeetCode-style problems asked in Python interviews? Often, yes — usually mediums. Python's built-ins make them fast to write, so interviewers expect clean, quick solutions.

Pair this with the general software engineer guide for the algorithm side, and drill live with Aissence's coding copilot when you want feedback mid-problem.

Java interview questions

Java interviews are unapologetically old-school in one respect: they test whether you understand the platform, not just the language. The JVM, the memory model, the collections framework — these are fair game at every level, and candidates who treat Java as "just syntax" get caught out fast.

The core idea: Java's interview questions revolve around contracts. equals/hashCode is a contract. The Java Memory Model is a contract. Interfaces are contracts. Interviewers are checking whether you honour them.

The question taxonomy

• Core language. String immutability, final, autoboxing pitfalls, generics and type erasure.
• Collections. HashMap internals, ArrayList vs LinkedList, ConcurrentHashMap, fail-fast iterators.
• JVM and memory. Heap vs stack, garbage collection basics, class loading.
• Concurrency. synchronized vs locks, volatile, thread pools, the happens-before relationship.
• Modern Java. Streams, lambdas, Optional, records, virtual threads.

Worked example: the equals/hashCode contract

"Why must you override hashCode when you override equals?" Show, don't tell:

class Employee {
    private final String id;
    Employee(String id) { this.id = id; }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Employee)) return false;
        Employee other = (Employee) o;
        return id.equals(other.id);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id);
    }
}

Then the explanation: a HashMap first uses hashCode to pick a bucket, then equals within the bucket. If two equal objects return different hash codes, the map looks in the wrong bucket and your key "disappears" — lookups fail on objects you know are there. Walk through that scenario out loud and you've answered the question the way a senior would.

How answers get scored

Expect grading on precision (do you say "it depends" in the right places — ArrayList vs LinkedList is workload-dependent), on concurrency correctness (no hand-waving "synchronized fixes it"), and on knowing the modern features well enough to not write Java 7 in 2026. Streams questions reward readability over cleverness.

Common mistakes

• Comparing strings with == instead of equals.
• Overriding equals but forgetting hashCode — the classic.
• Claiming volatile makes compound actions like i++ atomic. It doesn't; it only guarantees visibility.
• Modifying a collection while iterating and being surprised by ConcurrentModificationException.

The questions that expose shallow prep

A few questions reliably separate readers from practitioners. "How does a HashMap handle collisions?" — chaining versus treeification, and why the threshold exists. "Why is String immutable?" — security, caching, thread safety, the string pool. "What's the difference between Comparable and Comparator?" — one belongs to the class, the other to the caller. None of these are hard if you've written Java professionally; all of them are brutal if you've only skimmed a cheat sheet. The defence is simple: when you practise, implement the thing once. Write a tiny hash map with buckets and linked entries. Write a thread-safe counter three ways — synchronized, AtomicInteger, explicit lock — and say out loud when each is appropriate. Twenty minutes of implementation buys you more interview credibility than hours of re-reading definitions ever will.

One more habit pays off disproportionately: learn to read stack traces out loud, frame by frame, naming the line where you'd look first and why. Interviewers who hand you a broken snippet or a logged exception are testing exactly that reflex, and it's surprising how many strong coders freeze when the output isn't an IDE hint. Practise on deliberately broken code — a null here, a wrong generic there — until a trace reads like a story instead of noise.

FAQ

How deep on the JVM do I need to go? For most roles: heap/stack, GC generations at a high level, and when you'd profile. JVM tuning internals are for platform and performance-specific roles.

Are data structure questions asked in Java? Yes — you'll implement them in Java, so generics and collections fluency matter. See the software engineer interview guide for that side.

Want to pressure-test your answers out loud? Run timed sessions with Aissence practice, and use the coding copilot when you're mid-implementation.

SQL interview questions

Here's the open secret of SQL interviews: the hard questions are almost never about syntax you haven't seen. They're about grouping and windows. If you can think in sets rather than loops — and you can wield window functions without flinching — you will clear the bar at most companies, from startups to the big ones.

The key idea: SQL is declarative. You describe what result you want, not how to compute it. Interview questions probe whether you actually think that way, or whether you're secretly writing a for-loop in your head.

The question taxonomy

• Joins and filtering. Inner vs left joins, the three-valued logic of NULL, anti-joins ("find customers with no orders").
• Aggregation. GROUP BY with HAVING, conditional aggregation with SUM(CASE WHEN ...).
• Window functions. ROW_NUMBER vs RANK vs DENSE_RANK, running totals, "top N per group" — the highest-signal topic in the whole interview.
• Schema design and indexes. Normalisation trade-offs, what an index actually is, when one doesn't help.
• Query reasoning. Given a slow query and an execution plan, what would you look at first?

Worked example: top N per group

"Get the two most recent orders per customer." The wrong instinct is a correlated subquery or a self-join mess. The right instinct is a window function:

SELECT customer_id, order_id, order_date, total
FROM (
  SELECT o.*,
         ROW_NUMBER() OVER (
           PARTITION BY customer_id
           ORDER BY order_date DESC
         ) AS rn
  FROM orders o
) ranked
WHERE rn <= 2;

Be ready for the follow-ups, because they always come: What if two orders share the same date (use RANK, or add a tiebreaker)? Why not just GROUP BY (because grouping collapses rows — you need the full row back)? How would an index on (customer_id, order_date) change the plan? Each follow-up is an invitation to show depth.

How answers get scored

Rubrics reward set-based thinking, correct NULL handling (this is where most candidates quietly lose points — NULL = NULL is not true), and the ability to reason about performance without a GUI. Saying "I'd check the execution plan and whether the join column is indexed" is a complete, senior-sounding answer. You don't need to recite B-tree internals unless it's a database-engineer role.

Common mistakes

• Filtering on an aggregated column in WHERE instead of HAVING.
• Using NOT IN with a subquery that can return NULL — it silently returns zero rows. Prefer NOT EXISTS.
• Confusing RANK and ROW_NUMBER when duplicates exist.
• Writing SELECT * in joins and getting ambiguous or duplicated columns.

How to practise SQL so it transfers

Reading solutions doesn't work for SQL — you have to write queries against data you haven't seen. Set up a small local database (a Dockerised Postgres with a sample schema takes minutes), then practise three moves daily: a join with an aggregate, a window function, and a "find the gap" anti-join. After solving each, rewrite the query a second way and compare. Can the window function become a self-join? Should it? This habit of producing alternatives is exactly what interview follow-ups demand. And always state your assumptions before writing: "I'll assume order_date has no ties; if it can, I'd add a tiebreaker." In a live round, the interviewer can't see your schema knowledge — only your narration. Two sentences of assumption-stating at the start do more for your score than ten minutes of silent, correct typing.

FAQ

Which SQL dialect should I practise? Standard SQL (PostgreSQL-style) transfers everywhere. Know that MySQL, SQL Server, and BigQuery differ in functions and limits, but the thinking is identical.

Do data roles and backend roles ask different SQL? Data roles lean harder on windows and analytics; backend roles add schema design and transactions. Prepare both if you're interviewing broadly — the data engineer guide goes deeper on pipelines.

Drill real queries with live feedback in Aissence practice, and cross-check the backend angle in the backend interview guide.

React interview questions

React interviews have a tell: they almost always circle back to state and rendering. Not JSX trivia, not the difference between a class and a function component — but whether you understand when React re-renders, why, and how to stop it from doing so wastefully. Master that mental model and the rest of the interview feels like conversation.

The key idea: React re-renders a component when its state or props change — and by default, it re-renders that component's entire subtree. Most performance questions are really this one sentence wearing a costume.

The question taxonomy

• Hooks mechanics. useState, useEffect (especially the dependency array and cleanup), useMemo/useCallback, and the rules of hooks.
• Rendering behaviour. Reconciliation, keys in lists, why lifting state up causes re-renders, when React.memo helps.
• State architecture. Local state vs context vs a store; when context alone causes render storms.
• Data fetching. Effects vs a query library, race conditions, cancellation.
• Practical coding. Build a debounced search, a custom hook, or a small form with validation.

Worked example: the stale closure trap

"This counter should increment every second but stays stuck — why?" This is the single most diagnostic React question:

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      setCount(count + 1); // BUG: 'count' is captured from render 0
    }, 1000);
    return () => clearInterval(id);
  }, []); // empty deps: closure never sees new count

  return <p>{count}</p>;
}

The fix — and the sentence that earns the points — is the functional update form: setCount(c => c + 1). Then explain why: the interval callback closed over the initial render's count, so it kept adding one to zero. If you can also mention that adding count to the deps would fix it but recreate the interval every tick, you've shown genuine fluency, not memorisation.

How answers get scored

Rubrics typically reward: a correct mental model of the render cycle, knowing when not to optimise (reaching for useMemo everywhere is a junior tell), and clean effect hygiene — no missing dependencies, always returning cleanup for subscriptions and timers. Building something that works while explaining why it works beats a flashy solution every time.

Common mistakes

• Mutating state directly and wondering why nothing re-renders.
• Using array indexes as keys in a list that reorders.
• Putting data fetching in an effect with no race-condition handling.
• Wrapping everything in useMemo "for performance" without measuring.

The take-home and live-build formats

Expect one of two practical formats. In a timed live build, you get a small spec — an autocomplete, a paginated list, a form with validation — and roughly an hour. The winning strategy is boring: get the simplest working version running in the first twenty minutes, then layer polish (loading state, error handling, keyboard support) while narrating trade-offs. In a take-home, they're reading your code like a pull request: component decomposition, sensible naming, no dead code, a README that explains how to run it and what you'd do next. In both formats, the fastest way to lose points is chasing a clever abstraction while the basic requirement stays broken. Ship the plain thing first. Interviewers would rather review a simple component done completely than an elaborate one done halfway — because that's the judgment they need from you on a Tuesday afternoon at work.

FAQ

Do class components still come up? Rarely for writing, but you should recognise lifecycle methods and be able to map them to hooks — many codebases still have both.

Will I be asked about React Server Components or the compiler? In 2026, increasingly yes at a conceptual level: what they are and what problem they solve. Deep internals, no.

Round this out with the frontend interview guide for the JavaScript fundamentals underneath, and rehearse component builds with mock practice.

Data engineer interview questions

Data engineering interviews have a reputation for being the most practical in the data family — and it's deserved. Nobody asks you to derive backpropagation. They ask how you'd move a hundred million rows a day reliably, what happens when a job fails halfway, and why your pipeline is slow. Reliability thinking, not algorithm trivia, is the whole game.

The core idea: A data engineer's product is trustworthy data. Interviews test whether you build pipelines that are correct (no duplicates, no silent loss), recoverable (rerunnable without disaster), and observable (you know when they break before your users do).

The question taxonomy

• SQL, but harder. Window functions, deduplication, incremental queries. The SQL guide is essential groundwork.
• Data modelling. Star schemas, slowly changing dimensions, denormalisation trade-offs, partitioning strategy.
• Pipeline design. Batch vs streaming, idempotency, backfills, late-arriving data.
• Distributed processing. Spark partitions and shuffles, why a job skews, broadcast joins.
• Operations. Orchestration, data quality checks, alerting, lineage.

Worked example: the idempotent backfill

"Your daily job failed on Tuesday. It's now Thursday. Walk me through the fix." The junior answer is "rerun it." The senior answer starts with a question: is the job idempotent? Then show what idempotency looks like:

-- Idempotent write: delete the partition, then rewrite it.
-- Rerunning for the same date never creates duplicates.
DELETE FROM events
WHERE event_date = '2026-08-25';

INSERT INTO events
SELECT *
FROM staging_events
WHERE event_date = '2026-08-25';

(Many warehouses express this as a MERGE or a partition swap — the principle is identical.) Then narrate the operational story: fix the root cause, backfill Tuesday and Wednesday in order, verify row counts against the source, and add a data-quality check so the next failure pages you instead of corrupting dashboards silently. That last sentence — and here's how we catch it next time — is what interviewers are waiting to hear.

How answers get scored

Rubrics reward failure-mode thinking above all: what breaks, how you detect it, how you recover without duplicates or gaps. In Spark questions, knowing that a shuffle is expensive — and that skewed keys cause one executor to do all the work — matters more than API trivia. In modelling questions, justifying your grain ("one row per what?") is the fastest credibility signal there is.

Common mistakes

• Designing pipelines that can't be rerun safely — append-only writes with no dedupe strategy.
• Ignoring late-arriving and out-of-order data until it corrupts aggregates in production.
• Choosing a partition key with high skew (like a status column with two values).
• Describing tools — Airflow, dbt, Spark — without being able to explain the design choices underneath them.

The modelling question: "design a schema for X"

Expect a modelling design round: "design tables for an e-commerce order history" or "model ride-sharing trips." Start with the grain — one row per what? Everything follows from that sentence. Then separate facts (events with measures: orders, clicks, payments) from dimensions (the who/what/where: customers, products, dates). Discuss slowly changing dimensions when attributes mutate: does the business need the customer's address at time of order or the current one? That single question marks experience. Finish with physical design: partition large fact tables by date, cluster or index by the most common filter column, and justify each choice in terms of the queries it serves. The rubric rewards candidates who design from query patterns backward rather than normal forms forward — analytics schemas exist to be read, and saying so frames every decision correctly.

FAQ

Spark or SQL — which matters more? Strong SQL first, always; it's assumed. Spark depth matters for roles processing large volumes — understand partitions, shuffles, and joins conceptually even if you mostly write SQL.

Is streaming required? For most roles, conceptual fluency is enough: event time vs processing time, watermarks, exactly-once semantics. Deep Kafka/Flink internals are for streaming-specialist positions.

Compare this path with the analytics-leaning data scientist guide, and drill your SQL with Aissence's coding copilot.

Cybersecurity interview questions

Security interviews are unlike any other engineering loop because the subject is an adversary. Every other discipline asks "will it work?" Security asks "how will it be made to fail?" Interviewers want to see that adversarial reflex — the instinct to ask what an attacker controls, what they can observe, and what breaks first. Cultivate that instinct and the technical questions mostly answer themselves.

The core idea: Security is defence in depth against an intelligent opponent who only needs to succeed once. No single control is trusted; every layer assumes the one above it has already failed.

The question taxonomy

• Web application security. The OWASP classics: injection, XSS, CSRF, broken access control. Expect to explain and mitigate.
• Threat modelling. "Here's a system — how would you attack it?" Structured approaches like STRIDE help, but the thinking matters more than the acronym.
• Cryptography, applied. Hashing vs encryption vs encoding, TLS at a high level, why you never roll your own.
• Network and infrastructure. Segmentation, least privilege, zero trust principles.
• Detection and response. Logging, indicators of compromise, what you'd do with a suspected breach.

Worked example: SQL injection, end to end

"Explain SQL injection and how you prevent it." Cover all four beats — mechanism, impact, fix, and layered defence:

-- Vulnerable: string concatenation lets input become SQL
query = "SELECT * FROM users WHERE name = '" + user_input + "'"

-- Safe: parameterised query — input is data, never code
cursor.execute(
    "SELECT * FROM users WHERE name = %s",
    (user_input,)
)

Then the layers: parameterised queries as the primary fix, an ORM that defaults to safe behaviour, least-privilege database accounts so a successful injection can't drop tables, and a WAF as a speed bump — never as the fix itself. Explaining why each layer exists (because the one above it might fail) demonstrates defence in depth rather than reciting it.

How answers get scored

Rubrics reward attacker thinking ("what does the attacker control here?" should be your first sentence in any scenario), precise terminology (hashing is not encryption; authentication is not authorisation), and pragmatism — security that users route around is worse than none. In incident scenarios, containment before eradication, and evidence preservation before heroic cleanup, are the marks of someone who'd be trusted during a real breach.

Common mistakes

• Encoding or encrypting passwords instead of hashing them with a slow, salted algorithm like bcrypt or Argon2.
• Treating the perimeter as the defence — "it's on the internal network" has ended many careers.
• Fixing the specific vulnerability in a scenario without mentioning the class of vulnerability it belongs to.
• Answering "how would you attack this?" with defences. Answer the question that was asked.

The threat-modelling round

"Here's a system that stores customer documents — walk me through how you'd assess it." Resist the urge to list vulnerabilities. Instead, model like an engineer: what assets matter (the documents, the credentials guarding them), who the adversaries are (external attackers, malicious insiders, careless employees), what the trust boundaries are (every place data crosses from one control domain to another — the upload endpoint, the database, the support tool that can read anything), and what happens at each boundary if the attacker controls the input. Then prioritise by impact and likelihood, and only then propose controls, matched to the specific threats you named. The rubric rewards that order — assets, adversaries, boundaries, then controls — because it's how real assessments run. Candidates who jump straight to "encrypt everything and add a WAF" have described spending, not security.

FAQ

Do I need certifications to pass the interview? Certifications help get the interview; the interview itself tests reasoning. A candidate who thinks adversarially with no cert beats a certified candidate who recites definitions.

How much coding is expected? Enough to read code and spot the injection, the missing access check, the hardcoded secret. For application-security roles, expect to write exploit proofs-of-concept and fixes.

For the engineering fundamentals underneath, see the backend interview guide, and pressure-test your scenario answers with Aissence practice.