Calpine Software Engineer Interview Guide

The 60-second brief

Calpine operates in the energy sector, and the Software Engineer role candidates describe is about the software behind its operations. That covers applications that support energy generation, data management and day-to-day operational work, with plant performance and regulatory compliance named as areas the software touches. The listed stack is C# and SQL, with Git, IDEs, testing frameworks and continuous integration and deployment practices around them; cloud experience is described as a plus. Day to day, the role is reported to include building and maintaining applications, gathering requirements with cross-functional teams, taking part in code reviews, troubleshooting issues, and helping deploy updates. In practice that means ordinary application engineering over operational data: a C# service, a relational database, and people outside engineering who depend on both.

This guide is for candidates applying for a Software Engineer role at Calpine, typically described as needing a few years of experience in C# and SQL. It covers the three reported rounds, the technical, problem-solving, coding and behavioral questions candidates report, and a plan for rehearsing them. It does not cover pay or team-specific details.

Candidates report three stages over roughly three to five weeks: a Preliminary Screening with HR, Technical Assessments with engineering managers or technical leads, and Behavioral Interviews on past projects, problem solving and fit.

Focus areas

• SQL (Querying & Assessment)
• C# Programming
• Assessment-Based Interviewing (SQL Assessment)

Overview

The reported question set is broad rather than deep. It mixes fundamentals (object-oriented principles, a basic sort, the height of a binary tree, stack versus queue, reversing a string), database work (experience with SQL, tuning a slow query, analysing a sample dataset), and engineering-practice questions (debugging, designing a feature, gathering requirements, what to do when stuck). Alongside those sit the behavioral prompts on challenges, prioritising, cross-functional work, feedback and motivation. Candidates also report a SQL assessment among the topics, so treat SQL as something you may have to write, not only discuss.

Because the listed stack is C# and SQL, build your answers around them. When you explain the principles of object-oriented programming, show them in C#: an interface and an abstract class, a virtual method overridden in a subclass, a private field behind a property. When you describe database experience, name the engines you have used, the queries you tuned and how you read an execution plan. Fundamentals questions are short, so the way to stand out is precision: state complexity, name the edge case, and say what you would test.

Several questions ask you to describe your own work: a complex project, an algorithm you implemented, a challenge you handled. Those answers are only as good as the material behind them, so spend the first day choosing two or three projects you can discuss in depth, including what you personally decided, what broke, and what you measured afterwards. The same projects can feed the technical conversation and the behavioral stage.

Candidates describe the process as conversational, and the role touches operations and compliance. Practise explaining technical decisions in plain language to a project manager or another non-engineer, and read a little about how power generation businesses use software so that your questions to the team are informed. Familiarity with the energy sector is described as a plus, not a requirement, so never bluff it.

The Calpine interview process

Candidates report three stages over roughly three to five weeks, and say the details vary by team and role. Treat the descriptions below as what candidates describe, not a published process.

Preliminary Screening

Candidates report this first stage as a conversation with HR about your qualifications and fit for the role. Expect it to cover your background, the languages you work in and what you want from the position, so you should be able to give a tight summary of your experience and say plainly where C# and SQL appear in it. It is also the natural point to ask about the team, the shape of the later rounds and whether work arrangements are flexible, since candidates report these vary by team.

What to demonstrate

• Whether your experience lines up with the role as described: C# and SQL, a few years in software engineering
• How clearly you can summarise your background and the projects you have worked on
• Basic fit for the position and the team you would join

How to prepare

• Write a short spoken summary of your career that names your strongest language and one project in C# or SQL
• Rehearse the question about which programming languages you are most comfortable with, with a reason and an example for each
• Prepare two or three questions about the team and the later technical stage

Technical Assessments

Candidates report interviews with engineering managers or technical leads that test technical competence. The reported question mix includes language and OOP questions, database work, debugging and design discussions, and coding fundamentals; where a given question lands in the loop varies, so prepare all of them. A live coding or SQL exercise tests working code, so practise writing and trace-testing code by hand, and practise saying your plan out loud before you type.

What to demonstrate

• Working knowledge of the listed stack, C# and SQL, and of object-oriented principles
• Coding fundamentals: strings, sorting, trees, stacks and queues
• How you debug, reason about a slow query and structure a new feature

