Interview guides · CFC

CFC Software Engineer Interview Guide

CFC Software Engineer interview guide: 3 reported rounds, C#, SOLID, SQL joins, architecture and cloud questions, behavioral prep and a 7-day plan.

The 60-second brief

CFC is described by candidates as a specialist insurance provider. Engineers there are reported to work on product development, end-user technology or business resumption systems, so the software supports insurance operations and has to keep working when something fails. The requirements candidates describe centre on C# and the .NET frameworks, SQL on relational databases, Agile delivery and a working knowledge of software architecture and design patterns. Cloud platforms such as AWS or Azure, high-availability experience and an insurance or fintech background are listed as extras, not requirements.

This guide is for engineers preparing for a Software Engineer interview at CFC.

Candidates report three rounds spread over roughly 3-5 weeks: an initial screening call, technical assessments that may include a take-home task, and face-to-face or virtual interviews with engineers and management.

Focus areas

SOLID Principles
C#
Architecture

Overview

The reported questions fall into two groups. The technical group is SOLID principles with C# examples, recursion and when to use it, complex SQL joins in high-volume environments, preferred architectural patterns, and how you use cloud technologies. The behavioral group is your current strengths, what you are learning, team cooperation and communication, hobbies and work-life balance, and your experience in an Agile environment. Candidates also report prompts about refactoring legacy code, making code testable, designing for high concurrency, choosing between a monolith and microservices, receiving constructive feedback and getting unstuck on a technical problem.

Because the stack listed is C#, .NET and SQL, prepare answers you can back with code you have actually written. For SOLID, that means a real before-and-after refactor you can sketch from memory. For SQL, it means a query you tuned and what the execution plan showed. For architecture and cloud, it means a system you built or worked in, with the trade-offs you saw. Candidates describe the questions as practical rather than trick questions, so concrete examples and the reasoning behind your choices carry more weight than memorised definitions.

One reported tip is that nerves can be mistaken for a lack of technical depth. The practical answer is rehearsal: say your answers aloud, keep a fixed opening sentence for each common question, and decide in advance what you will say when you do not know something (what you would check first, and why). The plan below spends two days on spoken behavioral practice for that reason.

The behavioral questions look casual, and the hobbies and strengths questions are easy to under-prepare. Candidates report that the final stage involves both engineers and management, so the same story may be heard by a technical and a non-technical listener. Prepare each story at two levels: one plain-language version of the outcome, and one version with the technical decisions underneath.

The CFC interview process

Candidates report three stages over roughly 3-5 weeks; the descriptions below say what each is reported to cover and how to prepare for it.

Initial Screening Call

