1CloudHub Software Engineer Interview Guide

The 60-second brief

1CloudHub builds and maintains cloud-based solutions for client organisations. The role description candidates see mentions cloud migration, platform development and custom software projects. In this role you take business requirements through design, code and maintenance. The must-have skills candidates list are Python or C#, SQL, and data structures and algorithms. Familiarity with AWS, Azure or GCP, microservices and containerisation is listed as a plus. The role description lists work such as building features for cloud platforms, SQL for data-heavy applications, design reviews with senior engineers and architects, team problem-solving sessions and project documentation.

This guide is for Software Engineer candidates interviewing at 1CloudHub. It covers the five reported stages: Initial Screening, Online Tests, Group Interactions, Technical Evaluations and Final Evaluation. It also covers the thirteen questions candidates report, grouped into three sets: cloud and domain knowledge (service models, migration, SQL tuning, OOP, Python or C#), problem solving (debugging, data structure optimisation, unit testing, learning a stack quickly), and behavioral questions. The code topics candidates report for the role are coding, Python, DSA, SQL and OOP. Have your answers ready in Python or C#, the two languages listed for the role.

Candidates report five rounds over roughly 4-6 weeks. The loop goes from an initial screen and online tests, through a group round and in-depth technical rounds, to a final evaluation.

Focus areas

• Coding (Programming Algorithms)
• Python
• DSA (Data Structures and Algorithms)

Overview

Candidates describe the role as cloud engineering delivered for client organisations. You build and maintain cloud-based solutions, and the work includes cloud migration, platform development and custom software. As a result, the reported questions mix conceptual cloud topics (IaaS vs PaaS vs SaaS, what to plan when migrating an on-premises application) with day-to-day engineering topics: tuning a slow SQL query, applying OOP in your own code, writing unit tests and debugging a production incident. For each of these, a definition alone is not enough. Give the definition, then one example from your own work, then the trade-off you weighed.

Candidates report that the technical rounds cover practical experience, coding proficiency and cloud domain knowledge. They also report deep questions on the projects on the resume: how each project was built, what went wrong, and why each technology was chosen. Treat your resume as part of the question set. For every project, be ready to sketch the architecture, name the hardest problem and how you solved it, and say what you would change now. Remove any tool you cannot compare with an alternative.

The coding side is standard data structures and algorithms in Python or C#. Candidates say the technical rounds involve algorithmic problems or implementing specific features. Practise stating the brute force first, choosing the data structure from the access pattern, giving time and space complexity, and testing edge cases out loud. SQL appears both as a must-have skill and as a reported question. Read query plans, write sargable predicates, and design composite indexes until you can do each without notes.

Candidates report that the Group Interactions stage assesses collaborative style and teamwork, including how you get technical points across and respond to feedback in a group. No discussion topics are reported, so rehearse it like any other round. Run one mock group discussion on a cloud topic such as monolith vs microservices or rehost vs refactor, and one on a general or business topic, so framing and summarising are practised outside cloud trade-offs.

The 1CloudHub interview process

Candidates report these five stages, in this order, over roughly 4-6 weeks. Each entry below gives what is reported about the stage and how to prepare for it.

Initial Screening

Candidates describe the Initial Screening as a first check of technical skills and logical reasoning. What it contains is not reported: candidates do not describe a format, topics or questions for this stage. Prepare by being able to explain your resume and your main language clearly, and by practising logical-reasoning exercises, which the plan schedules on Day 2. Candidates also report deep project questions in the technical rounds, so keep your account of each project the same from your first conversation onward.

What to demonstrate

• Technical skills, as candidates describe the stage
• Logical reasoning

How to prepare

• Write a short spoken walkthrough of your resume: for each project, one line on the problem, your part, the stack (Python or C#, SQL, any cloud platform) and the result.
• Do timed aptitude-style sets on number series, ratios, time-and-work and puzzle logic, plus two short coding warm-ups, explaining each step aloud as you go.
• Have a short answer ready for why you want to join 1CloudHub, based on the cloud migration, platform and custom software work candidates describe.

Online Tests

Candidates say the Online Tests set a baseline of their skills. The test format and the topics tested are not described in reports, so this guide does not tie any topic to this stage. The topics candidates list for the role overall are coding, Python, data structures and algorithms, SQL and OOP, and the plan covers them across Days 2 to 4. Practise in a plain editor without autocomplete so syntax slips do not cost you time.

What to demonstrate

• A baseline of your skills, as candidates describe the stage
• Nothing further about what the tests score is reported

How to prepare

• General preparation for the reported role topics: solve timed array, string, hash map, stack/queue, two-pointer and sliding-window problems in your chosen language, and state the complexity of each solution.
• Write SQL from scratch as general preparation: joins (including LEFT JOIN with unmatched rows), GROUP BY with HAVING, subqueries, and window functions such as ROW_NUMBER and running totals.
• Review OOP fundamentals as general preparation: the four principles, abstract classes vs interfaces, overriding vs overloading. Write one small class hierarchy and the code that uses it.

Group Interactions

Candidates report that Group Interactions assess collaborative style and teamwork, including how clearly you convey technical information and how you handle feedback in a group discussion. No discussion topics are reported, so the group might get a technical, general or business topic. Be ready to take a clear position, build on other people's points, and help the group reach a conclusion, without dominating the discussion or staying silent.

What to demonstrate

• Collaborative style and teamwork
• Communicating technical points in a group and responding to feedback

How to prepare

• Run mock group discussions with two or three peers: one on a cloud topic, for example 'rehost or refactor a legacy application' or 'monolith vs microservices for a new client platform', and one on a general or business topic.
• Practise three moves: open by framing the decision and its criteria, build on a named peer's point before adding your own, and summarise where the group agrees when the discussion stalls.
• Prepare a few facts per cloud topic (cost, operations effort, lock-in, team skills) so your contributions are concrete.

Technical Evaluations

Candidates report that these rounds go into your hands-on experience and how well you code. They also report coding on algorithmic problems or feature implementation, cloud domain knowledge, and deep questions on resume projects: architecture, challenges and the reasoning behind technical choices. The coding and cloud question types in this guide are the ones to practise for this stage. When coding, say your approach before writing code. When discussing projects, explain why each technical choice was made.

What to demonstrate

• Coding proficiency on algorithmic problems or feature implementation
• Practical project experience: architecture, challenges and the reasons behind decisions
• Cloud domain knowledge

How to prepare

• For each resume project, write one page covering the architecture sketch, the hardest problem, the alternatives you rejected and why, and what you would change today.
• Practise the data-structure optimisation pattern out loud: brute force, find the repeated work, choose the better structure, state the complexity, test edge cases.
• Prepare the cloud material: a responsibility table for IaaS, PaaS and SaaS with named services, and a migration plan covering assessment, data move, what breaks, security and cutover for an application you know.
• Check that every technology on your resume has a stated pros, cons and alternative.

Final Evaluation

The Final Evaluation is reported only as a last assessment of alignment with quality and innovation standards. No format or question list is reported. Prepare by keeping your account of your projects consistent with what you said in earlier rounds. Behavioral stories are worth having ready for the late rounds, and so is a short list of your own questions about the team and its work.

What to demonstrate

• A final alignment check, as candidates describe the stage
• Alignment with quality and innovation standards, as reported

How to prepare

• Have STAR stories ready for the reported behavioral questions: technical disagreement, juggling deadlines, explaining a technical idea to a non-technical stakeholder, and learning a new stack quickly.
• Prepare a short account of the project you are proudest of, covering a quality decision you made (tests, reviews, monitoring) and its result.
• List three specific questions about client projects, cloud platforms in use and team practices.

Where candidates lose points

Listing a technology on the resume (a cloud service, Kubernetes, a framework) and then being unable to explain its pros, cons or an alternative when asked about it.

Candidates report deep questions on the projects and tools on the resume. Before the loop, go through each listed technology and write one line on why you used it, one weakness, and the alternative you considered. Remove anything you cannot defend at that level.

Answering the SQL tuning question with 'add an index' without measuring, reading the plan or checking whether the predicate can use an index at all.

Follow a fixed sequence: find the statement and its cost, read the plan (from a replica or a captured plan in production, since EXPLAIN ANALYZE runs the statement), fix non-sargable predicates and stale statistics, then design a composite index and weigh its write cost. Practise once on a real database so you can describe an actual plan, not a memorised list.

Treating the cloud migration question as 'move the VMs to EC2' and skipping data transfer, downtime, security, cost and rollback.

Learn a five-part checklist: assessment and strategy per component, the data move with validation and rollback, what breaks in the cloud (local disk, sessions, hard-coded hosts), security and network, and the cutover plan. Apply it to an application you know so the answer contains real dependencies.

In the Group Interactions round, either taking over the discussion or saying almost nothing, and never moving the group toward a conclusion.

Practise mock group discussions on a cloud trade-off and on a general topic. Open by framing the criteria, build on a peer's point by name before adding yours, concede when someone brings better evidence, and offer a summary when the discussion stalls.

Reciting the four OOP principles with textbook animal or shape examples, or jumping straight into code on a data-structure problem without a brute force or complexity.

For OOP, prepare one example from your own code that shows an interface, polymorphism and dependency injection. For coding, state the brute force and its complexity, then the improved structure and its trade-off, before you write code.

Questions & practice

Given a specific data structure problem, how would you optimize for time and space complexity?

Medium · Problem-Solving & Coding

Approach

1. Clarify input size and constraints, state the brute force and its complexity, then point to the repeated work it does. The better data structure exists to remove that repetition.
2. Match the structure to the access pattern. A hash map or set gives O(1) average lookups, which takes pair-sum from O(n^2) to O(n) time with O(n) space. A size-k heap handles top-k in O(n log k). Sliding windows handle contiguous ranges, prefix sums handle repeated range queries, and binary search handles sorted data.
3. Sorting plus two pointers can save memory: O(n log n) time, and O(1) extra space only with an in-place sort such as heapsort. Python's Timsort uses O(n) extra and introsort uses O(log n). Sorting also mutates the input and loses the original indices, so it does not fit if the question asks for indices.
4. State the trade-off explicitly. Most speed-ups spend memory to save time, so say which one you chose and why, given the limits.
5. Cover edge cases out loud: empty input, a single element, duplicates, negatives, very large values (integer overflow is a risk in C#, not in Python), and ties. Then write clean code in Python or C# and trace one small example by hand.

Follow-up

• Can you reduce the extra space to O(1)?
• What changes if the data arrives as a stream you cannot store?
• What if the input is already sorted?

How do you approach writing unit tests for your code?

Medium · Problem-Solving & Coding

Approach

1. Describe your structure: Arrange-Act-Assert, one behaviour per test, and test names that read as requirements (for example, returns_empty_list_when_no_orders).
2. Choose cases deliberately: the normal path, boundaries (empty, one item, the maximum), invalid input and expected exceptions, and every branch the code can take.
3. Isolate the unit. Inject dependencies so the database, network, clock and random numbers can be swapped for fakes or mocks: pytest fixtures and unittest.mock in Python, xUnit or NUnit with Moq in C#. Tests must be deterministic and fast.
4. Place unit tests in the test pyramid: many unit tests, fewer integration tests against a real database or container, and a few end-to-end tests, all running in CI on every change. Use coverage to find untested branches, not as a target.
5. Name the risk of over-mocking. Tests then pin the implementation and break on refactors, so assert on public behaviour.

Follow-up

• How do you test code that calls an external API or a database?
• A test passes locally but fails in CI only sometimes. What do you check?
• Do you write tests first? When does TDD help and when does it not?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

• The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
• Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

How do you optimize a SQL query that is performing poorly in a production environment?

Medium · Technical & Domain Proficiency

Approach

1. Measure before changing anything. Find the statement in the slow-query log, Query Store (SQL Server) or pg_stat_statements (PostgreSQL), and record how often it runs, its latency and the rows it reads.
2. Read the actual plan, with a caveat. EXPLAIN ANALYZE and SQL Server's actual plan execute the statement, so they add load, and for UPDATE or DELETE they change data unless you wrap them in a transaction you roll back. In production, prefer a replica, captured plans (Query Store, auto_explain) or plain EXPLAIN.
3. Find the expensive operator in the plan. Look for a full scan where few rows are needed, a nested loop over a large input, a sort or hash spilling to disk, or estimated rows far from actual rows, which points to stale statistics.
4. Fix in order of risk. Make predicates sargable: no function around an indexed column, no LIKE pattern that starts with a wildcard, no implicit type conversion. Select only the columns you need. Rewrite correlated subqueries as joins or EXISTS. Replace deep OFFSET paging with keyset paging. Refresh statistics. Then add a composite index with equality columns first and the range column last, made covering if that removes lookups.
5. Treat it as a production change. Every index slows writes and uses storage, so check the table's write rate first. Build the index online with CREATE INDEX CONCURRENTLY in PostgreSQL. In SQL Server, ONLINE = ON needs Enterprise edition (or Azure SQL); on Standard edition, schedule the build in a low-traffic window. Compare plan and latency on production-sized data before and after.

Follow-up

• The query is fast in staging and slow in production. What differs, and how do you check?
• If you are not allowed to add an index, what else can you do?
• How would you recognise parameter sniffing, and what are the fixes?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Can you explain the difference between various cloud service models (IaaS, PaaS, SaaS)?

Medium · Technical & Domain Proficiency

Approach

1. Frame it as a split of responsibility. On-premises, you run everything. IaaS gives you virtual machines, storage and networking, but you still patch the OS, runtime and application. PaaS also takes over the OS and runtime, so you ship code and configuration. SaaS is finished software, and you manage only users, data and settings.
2. Name one service per model on a platform you know. IaaS: EC2, Azure Virtual Machines or Compute Engine. PaaS: Elastic Beanstalk, Azure App Service or App Engine. SaaS: Microsoft 365 or Salesforce. Managed databases (RDS, Azure SQL Database) and serverless functions (Lambda, Azure Functions) sit on the PaaS side. Containers on Kubernetes sit between IaaS and PaaS.
3. State the trade-off. Moving up the stack gives up control (OS tuning, custom agents, exact versions) in exchange for less operations work and faster delivery. The costs are platform limits and more vendor lock-in. Billing varies too: many PaaS offerings, such as App Service plans and Elastic Beanstalk instances, still bill by instance hours, per-request billing applies to serverless, and per-seat billing to SaaS.
4. End with a decision example. A legacy app that depends on a specific OS library starts on IaaS. A stateless web API fits PaaS. Email or CRM is bought as SaaS.

Follow-up

• Under the shared responsibility model, who patches the database engine on a managed SQL service, and who patches SQL Server installed on a VM?
• Where do serverless functions fit, and when would you avoid them?
• Which model would you choose for a legacy .NET application with a tight deadline, and why?

Explain the principles of Object-Oriented Programming (OOP) and how you have applied them in recent projects.

Medium · Technical & Domain Proficiency

Approach

1. Define each principle in one line and tie it to a benefit. Encapsulation keeps state behind methods so invariants hold. Abstraction exposes what an object does, not how it does it. Inheritance reuses behaviour through an is-a relationship. Polymorphism lets callers use one interface for many implementations.
2. Spend most of the answer on one real example, such as: 'I defined a storage interface with upload and download methods, implemented it for local disk and for cloud blob storage, and injected it into the service, so tests used an in-memory fake.' That single example shows abstraction, polymorphism and encapsulation.
3. Show judgement. Prefer composition over deep inheritance. Name one SOLID principle you actually applied, such as single responsibility or dependency inversion. Describe a case where inheritance hurt: a fragile base class, or a subclass that broke Liskov substitution.
4. Give language specifics for your stack. C# has interfaces, abstract classes, access modifiers and sealed classes. Python relies on duck typing, abc.ABC for abstract base classes, and the single-underscore naming convention instead of enforced private members.

Follow-up

• When do you choose an abstract class and when an interface?
• Show a case in your own code where inheritance should have been composition.
• How does polymorphism work in Python without declared interfaces?

What are the key considerations when migrating an on-premise application to the cloud?

Medium · Technical & Domain Proficiency

Approach

1. Start with assessment. Inventory the application, its dependencies (databases, file shares, batch jobs, systems it calls), data volume, traffic pattern and compliance needs. Then choose a strategy per component: rehost (lift and shift), replatform (for example, move the database to a managed service), refactor, repurchase as SaaS, retain or retire.
2. Plan the data move separately. Data size and acceptable downtime decide between an offline backup and restore, or continuous replication / change data capture with a short cutover. Always plan validation (row counts, checksums) and a rollback path.
3. List what breaks in the cloud: writes to local disk, in-memory sessions behind a load balancer, hard-coded IPs and hostnames, Windows authentication or LDAP dependencies, licences tied to hardware, and latency to systems that stay on-premises.
4. Cover security and operations: least-privilege IAM roles, network design (VPC/VNet, private subnets, VPN or a dedicated link to the data centre), encryption at rest and in transit, logging and monitoring, backups, and cost controls (right-sizing, reserved capacity, egress charges).
5. End with the cutover: migrate a low-risk component first, run old and new in parallel, lower DNS TTL before switching, and define the metrics that confirm success.

Follow-up

• How would you move a multi-terabyte database with minimal downtime?
• The application stores uploaded files on local disk. What has to change?
• After migration the monthly bill is higher than on-premises. Where do you look first?

Walk me through your approach to debugging a complex production issue.

Medium · Problem-Solving & Coding

Approach

1. Start with impact and containment: who is affected, and since when? Can I mitigate now by rolling back the last deploy, turning off a feature flag, scaling out or failing over? Do that before hunting for the root cause.
2. Gather evidence in a fixed order: error-rate and latency dashboards, then recent changes (deploys, config, infrastructure, data), then logs filtered by a correlation or request ID, then traces to find the failing hop.
3. Narrow down by splitting the affected population: one host, region, tenant, version or input shape? Each split rules out a set of hypotheses. Reproduce with production-like data in a lower environment before changing code.
4. Fix, then verify with the same metric that showed the problem. Add a regression test and an alert, and write a blameless incident note covering the cause and how to prevent it.
5. Tell it through one real incident: the symptom, the false lead you dropped, and the evidence that confirmed the cause.

Follow-up

• The issue is intermittent and you cannot reproduce it. What next?
• The logs show nothing useful. How do you add visibility safely in production?
• How do you decide between rolling back and fixing forward?

Suggested practice checklist

Day 1 covers projects and your stack, Day 2 adds reasoning warm-ups and data structures, and Days 3 to 6 cover SQL and schema design, OOP, testing and containers, cloud, debugging and the group round. Day 7 is behavioral stories. Every task ends in something you can rehearse from.

Day 1 — Resume projects and your Python or C# story

• For each project on your resume, write one page covering the architecture sketch, your part, the hardest problem, the alternatives you rejected, and what you would change now.
• Go through every technology listed on the resume and write why you used it, one weakness and one alternative. Remove anything you cannot defend.
• Write and say aloud your answer to the Python or C# scalability question, with the scale numbers, the bottleneck and the measured result.

Deliverable: A one-page brief per project, a technology defence list, and a rehearsed scalability answer with numbers.

Day 2 — Reasoning warm-ups and data structures

• Do two timed aptitude-style sets on number series, ratios, time-and-work and puzzle logic, plus two short coding warm-ups, explaining each step aloud. This prepares the reported logical-reasoning check in the Initial Screening.
• Solve six problems in your chosen language, one each for hash map, two pointers, sliding window, heap (top-k), prefix sums and binary search. State brute force and optimised complexity for each.
• Work the heaviest-tenants practice problem, where memory is tight. With m distinct tenants, compare an exact hash map plus size-k heap (O(m log k) to pick the top k versus O(m log m) to sort everything, O(m) memory either way) with bounded-memory options such as Space-Saving or a count-min sketch, and say when each is acceptable.
• Rehearse the data-structure optimisation answer out loud: brute force, the repeated work, the better structure, the trade-off, the edge cases.

Deliverable: Two scored reasoning sets, six solved problems with complexity notes, a written exact-versus-bounded-memory comparison for heaviest tenants, and a spoken optimisation walkthrough.

Day 3 — SQL writing, tuning and schema design

• Load a sample database with a large table. Run EXPLAIN ANALYZE (or SQL Server's actual execution plan) on a slow query there, fix one non-sargable predicate, add a composite index, and record the before and after numbers.
• Write queries from scratch: LEFT JOIN with unmatched rows, GROUP BY with HAVING, ROW_NUMBER for top-n per group, and a running total.
• Work the per-tenant active cap problem. Lock the tenant's parent row (SELECT ... FROM tenants WHERE id = ? FOR UPDATE), then count, insert; child-row locks miss phantom inserts under READ COMMITTED. Or use UPDATE counters SET n = n + 1 WHERE tenant_id = ? AND n < cap and check the row count; decrement it in the same transaction that deactivates or deletes a row, or it drifts.
• Normalise a small schema (orders, customers, products) to 3NF, then write the DDL with primary keys, foreign keys and the indexes your queries need.

Deliverable: A before-and-after plan comparison, four from-scratch queries, a concurrency-safe cap transaction, and a 3NF schema with keys and indexes.

Day 4 — OOP design, unit tests and containers

• Write a small module with an interface and two implementations (for example, local and cloud file storage), injected into a service class.
• Write unit tests for that service with a fake or mock (pytest with unittest.mock, or xUnit/NUnit with Moq), covering the normal path, a boundary and an error path.
• Containerise the module with a Dockerfile and add a CI step that runs its tests, since containerisation and CI/CD appear among the role's topics.
• Rehearse the OOP principles answer and the unit testing answer out loud, using the code you just wrote as the example.

Deliverable: A small OOP module with a passing test suite, a Dockerfile and CI test step, and two spoken answers built on the module.

Day 5 — Cloud service models and migration

• Write a responsibility table for on-premises, IaaS, PaaS and SaaS, with one named service per model on the cloud platform you know best.
• Write a migration plan for an application you know: components and strategy per component, data move and rollback, what breaks in the cloud, security and network, and the cutover.
• Answer both cloud questions aloud, then answer their follow-ups (multi-terabyte database, files on local disk, a higher cloud bill).

Deliverable: A service-model table, a one-page migration plan for a real application, and rehearsed answers to both cloud questions.

Day 6 — Production debugging and the group round

• Write up one real production incident as a timeline: symptom, containment, evidence gathered, false lead, root cause, fix, prevention.
• Rehearse the debugging answer aloud, including the intermittent-issue and rollback-vs-fix-forward follow-ups.
• Run mock group discussions with peers: one on 'rehost or refactor a legacy application' and one on a general or business topic. Practise framing the criteria, building on others' points and summarising.

Deliverable: An incident timeline, a rehearsed debugging answer, and notes from two mock group discussions on what you would change.

Day 7 — Behavioral stories and the final stage

• Write STAR stories for the technical disagreement, juggling deadlines, explaining to a non-technical stakeholder, and learning a new stack quickly. Each needs a concrete result.
• Write your answer to why you want a career at 1CloudHub, tied to the cloud migration and platform work candidates describe and to your own projects.
• Prepare three specific questions about client projects and team practices, then run a full mock covering one coding problem, one project deep dive and two behavioral answers.

Deliverable: Four STAR stories, a motivation answer, three questions of your own, and notes from one full mock.

Behavioural preparation

The behavioral questions candidates report for this role cover technical disagreement, juggling deadlines, motivation for joining 1CloudHub, explaining technical ideas to non-technical stakeholders and learning a new stack quickly. Candidates also report detailed questions about resume projects. Each story should show a decision you made, how you made it, and a result you can describe concretely.

Describe your experience with Python or C# in the context of building scalable applications.

Medium · Technical & Domain Proficiency

Approach

1. Pick one application you built or changed. Give its scale in numbers (requests per second, rows, users, job runtime) and name the bottleneck you hit. Without numbers, 'scalable' carries no information.
2. Show language-level decisions. In Python: asyncio or threads for I/O-bound work, multiprocessing or a task queue for CPU-bound work because of the GIL, and profiling with cProfile before optimising. In C#: async/await all the way down without blocking on .Result, reusing HttpClient through IHttpClientFactory, and avoiding N+1 queries in Entity Framework.
3. Show system-level decisions: stateless services so instances scale horizontally, connection pooling, caching with an explicit invalidation rule, and moving slow work to background jobs.
4. Close with the measured result and what you would change. Be ready to explain the pros, cons and alternatives of any tool you list, including your framework.

Follow-up

• What is the GIL, and how did it affect your design?
• How did you find the bottleneck, and how did you confirm the fix worked?
• What would break first at ten times the load?

Describe a time you had to learn a new technology stack quickly to solve a problem.

Medium · Problem-Solving & Coding

Approach

1. Choose a story with a real deadline set by client delivery, which matches the client-facing cloud work candidates describe. For example, a client migration that needed an unfamiliar cloud service such as Azure App Service or AWS DMS, learned in days and delivered against a client date. Say what you knew at the start.
2. Make your learning method the core of the answer. Cover what you read first (official docs, a quick-start guide), the smallest working spike you built, how you used existing code or an experienced colleague, and how you checked you were using the stack correctly (tests, code review).
3. Give the result in concrete terms: delivered by the date, what it fixed, and what you would learn differently next time.
4. Avoid a story that is only about finishing a course. It has to end with something you shipped.

Follow-up

• What did you get wrong at first with the new stack, and how did you find out?
• How did you decide what to learn in depth and what to skip?
• How did you make sure your code met the team's standards?

Tell me about a time you had a technical disagreement with a teammate; how did you resolve it?

Medium · Behavioral & Communication

Approach

1. Pick a disagreement with real technical substance. A cloud or migration example fits this role: rehost vs refactor for a client application, or a managed database vs one self-hosted on a VM. Other options are a schema design or sync vs async processing. Present both positions fairly, including your teammate's strongest argument.
2. Show how you resolved it with evidence. First agree on criteria (for a migration: cost, downtime, lock-in; otherwise latency, maintenance effort), then use a benchmark, prototype or data. Say which criterion settled it. Escalate to a lead only if that fails.
3. Give the outcome and the state of the working relationship afterwards. Losing the argument is fine if you show you committed to the decision.
4. The answer fails if your teammate is the villain, if the story never resolves, or if it is a personality clash with no technical content.

Follow-up

• What would you have done if the data had not settled it?
• Looking back, was the chosen option the right one?
• How do you disagree in a code review without slowing the team down?

How do you manage your time when balancing multiple project deadlines?

Medium · Behavioral & Communication

Approach

1. Use one real period with competing deadlines and explain your method: list the work, rank it by impact and fixed dates, break each item into milestones, and timebox.
2. Show communication. For example: 'I told stakeholders early what would slip, offered options (cut scope, move the date, add help) and got a decision instead of silently missing a deadline.'
3. Mention your tools briefly (a task board, calendar blocks for focused work) and how you protect focus from interruptions.
4. Avoid 'I just worked longer hours'. That is not a system, and it does not hold up across several client projects.

Follow-up

• Tell me about a deadline you missed. What happened?
• Two managers each say their task is the top priority. What do you do?
• How do you estimate work you have never done before?

Why are you interested in a career at 1CloudHub?

Medium · Behavioral & Communication

Approach

1. Tie the answer to the work candidates describe: building and maintaining cloud-based solutions for client organisations, including cloud migration, platform development and custom software.
2. Connect it to your own evidence: a project where you used Python or C#, SQL and a cloud platform. Add what you want to learn next, such as a second cloud provider, microservices or containers, which appear among the role's nice-to-have skills.
3. Show research you actually did into 1CloudHub's work and say what drew you to it. Do not invent facts, and do not open with pay or a generic 'I like cloud'.
4. Finish with what you would contribute early on, tied to your strongest skill.

Follow-up

• Which cloud platform do you know best, and how deeply?
• Requirements change mid-project. How do you handle that?
• Where do you want to be technically in a few years?

Describe a situation where you had to explain a technical concept to a non-technical stakeholder.

Medium · Behavioral & Communication

Approach

1. Pick a case where a non-technical person had to make a decision, such as approving downtime for a migration, choosing between cost options or accepting a delay.
2. Show how you translated. Start from their goal, use an analogy or a simple diagram, drop jargon, present options with cost, risk and time, and check understanding by asking them to restate the decision.
3. Give the outcome: what they decided and what happened next.
4. Avoid condescension, and avoid a story where you 'simplified' something but no decision followed. To practise, explain IaaS vs PaaS, or why a slow query needed an index, to a friend outside engineering.

Follow-up

• How did you know they understood?
• What did you leave out, and why?
• What would you do if they still rejected your technical recommendation?