How to prepare

• Write C# examples for each OOP principle and for interface versus abstract class
• Practise reversing a string, a basic sort with its complexity, and tree height both recursively and iteratively
• Take one slow query, read its execution plan and explain the index or rewrite you would make
• Walk through a real bug you fixed, in order: reproduce, narrow, fix, prevent

Behavioral Interviews

Candidates describe the final stage as discussions about past projects, problem-solving scenarios and cultural fit. Behavioral prompts reported for the loop cover a significant challenge, prioritising across projects, cross-functional collaboration, handling feedback and what motivates you. Candidates also say collaboration is a theme, so choose stories where your own decisions and your work with other teams are clear.

What to demonstrate

• How you describe past projects and your own contribution to them
• How you approach problems you cannot solve immediately
• Teamwork, communication and fit, as shown by concrete examples

How to prepare

• Build five stories, one each for challenge, prioritisation, cross-functional work, feedback and motivation, and give each a measurable result
• Write each story in first person singular and cut every sentence that describes the team without you
• Prepare an honest answer on why you want to build software for an energy business

Where candidates lose points

Naming a favourite language in the first round, then being unable to go beyond syntax when asked about it

For each language you name, prepare one project, one feature you like or dislike and why, and one mistake you made with it. For C#, be ready to talk about interfaces, properties, collections and exception handling.

Reciting definitions of the object-oriented principles with no code behind them

Write a small C# example in which an abstract class or interface has two implementations and a method is overridden, and use it to show encapsulation, inheritance, polymorphism and abstraction. Say when you would prefer composition.

Answering the slow-query question with 'add an index' and nothing else

Describe a sequence: get the actual execution plan, find the scan or the bad row estimate, check for functions on indexed columns, select only needed columns, and compare timings before and after. Mention the cost of extra indexes on writes.

Writing a string reversal, sort or tree-height function without stating complexity or testing edge cases

State time and space cost aloud. Test the empty string, a single character, an empty tree and a skewed tree, and know that built-in reversal is a fine answer only if you can also write the loop.

Telling project and behavioral stories in 'we' with no result

For every story, write the sentence beginning 'I decided' and the measured outcome. If you cannot find either, choose a different story.

Questions & practice

Write a function to reverse a string in your preferred programming language.

Medium · Coding / Algorithms

Approach

1. Settle the edge cases first: null input, the empty string, and whether the input is plain ASCII or arbitrary Unicode. C# strings are immutable, so any reversal allocates a new string.
2. Simple C#: char[] chars = s.ToCharArray(); Array.Reverse(chars); return new string(chars);. That is O(n) time and O(n) extra space. To show the algorithm, swap with two pointers (i from the start, j from the end) until they meet, which takes n/2 swaps.
3. Do not build the result with += in a loop. Each concatenation copies the whole string, so the total is O(n^2). Use a StringBuilder or a char array.
4. Unicode: a C# char is a UTF-16 code unit, so reversing chars splits surrogate pairs (many emoji) and separates combining accents from their letters. If correctness matters, reverse text elements with System.Globalization.StringInfo instead.
5. Test with null (throw ArgumentNullException or return null, and state which), "", a single character, even and odd lengths, a palindrome and a string containing an emoji.

Follow-up

• Reverse the order of the words in a sentence while keeping each word intact.
• Check whether a string is a palindrome, ignoring case and punctuation, using O(1) extra space.
• What does LINQ's Reverse() return when called on a string, and what does that approach cost?

How would you implement a basic sorting algorithm? Can you explain its time complexity?

Medium · Coding / Algorithms

Approach

