Interview guides · Cendyn

Cendyn Software Engineer Interview Guide

Cendyn Software Engineer interview guide: the three reported rounds, C#, SQL and HTML prep, reported questions with answer approaches, and a 7-day plan.

The 60-second brief

Candidates describe Cendyn as a company that builds a customer relationship management (CRM) platform, plus other products, for hospitality businesses, with the goal of improving the guest experience. Reports say an engineer's projects range from back-end system integration to front-end interface changes, so the day-to-day work spans data, services and screens rather than one layer.

This guide is for engineers with a few years of professional experience (candidates describe 2-5 years as typical) interviewing for a Software Engineer role at Cendyn. It covers the three reported rounds, answer approaches for every reported technical, problem-solving and behavioral question, and a plan that pairs those questions with the C#, SQL and HTML skills the role lists. Details differ by team, so treat it as a map of what candidates report, not a fixed script.

Candidates report three stages over roughly three to five weeks: a phone screen, one or more technical interviews, and in-person interviews with team members and lead engineers.

Focus areas

Software Engineering (Role Core)
SQL
C#

Overview

Candidates describe the job as building and maintaining software for a hospitality CRM platform and related products. The listed responsibilities are designing and developing solutions, turning requirements from product managers and designers into technical specifications, taking part in code reviews, troubleshooting and debugging, and improving development processes. The requirements candidates describe are C#, SQL and HTML, familiarity with Agile and Scrum, and Git. Cloud platforms such as AWS or Azure, front-end frameworks such as React or Angular, and data structures and algorithms are listed as nice to have.

Fifteen questions are reported for this loop, five each in three groups: technical and domain questions (SQL versus NoSQL, code quality and testing, object-oriented programming, a project walk-through, and a performance story), problem-solving questions (production debugging, a hard technical problem, estimating a feature, prioritizing across projects, balancing performance and scalability), and behavioral questions (conflict, persuasion, feedback, motivation in a team, tight deadlines). Almost all of them are conversational and experience-based rather than algorithm puzzles, which means vague answers are the main risk.

The reports also say the technical stage may include coding assessments, and written testing and programming language proficiency appear among the reported topics. Since data structures and algorithms are a listed nice-to-have, keep a few coding drills warm even though no algorithm question is reported by title.

The practical consequence is to build a small set of real stories and reuse them. One performance story, one production incident, one disagreement, one tight deadline and one project you can narrate decision by decision will cover most of the fifteen questions from different angles. Back the technical half with C# and SQL you can write from memory, because that is the stack the role lists.

The Cendyn interview process

Candidates report three stages over roughly three to five weeks: a phone screen, one or more technical interviews, and in-person interviews. They add that the exact process varies by team and by role.

Phone Screen

