Interview guides · BGL Management

BGL Management Software Engineer Interview Guide

BGL Management Software Engineer interview guide: three reported rounds, C#, OOP, TDD/BDD and CI/CD questions, STAR stories and a 7-day prep plan.

The 60-second brief

Candidate reports describe BGL Management as the operator of high-traffic, customer-facing platforms, but they do not name the products, so check the company's own site before you interview. The Software Engineer role, as candidates describe it, covers the whole delivery cycle on those platforms: gathering requirements, designing, implementing, testing and deploying. It means maintaining existing systems, building new customer-facing features and working alongside Product Managers and Quality Assurance in an agile team with stand-ups, sprint planning and retrospectives.

This guide is for Software Engineer candidates preparing for the BGL Management loop. It covers the three reported rounds, all eleven reported questions (C# and OOP, TDD and BDD, CI/CD, your recent work, influence, and career motivation), a seven-day plan and a behavioral section. It is built around the stack candidates list for the role: C#, object-oriented design, TDD or BDD, CI/CD and agile delivery.

Candidates report three rounds over roughly 3-5 weeks: a telephone screen, a technical assessment that is either a take-home challenge or a pair-programming session, and face-to-face or virtual interviews with senior engineers and management.

Focus areas

Programming Challenges / Technical Exercises
CI/CD
Object-Oriented Programming (OOP)

Overview

The reported questions split into two groups. One group is about how you build software: how you use TDD and BDD day to day, what your CI/CD pipeline looks like and how you keep deployments reliable, how you approach C# and object-oriented design, and what technical problems you solved recently. The other is about you: why this company and this job, why you moved into software engineering, how you have influenced a decision, and where you want to be in five years. No algorithm-puzzle or system-design prompt appears among them, so the preparation weight sits on explaining real engineering practice with concrete examples.

Because the technical questions are open-ended, the answer quality comes from specifics. 'I write tests first' is thin. 'I write a failing xUnit test for the next behavior, make it pass with the simplest code, then refactor with the tests green' shows the habit. The same holds for CI/CD: name the stages of a pipeline you have actually run, what blocks a merge, how you version and roll back a release, and one deployment that went wrong and what changed afterwards.

The technical assessment is reported as either a take-home challenge or a pair-programming session, and candidates are told to confirm which one in advance. Prepare for both. For a take-home, that means readable C# with tests, a short README and a note on the trade-offs you made. For pairing, it means practising narrating your reasoning while you write code, starting from a test, and handling a requirement change mid-session.

The final round is reported to involve senior engineers and management and to focus on technical depth and cultural fit. Reported example scenarios include walking through a recent project and its design trade-offs, explaining how you would refactor a legacy module for performance and maintainability, disagreeing with a peer over a technical approach, and learning a technology quickly to meet a deadline. Have a story ready for each, and keep your motivation answers consistent with each other across the screen and the final round.

The BGL Management interview process

Candidates describe three stages in this order. The reports do not say which question comes up in which stage, so prepare every reported question for every stage.

Telephone Screen

The telephone screen is reported as an initial conversation to establish fit and background. The reported question set includes several that suit this kind of conversation: telling your career story, why you moved into software engineering, and why this company and this job. Treat it as your first chance to give a short, consistent account of who you are as an engineer, and expect to be asked about your recent work and current stack.

What to demonstrate

Fit for the role and the background you bring
How clearly you can summarise your career and recent work
Reasons for choosing software engineering, this job and this company

How to prepare

Write a two-minute career story with three beats: where you started, the move into software engineering, and what you build now. Rehearse it aloud until it holds together without notes.
Prepare a 60-second answer on your recent project: the system, your part in it, one technical challenge and how you overcame it, with a number or concrete outcome if you have one.
Find out what the company's platforms do from its public site, and write two specific reasons this job appeals to you that you can say without reading them.
List the stack the role reports (C#, OOP, TDD or BDD, CI/CD, agile) and note one project example for each, so a stack question gets a real answer.

Technical Assessment

The technical assessment is reported as a take-home challenge or a pair-programming session, and candidates advise confirming the format beforehand. The topics candidates list for the role are C# and object-oriented design, TDD and BDD, and CI/CD, so expect working code to be judged alongside how you test it. For a take-home, deliver something you would be willing to merge. For pairing, talk through your reasoning as you go, write a test before the implementation, and ask about requirements before coding.

What to demonstrate

Working, readable code, since both formats produce code
Object-oriented design choices in C#
Use of tests (TDD or BDD) in the way you build the solution

How to prepare

Do two or three timed coding exercises in C# starting from a failing test.
Review OOP in C#: encapsulation, inheritance versus composition, interfaces versus abstract classes, polymorphism, and the SOLID principles, each with a short example you can write live.
Build a submission template for take-homes: solution structure, unit tests, a README with run instructions and assumptions, and a short list of trade-offs and what you would do with more time.
Practise explaining out loud what you are about to write and why, then summarising the design when you finish.

Face-to-Face/Virtual Interviews

The final stage is reported as face-to-face or virtual interviews with senior engineers and management, centred on technical depth and cultural fit. Reported example scenarios are walking through a recent project and its design trade-offs, refactoring a legacy module for performance and maintainability, resolving a technical disagreement with a peer, learning a new technology under a deadline, and handling shifting priorities in an agile team. The reported motivation and influence questions belong in your preparation for this stage as well.

What to demonstrate

Technical depth on your own past work and design trade-offs
How you handle disagreement, influence and changing priorities
Cultural fit, as candidates describe it, and how well you can explain technical points to non-technical colleagues
Whether your motivation for the job and the five-year view hang together

How to prepare

Choose one project you know deeply and prepare its design story: requirements, options you rejected and why, what you would change now, and how you tested and deployed it.
Write a refactoring plan for a legacy module: add characterization tests first, find the hot path by measuring, make small behavior-preserving steps, then improve performance.
Prepare three to five STAR stories (influence, disagreement, quick learning, shifting priorities, a decision you defended) and map each to the reported questions.
Prepare three or four questions for the interviewers about the team's current technical challenges, how they work with Product and QA, and how engineers develop.

Where candidates lose points

Answering the TDD and BDD question with 'I write tests' and not separating the two

Describe the red, green, refactor cycle on a real feature, then say what BDD adds: shared Given/When/Then scenarios written with Product or QA before the code. Name the unit-test framework you have actually used and one thing TDD changed in a design.

Listing pipeline tools in the CI/CD answer without explaining what makes deployments reliable

Walk through the stages in order (build, tests, static checks, artifact, deploy). Then say what blocks a bad release: failing tests that stop a merge, versioned artifacts, staged rollout, health checks and a rehearsed rollback. Add one deployment that failed and the change you made after it.

Handing in a take-home that runs but has no tests, no README and no stated trade-offs

Treat it as a change you would put through code review. Add unit tests, a short README with run steps and assumptions, small focused classes, and a closing section on trade-offs and what you would do next.

Coding silently in a pair-programming session, or jumping to code before the requirements are clear

Restate the requirement, ask about edge cases, write a failing test, then explain each step as you type. If the pair changes the requirement, update the test first and say so aloud.

Giving a generic motivation answer ('a high-traffic platform') that could apply to any employer, or answers that contradict each other across why the company, why the job and why software engineering

Write one coherent motivation story with specific reasons: a platform feature you looked at as a user, one part of the reported role (full-lifecycle delivery, working with Product and QA) that matches your experience, and the moment you chose software engineering. Reuse the same facts in every version.

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?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

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

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.
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.
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.
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?

Why do you want to join BGL Management?

Medium · Behavioral & Leadership

Approach

Build the answer from three specific parts: what you learned about the company's products and users from your own research, the work candidates describe for this role (C# and object-oriented design, TDD or BDD, CI/CD, agile delivery), and how that fits your next career step.
Support each part with evidence: a product you tried or read about, a part of the stack you have used and want to go deeper in, a practice such as test-first development you already apply.
Avoid reasons that fit any employer (growth, culture, pay) and do not repeat the company's own marketing language back.
Keep it short and finish on what you would contribute, which leads naturally into your technical examples.

Follow-up

What do you know about the company's products, and what would you improve in one of them?
Which other companies are you speaking to, and how does this one compare?
What would make you leave within a year?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
How do you verify the backfill actually finished, given rows are still being inserted while it runs?

How do you apply TDD (Test-Driven Development) and BDD (Behavioral-Driven Development) in your daily workflow?

Medium · Technical & Domain Expertise

Approach

Describe the loop concretely: I write one failing unit test that names a behaviour, write the least code that makes it pass, then refactor with the test as a safety net (red, green, refactor). Give a real C# example, such as a pricing rule tested in xUnit or NUnit before the method exists.
Separate the two levels: TDD drives class-level design from the inside, while BDD starts from behaviour a product owner can read, written as Given/When/Then scenarios in Gherkin and bound to step definitions with a tool such as SpecFlow or its open-source fork Reqnroll. Say who writes the scenarios with you and when.
Explain how the tests stay fast and isolated: depend on interfaces, inject collaborators through the constructor, replace them with fakes or mocks (Moq, NSubstitute) at the boundary, and keep most tests at unit level with fewer integration and end-to-end tests. Note that heavy mocking couples tests to implementation details.
Be honest about where you do not test first: spikes, exploratory UI work, or legacy code with no seams, where I first add characterisation tests that pin current behaviour and only then refactor.
Close with evidence: a regression a test caught, a refactor the suite made safe, and how the tests run in CI on every pull request.

Follow-up

How do you test code that depends on the current time, the file system or a database?
What is the difference between a mock and a stub, and when has mocking made your tests worse?
Who writes the Gherkin scenarios on your team, and what happens when they drift from the real behaviour?

What does your current CI/CD pipeline look like, and how do you ensure deployment reliability?

Medium · Technical & Domain Expertise

Approach

Walk the pipeline in order with the tools you actually use: a pull request triggers restore, build and unit tests (for .NET, dotnet build and dotnet test) plus static analysis, and a merge to main produces one versioned artifact or container image.
Explain build once, deploy many: the same artifact is promoted through test or staging to production with only configuration changing, so what was tested is what ships. Say where secrets live (a vault or the CI system's secret store, never the repository).
Name the reliability controls: integration and smoke tests after each deploy, a rollout strategy such as blue-green or canary, feature flags that separate deploying code from releasing a feature, and a rollback path you have actually exercised.
Cover database changes, the usual reason a rollback fails: backward-compatible migrations using expand and contract, so the old and new application versions can both run against the schema during the rollout.
Back it with numbers, for example the four DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore service), and one incident the pipeline caught or missed and what you changed afterwards.

Follow-up

A release passed every stage and still broke production: how do you detect it and what is your first action?
How do you stop a slow or flaky test suite from blocking every merge?
How would you roll back a release that included a schema change?

Can you explain your approach to C# and OOPS (Object-Oriented Programming) concepts?

Medium · Technical & Domain Expertise

Approach

Define the four principles through C# mechanics rather than textbook phrases: encapsulation (private state behind properties and methods that protect invariants), abstraction (interfaces and abstract classes), inheritance (one base class, any number of interfaces) and polymorphism (virtual/override and interface dispatch).
Know the distinctions that tend to follow: abstract class versus interface (state and constructors versus a contract; default interface methods exist since C# 8), override versus new (new hides the member, so a call through a base-class reference still runs the base version), sealed, and access modifiers including internal and protected internal.
Show design judgement: prefer composition to deep hierarchies, and tie SOLID to code you wrote, such as a class that depends on an injected IEmailSender interface (dependency inversion) so a fake can replace it in tests.
Cover type-system basics: class is a reference type, struct a value type copied on assignment, records (C# 9) give value-based equality and concise immutable types, and a mutable struct stored in a collection is a common source of bugs.
Have a small model you can sketch live, and name where you would refuse inheritance, for example Square deriving from a mutable Rectangle, which breaks the Liskov substitution principle.

Follow-up

When would you still choose an abstract class over an interface?
How do transient, scoped and singleton lifetimes differ in .NET dependency injection, and what goes wrong if a singleton holds a scoped service?
What is IDisposable for, and why is the using statement needed when there is a garbage collector?

What have you been working on recently, and what technical challenges did you overcome?

Medium · Technical & Domain Expertise

Approach

Pick one recent project where you owned a meaningful part, and open with the context in a sentence or two: what the system does, who uses it, your role and the stack (C#, testing, CI where they apply).
Spend most of the answer on one hard technical problem: the symptom, how I diagnosed it (logs, a profiler, a failing test that reproduced it), the options I weighed and why I chose one.
Quantify the outcome and the cost: latency, error rate, release frequency or time saved, plus what the trade-off left behind, such as technical debt or a known limitation.
Be ready to sketch the architecture and go one level deeper on any component; say 'I' for your own work and credit what teammates did.
Finish with what you would change if you did it again, which shows reflection without undermining the result.

Follow-up

Why did you choose that approach over the alternative you mentioned?
How did you test the fix, and how did you confirm it worked in production?
What would fail first if the load on that system grew tenfold?

Tell us about yourself and your career journey.

Medium · Situational & Career Motivation

Approach

Use a present, past, future structure: your current role and stack, two or three earlier steps that explain how you got there, and why this role is the logical next move.
Choose details that match what candidates report this role asks for: C# and OOP, test-first practice, CI/CD, agile teamwork, plus one concrete achievement with a number attached.
Give a short spoken summary rather than your CV line by line, and leave hooks (a project, a migration, a difficult bug) that invite the next question.
Rehearse it aloud until it sounds natural, and drop personal history that does not connect to your engineering work.

Follow-up

Which of those roles taught you the most, and why?
Tell me more about the project you mentioned.
Why are you looking to move now?

Why did you decide to transition into software engineering?

Medium · Situational & Career Motivation

Approach

Name a concrete trigger: a task you automated, a course you took, a problem in your previous field that code solved. Avoid a vague 'I always liked computers'.
Show how you built the skills deliberately: languages learned (C# if it applies), projects shipped, tests and CI in your own repositories, code reviews you received and acted on.
Turn the earlier career into an asset: domain knowledge, stakeholder work and explaining technical ideas to non-technical people, which candidates report among the requirements for this role.
Be candid about gaps and how you are closing them, for example data structures and complexity analysis. If you never switched careers, answer the spirit of the question: how you came into engineering and what keeps you there.

Follow-up

What was the hardest part of the switch technically?
How have you covered what a computer science degree would have taught you?
What from your previous field do you still use day to day?

What made you choose this job and BGL Management in particular?

Medium · Situational & Career Motivation

Approach

Answer the two halves separately. For the job, point to the role as candidates describe it: maintaining and extending existing platforms, building new customer-facing features, working with product managers and QA, code review and agile ceremonies.
For the company, use what you found in your own research and say why it matters to you personally; do not invent facts or offer generic praise.
Show that you compared options: what this role offers that others did not, such as a C# codebase with test-first practice and a CI/CD pipeline you would work in.
Keep it consistent with your answers on why you want to join and where you see yourself in five years, since the three questions overlap.

Follow-up

Which part of this job do you expect to enjoy least?
What would you want to learn first after joining?
If you had two offers, how would you decide between them?

One customer endpoint stalls deliveries to every other destination

Medium · bulkhead · timeouts · saturation

The egress service delivers about 1.5k webhooks/second across 40,000 destinations, with a per-destination concurrency cap of 4 and a 10-second connect-plus-read timeout. Throughput falls to 300/second, queue depth climbs, and p99 delivery latency for unaffected destinations goes from 200 ms to minutes, while the error rate barely moves. One tenant holds 900 destination rows whose URLs share a hostname that now answers in 9.5 seconds. Explain the mechanism with the arithmetic, then give the containment in the order you would apply it.

Approach

Look at saturation before errors. A flat error rate with collapsing throughput says nothing is failing, things are waiting, so the first signal to pull is in-flight request count or pool wait time rather than the error counter. This is the distinction that decides the whole investigation.
Group in-flight work by resolved host, not by destination id. The cap is keyed per destination row, so 900 rows sharing one hostname buy 3,600 concurrent slots against a single host, each held for 9.5 seconds. The bulkhead was never a bulkhead for that host, and grouping by the wrong dimension is why the dashboard looked healthy.
Do the arithmetic in both directions. Required concurrency is arrival rate times latency, so 1.5k/second at 200 ms needs about 300 in flight, which is entirely consumed by 3,600 slow slots; conversely whatever concurrency is left sustains rate equals concurrency divided by 9.5 seconds, which is the 300/second you are seeing. Matching both numbers is what promotes this from a plausible story to the mechanism.
Explain why the circuit breaker never helped. It opens on consecutive failures, and a 9.5-second response inside a 10-second timeout is a success. Slow is not failing, so an error-rate breaker cannot see this; you need a slow-call ratio, a deadline propagated from the caller's remaining budget, or a concurrency limiter.

Follow-up

The host recovers to 80 ms. How long does the queue take to drain, and what does the drain do to the recovered host?
Where should the 10-second timeout number actually come from?

Suggested practice checklist

The plan follows the reported loop: confirm the assessment format, build C#, OOP, TDD/BDD and CI/CD answers with real examples, rehearse coding aloud, then spend the last days on influence stories and the motivation narrative.

Day 1 — Map the loop and confirm the format

Write the three reported rounds in order (telephone screen, technical assessment, face-to-face or virtual interviews) and next to each, the reported questions that fit it best.
Email the recruiter to ask whether the technical assessment is a take-home or a pair-programming session and what you may use in it.
List the reported stack (C#, OOP, TDD or BDD, CI/CD, agile) and mark your weakest two.

Deliverable: A one-page loop map, the sent recruiter question and a ranked list of weak stack areas.

Day 2 — C# and object-oriented design

Write a short C# example each for encapsulation, inheritance versus composition, interface versus abstract class, and polymorphism.
Walk through the SOLID principles using one class you have refactored, naming the principle each change served.
Answer aloud the reported question about your approach to C# and OOP, then re-record it shorter.

Deliverable: A code file with four OOP examples and a two-minute spoken answer.

Day 3 — TDD and BDD in practice

Solve a small kata in C# test-first, committing at red, green and refactor, so the history shows the cycle.
Write three Given/When/Then scenarios for a feature you have shipped, as you would with Product and QA.
Answer aloud the reported question on applying TDD and BDD daily, using the kata and scenarios as evidence.

Deliverable: A kata repository with a red-green-refactor commit history, a scenarios file and a spoken answer.

Day 4 — CI/CD and deployment reliability

Diagram the pipeline you use today: stages, gates that block a merge, artifact versioning, deployment steps and rollback.
Write a failed-deployment story: cause, detection, fix and the change you made so it would not recur.
Answer aloud the reported question about your CI/CD pipeline and how you ensure reliability.

Deliverable: A pipeline diagram, a written failure story and a spoken answer.

Day 5 — Pair-programming and take-home rehearsal

Do the redelivered event batch problem, then add a README with assumptions and a trade-offs note as you would for a take-home.
Prepare your answer on your recent work and a refactoring plan for a legacy module, starting with characterization tests.

Deliverable: Two solved problems with tests, one README with trade-offs and a written refactoring plan.

Day 6 — Influence and decision stories

Write two STAR stories, one about convincing someone of a technical decision and one about using influence without authority, including the evidence and the result.
Write a third story on a technical disagreement with a peer and a fourth on learning a technology quickly under a deadline.
Write and rehearse a structured five-year answer tied to the work in this role.

Deliverable: Four STAR outlines and a rehearsed five-year answer, each under two minutes.

Day 7 — Motivation narrative and full mock

Write the career story and the reasons you moved into software engineering, using the same facts you will use for why this company.
Write your reasons for choosing BGL Management and this job after reading its public material, and prepare three or four questions for interviewers.
Run a full mock: career story, motivation, one technical answer from each earlier day and one STAR story, back to back.

Deliverable: A written motivation narrative, a question list for interviewers and one recorded mock run to review.

Influence, motivation and career story

Reported behavioral questions focus on influence, motivation and career story. Reported example scenarios for the final round add peer disagreement, learning quickly under a deadline and shifting priorities in an agile team. Prepare a small set of STAR stories (candidates are told three to five) that you can adapt, and keep your motivation answers consistent.

Why do you want to join BGL Management?
Describe a disagreement with a peer over a technical approach and how it ended.
Describe learning a new technology fast to meet a deadline.

Give an example of a time you had to convince someone of a technical or strategic decision.

Medium · Behavioral & Leadership

Approach

Pick a decision where you had a real alternative and a counterpart who disagreed or was unsure, for example adding an automated test layer before a risky refactor, moving a manual release step into the pipeline, or choosing one library over another. A story where nobody disagreed shows no persuasion.
Use STAR with the weight on Action: state the situation and your stake in two sentences, then spend most of the answer on what you did to convince them. Name the concern they had, and show you addressed that concern rather than just repeating your view.
Show your evidence: a spike or prototype, a before-and-after measurement, defect or incident data, or a cost comparison. Say what the numbers were and how you presented them to a non-technical stakeholder if that was the audience.
Close with the result and one lesson: what was adopted, what changed measurably afterwards, and what you would do differently. The mistake that sinks this answer is describing how right you were and how the other person came round, with no sign you understood their position.

Follow-up

What if they had still said no? What was your fallback?
Which part of their objection turned out to be correct?
How did you check afterwards that the decision was the right one?

Tell us about a situation where you had to use your influence to achieve a specific outcome.

Medium · Behavioral & Leadership

Approach

Choose a situation where you needed an outcome from people you did not manage: a Product Manager, a QA lead, another team or a senior engineer. Influence stories that rest on rank or on escalation to a manager do not answer the question.
Start by showing you understood the other side: what each person cared about, such as delivery date, risk of regressions or workload. Explain how you framed your request in terms of that interest rather than your own preference.
Describe the concrete moves: a short pilot or proof of concept, a one-page summary, pairing with a skeptic, getting one early ally, or making the change easy to adopt. Say what you did first and why, so the order of your actions is clear.
State the specific outcome you achieved and how you know it was your influence (a changed process, a shipped fix, an agreed standard). Keep the pronoun 'I' for your actions and name teammates' contributions fairly. The common failure is a vague outcome such as 'everyone agreed' with no result.

Follow-up

What would you have done if the key person had refused to engage?
How did you keep the relationship intact afterwards?
How is this different from persuading someone you manage?

Where do you see yourself in the next five years?

Medium · Behavioral & Leadership

Approach

This is a direction question, not a STAR story. Use a three-part structure: where you are now, the skills you want to deepen over the period, and the kind of impact you want to be having at the end of it.
Anchor the answer to the work the role reports. For this job that means full-lifecycle delivery, C# and object-oriented design, testing and CI/CD practice, code reviews and mentoring juniors. Pick one or two of these as the growth path, such as becoming the person who raises the quality of a team's tests and releases, or growing into a senior engineer others learn from.
Be honest about the technical-versus-management question, and answer it with a preference and a reason rather than a dodge. Either path is fine if the reason is concrete, for example 'I want to deepen architecture skills before I take on more people responsibility'.
Avoid naming a specific title or employer, saying you have no plan, or giving a path that does not involve this job. Close by tying the five-year view back to why this role is a sensible next step.

Follow-up

What would you need to learn in the first year to move in that direction?
What if the available path pushed you away from hands-on engineering?
What would make you stay in this role for longer than five years?