1. Implement insertion sort, because it is short and easy to get right: for each i from 1, shift the larger elements of the sorted prefix one place right and insert a[i] in the gap. It is O(n^2) in the worst and average cases, O(n) on already-sorted input, uses O(1) extra space and is stable.
2. Explain the complexity. Insertion sort makes up to n(n-1)/2 comparisons on reversed input. Merge sort has about log2 n levels of merging, each O(n) work. No comparison sort can beat Omega(n log n) in the worst case.
3. Know the O(n log n) alternatives and the properties that decide between them. Merge sort: O(n log n) in every case, stable, O(n) extra memory. Quicksort: O(n log n) on average but O(n^2) with bad pivots (such as a first-element pivot on sorted input), in place, not stable. Heap sort: O(n log n) worst case, O(1) extra space, not stable.
4. Know your platform. In .NET, Array.Sort and List<T>.Sort use introsort (quicksort that switches to heap sort and insertion sort) and are not stable, while LINQ OrderBy is stable. That matters when you sort records by one key and expect an earlier ordering to survive.
5. Mention non-comparison sorts: counting sort runs in O(n + k) for integer keys in a small range k, and radix sort extends the idea to larger keys.

Follow-up

• When does stability matter? Give a concrete example.
• How would you sort a file too large to fit in memory?
• The input is almost sorted already. Which algorithm would you pick, and why?

Given a binary tree, write a function to determine its height.

Medium · Coding / Algorithms

Approach

1. State your convention. Height counted in edges gives -1 for an empty tree and 0 for a single node; counted in nodes it gives 0 and 1. Pick one and keep to it.
2. Recursive solution: Height(node) = node == null ? 0 : 1 + Math.Max(Height(node.Left), Height(node.Right)) (the node-count convention). It visits each node once, so it is O(n) time, with O(h) stack space where h is the height.
3. Name the risk: a fully skewed tree has h = n, so the recursion depth grows with n and can overflow the call stack. In .NET a StackOverflowException cannot be caught and ends the process, which is a reason to offer an iterative version.
4. Iterative solution: breadth-first search with a Queue<T>. At the start of each level, record queue.Count, dequeue that many nodes while enqueuing their children, then add 1 to the height. It is O(n) time and O(w) memory, where w is the widest level (about n/2 at the bottom of a perfect tree).
5. Test with an empty tree, a single node, left-skewed and right-skewed chains, a perfect tree and an unbalanced tree.

Follow-up

• Check whether the tree is height-balanced in a single O(n) pass.
• Find the minimum depth. Why can BFS stop earlier than DFS?
• Compute the diameter of the tree, meaning the longest path between any two nodes.

Explain the difference between a stack and a queue. When would you use each?

Medium · Coding / Algorithms

Approach

1. A stack is LIFO: push, pop and peek all work at one end. A queue is FIFO: enqueue at the back and dequeue at the front. All of these are O(1), amortized when the backing array has to grow.
2. In C#, Stack<T> and Queue<T> are both backed by arrays. Queue<T> uses a circular buffer, so a dequeue never shifts elements. Pop or Dequeue on an empty collection throws InvalidOperationException; TryPop and TryDequeue avoid the exception.
3. Use a stack for anything nested or that must be undone in reverse: the call stack and recursion, undo history, depth-first search, bracket matching, evaluating postfix expressions.
4. Use a queue when arrival order matters: breadth-first search, processing jobs or messages in the order they arrive, buffering between a producer and a consumer. Use ConcurrentQueue<T> when several threads share it.
5. When order should follow priority rather than arrival, use PriorityQueue<TElement, TPriority> (.NET 6 and later). It is a min-heap with O(log n) enqueue and dequeue, and it does not guarantee FIFO order among equal priorities.

Follow-up

• Implement a queue using two stacks. What is the amortized cost per operation?
• Design a stack that also returns its minimum element in O(1).
• For a very deep depth-first search, why might you replace recursion with an explicit Stack<T>?

Describe a project where you implemented an algorithm to solve a problem.

Medium · Coding / Algorithms

Approach

1. Choose a project where the choice of algorithm changed the outcome. State the problem, the real input size and the constraint (a time limit, memory, a batch window).
2. Describe the naive version, its complexity and why it failed, for example a nested loop matching two lists in O(n*m) that timed out. Then describe the replacement and its complexity: a hash-map lookup in O(n + m), sorting plus two pointers in O(n log n), merging intervals, or caching repeated work.
3. Explain the data structures you used and the memory you traded for speed, such as holding one side of the match in a Dictionary.
4. Show how you checked it was correct and faster: unit tests on edge cases, comparing the output against the brute-force version on random inputs, and timing both on realistic data.
5. Give the result in numbers you can defend, and be ready to write the core loop on the whiteboard and say what you would change now.