Candidates report an initial screening call whose purpose is to establish your background and your interest in the company. Treat it as the first test of how clearly you can talk about your own work. The strengths and learning questions from the behavioral list fit naturally here, so have short, specific answers ready. Expect to be asked to walk through your CV, so every role should come with the technologies you used (C#, .NET, SQL, cloud services if you have them) and the part you personally owned.

What to demonstrate

Your background and how it relates to the Software Engineer role
Your interest in CFC and in working for an insurance business
How clearly and concisely you describe your own contribution

How to prepare

Write a CV walk-through where each project names the stack and one outcome you personally produced; the CV is reported as fair game for questions.
Prepare two or three sentences on why a specialist insurance provider interests you, without repeating job-advert wording.
Rehearse the strengths question and the what-are-you-learning question aloud so each has one concrete example.
Prepare questions about the team's stack, the Agile ceremonies it uses and what the technical assessment involves.

Technical Assessments

Candidates report technical assessments that may include a take-home task. The stack and requirements candidates describe point to C#, .NET, SQL and design patterns, and the reported technical questions (SOLID with C# examples, recursion, SQL joins at volume, architectural patterns, cloud) show the level of explanation people prepare for. If a take-home appears, the work you submit is also the material you will be asked to explain, so keep it small, tested and easy to defend decision by decision.

What to demonstrate

Working, readable C# code where a take-home or coding task is set
Command of SQL, including how joins behave on large tables
Whether you can explain why you made a design choice, not only what you built

How to prepare

Build one small C# solution with unit tests and a short README covering the decisions and trade-offs; refactor one class so it visibly follows SOLID.
Write a recursive solution and its iterative equivalent, and be ready to state when recursion depth or repeated work makes it the wrong tool.
Take one slow multi-table query, read its execution plan, fix it and record the before and after.
Practise saying aloud how you ensure code is testable (constructor injection, small interfaces, no hidden static state).

Face-to-Face or Virtual Interviews

Candidates report face-to-face or virtual interviews, in more than one session, with engineers and management. This stage is where architecture, cloud, teamwork and Agile conversations are worth rehearsing, alongside a longer discussion of your past projects. Candidates also report prompts about designing for high concurrency and choosing between a monolith and microservices, so be ready to draw a design and name its trade-offs. Stay composed: candidates report that visible nerves can be read as thin technical depth.

What to demonstrate

Architectural reasoning and your ability to compare patterns and their costs
Fit with an Agile team and how you cooperate with product managers and engineers
How you communicate technical work to both engineers and management

How to prepare

Prepare a monolith-versus-microservices answer from a system you know: what you would split, what you would keep together and what operational cost you accept.
Prepare a cloud answer for what you actually deployed or used (compute, storage, queues, monitoring), and how you handled failure and recovery.
Rehearse stories for team cooperation, constructive feedback and being stuck on a technical problem, each with an outcome.
Write the two or three technical choices on your CV you can defend in depth and the alternatives you rejected.

Where candidates lose points

Defining each SOLID letter from memory but never showing C# code

Prepare one before-and-after refactor you can sketch: a class with a type switch becomes an interface plus implementations with constructor injection. Say which letter each change serves and what testing gain it gave you.

Answering the SQL joins question with only 'add an index'

Start from cardinality and the execution plan, then name the join strategy, the fan-out risk, early filtering and one measured result from your own work.

Staying vague about past projects and technical challenges

For every project on your CV, prepare the stack, your specific contribution, one hard problem and its outcome. Candidates report that vague answers about technical challenges are the ones to avoid.

Telling behavioral stories where your own action is missing

For the teamwork, feedback and stuck-on-a-problem prompts, write the story so that the decision, the action and the result are visibly yours, and rehearse it aloud until it is steady.

Letting nerves undermine a correct technical answer

Candidates report that nerves can be read as lack of depth. Rehearse aloud, use a fixed opening sentence per question, and when stuck say what you would check first and why.

Questions & practice

Explain your approach to Recursion and when it is appropriate to use.

Medium · Technical and Architectural Proficiency

Approach

Define it precisely: a recursive function needs a base case and a step that makes the input strictly smaller. Each call adds a stack frame, so extra space is O(depth): O(log n) for a balanced tree or for merge sort's recursion, but O(n) for a degenerate tree or a linked list.
Use it when the data or the algorithm is self-similar: tree and graph traversal (DFS over an org or product hierarchy, nested JSON), divide and conquer (merge sort, quicksort, binary search) and backtracking (permutations, subsets, constraint search). In these cases the recursive version is usually the clearest.
Know the .NET limit. C# does not guarantee tail-call elimination, and a StackOverflowException cannot be caught, so it ends the process. For input whose depth you do not control, rewrite with an explicit Stack<T> (DFS) or Queue<T> (BFS) to move the state onto the heap.
Handle overlapping subproblems. Naive Fibonacci is O(2^n) calls. Memoising with a Dictionary<int, long> makes it O(n), and a bottom-up loop gives O(n) time with O(1) space. Say which one you would ship and why.
Link it to SQL: hierarchies stored as parent_id rows can be walked with a recursive CTE. SQL Server stops at 100 recursion levels by default unless you set OPTION (MAXRECURSION n). Guard against cycles in either language with a visited set or a depth cap.

Follow-up

Rewrite your recursive tree traversal iteratively. What does the explicit stack hold?
What happens if the hierarchy contains a cycle, and how do you detect it?
When would you choose memoisation over a bottom-up table?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
A dashboard runs this for 40 owners in one page load. What changes about the design?

Describe SOLID Principles with examples in C#.

Medium · Technical and Architectural Proficiency

Approach

Give each principle one C# example from a single domain, such as an invoicing or policy-pricing service, so the five read as one design instead of five slogans. Single responsibility: split an InvoiceService that calculates, saves and emails into InvoiceCalculator, IInvoiceRepository and IInvoiceNotifier, each with one reason to change.
Open/closed: replace a switch on product type with an IPricingRule strategy (decimal Apply(Quote q)) and register one class per rule. Adding a rule then means adding a class, and no tested code has to change. Liskov: a subtype must honour its base contract. .NET arrays implement IList<T> but throw NotSupportedException from Add, so code written against IList<T> breaks when it gets an array.
Interface segregation: split a large IRepository<T> into IReadRepository<T> and IWriteRepository<T> so a reporting class cannot see Delete. Dependency inversion: high-level code depends on abstractions passed in through the constructor, and the composition root wires them, e.g. services.AddScoped<IInvoiceRepository, SqlInvoiceRepository>().
Connect the principles to testability. Constructor-injected interfaces let you unit-test InvoiceCalculator with a fake repository and no database. Name the cost too: an interface for every class with a single implementation adds indirection, so I apply SOLID where change is likely, not everywhere.

Follow-up

What is the difference between dependency inversion and using a DI container?
Show a Liskov violation in code you have seen and how you would fix it without breaking callers.
When have you deliberately not applied open/closed, and why?

What are your preferred Architectural patterns for building scalable, maintainable systems?

Medium · Technical and Architectural Proficiency

Approach

Start from the forces, not a favourite pattern: team count, how independently parts must deploy and scale, and consistency needs. For most products I start with a layered or clean architecture where dependencies point inward to the domain, so business rules have no references to EF Core, HTTP or the cloud SDK.
Prefer a modular monolith first: one deployable with enforced module boundaries (separate projects, internal types, no cross-module table access). Split a module into a service only when it needs its own release cadence, scaling profile or failure isolation, because microservices bring network calls, distributed data and more operational work.
Use CQRS where read and write shapes really differ, such as a write model that enforces rules and a denormalised read model for dashboards. Accept the eventual consistency it introduces, and do not apply it to plain CRUD screens.
For event-driven integration between modules or services, publish through a message broker and use the transactional outbox: write the event to an outbox table in the same database transaction as the state change, then relay it. This avoids the lost-message or phantom-message problem of a dual write. Consumers must be idempotent because delivery is at-least-once.
Close with how you keep it maintainable: architecture tests or project references that fail the build on forbidden dependencies, correlation IDs and structured logs across boundaries, and one concrete system you built where you can name the pattern and what it cost.

Follow-up

How do you decide between a monolithic and microservices approach for a new product?
How do you keep data consistent when one business operation spans two services?
What would make you merge two services back together?

How do you utilize Cloud technologies to support your application's infrastructure?

Medium · Technical and Architectural Proficiency

Approach

Anchor the answer in one real application and a named provider (Azure or AWS), then walk through the layers. Compute: App Service or ECS/Fargate for long-running APIs, and Azure Functions or Lambda for event-driven jobs, accepting cold starts and execution limits. Data: a managed relational database (Azure SQL or RDS) with automated backups and point-in-time restore.
Infrastructure as code: Bicep, ARM, CloudFormation or Terraform, kept in the repo and applied from the CI/CD pipeline, so every environment can be rebuilt and every change is reviewed. Avoid manual portal changes, because they drift from the code.
Security: secrets live in Key Vault or Secrets Manager, and the app authenticates with a managed identity or IAM role instead of keys in appsettings. Networking uses least-privilege roles and keeps the database off the public internet.
Resilience and continuity: run across availability zones, put health checks behind the load balancer, autoscale on a metric that tracks load, and decouple slow work with a queue (Service Bus or SQS) plus a dead-letter queue. Define RPO (how much data loss, measured in time, is acceptable) and RTO (how long a restore may take), then choose backups, geo-replication or a warm standby region to meet them.
Operations: centralised logs, metrics and traces (Application Insights or CloudWatch), alerts on symptoms such as error rate and latency, and cost controls through budgets, right-sizing and turning off non-production environments. Name one incident or cost problem you solved this way.

Follow-up

Walk through what happens to your application if its primary region goes down.
How do you deploy a new version with no downtime, e.g. deployment slots or blue-green?
How did you find and cut the largest item on your cloud bill?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

The plan follows the three reported rounds: screening-call stories first, then C#, SQL and design for the technical assessment, then architecture, cloud and behavioral practice for the later interviews, ending with a full dry run.

Day 1 — Map the loop and build your story inventory

Write down the three reported stages and, for each, the questions you are least ready to answer.
Write a CV walk-through in which every project lists the stack (C#, .NET, SQL, cloud if used) and the part you personally owned.
List six real episodes from your work (a refactor, a slow query, a disagreement, feedback you received, a time you were stuck, a sprint change) to reuse across behavioral answers.

Deliverable: A one-page loop map, a CV walk-through script and a list of six episodes tagged with the questions each one can answer.

Day 2 — SOLID in C# and recursion

Write a short C# example for each SOLID principle, using a single class that you refactor step by step (a type switch becoming an interface, constructor injection, small interfaces).
Write one recursive solution and its iterative equivalent; state the base case, the depth limit and when you would choose iteration.
Answer aloud: how do you ensure your code is testable, and what does the refactor you just wrote change about testing?

Deliverable: One annotated C# refactor covering all five principles, one recursion-versus-iteration pair, and a recorded spoken answer on testability.

Day 3 — SQL joins at volume

Take a multi-table query, read its execution plan, and write down the join types used, the row estimates and where they diverge from actual rows.
Fix it with an index or a rewrite (pre-aggregate before a one-to-many join), and record the before and after.

Deliverable: A before-and-after plan comparison for one query, and a spoken answer to the SQL joins question that includes your measured result.

Day 4 — Architecture and cloud

Pick a system you know and write a monolith-versus-microservices answer for it: what you would split, what stays together and the operational cost.
Outline how you would design a service for high concurrency: where state lives, how you avoid contention, and what happens during a partial outage.
Write the cloud services you have actually used (compute, storage, messaging, monitoring) and how each supported the application's availability.

Deliverable: A one-page architecture answer with a diagram, a concurrency design outline, and a cloud usage note with two trade-offs.

Day 5 — Teamwork, Agile and feedback stories

Write the team cooperation story in situation, action, result order, with the decision and evidence of resolution.
Write your Agile answer: cadence, ceremonies, your part in them, and one retrospective change with its result.
Write the constructive-feedback story and the stuck-on-a-technical-problem story, then say all four aloud.

Deliverable: Four written stories (teamwork, Agile, feedback, getting unstuck) and one recording of them spoken aloud.

Day 6 — Strengths, learning and balance

Choose two or three strengths and attach one evidence episode to each; add one area you are actively improving.
Name what you are learning and write one thing you built or changed because of it, including a limitation you found.
Prepare a short natural answer on hobbies and work-life balance that ends with how you keep a steady pace at work, then rehearse all three answers aloud.

Deliverable: Three rehearsed answers (strengths, current learning, hobbies and balance), each with one concrete example.

Day 7 — Full dry run

Run a spoken mock covering the screening-call questions, one SOLID answer, the SQL joins answer and two behavioral stories, ideally with another person.
Write two questions to ask the engineers and two for management.

Deliverable: A tested C# solution with a README, a recorded mock, and four questions to ask.

Behavioral preparation for CFC

Candidates report that the behavioral questions concern your strengths, your learning, team cooperation, hobbies and balance, and Agile experience, and that the final stage includes both engineers and management. Prepare stories where your own decision and result are clear, and rehearse them aloud, since nerves are reported to be mistaken for lack of depth.

Describe a time you received constructive feedback and how you acted on it.

How do you handle complex SQL Joins in high-volume environments?

Medium · Technical and Architectural Proficiency

Approach

Start with the shape of the query, not the index. Name the tables, the join keys, the cardinality (one-to-one, one-to-many, many-to-many) and which side carries the filter. Say you would read the actual execution plan first and compare estimated and actual row counts, since a large gap points to stale statistics or a bad cardinality guess.
Match the join strategy to the data: nested loops with an index seek suits a small filtered outer input; a hash join suits two large unsorted inputs; a merge join suits inputs already sorted on the key. Index the join and filter columns, add included columns where it removes lookups, and select only the columns you need.
Reduce rows before you join. Filter early, and pre-aggregate in a derived table or CTE when a one-to-many join would otherwise multiply rows before a SUM or COUNT. Fan-out is also a correctness bug, so say you check totals against the unjoined table.
Call out the common traps: functions or implicit type conversions on a join column that block index use, a WHERE condition on the right table that turns a LEFT JOIN into an inner join, NOT IN with NULLs (use NOT EXISTS), and OR conditions across tables.
For high volume, add keyset paging instead of OFFSET, batching for writes, a read replica or reporting copy for heavy reads, and partitioning or a summary table when the same join runs repeatedly. Then give a measured result from your own work: rows read, duration and plan before and after.

Follow-up

The query is fast on test data and slow in production. What do you check first?
When would you denormalise or add a summary table instead of tuning the join?
How would you page through a large joined result consistently while rows are being inserted?