Candidates describe this as an initial call about your background and your fit for the role. Treat it as the first test of whether your experience lines up with the stack the role lists (C#, SQL, HTML, Git, Agile and Scrum). Go in with a short, structured account of your career and one or two projects you can describe precisely, and use the call to learn what the later stages contain, since reports say the format varies by team.

What to demonstrate

How your background and recent experience map onto the role
Your fit for the role as you describe it
Whether you can summarize your work clearly and concisely

How to prepare

Write a spoken career summary that ends on why a hospitality CRM engineering role suits you, and rehearse it aloud until it holds together without notes.
List your hands-on experience with C#, SQL, HTML, Git and Agile or Scrum, each with one concrete example you can give in a sentence or two.
Choose the project you would describe if asked for a recent one, and outline its purpose, your part, the main design decision and the result.
Prepare questions for the recruiter about what the technical interviews include (coding assessment, written test, situational questions) and who the in-person interviews involve.

Technical Interviews

Candidates report one or more technical interviews that may include coding assessments and situational questions. Reported topics include SQL, C#, written testing and programming language proficiency. This is where the conceptual questions fit: SQL versus NoSQL, testing strategy, object-oriented principles, estimation and production debugging. Prepare to write real C# and SQL by hand, and to explain choices aloud while you write.

What to demonstrate

Working knowledge of C# and SQL, shown through code or written answers
Understanding of object-oriented design and testing practice
Structured reasoning on situational questions such as debugging or estimating

How to prepare

Write C# without autocomplete: classes with interfaces, an abstract base class with a virtual method, a LINQ query, and an async method, then explain each design choice.
Rehearse the SQL-versus-NoSQL answer with a concrete scenario each side wins, and write joins, GROUP BY with HAVING, a window function and an indexed lookup from memory.
Outline your testing answer in layers (unit, integration, end-to-end, review, continuous integration) and attach one real example of a bug a test caught.

In-Person Interviews

Candidates report in-person interviews with team members and lead engineers, with deeper discussion of your experience and fit. Expect to go further into past work than in the earlier stages, so your project stories must hold up to detailed discussion of what you built, what you rejected and what you would change. Prepare for conversations with both engineers and people you would work beside.

What to demonstrate

Depth of experience in the projects you describe
Fit with the team you would join
Ability to work with other engineers, product managers and designers

How to prepare

Take your best project and write its decision log: requirements, options you considered, what you chose, what went wrong, what you would change now.
Prepare one story each for a disagreement, persuading others, receiving critical feedback and a tight deadline, and make sure each names your own actions rather than the team's.
Be ready to explain a technical idea to a non-technical colleague, since reports mention cross-functional work with product managers and designers.
Write questions for the team about code review practice, how work is estimated, how production issues are handled and what the first projects would be.

Where candidates lose points

Answering SQL versus NoSQL with 'NoSQL scales better' and stopping

Compare on schema flexibility, transactions, joins, query patterns and consistency, and give one scenario each side suits. Pair it with real SQL you have written: joins, aggregates, indexes and a query you tuned.

Reciting the four object-oriented principles as definitions with no C# behind them

For each principle, show a small C# example: private state behind properties, an interface with two implementations, an abstract base with an overridden method, and a case where composition beats inheritance.

Narrating a project as a list of technologies with no decisions in it

Prepare a decision log for one project: the requirement, two options you weighed, why you chose one, what failed, and what you would change now. Be ready to defend each decision.

Answering the production-debugging question with a fix before any diagnosis, or with a single estimate for a new feature

Give the sequence: assess impact, mitigate (rollback or flag), check what changed, use logs and metrics, find the cause, write a regression test, review afterward. For estimates, break the work down, name unknowns and give a range.

Telling behavioral stories in 'we' with no personal action, or a conflict story where the other person is the villain

Use first person singular for decisions you made. Choose conflict and feedback stories where you changed your mind or your habits, and say what you would do differently.

Questions & practice

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

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

Approach

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

Follow-up

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

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

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

Approach

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

Follow-up

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

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

What is your experience with SQL databases, and can you explain the differences between SQL and NoSQL?

Medium · Technical / Domain Questions

Approach

Start with a concrete account of your own SQL work: which engine (SQL Server, PostgreSQL, MySQL), roughly how large the schema was, and what you did in it (designed tables, wrote joins and stored procedures, added indexes after reading an execution plan). One specific example is worth more than a list of engines.
Contrast the data models: relational tables with a fixed schema, foreign keys and joins, against NoSQL families (document, key-value, wide-column, graph) that are usually schema-on-read and modelled around access patterns, often by denormalising data that a relational design would normalise.
Contrast the guarantees accurately: relational engines give multi-row ACID transactions; many NoSQL stores scope atomicity to one document or partition by default and offer tunable or eventual consistency. Avoid saying NoSQL has no transactions: MongoDB, for one, has supported multi-document transactions since version 4.0.
Contrast scaling: relational databases usually scale up and add read replicas, and sharding them is manual work; many NoSQL stores partition horizontally by key out of the box, at the cost of expensive cross-partition queries and no general joins.
Finish with a decision rule and an example: data with relationships, reporting and integrity constraints (customer profiles, bookings, invoices) stays relational; high-volume, key-addressed data with a simple access path (session state, event logs, cached lookups) suits a key-value or document store.

Follow-up

When would you denormalise inside a relational database instead of moving that data to a NoSQL store?
A query that used to take 50 ms now takes 5 seconds. How do you use the execution plan to find out why?
With an eventually consistent store, what does a user see if they save a change and reload immediately, and how would you guarantee read-your-writes?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

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

Approach

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

Follow-up

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

How do you ensure the quality of your code? What testing methodologies do you use?

Medium · Technical / Domain Questions

Approach

Describe the layers you actually use: many fast unit tests on business logic, fewer integration tests across real boundaries (database, HTTP), and a small number of end-to-end tests on the paths that matter most. In C#, name the tools you know: xUnit, NUnit or MSTest, with Moq or NSubstitute for faking interfaces.
Say what a good unit test covers: behaviour rather than implementation, with the edge cases named (null and empty input, boundary values, duplicate records, time zones). Add the rule that every fixed bug gets a regression test that fails before the fix and passes after it.
Explain why data-access code needs integration tests against a real database instance (for example, one started in a container in CI): a mocked repository cannot catch a wrong join, a missing index or a constraint violation.
Cover the gates around the tests: code review on every pull request, static analysis (Roslyn analyzers, nullable reference types turned on), and a CI pipeline that blocks merges on failing tests. Treat coverage as a signal for untested areas, not a number to hit.
Be honest about test-driven development: say where writing the test first helped you (well-specified logic, bug fixes) and where you test after (exploratory UI work), rather than claiming you always use it.

Follow-up

How do you unit test code that depends on the current time or on a third-party API?
What is the difference between a mock, a stub and a fake, and when would you use each?
One test fails about one run in twenty in CI. What do you do about it?

Explain the concept of object-oriented programming and its principles.

Medium · Technical / Domain Questions

Approach

Define it in one line: OOP organises code as objects that combine state with the behaviour that operates on it. Then cover the four principles, each with a short C# example rather than a textbook definition.
Encapsulation: private fields behind methods or properties that enforce invariants (a booking whose end date cannot precede its start date). Abstraction: an interface such as INotificationSender exposes what a component does and hides how.
Inheritance and polymorphism: C# allows single class inheritance and multiple interface implementation. Separate runtime polymorphism (virtual/override, interface dispatch) from compile-time overloading, and show one call site that works on EmailSender and SmsSender through the shared interface.
Add the judgement: prefer composition over deep inheritance, because a base-class change ripples into every subclass (the fragile base class problem). Connect this to SOLID, and to patterns you have used, such as Strategy, Factory and constructor dependency injection.
Avoid reciting the four words without examples, and do not call overloading and overriding the same thing.

Follow-up

In C#, when would you choose an abstract class over an interface, and what changed when interfaces gained default implementations in C# 8?
Give an example that violates the Liskov substitution principle and explain how you would fix it.
When has inheritance made a codebase harder to change for you?

Can you walk us through a recent project you worked on, detailing your coding and design decisions?

Medium · Technical / Domain Questions

Approach

Use a fixed structure: the problem and who used the result, your exact role, a short architecture sketch (components, data flow, storage), two or three decisions, the measured outcome, and what you would change. Keep the overview short and leave room for questions.
For each decision, name the alternatives you rejected and why: for example a relational schema against a document store, a synchronous API call against a queue, or building a component against adopting a library. Trade-offs carry the answer, not the feature list.
Keep "I" and the team separate: say which parts you designed or wrote and which you reviewed or inherited.
Give numbers wherever you can (latency before and after, error rate, data volume, delivery time) and say how you measured them.
Expect to go deeper on anything you mention: be ready to write the key query or class, explain how it was tested, and describe how it was deployed and rolled back.

Follow-up

What would break first if usage grew tenfold?
Which decision would you reverse now, and what would it cost to change?
How was it tested and released, and what went wrong after launch?

Describe a challenging technical problem you encountered and how you resolved it.

Medium · Problem-Solving / Case Studies

Approach

Pick a problem that was hard for technical reasons (a race condition, a performance cliff, data corruption, an unreliable third-party integration), not a scheduling or people problem, and one where you did the diagnosis yourself.
Tell it as an investigation: the symptom and why it mattered, the hypotheses you formed, how you tested each one and what it ruled out, then the root cause stated precisely (for example, two writers updating the same row without a concurrency check).
Explain the fix and why you chose it over alternatives: optimistic concurrency against locking, a retry with idempotency keys against a distributed transaction, an index against a cache.
Show verification with evidence: the failing test that now passes, the metric that returned to normal, how long you monitored it.
End with what changed permanently (a test, an alert, a coding guideline). Answers that fail say "it was fixed" without ever naming the root cause.

Follow-up

How did you confirm that was the root cause and not a coincidence?
What would you have done if the cleanest fix had not been feasible in time?
What did you change so the same class of problem does not happen again?

If given a new feature requirement, how would you go about estimating its implementation time?

Medium · Problem-Solving / Case Studies

Approach

Pin down scope first: acceptance criteria, edge cases, which systems it touches, and what is explicitly out of scope. List the unknowns separately from the known work.
Break it into tasks small enough to estimate with confidence (about a day or two each): schema migration, API, UI, tests, code review, deployment, documentation. Non-coding work is where estimates usually slip.
Estimate from evidence: compare with similar past work, and use three-point estimates (optimistic O, most likely M, pessimistic P; the PERT mean is (O + 4M + P) / 6). For a large unknown, propose a timeboxed spike before committing.
Give a range with its assumptions rather than one number, and in a Scrum team express it in story points measured against the team's velocity.
Re-estimate as you learn: flag slippage as soon as it appears and offer options (cut scope, change the date, add help) instead of quietly absorbing it.

Follow-up

The product manager needs one date and your range is wide. What do you tell them?
Halfway through you find the work is twice as large as estimated. What do you do?
What is the difference between story points and hours, and when would you use each?

How do you prioritize tasks when working on multiple projects simultaneously?

Medium · Problem-Solving / Case Studies

Approach

Make every commitment visible in one list, then rank by impact and urgency (cost of delay), with dependencies first: work that unblocks other people jumps the queue.
Where projects conflict, settle the order explicitly with your manager or the stakeholders rather than choosing silently, and state the trade-off in plain terms ("if I take this, that slips to Thursday").
Protect focus: limit work in progress, finish before starting, and batch interruptions into set slots. Production incidents are the stated exception that pre-empts everything.
Ground it in a real example with an outcome: what you shipped, what you deliberately deferred, and how you told the people affected.
Avoid an answer about tools alone ("I use Jira"); the content is how you decide and how you communicate.

Follow-up

Two stakeholders each insist their work comes first. What do you do?
Tell me about something you deprioritised. How did you communicate it, and what happened?
How do you handle urgent requests that arrive in the middle of a sprint?

Present a case study where you had to balance performance and scalability in your design choices.

Medium · Problem-Solving / Case Studies

Approach

Separate the terms first: performance is how fast one request or job runs at the current load (latency, throughput); scalability is whether the system keeps meeting its targets as load or data grows when you add resources. One can improve while the other gets worse.
Choose a case with numbers: the load, the bottleneck you found by profiling or load testing (p95/p99 latency, database CPU, lock waits), and the change you made.
Name the trade-off and what it cost: a cache-aside layer with a TTL buys read latency at the price of staleness and invalidation work; an index speeds up reads and slows down writes; moving work onto a queue raises throughput but makes results eventually consistent; keyset pagination stays fast at deep pages where OFFSET has to scan and discard every skipped row.
Explain why you stopped where you did: what the next bottleneck would be, and why solving it early was not yet worth the complexity or cost.
Close with verification: before and after measurements under realistic load, and the monitoring you left behind.

Follow-up

What breaks first at ten times the load?
How do you keep the cache consistent when the underlying data changes?
Why not design for horizontal scaling from the start?

How would you approach debugging a critical issue in a production environment?

Medium · Problem-Solving / Case Studies

Approach

Triage before root cause: establish severity, who is affected and how widely, then mitigate. Roll back the latest deploy, switch off the feature flag or fail over, and post status updates while the problem is still unexplained.
Gather evidence on what changed: deploys, configuration, schema migrations, data volume, traffic and upstream dependencies. Build a timeline from logs, metrics and traces, and split error rates by endpoint, version and host to narrow the scope.
Narrow the cause systematically: reproduce with production-like data in a lower environment, or bisect between a known-good and a known-bad commit (git bisect is a binary search, so it needs about log2(n) builds for n commits). Add targeted logging when the existing signal is not enough.
Know the usual suspects for a C# and SQL service: unhandled exceptions traced by correlation ID, slow queries or blocking and deadlocks in the database, connection pool exhaustion, and thread pool starvation caused by blocking on async code (.Result or .Wait()).
Close the loop: fix the root cause rather than only the trigger, add a regression test and an alert on the signal that would have caught it sooner, and write a blameless postmortem with owned action items.

Follow-up

You cannot reproduce it outside production and the logs lack detail. What do you do next?
A rollback is not safe because a schema migration has already run. How do you mitigate?
How do you tell the actual cause from something that only coincided with the incident?

Suggested practice checklist

The plan follows the three reported rounds: orient on the stack, then C# and SQL fundamentals, testing and estimation, production and performance, project and coding practice, and a final behavioral run-through.

Day 1 — Map the loop and your stories

Write the three reported rounds (phone screen, technical interviews, in-person interviews) on one page, with the topics reported for each and the one you are weakest on.
Make a table of the listed requirements (C#, SQL, HTML, Git, Agile and Scrum) with a real example of your own experience for each, and mark gaps.
List five stories: performance, production incident, disagreement, tight deadline and a project walk-through, with one line on what each shows.

Deliverable: A one-page loop map, a requirements-versus-experience table and a list of five story candidates.

Day 2 — C# and object-oriented design

Write a small C# program that uses an interface with two implementations, an abstract base class with a virtual method, and composition in place of one inheritance case, then explain each choice aloud.
Review C# language points you may be asked about (LINQ, async and await, generics, IDisposable, collections) and write one short example for each.
Rebuild a simple HTML form page with semantic elements and labels from memory, to refresh the HTML requirement.

Deliverable: A working C# example covering the object-oriented principles, one-page C# examples for each language point, and one HTML form page.

Day 3 — SQL and data modelling

Write a spoken answer to the SQL-versus-NoSQL question that includes one scenario where each choice is right and your own SQL experience.
Write queries from memory: a join with an aggregate, a GROUP BY with HAVING, a window function and a lookup that depends on an index, then explain the plan you expect.
Do the practice question on replacing offset paging with keyset paging, and write down why keyset paging stays fast on a deep page.

Deliverable: A rehearsed SQL-versus-NoSQL answer, four SQL queries with notes on the indexes they use, and a solved keyset paging exercise.

Day 4 — Testing, estimation and prioritizing

Outline your answer on code quality and testing: unit, integration and end-to-end layers, code review, and continuous integration, with one real bug a test caught.
Break one real feature into tasks, mark the unknowns, and produce a range estimate with the assumptions you would confirm with product first.
Write how you rank work across several projects at once, with the criteria and one example where you renegotiated scope.

Deliverable: A layered testing answer with an example, a task-level estimate with assumptions, and a written prioritization method.

Day 5 — Production debugging and performance

Write your debugging sequence for a critical production issue: impact, mitigation, what changed, logs and metrics, cause, regression test and review afterward. Rehearse it aloud.
Prepare the case study that balances performance and scalability: the bottleneck, the options, the trade-off and what you measured.
Write your performance optimization story with the baseline, how you found the cause, the fix and the result.

Deliverable: A spoken debugging sequence, one performance-versus-scalability case study, and a performance story with before-and-after numbers.

Day 6 — Project walk-through and coding practice

Turn your best project into a decision log: requirements, options, choice, failures and what you would change, then walk it through aloud.
Write up your hardest technical problem with the symptom, the dead ends, the cause and the resolution.
Work the practice problems on overlapping intervals and on a rolling failure rate, writing code without autocomplete, as a warm-up for a coding assessment.

Deliverable: A project decision log, a written account of one hard problem, and two solved coding exercises.

Day 7 — Behavioral run-through

Write each behavioral story in situation, action, result form using 'I', then cut it to a version you can say aloud.
Answer the conflict, persuasion, feedback, motivation and deadline questions aloud and record yourself, then check that each answer names your own actions.
Finish the performance story, then write three questions to ask the team about review, estimation and production issues.

Deliverable: Five written and recorded behavioral answers, one finished performance story, and three questions for the team.

Behavioral stories to prepare for Cendyn

The reported behavioral prompts cover conflict with a teammate, persuading others, handling criticism, motivation in a team and meeting tight deadlines, and one performance story sits among the technical questions. Reports also describe example questions about aligning with product managers and about explaining technical ideas to non-technical colleagues. Build each story around what you decided and did, and keep a spare one for cross-functional work.

Describe a time when you optimized a piece of code for performance.

Medium · Technical / Domain Questions

Approach

Choose a case where you found the problem and drove the fix. Open with the symptom and a number: an endpoint's response time, a nightly job's run time, or a query's cost. Without a baseline the story is an anecdote.
Show how you found the cause instead of guessing: a profiler, timing around suspected sections, or a SQL execution plan. Typical C# and SQL causes are repeated queries in a loop, a missing index, loading too many rows into memory, or a quadratic loop over two lists.
Describe the change and why it fits the cause, such as batching the queries, adding an index, switching to a dictionary lookup, caching with an invalidation rule, or streaming rather than loading everything.
Close with the measured result, the guard against regression (a test or a benchmark), and the cost you accepted, for example extra memory, more complex code, or staleness from caching.

Follow-up

How did you know the bottleneck was there rather than somewhere else?
What did the optimization cost in readability or memory, and was it worth it?
How would you stop it from regressing later?

Describe a situation where you had a conflict with a team member. How did you handle it?

Medium · Behavioral / Leadership

Approach

Pick a real disagreement about a technical or process matter, such as an approach in a pull request, ownership of a module, or how to handle scope. A personality clash with no substance is hard to turn into a story about your judgment.
Use a clear structure. State the situation briefly, then spend most of the answer on what you did: you asked to understand their reasoning first, spoke with them directly and privately, and agreed on what evidence or criteria would settle it.
Give the resolution honestly. It may be that they were right, that you met in the middle, or that you ran a small experiment. A story where you simply won shows less than one where you changed your own position.
End with the working relationship afterward and one habit you kept, for example writing decisions into the ticket or asking for a short call before long review threads.

Follow-up

What if they had still disagreed after you showed the evidence?
Did you involve your manager, and when is that the right step?
What would you do differently if it happened again?

Tell us about a time when you had to persuade others to adopt your viewpoint in a project.

Medium · Behavioral / Leadership

Approach

Choose a situation where you held a view that others did not initially share: a library choice, a refactor, a testing approach, or a change to a requirement. Make it a decision that changed a project's direction.
Show that you tailored the case to each audience. Engineers respond to a prototype, a benchmark or a cost estimate, while a product manager responds to delivery risk, customer impact and what would be dropped.
Show that you listened and adjusted. Name the objection that most changed your proposal and how you modified the plan to address it.
State the outcome whichever way it went, including what you did if you lost the argument: committed to the decision, recorded the risk, and revisited it when new information arrived. The mistake that sinks the story is persuasion by seniority or repetition.

Follow-up

What was the strongest argument against your position?
How would you have approached it if you had no data yet?
Tell me about a time you were persuaded to change your own view.

How do you handle feedback and criticism regarding your work?

Medium · Behavioral / Leadership

Approach

Use a specific critique, ideally from a code review or a performance conversation with a lead. Name the feedback in its own words and show that you took it seriously rather than defending yourself.
Describe what you did within days: asked clarifying questions, changed the code or the habit, and checked back to confirm the change addressed the concern.
Show durable change, such as a review checklist, smaller pull requests, or tests written first. A repeated pattern in later work is stronger proof than saying you are open to feedback.
If the feedback was partly wrong, say how you separated the useful part from the rest and responded without becoming defensive. Avoid a disguised strength such as saying you work too hard.

Follow-up

Tell me about feedback you disagreed with and what you did.
How do you give hard feedback in a code review?
What is the most useful feedback you have received in the last year?

What motivates you to perform well in a team setting?

Medium · Behavioral / Leadership

Approach

This is a values question, so answer with one or two specific motivators and back each with an episode. Examples include shipping something other people rely on, learning from stronger engineers in code reviews, or seeing a messy area become reliable.
Tie it to how you behave in a team: you answer review requests promptly, pair on hard bugs, write notes others can use, and share credit. Concrete habits are more convincing than the statement that you enjoy teamwork.
Relate it to this role: working with product managers and designers, supporting a CRM platform used by hospitality businesses, and being accountable for a feature end to end.
Be honest about what drains you, such as unclear ownership or repeated rework, and what you do about it. An answer where the only motivator is money, or one that sets you against the team, works against you.

Follow-up

What demotivates you at work, and how do you handle it?
Describe the team environment in which you did your best work.
How do you keep a teammate going when they are discouraged?

Share an experience where you had to meet tight deadlines. How did you manage your time?

Medium · Behavioral / Leadership

Approach

Pick a deadline that was real and had consequences, such as a release date tied to a customer or an integration partner. State the constraint in one sentence and move quickly to what you did.
Show prioritization: you split the work into must-have and deferrable, cut or postponed items with the product owner, and agreed on a smaller scope instead of silently working longer.
Show how you protected quality under pressure: tests on the critical path, small increments merged often, and an early check-in when a risk appeared, not on the last day.
Close with the result and the follow-up: what shipped, what was deferred, how you paid back any shortcut afterward, and what you changed in how you estimate. Working nights as the whole answer shows effort but no judgment.

Follow-up

What did you decide to cut, and who agreed to it?
How did you tell stakeholders the date was at risk?
Would you commit to the same deadline again, and what would you change in the estimate?