Follow-up

• Why not use a library function or push the work into a database query instead?
• How did you prove the new version gave the same results as the old one?
• What happens to your solution if the input grows tenfold?

Explain how you would optimize a slow-running database query.

Medium · Problem-solving / Case Studies

Approach

1. Measure before changing anything. Reproduce with realistic parameters and capture the actual plan: in SQL Server, the actual execution plan plus SET STATISTICS IO, TIME ON; in PostgreSQL, EXPLAIN (ANALYZE, BUFFERS). Compare estimated and actual row counts.
2. Find the costly operator in the plan: a full scan where a seek was expected, a key lookup repeated for every row, a sort or hash join spilling to disk or tempdb, or large estimate errors that point to stale statistics.
3. Make the predicates sargable so an index can be used. Replace WHERE YEAR(ReadingTime) = 2024 with ReadingTime >= '2024-01-01' AND ReadingTime < '2025-01-01', avoid leading-wildcard LIKE, and match parameter types to column types so there are no implicit conversions.
4. Index for the query: a composite index with the equality columns first and the range column last, and INCLUDE the selected columns (SQL Server) to make it covering. Return only the columns and rows you need. Each index adds write cost and storage, so justify it.
5. Look beyond the SQL text: N+1 queries from an ORM, missing pagination, blocking and lock waits, and SQL Server parameter sniffing, where a plan cached for one parameter value runs badly for another. Confirm the gain with the same measurements you started with.

Follow-up

• The query is fast in SSMS but slow when the application calls it. What could explain that?
• You added an index but the plan still scans the table. Why might the optimizer ignore it?
• The table is write-heavy. How does that change your indexing choices?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

What programming languages are you most comfortable with, and why?

Medium · Technical / Domain Questions

Approach

1. Lead with the one or two languages you have shipped production code in. If C# and SQL are among them, put them first, since the requirements candidates describe for this role list both. Name the version and frameworks you actually used (for example .NET 6+, ASP.NET Core, Entity Framework).
2. Give the 'why' as concrete properties, not taste. For C#: static typing and compiler checks, LINQ for querying collections, async/await for I/O-bound work, garbage-collected memory. For SQL: set-based queries where the engine chooses the execution plan.
3. Back each claim with one piece of work: what you built, roughly how big it was, and one moment where a language feature mattered (for example, nullable reference types warning about a null path before it reached production).
4. Be honest about depth. Separate the languages you could write production code in tomorrow from the ones you have only scripted in, and explain how you get productive in a new one: official docs, porting a small existing module, writing tests first.
5. Name one weakness of your main language and how you work around it, such as hidden allocations from boxing or LINQ in hot loops in C#, which you measure with a profiler before rewriting anything.

Follow-up

• What is the difference between a value type and a reference type in C#, and when does boxing happen?
• If this team's codebase used a language you know less well, how would you become productive in it?
• Which language feature have you misused, and what did it cost you?

Can you explain the principles of object-oriented programming?

Medium · Technical / Domain Questions

Approach

1. Name the four principles, one line each. Encapsulation: state hidden behind methods and properties. Abstraction: callers see what an object does, not how. Inheritance: specialising a base type in an is-a relationship. Polymorphism: one call whose behaviour depends on the object's runtime type.
2. Map them to C#: private fields exposed through properties; the access modifiers private, protected, internal and public; abstract classes and interfaces; virtual/override for runtime dispatch; sealed to stop further overriding. A class has exactly one base class but can implement many interfaces.
3. Walk through one small example. An interface such as IDataSource with a ReadAsync method has several implementations, and the calling code depends only on the interface, so adding a new source does not change the caller. Say that this is the open/closed principle.
4. Give the trade-offs. Deep inheritance trees tie subclasses to base-class internals (the fragile base class problem). Prefer composition and interfaces when the relationship is has-a or when behaviours vary independently. Use Liskov substitution as the test of whether a subclass is valid.
5. Distinguish overloading (same name, different parameters, resolved at compile time) from overriding (virtual dispatch at runtime). Note that the C# new modifier hides a member instead of overriding it, so a reference typed as the base class still calls the base version.

Follow-up

