Candidates describe 66degrees as a cloud consulting company. Its engineers build new cloud-native applications and modernize legacy systems for enterprise clients. Candidates describe the work as spanning the front end, backend services, data and deployment, with direct contact with client stakeholders. The reported questions reflect this: they lean on your own projects and on cloud architecture as much as on algorithms.
The reported questions fall into four groups. Five ask about your own work: a resume walk-through of a project you owned, how you used data to make decisions, a difficult production issue in the cloud, full-stack experience with React and Python or .NET, and how you keep code clean and testable. Candidates report detailed questions on the projects listed on their resumes. Have three or four projects ready down to the schema, request volumes, failure modes and the decision you personally made.
Five are cloud design questions: a multi-region web application, relational versus non-relational databases for a client project, high availability and disaster recovery, a secure high-volume API gateway, and cutting compute and storage costs. The reported topic emphasis is Microsoft Azure, Python, React and full-stack development. Practise naming concrete managed services on one cloud, and state RTO, RPO, consistency and cost trade-offs out loud instead of only drawing boxes.
The coding questions are practical. They cover a medium data-structure problem, optimizing a slow algorithm or query, transforming a nested JSON payload, error handling in backend services, and refactoring legacy code. The behavioral questions cover disagreement over technical direction, shifting requirements in consulting work, explaining technical ideas to non-technical people, a failure, and why 66degrees. Practise the coding in Python with tests, and write the stories in STAR form with a measurable result.
Recruiter Screening
reportedCandidates describe the Recruiter Screening as a first conversation about your background, your interests and which open role fits you. The role requirements list several tracks (Full Stack Engineer, App Dev Architect, Forward Deployment Engineer), so use this call to learn which one you are being considered for. Also ask what the Technical Assessment will look like, since candidates report it can be a resume deep dive, live coding or system design. Keep your background summary short and built around the stack in the posting.
What to demonstrate
- Whether your experience fits one of the open roles
- Your interests and which track suits them
- Your background as you summarize it
How to prepare
- A short spoken summary of your career that names the languages (Python, JavaScript/TypeScript or .NET), React and the cloud platform you have shipped on
- A one-line reason for wanting 66degrees, tied to client-facing or cloud delivery work you have done
- Questions for the recruiter: which track, the format of the Technical Assessment, and whether the role is remote, hybrid or based at a hub
Hiring Manager Discussion
reportedCandidates report a conversation with the hiring manager that goes deeper into fit and expectations for the role. No specific format is reported, so prepare it as a structured conversation about your projects and how you work. Use the same project stories you build for the resume deep dive, and be ready to discuss how you handle changing scope on client work. Bring your own questions about the team's projects and delivery model.
What to demonstrate
- Fit and expectations for the role
- Candidates report this conversation goes further into fit than the recruiter screen
How to prepare
- Two project stories, each with your own decision, the alternative you rejected and a measured result
- A concrete account of how you handle requirements that change mid-project on client work
- Questions about the client mix, which cloud the team mostly delivers on, and what your first projects would be
Technical Assessment
reportedCandidates describe the Technical Assessment as taking one of three forms: a deep dive into your resume, live coding, or a system design exercise. Reports do not show one consistent format, so ask the recruiter which one you will get and prepare all three. For live coding, practise in Python on practical problems such as transforming nested JSON and on standard hash-map and heap problems, stating the brute force before improving it. For design, rehearse cloud architectures end to end: regions, data replication, gateways, availability and cost. For the resume deep dive, be ready to justify every technology on your CV.
What to demonstrate
- Working, tested code written live
- Cloud architecture reasoning: regions, data stores, availability and cost trade-offs
- Depth behind the projects and technologies on your resume
How to prepare
- Code a nested-JSON flatten and transform in Python with tests for empty objects, nulls, arrays and deep nesting
- Whiteboard a multi-region web app and an API gateway using named managed services on Azure or Google Cloud
- Rehearse a measure-then-fix answer for a slow query using real EXPLAIN ANALYZE output from a local database
Final Rounds
reportedCandidates report final interviews with directors or senior leadership before the decision. No question set is reported for this stage specifically, so prepare higher-level versions of your material. Have a version of your strongest project that leads with the outcome. Bring behavioral stories on disagreement, failure and explaining technical ideas to non-technical people, each ending in a result. Prepare a grounded answer on why 66degrees and why your track.
What to demonstrate
- Candidates report this stage finalizes the evaluation with senior leadership
- Reported interviewers: directors or senior leadership
How to prepare
- Be ready to present your work and decisions to senior leadership
- Short and long versions of your strongest project: outcome first, then architecture and your decision
- STAR stories for disagreement, failure and explaining a technical concept to a non-technical audience, each with a result
- Questions for leadership about the delivery model and the cloud practice areas the team covers
PracHub editorial advice for the preparation topics above.
Walking through your resume as a list of technologies instead of decisions
For the resume and full-stack questions, build each project around the choice you made, the option you rejected and a number that moved. Candidates report detailed questions on resume projects, so cut anything from your CV that you cannot explain down to the schema and failure modes.
A multi-region or high-availability design that never says how data is replicated
State RTO and RPO up front. Pick a replication model (single primary with replicas, active-active, or users partitioned by region), say whether it is synchronous or asynchronous, and name the consistency guarantee you give up. Putting load balancers in every region is the easy half of the answer.
A nested-JSON function that only handles the happy path
Before coding, agree how arrays, nulls, empty objects and keys containing the separator are handled, then test those cases out loud. Mention Python's recursion limit and when you would switch to an explicit stack or a streaming parser.
Answering the optimization question with a guess like 'add an index' or 'add caching'
Lead with measurement (a profiler or EXPLAIN ANALYZE), name the specific cause, then give the fix and how you verified it. Include what the fix costs: slower writes for an index, invalidation work for a cache.
A why-66degrees answer that could apply to any company
Refer to the consulting and cloud delivery work candidates describe, and connect it to client-facing or cloud projects you have done. Find out your track at the recruiter screen and tailor the answer to it.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Walk me through your thought process while solving a medium-difficulty data structure or algorithm problem.
Walk me through your thought process while solving a medium-difficulty data structure or algorithm problem.
Approach
- Show a repeatable sequence: restate the problem and constraints, work a small example by hand, ask about input size and edge cases, state a brute-force solution with its complexity, then improve it.
- Narrate a concrete example. For top-k frequent elements, sorting all counts is O(n log n). A hash map of counts plus a size-k min-heap is O(n log k), and bucketing by frequency is O(n).
- Justify the data structure from the access pattern: a hash map for O(1) lookup, a heap for repeated min or max, two pointers or a sliding window for contiguous ranges, BFS for shortest paths in unweighted graphs.
- Write the code, then test it out loud on an empty input, a single element, duplicates and the largest size. State the final time and space complexity.
Follow-up
- What changes if the input is a stream you cannot store?
- Can you do it with less memory?
- How would you unit-test this function?
Write a function to parse and transform a nested JSON payload efficiently.
Write a function to parse and transform a nested JSON payload efficiently.
Approach
- Clarify the transform first: flatten to dot-path keys, rename or filter fields, convert types, or reshape into records. Ask how arrays should appear (an index in the path or one row per element), how large payloads get, and how to treat nulls and missing keys.
- For flattening, recurse over the structure: a dict extends the path with each key, a list extends it with the index, and a scalar emits the joined path and its value. Passing path + (key,) to each call copies O(depth) per level, the same asymptotic cost as string concatenation. For a real saving, keep one mutable list and append before descending and pop after returning (backtracking), or store parent pointers and build the path only at the leaf.
- State the bounds precisely. Every leaf emits its full path, so the output alone is O(leaves x depth), and time is linear in input size plus output size, not in node count alone. The join at each leaf cannot be avoided because it is part of the output. Recursion uses O(depth) call stack, or O(depth^2) if each frame holds its own path tuple. An explicit stack that pushes every child holds all pending siblings, so it can reach O(n) for wide objects.
- Handle the edge cases: empty dicts and lists (keep or skip them, as agreed), None, keys that contain the separator, mixed types in a list, and very deep nesting. Python's default recursion limit is about 1000, so an iterative stack is safer for untrusted, deeply nested input.
- For payloads that do not fit in memory, use a streaming parser such as ijson. Show tests on a small nested example, including an empty object and a key containing the separator.
Follow-up
- How would you write the reverse (unflatten), and what information can flattening lose?
- How would you validate the payload against an expected schema first?
- What changes if this transform runs over millions of records in a pipeline?
Describe how you approach refactoring legacy code without breaking existing functionality.
Describe how you approach refactoring legacy code without breaking existing functionality.
Approach
- Pin down current behavior first. Write characterization tests that capture what the code does today around the area you will change, including odd outputs. If the code is hard to call, add logging or metrics first.
- Find seams. Extract the logic you need to change behind an interface so you can test it in isolation, and break hard dependencies on globals, the database or the system clock.
- Change in small, reversible steps. Keep refactoring commits separate from behavior changes and keep each step deployable. For larger rewrites, use feature flags or the strangler fig pattern, moving routes or features to new code one at a time.
- Verify in production: compare old and new outputs side by side (shadow traffic or dual runs) where the risk is high, watch error rates after each release, and keep a rollback ready. Use a real example and say what you deliberately left alone.
Follow-up
- The code has no tests and no documentation. Where do you start?
- How do you convince a client to pay for a refactor that adds no features?
- When would you rewrite instead of refactor?
How do you manage shifting priorities and ambiguous project requirements in a consulting environment?
How do you manage shifting priorities and ambiguous project requirements in a consulting environment?
Approach
- Answer with a story from client or project work where scope or priorities changed: a stakeholder replaced the main requirement, a deadline moved, or a dependency fell through.
- Show your method. Clarify the goal behind the request, write down assumptions and get them confirmed, and split work into small deliverables so re-planning is cheap. Make trade-offs explicit: if this comes in, what moves out?
- Reduce ambiguity actively. Build a quick prototype or mock-up to make requirements concrete, and keep a decision log so settled questions are not reopened.
- End with the outcome and what you changed in your process. Avoid stories where you simply absorbed every change by working longer hours.
Follow-up
- How do you push back when a client keeps adding scope?
- Two stakeholders send conflicting urgent requests. How do you decide?
- What do you do when nobody can define what done means?
How do you optimize an inefficient algorithm or query that is causing performance bottlenecks?
How do you optimize an inefficient algorithm or query that is causing performance bottlenecks?
Approach
- Measure before changing anything. Reproduce the problem with realistic data, then profile the code (cProfile or py-spy for Python) or read the query plan (EXPLAIN ANALYZE in PostgreSQL, the actual execution plan in SQL Server) to find where the time goes.
- For queries, look for full scans on selective filters, and check that the predicate does not wrap the column in a function or cast that makes its index unusable. Also look for N+1 queries from an ORM, SELECT * pulling wide rows, and joins that fan out before aggregation.
- For algorithms, replace nested-loop lookups with a hash map (O(n^2) to O(n)), sort once instead of repeatedly, batch network and disk calls, memoize repeated work, and stream large inputs instead of loading them whole.
- Verify with the same benchmark and confirm the results did not change. Check the side costs: each index slows writes and every cache needs invalidation. Add a regression test or a latency alert.
Follow-up
- The index exists but the planner ignores it. What are the likely reasons?
- What does an extra index cost on a write-heavy table?
- How would you catch this regression in production before users report it?
Explain why the owner filter ignores the listing index
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?
Walk me through your resume and highlight a complex technical project you owned from end to end.
Walk me through your resume and highlight a complex technical project you owned from end to end.
Approach
- Open with a brief arc: current role, the stack you work in, and the one project you will go deep on. Pick a project where you owned both design and delivery, ideally full-stack or cloud-deployed, since that matches the reported stack.
- For the project, cover in order: the problem and who used it, the architecture (front end, API, data store, cloud services), the decision you made and the alternative you rejected, and the measured result (latency, cost, adoption, defect rate).
- Name the hardest technical problem in the project and how you solved it, such as a migration, a scaling limit or a consistency bug. Candidates report detailed questions on resume projects, so know the schema, request volumes and failure modes.
- Close with what you would change now. It shows you understand the trade-offs behind the result.
Follow-up
- Why did you pick that database or cloud service over the alternative?
- What broke in production, and how did you find out?
- Which parts did someone else own, and how did you work with them?
How have you utilized data in your past work or projects to drive decision-making or performance improvements?
How have you utilized data in your past work or projects to drive decision-making or performance improvements?
Approach
- Pick one concrete case with a before and after number. Examples: a page whose p95 latency you cut using APM traces, a query you fixed from slow-query logs, or a feature you dropped after usage data showed no adoption.
- Structure it as: the question you had, where the data came from (logs, metrics, product analytics, a SQL query on a replica), what it showed, the decision you made, and the measured result.
- Say how you checked the data was trustworthy: instrumentation gaps, sample size, and a comparison period not distorted by a release or seasonality.
- If you have one, add a case where the data contradicted your instinct and you changed course.
Follow-up
- How did you know the improvement came from your change and not something else?
- What would you instrument differently next time?
- How did you present the result to a non-technical stakeholder?
What experience do you have building full-stack applications using modern frameworks like React paired with ba
What experience do you have building full-stack applications using modern frameworks like React paired with backend technologies like Python or.NET?
Approach
- Describe one app end to end: the React front end, the backend (for example FastAPI or Django in Python, or ASP.NET Core in .NET), the database, authentication, and where and how it was deployed.
- Go one level deeper on the front end. Explain how you managed state (local state, context, a store such as Redux, or a server-state cache such as React Query) and how you handled loading, error and empty states.
- On the backend, cover the API contract (REST or GraphQL, versioning, pagination, validation). Explain how the front end and backend stayed in sync, for example with TypeScript types generated from an OpenAPI schema.
- Finish with testing and delivery: component tests, API tests, and the CI/CD pipeline that built and deployed the app to containers or a managed app service.
Follow-up
- How did the React app authenticate to the API, and where were tokens stored?
- What would you change to make the app faster for users on slow connections?
- Why that backend framework rather than another one you know?
How do you approach writing clean, testable, and maintainable code in a fast-paced team?
How do you approach writing clean, testable, and maintainable code in a fast-paced team?
Approach
- Give concrete practices, not adjectives. Keep pull requests small, give each function one responsibility, use names from the domain, and inject dependencies so business logic can be unit-tested without real cloud services.
- Describe a test strategy: many fast unit tests, fewer integration tests against a real database in a container, a few end-to-end tests. When you fix a bug, write a test that reproduces it.
- Name the automation that keeps quality cheap under deadline pressure: formatters and linters (Ruff or Black for Python, ESLint and Prettier for TypeScript), type checking (mypy, TypeScript strict mode), and CI that blocks merges when checks fail.
- Address the trade-off honestly. When you ship a shortcut, record it as a ticket with an owner, and give an example of paying one down.
Follow-up
- Tell me about a time you skipped tests to hit a deadline. What happened?
- How do you review a pull request that is too large?
- How do you test code that calls a cloud service?
How would you design a scalable web application deployed across multiple cloud regions?
How would you design a scalable web application deployed across multiple cloud regions?
Approach
- Clarify first: where users are, the read/write ratio, the latency and availability targets, RPO and RTO, and whether data residency rules pin some data to a region.
- Baseline design: a stateless app tier in each region (Kubernetes or a managed app service) behind regional load balancers, plus a CDN for the static React build. In front, put a global entry point with health checks, either DNS-based routing or a global HTTP load balancer such as Azure Front Door.
- The hard part is data. One option is a single primary region with read replicas elsewhere: simple, but writes pay cross-region latency and failover needs promotion. Another is active-active on a multi-region database, which gives local writes but requires conflict handling and weaker consistency. A third is partitioning users by home region. Choose one for the stated requirements and say what you give up.
- Cover sessions (stateless tokens or a replicated cache), background work through queues in each region, and observability. Then walk through a full region outage: how health checks shift traffic and what data might be lost.
Follow-up
- A user writes in one region and immediately reads in another. What do they see?
- Walk through failover step by step. How do you test it?
- How does the cost compare with one region plus cross-region backups?
Discuss your approach to choosing between relational and non-relational databases for a new client project.
Discuss your approach to choosing between relational and non-relational databases for a new client project.
Approach
- Start from requirements, not preference: the shape of the data, the access patterns, transactional needs, expected volume and growth, and the client team's ability to operate the database.
- Relational databases (PostgreSQL, SQL Server, Azure SQL) fit related entities, multi-row transactions, ad hoc reporting and constraints the database enforces. They scale reads with replicas and writes vertically or through sharding work.
- Non-relational stores fit specific patterns. Document stores (Cosmos DB, MongoDB, Firestore) suit self-contained records read by key with a flexible schema, key-value stores suit caching and sessions, and wide-column stores suit very high write throughput. The cost is designing around a partition key and doing joins in application code.
- Give a default with a reason, for example relational for a line-of-business app, plus a key-value or document store for one high-volume access path. Mention JSON columns in PostgreSQL or SQL Server as a middle ground.
Follow-up
- How would you choose a partition key in a document store for this project, and which query becomes expensive?
- The client may want to switch databases later. How do you keep that option open?
- How do you support reporting if the main store is NoSQL?
How do you ensure high availability and disaster recovery in cloud infrastructure?
How do you ensure high availability and disaster recovery in cloud infrastructure?
Approach
- Separate the two. High availability keeps the service running through instance and zone failures. It avoids data loss only when replication across zones is synchronous (for example zone-redundant Azure SQL); with asynchronous replicas a failover can lose the last writes, so RPO depends on the replication mode. Disaster recovery covers losing a region, data corruption or accidental deletion. Anchor both on RTO and RPO agreed with the business.
- For HA, run redundant instances across availability zones behind health-checked load balancers, with autoscaling and zone-redundant managed databases that fail over automatically. Check for single points of failure in DNS, secrets and queues.
- For DR, use point-in-time backups stored in another region and account, geo-replicated databases and storage, and infrastructure as code (Terraform, Bicep) so the stack can be rebuilt. Geo-replication is usually asynchronous, so state the RPO it implies. Pick a pattern priced against the RTO and RPO: backup-and-restore, pilot light, warm standby or active-active.
- Make it real with scheduled restore tests and failover drills, runbooks, and alerts on replication lag and failed backups. A backup that has never been restored is not a recovery plan.
Follow-up
- Someone drops a production table by mistake. How do you recover, and how much data is lost?
- How would you justify the cost of warm standby to a client?
- How do you test failover without hurting users?
Explain how you would architect a secure API gateway handling high-volume traffic.
Explain how you would architect a secure API gateway handling high-volume traffic.
Approach
- List the gateway's jobs: TLS termination, authentication (validating OAuth2/OIDC JWTs or API keys), route-level authorization, rate limits and quotas, request validation and size limits, routing to backends, and logging with correlation IDs.
- For scale, keep the gateway stateless and run it horizontally across zones behind a load balancer. Keep shared state such as rate-limit counters in a fast store like Redis, using a token-bucket or sliding-window algorithm. Accept slight over-admission rather than a global lock on every request.
- Layer the security: a WAF and DDoS protection at the edge, private networking from gateway to services, mTLS or signed tokens for service-to-service calls, and secrets kept in a key vault rather than in configuration.
- For resilience, set timeouts and circuit breakers per backend, cache safe GET responses and degrade gracefully. Name a managed option (Azure API Management, Apigee, Kong) and say when you would run your own instead.
Follow-up
- How do you enforce a per-client rate limit consistently across many gateway instances?
- Where is the JWT validated, and how do you handle signing-key rotation?
- The gateway's added latency becomes the bottleneck. What do you change?
What strategies do you use to optimize cloud compute and storage costs in a distributed architecture?
What strategies do you use to optimize cloud compute and storage costs in a distributed architecture?
Approach
- Start with visibility. Tag resources by project and client, set Azure Cost Management budgets and alerts (Cloud Billing budgets on GCP), and find the top cost drivers before changing anything. These are usually compute, managed databases, egress and logging.
- For compute, right-size from utilization metrics and autoscale on load. Cover steady baseline load with Azure Reservations or Savings Plans (committed-use discounts on GCP), run interruptible batch work on Azure Spot VMs (Spot VMs on GCP), and put spiky low-volume services on Container Apps or Functions with scale-to-zero (Cloud Run or Cloud Functions on GCP). Shut down idle non-production environments on a schedule.
- For storage, move ageing data to the Blob Storage cool, cold and archive tiers with lifecycle management policies (Nearline, Coldline and Archive with lifecycle rules in Cloud Storage), delete orphaned disks and snapshots, compress and partition data, and set Log Analytics retention. Watch cross-region and internet egress, which distributed designs often underestimate.
- Close with the trade-off: each saving costs some reliability or latency (Spot evictions, cold starts on scale-to-zero, rehydration delays from the archive tier, commitment lock-in on reservations). Tie each lever to the workload's actual requirements.
Follow-up
- The bill jumped this month. How do you find out why?
- When does serverless become more expensive than containers?
- How do you stop non-production environments from running all weekend?
Explain a time when you had to debug a difficult production issue in a cloud environment.
Explain a time when you had to debug a difficult production issue in a cloud environment.
Approach
- Tell it in STAR order with a technical spine: the symptom (error rate, latency, bad data), how it was detected, the blast radius and your role.
- Show mitigation before diagnosis: a rollback, turning off a feature flag, scaling out or failing over, and why that choice was safe.
- Walk through the diagnosis concretely. Cover what changed (deploys, config, dependency versions, traffic), which logs, metrics and traces you correlated, and the first hypothesis you ruled out. Name a cloud-specific cause if it applied: throttling limits, connection-pool exhaustion, expired secrets or certificates, a misconfigured IAM role, cold starts.
- End with the root cause, the permanent fix and the prevention you drove: an alert, a test, a runbook entry or a postmortem action.
Follow-up
- How did you tell the cause from a coincidence in the timeline?
- What alert would have caught this earlier?
- How did you keep users or the client informed during the incident?
Seven days built around the four reported stages and the reported questions. The order runs from resume stories and a React and Python build to coding and robustness, then cloud design, behavioral stories, and a full rehearsal for the later stages.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Project stories and a React screen
- Pick two projects and write each one up as problem, architecture, your decision, the rejected alternative and the measured result
- Build a small React screen that fetches from a Python API, with loading, error and empty states, token handling and one component test, then rehearse your state-management answer for the full-stack question on it
- Answer the resume walk-through and full-stack experience questions aloud using those projects and the screen you built, and record yourself
- Write one example of using data to make a decision, naming the data source and the before and after numbers
Deliverable: Two written project stories, a working React screen on a Python API with one component test, one data-driven decision example, and recordings of the resume and full-stack answers.
Practice prompt ↗Practice prompt ↗Practice prompt ↗02Practical coding in Python
- Implement a nested-JSON flattener in Python with backtracking on one mutable path list, plus tests for nulls, empty containers, arrays and deep nesting
- Write the matching unflatten function and note what flattening can lose
- Solve two medium hash-map or heap problems (for example top-k frequent elements) aloud, covering the brute force, the improvement and the complexity
Deliverable: A tested flatten/unflatten module with stated output-sensitive complexity, and two narrated solutions with stated time and space complexity.
Practice prompt ↗Practice prompt ↗03Performance, error handling and legacy code
- Create a slow query on a local PostgreSQL table, read EXPLAIN ANALYZE, fix it with an index, then break the index by wrapping the column in a function
- Work the practice question on why an owner filter ignores the listing index
- Outline error handling for one backend endpoint: validation, retries with backoff and jitter, idempotency keys, timeouts
- Write a refactoring story built on characterization tests and incremental, reversible steps
Deliverable: Before and after query plans, an error-handling outline for one endpoint, and a written refactoring story.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗04Cloud design: multi-region app and API gateway
- Sketch the multi-region web app on Azure or Google Cloud with a global entry point, stateless regional tiers, a CDN and a chosen data replication model
- Sketch the API gateway with authentication, token-bucket rate limiting in Redis, a WAF, routing and logging
- For each design, write what fails first at ten times the traffic and what happens when a region goes down
Deliverable: Two architecture diagrams, each with written scaling and failure notes.
Practice prompt ↗Practice prompt ↗05Data stores, availability, cost and incidents
- Write a one-page guide to choosing relational or document storage, with one client scenario for each
- Set RTO and RPO for a sample app, note which replication mode each target needs, and match a recovery pattern (backup-restore, pilot light, warm standby, active-active) with its cost
- List five Azure cost levers (Reservations or Savings Plans, Spot VMs, scale-to-zero, Blob tiers with lifecycle policies, budgets) with their GCP equivalents and reliability trade-offs
- Rehearse your cloud production-debugging story: mitigation, diagnosis, root cause and prevention
Deliverable: A database decision guide, an HA/DR plan, a cost-lever list and a rehearsed incident story.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗06Behavioral stories
- Write STAR stories for a disagreement over technical direction, shifting priorities on client work, and a failure, each with a measurable result
- Explain eventual consistency and one of your own systems to a non-technical listener, then ask them to restate it
- Record the stories and rewrite any that blame others or end without a result
Deliverable: Recorded STAR stories for disagreement, shifting priorities, failure and a plain-language explanation tested on a real listener.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗07Full rehearsal and why 66degrees
- Write your why-66degrees answer, tied to the consulting model, your track and your stack
- Run a mock session: one coding problem, one cloud design question and two behavioral questions back to back
- Rehearse the clean-code answer using the actual linters, type checkers and test strategy you work with
- Write your questions for the recruiter, hiring manager and leadership stages
Deliverable: A written why-66degrees answer, mock-session notes with fixes, a clean-code answer and a question list for each stage.
Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
The reported behavioral questions focus on client and team work: disagreeing about technical direction, handling shifting and ambiguous requirements in consulting, explaining technical ideas to non-technical people, owning a failure, and why you want to join 66degrees. Prepare each as a STAR story built on your own decision and a measurable result, and keep a plain-language version of your main project ready.
How do you handle edge cases and error handling when writing robust backend services?
How do you handle edge cases and error handling when writing robust backend services?
Approach
- Validate at the boundary. Schema-validate requests (pydantic in Python, data annotations or FluentValidation in .NET), reject bad input with clear 4xx errors, and keep internal code free of repeated defensive checks.
- Classify failures as client errors, transient dependency errors (timeouts, 503s, throttling) or bugs. Retry only transient errors, with exponential backoff, jitter and a cap, and only for idempotent operations or requests carrying an idempotency key.
- Protect the service with timeouts on every outbound call, circuit breakers, bounded connection pools, and dead-letter queues for messages that keep failing.
- Make failures visible: structured logs with correlation IDs, no swallowed exceptions, and error-rate metrics. Write tests for empty input, boundary values, duplicate requests, partial failures and dependency timeouts, and give one example from a service you built.
Follow-up
- A payment call times out. Do you retry, and how do you avoid charging twice?
- What does the client receive when a downstream service is down?
- How do you simulate a dependency failure in tests?
Tell me about a time you had a disagreement with a team member or stakeholder regarding a technical direction.
Tell me about a time you had a disagreement with a team member or stakeholder regarding a technical direction. How did you resolve it?
Approach
- Pick a real technical disagreement where you held a position: a framework or database choice, build versus buy, or how much testing to do before a client deadline.
- Keep the situation brief and spend the time on substance. Cover the two options, the criteria that mattered (cost, timeline, risk, the client's ability to operate it) and the evidence you gathered, such as a spike, a benchmark or a cost estimate.
- Show how it was resolved. You engaged with the other side's strongest argument, agreed on criteria or a bounded experiment, and committed to the outcome even if your option lost.
- Give the result and how the working relationship looked afterwards. The answer falls apart if the other person is cast as simply wrong, or if escalating to a manager was your only move.
Follow-up
- What would you have done if the decision had gone the other way?
- Which part of their argument did you come to agree with?
- How was the decision communicated to the client or wider team?
Describe a situation where you had to explain a complex technical concept to a non-technical audience.
Describe a situation where you had to explain a complex technical concept to a non-technical audience.
Approach
- Choose a case with a real decision at stake: why a migration needed downtime, why a cloud bill grew, or why a security fix would delay a release.
- Show the technique. Start from what the audience cares about (cost, risk, timeline), use an analogy or a simple diagram, drop jargon, and check understanding by asking them to restate the decision in their own words.
- Give the outcome: the decision your explanation made possible, and the written summary you sent afterwards.
- Be ready to do it live. Practise explaining one of your own systems, or a concept such as eventual consistency or load balancing, in plain language.
Follow-up
- Explain eventual consistency as if I ran the client's finance team.
- How did you know they actually understood?
- What did you do when they still disagreed after the explanation?
Why do you want to work at 66degrees, and how does your background align with our engineering goals?
Why do you want to work at 66degrees, and how does your background align with our engineering goals?
Approach
- Connect three things: the work candidates describe at 66degrees (building and modernizing cloud applications for enterprise clients), the parts of your background that match it, and what you want next.
- Be specific about the consulting side: the variety of client problems, direct work with stakeholders, and delivery on Azure or Google Cloud. Say why that suits you better than a single-product company.
- Map your experience to the stack in the posting with one example per item, such as a React and Python app you deployed to Azure, rather than reciting a list of technologies.
- Avoid generic praise and claims you cannot support. Read the specific posting and know your track before the call.
Follow-up
- Which track interests you most, and why?
- What would you find hardest about client-facing work?
- What do you want to learn in your first year?
Tell me about a time you failed or made a mistake on a project, and what you learned from the experience.
Tell me about a time you failed or made a mistake on a project, and what you learned from the experience.
Approach
- Choose a real mistake you caused that had consequences: a bad deploy, a missed requirement, an underestimate, or a design that did not scale. Do not offer a strength disguised as a weakness.
- Keep the situation short and spend most of the answer on your actions: how you noticed, how you limited the damage, and who you told and how quickly.
- Make the lesson concrete and show you applied it later. Name the checklist, test, review step or estimation habit you adopted, and a later project where it made a difference.
- Own it plainly. Blaming the team, the client or unclear requirements undermines the answer.
Follow-up
- What would you do differently on day one of that project?
- How did the people affected react, and how did you rebuild their trust?
- Has a similar mistake happened since?
- 01
Tell me about a time you had a disagreement with a team member or stakeholder regarding a technical direction. How did you resolve it?
- 02
How do you manage shifting priorities and ambiguous project requirements in a consulting environment?
- 03
Describe a situation where you had to explain a complex technical concept to a non-technical audience.
- 04
Tell me about a time you failed or made a mistake on a project, and what you learned from the experience.
- 05
Describe a situation where you had to convince a skeptical stakeholder to adopt a better technical approach.
- 06
Tell me about a time when project requirements changed drastically mid-sprint. How did you adapt?
How many rounds are in the 66degrees Software Engineer interview?
Candidates report four stages: Recruiter Screening, Hiring Manager Discussion, Technical Assessment and Final Rounds. The last stage is with directors or senior leadership. Reports also note that a team may change a round's format or add a specialist technical panel when the opening is weighted toward full-stack, cloud or architecture work.
66degrees Software Engineer candidate reports ↗How long does the process take from first call to decision?
Reports vary. The reported loop runs about three to five weeks, and some candidates describe getting from the recruiter call to the final rounds in about two weeks. Reports attribute timeline variation to scheduling availability and team hiring needs, so ask the recruiter for the expected sequence early.
66degrees Software Engineer candidate reports ↗Is the Technical Assessment live coding or system design?
Candidates report it can be either, or a deep dive into your resume. Ask at the recruiter screen which format your track uses, and prepare all three. That means Python coding on practical problems such as transforming nested JSON, cloud design questions such as a multi-region web app or an API gateway, and a detailed defence of the projects on your CV.
66degrees Software Engineer candidate reports ↗Which technologies should I prepare?
The requirements candidates describe list Python, JavaScript/TypeScript or .NET, React, SQL and NoSQL databases, and cloud fundamentals. Azure or Google Cloud, Docker, Kubernetes, CI/CD and data engineering basics are listed as a plus. The reported topic emphasis is Microsoft Azure, Python, React and full-stack development, so learn one cloud's compute, database, networking and identity services by name.
66degrees Software Engineer candidate reports ↗Are the roles remote or location-specific?
Candidates report a mix of remote, hybrid and hub-based roles, with hubs mentioned in the United States and India. Confirm the arrangement for your posting at the recruiter screen.
66degrees Software Engineer candidate reports ↗Do I need consulting experience?
The requirements candidates describe list client-facing consulting or professional-services experience as an advantage, not a must-have. Several reported questions involve stakeholders and non-technical audiences. Without consulting experience, use stories where you worked directly with internal customers, business teams or external partners, and show how you handled changing requirements.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 0166degrees Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Raytheon Technologies Corporate Headquarters Software Engineer Interview Guide
What Raytheon Technologies Corporate Headquarters asks Software Engineer candidates, from reported rounds and questions.
nference Software Engineer Interview Guide
What nference asks Software Engineer candidates, from reported rounds and questions.
Kpmg Us Software Engineer Interview Guide
What Kpmg Us asks Software Engineer candidates, from reported rounds and questions.
Inovex Software Engineer Interview Guide
What Inovex asks Software Engineer candidates, from reported rounds and questions.