66degrees Software Engineer Interview Guide

The 60-second brief

Candidates describe 66degrees as a cloud consulting company. Its engineers build new cloud-native applications for enterprise clients and modernize legacy ones. The stack in the requirements candidates describe has Python, JavaScript/TypeScript or .NET on the backend, React on the front end, SQL and NoSQL databases, and cloud fundamentals. Experience with Azure or Google Cloud, Docker, Kubernetes and CI/CD is listed as a plus. Candidates describe engineers working across the front end, services, data and deployment, alongside architects, product managers, data engineers and client stakeholders. The role requirements list tracks such as Full Stack Engineer, App Dev Architect and Forward Deployment Engineer.

This guide is for mid-level and senior engineers interviewing for a Software Engineer opening at 66degrees, including the full-stack, application architecture and forward-deployment tracks listed in the role requirements. It covers the four reported stages and the reported questions, grouped as resume deep dive, cloud system design, problem-solving and coding, and behavioral. Each question gets an answer approach and likely follow-ups. The guide also has a seven-day plan, the specific ways to lose points on these question types, and answers to common process questions.

Candidates report four stages: Recruiter Screening, Hiring Manager Discussion, Technical Assessment and Final Rounds. Reports of the total length range from about two weeks to three to five weeks. The Technical Assessment is reported as a resume deep dive, live coding or a system design exercise, so prepare for all three.

Focus areas

• Microsoft Azure
• Python
• React

Overview

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.

The 66degrees interview process

The four stages below are the ones candidates report. The Technical Assessment format varies between loops, and the final stage is reported to involve directors or senior leadership.

Recruiter Screening

Candidates 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

Candidates 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

Candidates 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

Candidates 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

Where candidates lose points

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.

Questions & practice

Walk me through your thought process while solving a medium-difficulty data structure or algorithm problem.

Medium · Problem-Solving and Coding

Approach

1. 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.
2. 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).
3. 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.
4. 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.

Medium · Problem-Solving and Coding

Approach

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Medium · Problem-Solving and Coding

Approach

1. 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.
2. 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.
3. 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.
4. 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?

Medium · Behavioral and Collaborative Alignment

Approach

1. 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.
2. 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?
3. 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.
4. 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?

Medium · Problem-Solving and Coding

Approach

1. 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.
2. 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.
3. 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.
4. 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

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

1. 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.
2. 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.
3. 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.
4. 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.

Medium · Technical and Resume Deep Dive

Approach

1. 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.
2. 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).
3. 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.
4. 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?

Medium · Technical and Resume Deep Dive

Approach

1. 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.
2. 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.
3. Say how you checked the data was trustworthy: instrumentation gaps, sample size, and a comparison period not distorted by a release or seasonality.
4. 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

Medium · Technical and Resume Deep Dive

What experience do you have building full-stack applications using modern frameworks like React paired with backend technologies like Python or.NET?

Approach

1. 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.
2. 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.
3. 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.
4. 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?

Medium · Technical and Resume Deep Dive

Approach

1. 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.
2. 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.
3. 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.
4. 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?

Medium · System Architecture and Design

Approach

1. 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.
2. 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.
3. 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.
4. 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.

Medium · System Architecture and Design

Approach

1. 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.
2. 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.
3. 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.
4. 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?

Medium · System Architecture and Design

Approach

1. 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.
2. 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.
3. 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.
4. 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.

Medium · System Architecture and Design

Approach

1. 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.
2. 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.
3. 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.
4. 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?

Medium · System Architecture and Design

Approach

1. 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.
2. 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.
3. 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.
4. 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.

Medium · Technical and Resume Deep Dive

Approach

1. 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.
2. Show mitigation before diagnosis: a rollback, turning off a feature flag, scaling out or failing over, and why that choice was safe.
3. 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.
4. 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?

Suggested practice checklist

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.

Day 1 — Project 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.

Day 2 — Practical 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.

Day 3 — Performance, 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.

Day 4 — Cloud 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.

Day 5 — Data 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.

Day 6 — Behavioral 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.

Day 7 — Full 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.

Behavioural preparation

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.

1. How do you manage shifting priorities and ambiguous project requirements in a consulting environment?
2. Describe a situation where you had to convince a skeptical stakeholder to adopt a better technical approach.
3. Tell me about a time when project requirements changed drastically mid-sprint. How did you adapt?

How do you handle edge cases and error handling when writing robust backend services?

Medium · Problem-Solving and Coding

Approach

1. 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.
2. 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.
3. Protect the service with timeouts on every outbound call, circuit breakers, bounded connection pools, and dead-letter queues for messages that keep failing.
4. 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.

Medium · Behavioral and Collaborative Alignment

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

1. 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.
2. 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.
3. 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.
4. 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.

Medium · Behavioral and Collaborative Alignment

Approach

1. 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.
2. 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.
3. Give the outcome: the decision your explanation made possible, and the written summary you sent afterwards.
4. 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?

Medium · Behavioral and Collaborative Alignment

Approach

1. 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.
2. 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.
3. 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.
4. 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.

Medium · Behavioral and Collaborative Alignment

Approach

1. 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.
2. 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.
3. 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.
4. 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?