• When would you choose an abstract class over an interface in C#, now that interfaces can carry default implementations (since C# 8)?
• Give an example of a subclass that breaks Liskov substitution, such as Square deriving from Rectangle, and say how you would fix it.
• How does encapsulation help when the validation rules for a field change after release?

Describe a complex project you worked on and the technologies you used.

Medium · Technical / Domain Questions

Approach

1. Pick a project where you owned a real part of it. Open with the problem in two sentences: who used it, what it had to do, and the constraint that made it hard (data volume, latency, integration with a legacy system, an audit trail requirement).
2. Sketch the architecture as a data flow: inputs, services, storage, outputs. Name each technology and the alternative it beat, for example a relational database over a document store because the data was relational and updates needed transactions.
3. Spend most of the answer on one hard technical decision or incident: the options you weighed, what you chose, and what that choice cost later. Use 'I' for your own work and keep it separate from the team's.
4. Close with a measurable result (runtime, error rate, hours saved) and one thing you would build differently now.
5. Be ready to draw it and go one level deeper on any part: the schema, how changes moved through Git and the CI/CD pipeline, and which tests caught real bugs.

Follow-up

• If the data volume grew tenfold, which component would fail first, and what would you change?
• Why that database or framework, and what would make you switch?
• How was the system tested and deployed, and what reached production that tests missed?

How would you approach designing a new software feature?

Medium · Problem-solving / Case Studies

Approach

1. Start from the user and the problem: who needs the feature, what they do today without it, and how success will be measured. Write acceptance criteria before any design.
2. List the non-functional requirements explicitly: data volume and performance, permissions and security, availability, and auditability (who changed what and when) if the data feeds reporting or compliance.
3. Design from the data outward: schema changes and migrations for existing rows, the API or UI contract, and how the feature plugs into existing services without breaking current callers.
4. Plan delivery in small increments behind a feature flag, with unit and integration tests in the CI pipeline and logging or metrics that show it works once released.
5. Say the trade-offs out loud: extending an existing module versus building a new component, doing work synchronously versus in a background job, and what you would deliberately leave for a later version.

Follow-up

• Requirements change halfway through the build. How do you handle it?
• How would you roll the feature out without disrupting existing users or data?
• How would you estimate the effort, and what would you do if the estimate was badly off?

Describe your process for gathering requirements from stakeholders.

Medium · Problem-solving / Case Studies

Approach

1. Identify every stakeholder group (end users, their managers, operations or support, security or compliance, other teams that integrate with the system) and agree on who makes the final call when they conflict.
2. Ask people to walk through the last time they did the task, rather than asking what they want. Find where it breaks and what workaround they use, and watch the workflow directly if you can.
3. Write the requirements back as user stories with acceptance criteria (Given/When/Then), including edge cases and non-functional needs, and get explicit confirmation.
4. Prioritise with the stakeholders (for example MoSCoW: must, should, could, won't), and show a mockup or thin prototype early, because people react to something concrete more reliably than to a written spec.
5. Keep the requirements somewhere tracked (tickets, or a document under version control) and agree up front how changes are requested and approved.

Follow-up

• Two stakeholders want contradictory behaviour. How do you resolve it?
• A stakeholder cannot say what they want until they see it. How do you proceed?
• How do you catch a requirement that nobody mentioned until after release?

What steps do you take when you encounter a problem you cannot solve immediately?

Medium · Problem-solving / Case Studies

Approach

1. Timebox the first attempt, then write down what you know: the exact symptom, what you have ruled out, and your current hypotheses.
2. Shrink the problem. Build a minimal reproduction, isolate the failing component, and check your assumptions one at a time (inputs, configuration, library versions).
3. Use sources in order of cost: documentation and library source, a search on the exact error message and the project's issue tracker, the logs, then a colleague. Explaining the problem out loud often exposes the gap.
4. When you ask for help, ask precisely: what you are trying to do, what you expected, what actually happened, and what you have already tried.
5. Tell anyone who depends on you about the risk early and offer a workaround or a reduced scope. Once it is solved, record the cause and the fix so the next person does not repeat the search.

Follow-up

• How do you decide when to stop and ask for help?
• Tell me about a time your first hypothesis was wrong. What changed your mind?
• What do you do when nobody on the team knows the answer either?

Given a sample dataset, how would you go about analyzing it?

Medium · Problem-solving / Case Studies

Approach

1. Ask what decision the analysis has to support before touching the data. That choice determines the metric, the grain and how much cleaning is worth doing.
2. Profile first: row count, column types, the grain (one row per what?), whether keys are unique, null rates, value ranges and distinct counts. In SQL use COUNT(), COUNT(DISTINCT ...) and GROUP BY ... HAVING COUNT() > 1; in pandas use df.info(), df.describe() and df.isna().sum().
3. Clean by written rules: remove duplicates, handle missing values (drop, fill or flag, and say why), and normalise units and time zones. Daylight-saving changes create repeated or missing local hours in timestamped data. Check outliers against the domain before removing them.
4. Explore with distributions, trends over time, group comparisons and plots. Prefer the median to the mean on skewed data, and do not present a correlation as a cause.
5. Report the answer, the evidence and the data-quality caveats, plus a next step. Keep the cleaning and analysis in a script so the result can be reproduced.

Follow-up

• An extreme value could be a data-entry error or a real event. How do you decide which?
• A fifth of the values in a key column are missing. What do you do?
• How would you automate this analysis if a new file arrived every day?

How do you approach debugging a software issue?

Medium · Technical / Domain Questions

Approach

1. Reproduce the bug first and write down the exact facts: error message, stack trace, inputs, environment, version and when it started. A reliable reproduction turns the rest of the work into a search.
2. Halve the search space. Isolate components, check values at each boundary, or run git bisect between a known-good and a known-bad commit. Bisect takes about log2(n) steps, roughly 10 for 1,000 commits.
3. Test one hypothesis at a time, changing one variable per experiment, with the debugger (breakpoints, conditional breakpoints, watch windows, stepping through code) or with targeted logging.
4. Fix the root cause rather than the symptom. Add a regression test that fails before the fix and passes after it, and search the codebase for the same pattern elsewhere.
5. For intermittent failures, suspect concurrency, timing, caching or environment-specific configuration. Add structured logs with timestamps and correlation IDs, then compare a failing run with a passing one.

Follow-up

• The bug only happens in production and you cannot attach a debugger. What do you do?
• How would you track down a failure that appears about once a day with no obvious pattern?
• When is a quick workaround acceptable, and how do you make sure the real fix still happens?

Suggested practice checklist

The plan follows the reported loop: it opens by mapping the rounds and choosing your projects, spends the middle days on SQL, C#, coding and problem-solving questions, and ends with behavioral stories and a full rehearsal.

Day 1 — Map the loop and choose your projects

• Write the three reported stages in order: Preliminary Screening with HR, Technical Assessments with engineering managers or technical leads, and Behavioral Interviews.
• List two or three projects you can discuss in depth, with the stack, your decisions and a measurable result for each.
• Write and say aloud your answer on which languages you are most comfortable with, and the answer on a complex project you worked on.

Deliverable: A one-page loop map, a project inventory with results, and two spoken answers (languages, complex project).

Day 2 — SQL: experience, tuning and analysis

• Take a slow query from your own work, or write one over a sample schema, and read its execution plan. Note the scan, the join order and the index you would add.
• Write queries for duplicate detection, a left join that keeps unmatched rows, and a top-N per group using a window function.
• Do the practice exercise on detecting a concurrent edit in an update statement, then explain it in two sentences.
• Outline how you would analyse an unfamiliar dataset: row counts, nulls, duplicates, distributions, then a question to answer.

Deliverable: A tuned query with before and after plan notes, three written queries, and a spoken outline for the SQL experience question and the dataset question.

Day 3 — C# and object-oriented principles

• Write a small C# model with an interface, an abstract class and two implementations to show all four OOP principles.
• Prepare the contrast between interface and abstract class, inheritance and composition, and overriding and overloading.
• Explain your answer on the principles of OOP out loud, using your own code as the example.

Deliverable: One C# file of examples and a spoken explanation of the OOP principles built on it.

Day 4 — Coding fundamentals

• Write string reversal three ways (built-in, two-pointer swap, stack) and state the cost of each.
• Implement insertion sort and merge sort, state their time complexity and say when each is a sensible choice.
• Write binary tree height recursively and with a queue, and test an empty tree and a skewed tree.
• Write the difference between a stack and a queue with one real use of each, and an example of an algorithm you implemented in a project.

Deliverable: Four working functions in C# with complexity notes, plus a prepared example of an algorithm from your own work.

Day 5 — Debugging, design and requirements

• Write your debugging sequence and apply it to a real bug you fixed: reproduce, narrow, form a hypothesis, fix, add a test.
• Outline how you would design a new feature: requirements, interfaces, data model, tests, rollout.
• Write your requirements-gathering process, including questions you ask stakeholders and how you record agreements.
• Write what you do when stuck: reduce the problem, search, ask a colleague with a prepared question.

Deliverable: Four written outlines (debugging, feature design, requirements, getting unstuck), each tied to an example from your own work.

Day 6 — Behavioral stories

• Write five stories with the situation, your decisions and the result: challenge, prioritisation, cross-functional work, feedback, motivation.
• Cut every 'we' and replace it with what you did.
• Say each story aloud and trim it to a version you can tell without notes.

Deliverable: Five rehearsed first-person stories, one per reported behavioral prompt.

Day 7 — Full rehearsal and questions for the team

• Run a mixed rehearsal: the introduction and language answer, the OOP question, a query tuning explanation, one coding function and two behavioral stories.
• Write questions for the HR screen and for technical leads: how the team deploys, how code review works, what the SQL assessment looks like.
• Fix the weakest answer from the rehearsal and record it again.

Deliverable: A recorded mixed rehearsal, a list of questions to ask, and one improved answer.

Stories for the final round

Candidates describe the final stage as discussions of past projects, problem-solving scenarios and cultural fit, and the reported prompts cover challenge, prioritisation, cross-functional work, feedback and motivation. The role works with project managers and other stakeholders, so choose stories that show your own decisions and how you worked with people outside your team.

1. Describe a complex project you worked on and the technologies you used.

What is your experience with database management systems, particularly SQL?

Medium · Technical / Domain Questions

Approach

1. Answer in layers, then anchor it with one story. Cover what you have built (schemas, keys, constraints and normalisation), what you have queried (joins, aggregation with GROUP BY and HAVING, subqueries and window functions), and what you have tuned (indexes, execution plans). Name the database engines you have actually used and avoid listing products you cannot discuss.
2. Pick one concrete case: a query or report that was slow, how you found the cause (an execution plan showing a scan, a missing index, a function on an indexed column), what you changed, and the measured before and after. A number from your own work beats a general claim.
3. Cover how application code reaches the database, since the role lists C# and SQL: parameterised queries against SQL injection, ORM versus hand-written SQL and when each is better, and transactions with a sentence on isolation levels and deadlocks.
4. Be ready to write SQL on the spot, because candidates report a SQL assessment: an inner versus left join, a duplicate-finding GROUP BY ... HAVING, a top-N per group with a window function. Say which indexes you would expect it to use.
5. The mistake that sinks this answer is a one-line claim of being comfortable with SQL. Another is naming advanced features you cannot explain when pushed.

Follow-up

• What is the difference between a clustered and a non-clustered index, and when does an index not help?
• Walk me through how you would find and delete duplicate rows safely.
• How do you stop two users from overwriting each other's update to the same record?

Tell me about a time you faced a significant challenge at work. How did you handle it?

Medium · Behavioral / Leadership

Approach

1. Use a situation-task-action-result structure, and spend most of the time on action. Open with two sentences of context, then say what was at stake and what made it hard: a production fault, an unclear requirement, a deadline that moved, or a system you did not know.
2. Choose a challenge where you made the decisions. Name the options you weighed and why you chose one, such as rolling back versus patching forward, or cutting scope versus adding people. Say what you did when your first approach failed, because that shows how you actually work.
3. Close with a result you can verify (an error rate that dropped, a release that shipped, a process that changed) and one thing you would do differently. A story about overcoming a hard technical or delivery problem fits an engineering role better than a purely personal one.
4. Avoid a challenge that was really someone else's fault, a story told only in 'we', and a happy ending with no cost. State what the problem cost and how you contained it.

Follow-up

• What would you do differently if you faced the same situation today?
• Who else did you need to bring in, and how did you ask for their help?
• How did you know the fix worked and the problem would not come back?

How do you prioritize tasks when working on multiple projects?

Medium · Behavioral / Leadership

Approach

1. Give the method before the anecdote. List every commitment with its deadline, who is waiting on it and what happens if it slips. Rank by impact and urgency, and move up anything that blocks other people. Then say where you record this so others can see it, such as a shared board or a short status note.
2. Show that you renegotiate instead of silently absorbing load. When two requests collide, tell both requesters the trade-off ('if I take the report change now, the deployment fix moves to Thursday') and let the owner decide, or escalate to the manager if they disagree.
3. Use a real example from your own work, such as a production defect arriving in the middle of a feature. Explain how you triaged it: severity, workaround available, and whether the planned work could wait.
4. Name how you protect time for quality work like code reviews and tests, rather than dropping them first when time is short. The weak answer is 'I work longer hours' or 'I do the urgent things first' with no criteria.

Follow-up

• Two stakeholders both say their request is the top priority. What do you do?
• A production issue interrupts a feature you promised for this week. What happens to each?
• How do you handle a task that keeps getting deferred but is still important?

Describe a situation where you had to collaborate with a cross-functional team. What was your role?

Medium · Behavioral / Leadership

Approach

1. Pick a project that involved people outside engineering, such as a project manager, an operations user or another team's engineer. Say who they were and what each needed from you, so your role is easy to see.
2. State your own role in one sentence (for example 'I owned the C# service and the requirements conversations with the operations side') and then describe actions only you took: running a requirements session, translating a technical constraint into a business trade-off, or agreeing an interface with another team.
3. Include one point of friction, such as conflicting priorities or a requirement that kept changing, and show how you resolved it with evidence: a prototype, a written decision, or a demo. Finish with what shipped and what the other function said about it afterwards.
4. The common mistake is describing what the group achieved with no visible contribution from you. Another is blaming the other function. Talk about how you adapted your communication to their needs.

Follow-up

• How did you explain a technical limitation to someone without a technical background?
• What did you do when a stakeholder changed the requirement late in the work?
• What would you change about how that team worked together?

How do you handle feedback on your work?

Medium · Behavioral / Leadership

Approach

1. Choose a specific piece of feedback, ideally a code review comment, a design critique or a performance conversation, and say exactly what was said. Specific beats general: 'a reviewer pointed out that my loop issued a query per row' is far stronger than 'I welcome feedback'.
2. Show your sequence: listen and ask a clarifying question, check whether the feedback is right (for example by running the numbers), change the work, and then follow up with the person to confirm it addressed their concern.
3. Show the lasting change: what you do differently now, such as a checklist before opening a pull request or writing tests first. Mention that you also give feedback, and how you phrase it, because code reviews are part of the role.
4. The mistakes are a story where the feedback was obviously wrong and you were vindicated, and a story with no change in behaviour. If you disagreed, say how you raised it respectfully and what evidence you brought.

Follow-up

• Tell me about feedback you disagreed with. What did you do?
• How do you give critical feedback to a peer in a code review?
• What is the most useful piece of feedback you have received, and what changed afterwards?

What motivates you to succeed in your role?

Medium · Behavioral / Leadership

Approach

1. Answer with something true, and prove it with behaviour instead of adjectives. If you are motivated by solving hard problems, point to a bug you chased down; if it is software others rely on, point to a service you kept stable; if it is learning, point to a skill you built and used.
2. Connect the motivation to this role without inventing enthusiasm. The reported work involves software for operations, data and compliance, so you might say you like building reliable tools that people depend on daily. Say it only if it is true, and show you read about the energy business.
3. Give a short example where that motivation led to a concrete result, such as staying with a hard defect, mentoring a junior colleague, or improving a deployment process. Keep the answer brief and end with where you want to grow.
4. Avoid answers that are only about pay, only about the company's mission with no link to your work, or so generic ('I love technology') that any candidate could give them.

Follow-up

• What kind of work drains your motivation, and how do you handle it?
• Tell me about a time your motivation was low. What did you do?
• What would you want to learn or build in your first year in this role?