Celestar Software Engineer Interview Guide

The 60-second brief

Candidates describe the Software Engineer work at Celestar as program work inside the SOUTHCOM EDA (Enterprise Data Analytics) environment, which supports defense and government missions. The engineering covers the platforms that move data streams through processing, protect them and present them in web interfaces. Reports list several sub-specialties under the Software Engineer title: Cloud Engineer, Kubernetes Engineer, IAM Engineer, Cloud Web Developer and Help Desk Support Engineer. Day to day, candidates describe keeping the analytics platforms working and secure, maintaining the data pipeline and the web front ends, monitoring system health, handling routine maintenance, closing vulnerabilities, turning stakeholder needs into technical specifications and writing documentation for code and designs. The team is described as remote and distributed.

This guide is for candidates interviewing for a Software Engineer position at Celestar, whichever sub-specialty the posting names (cloud, Kubernetes, IAM or web development). It covers the four reported rounds, the technical and behavioral questions candidates report, how to answer the behavioral ones in detail, and a seven-day plan. Check your posting to see which technologies it stresses, then weight the plan toward them.

Candidates report four rounds spread over about 3-5 weeks: Technical Screening, Technology Deep Dive, Interaction with Leads and Final Assessment. Clearance requirements and team availability are said to affect the pace.

Focus areas

• IAM (Identity and Access Management)
• Monitoring and Oversight
• Kubernetes

Overview

The reported question set splits cleanly into two halves. The technical half is about operating systems rather than writing algorithms: cost versus performance in cloud-native environments, securing an identity management architecture, troubleshooting a failed Kubernetes deployment, high availability and disaster recovery for cloud web applications, and balancing fast feature delivery against federal compliance. The behavioral half covers explaining a technical concept to a non-technical stakeholder, taking the initiative on technical debt, working productively in a remote asynchronous setup, and changing technical direction when requirements shift. Prepare both halves with the same discipline: a fixed structure, a concrete example from your own work, and a stated trade-off.

The topics candidates associate with the loop are IAM, Monitoring and Oversight, Kubernetes, Container Orchestration and Cloud Infrastructure Engineering. Reports mention Terraform and CloudFormation for infrastructure as code, AWS and Azure as the cloud providers to be ready to discuss, and CI/CD experience as a plus. Example scenarios that candidates quote include designing a secure, multi-region cloud architecture for a data-intensive application and migrating a legacy application to a cloud-native environment. Practise drawing both, since reports say you may be asked to share your screen to walk through code or architecture diagrams.

Two points shape how you should answer. First, the roles list the ability to obtain and maintain security clearances as a requirement, and the technical questions keep returning to security and compliance, so every design answer should name how access is limited, how data is protected and how changes are recorded. Second, documentation and written status updates are described as part of the job, which makes your stories about handoffs, runbooks and early blocker reports as useful as your technical stories. Whether a coding test appears depends on the specific role, so keep a short design walk-through and some practice coding in reserve.

The Celestar interview process

The four rounds below are the stages candidates describe, in the order they report them. Reports add that earlier stages lean on your resume and core competencies and later ones on technology deep dives and scenario-based assessments.

Technical Screening

Candidates describe the Technical Screening as an initial assessment of your baseline skills, and reports add that the early rounds work from your resume and core competencies. Expect the conversation to follow the technologies you list for the sub-specialty you applied to, whether that is cloud, IAM, Kubernetes or web development. The way to approach it is to be able to say, for every tool on your resume, what you built with it, what went wrong and what you would change now.

What to demonstrate

• Baseline competence in the domain named in the posting: cloud, IAM, Kubernetes or web development
• How precisely you can describe the work listed on your resume
• Whether your experience matches the stack the role names

How to prepare

• Write a tool inventory from your resume with one concrete decision or incident per technology, including AWS or Azure services you have used
• Rehearse short versions of the cloud cost-versus-performance story and the identity-security answer so they hold up without notes
• Read your posting and mark which of cloud, IAM, Kubernetes or web development it stresses, then rank your resume items by that

Technology Deep Dive

The Technology Deep Dive is reported as in-depth discussion of your experience with specific technologies such as Kubernetes or cloud infrastructure. This is the stage where the operational questions fit: a failed Kubernetes deployment, high availability and disaster recovery for a cloud web application, and securing identity management. Approach it as a walk through real systems you ran, giving the component choices, the failure modes and the trade-offs, rather than a tool tour.

What to demonstrate

• Depth of hands-on experience with Kubernetes, container orchestration or cloud infrastructure
• Ability to explain why a technology suited a particular architecture, not only how it works
• Working knowledge of infrastructure as code, monitoring and least-privilege access

How to prepare

• Write a fixed debugging sequence for a failed Kubernetes rollout, from the rollout status and pod events through logs, image and configuration, to permissions and quotas
• Outline a high availability and disaster recovery design for a cloud web app, stating recovery point and recovery time targets you would choose and what each costs
• Prepare infrastructure-as-code talking points for Terraform or CloudFormation: state handling, environments, review of changes and drift
• Write a least-privilege access model for a data platform covering roles, service identities, encryption at rest and in transit, and audit logs

Interaction with Leads

Interaction with Leads is described as time with technical leads and project managers, where you show how you work through a problem. Because project managers are present, expect the discussion to cover scope, delivery pressure and compliance as well as technology. Approach it by narrating a problem from symptom to decision aloud, naming the options you rejected, and by having a clear answer on balancing rapid feature delivery against federal compliance requirements.

What to demonstrate

• Your problem-solving process as you narrate it
• Communication with both technical leads and non-technical project managers
• How you weigh delivery speed against compliance constraints

How to prepare

• Build the stakeholder-explanation story with a decision at the end of it, and a plain-language version of a concept such as recovery objectives or least privilege
• Write a decision rule for compliance versus speed: which checks run automatically in the pipeline, which need sign-off, and what you document
• Practise thinking aloud on one past incident: symptom, hypotheses, what you checked first and why, and the fix

Final Assessment

The Final Assessment is reported as a comprehensive evaluation of whether you can handle the complexity of the SOUTHCOM EDA environment, and reports say later rounds can include technical deep dives or scenario-based assessments. Depending on the role, candidates also mention a technical assessment or a design problem. Approach it with two rehearsed scenario designs, a diagram you can share on screen, and behavioral stories that cover technical debt, remote work and changing requirements.

What to demonstrate

• Ability to handle scenario-based problems that combine architecture, security and operations
• Ownership and initiative, shown through your technical debt and workflow stories
• Readiness for remote, distributed work, including documentation and status communication

How to prepare

• Sketch a secure, multi-region architecture for a data-intensive application and a migration plan for a legacy application to a cloud-native environment, each with its trade-offs written beside it
• Keep one architecture diagram and one code snippet from your own work ready to share and explain on screen
• Prepare the technical debt, remote workflow and changing-requirements stories in full, with the measured result for each
• Write two questions to ask the team about how it balances security requirements with delivering changes

Where candidates lose points

Describing cloud-native experience in general terms, with no environment, no target and no numbers for the cost-versus-performance trade-off

Prepare one named environment with its service-level target, the decision you made, the two quantities you traded and how you measured them. State the direction and method if you cannot recall exact figures.

Answering the identity-security question with a list of products instead of an access model

Walk through the model: who gets which role, how service identities and short-lived credentials work, how access is reviewed and revoked, what is encrypted and what is logged. Then name the tools that implement each part.

Treating a failed Kubernetes deployment as a guessing game of restarts and rollbacks

Memorise a fixed order: what changed, rollout and pod status, events, logs, image and configuration, secrets and permissions, resource quotas, then the cluster. Say what each step rules out and how you would confirm the cause.

Framing compliance as friction to be worked around when asked how to balance it with fast delivery

Describe compliance checks as part of the pipeline and the release process: automated policy checks, recorded approvals and documentation kept with the change. Then say what you would still slow down and why.

Giving remote-work and ownership answers that contain no evidence, such as written updates, runbooks or blockers raised early

Bring concrete artifacts: a status note you sent, documentation you wrote, a blocker you reported before it cost time. Tie each to a result.

Questions & practice

How do you manage your workflow and stay productive while working in a fully remote, asynchronous environment?

Medium · Behavioral & Problem-Solving

Approach

1. Describe a concrete system, not a list of tools. Explain how you take on work (tickets with acceptance criteria), when and where you post written status (done, next, blocked), and where decisions live (design docs or decision records) so a teammate can catch up without a meeting.
2. Show that you raise blockers early: name the blocker, make a specific ask, and say what you will do by default if nobody answers by a set time. Also say how you use the hours you overlap with teammates.
3. Treat documentation as part of done: runbook and README updates ship with the change, and handoff notes are good enough that someone in another time zone can continue the work.
4. Anchor it in one real example with an outcome, such as an async handoff that kept a deploy or an incident moving overnight. If a past role restricted which systems information could pass through, say how you kept communication inside them.
5. Avoid the answers that sink this question: a generic list of chat and ticketing apps with no story, or one that implies you need frequent check-ins to stay on track.

Follow-up

• How do you decide when a written thread should become a call?
• Tell me about a time an async update was misread. What did you change afterwards?
• How do you keep a teammate in another time zone unblocked on work that depends on yours?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

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

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

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

1. Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
2. Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
3. Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
4. Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

• The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
• A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

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

1. 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.
2. 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.
3. 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.
4. 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 approach securing an identity management architecture in a high-security, government-adjacent envir

Medium · Technical & Domain Expertise

How do you approach securing an identity management architecture in a high-security, government-adjacent environment?

Approach

1. Start from one authoritative identity provider and federate everything to it over SAML 2.0 or OIDC, so no application keeps its own password store. Require phishing-resistant MFA (PIV/CAC smart cards or FIDO2/WebAuthn keys) rather than SMS or push codes.
2. Enforce least privilege with role- or attribute-based access, and replace long-lived keys with short-lived credentials: AWS STS AssumeRole, Azure managed identities, Kubernetes workload identity. Grant admin rights just in time, with an approval step and an expiry, never as standing access.
3. Automate the joiner-mover-leaver lifecycle: SCIM provisioning driven by the HR source of record, deprovisioning that revokes active sessions as well as accounts, and periodic access reviews that remove unused entitlements.
4. Protect the identity plane itself. Keep token-signing keys in an HSM or KMS, keep access-token lifetimes short and rotate refresh tokens, validate issuer, audience and signature on every token, and give admins separate tiered accounts plus monitored break-glass accounts.
5. Send every authentication and authorization event (CloudTrail, Entra ID sign-in and audit logs) to append-only central storage and a SIEM, with alerts for privilege escalation and anomalous sign-ins. Map each control to the NIST SP 800-53 AC, IA and AU families so you can show assessors the evidence.

Follow-up

• How do services and pods authenticate to cloud APIs without static secrets?
• If the identity provider is down, how do break-glass accounts work without becoming a permanent backdoor?
• A session token is stolen from a laptop. How do you detect it and revoke it everywhere?

What strategies do you use to ensure high availability and disaster recovery for cloud-based web applications?

Medium · Technical & Domain Expertise

Approach

1. Set RTO and RPO per service tier before you pick any technology, because they decide the DR pattern: backup and restore, pilot light, warm standby or multi-site active-active. Cost and complexity rise in that order, and RTO falls.
2. Within one region, run the stateless tier across at least two availability zones behind a load balancer with health checks, using autoscaling groups or Kubernetes replicas with topology spread constraints. Give the database a synchronous standby in another zone (RDS Multi-AZ or zone-redundant Azure SQL) so a zone failure loses no committed data.
3. Across regions, replication is usually asynchronous, so RPO is greater than zero; say so plainly. Use cross-region read replicas or storage replication, DNS or global load-balancer failover with health checks (Route 53, Azure Front Door or Traffic Manager), and keep the infrastructure in Terraform or CloudFormation so the standby region can be rebuilt.
4. Look for single points of failure beyond compute: DNS, the identity provider, secrets and KMS keys, the container registry and the CI/CD pipeline all have to work in the recovery region. Copy backups to another account and region with versioning or object lock, so ransomware or a compromised admin account cannot delete both copies.
5. Prove it with scheduled failover exercises and restore tests that measure the RTO and RPO you actually achieve, keep a runbook for both failover and failback, and guard against split-brain by fencing the old primary before you promote the new one.

Follow-up

• If both regions accept writes, how do you resolve conflicting updates?
• How would you show that last night's backup actually restores, and how long the restore takes?
• Budget allows only pilot light, not warm standby. What do you give up, and how do you explain that to the business?

How do you balance the need for rapid feature delivery with the strict compliance requirements inherent in fed

Medium · Technical & Domain Expertise

How do you balance the need for rapid feature delivery with the strict compliance requirements inherent in federal contracts?

Approach

1. Move the controls into the pipeline so compliance evidence is produced on every commit, not gathered at the end: SAST, dependency and container image scanning, IaC scanning (for example Checkov or tfsec), an SBOM and signed artifacts, with the build failing on policy violations above an agreed severity.
2. Prevent violations instead of auditing for them afterwards: admission control in Kubernetes (OPA Gatekeeper or Kyverno), cloud guardrails (AWS SCPs and Config rules, Azure Policy), and hardened base images built to DISA STIG or CIS benchmarks, so the fast path is also the compliant path.
3. Sort changes by security impact. Routine application changes go through the normal pipeline. Changes to the authorization boundary, data flows, authentication or encryption get a security impact analysis and review before release, which keeps the slow path for the few changes that need it.
4. Get the audit trail as a side effect of the work: every deploy traces to a ticket, an approved pull request and stored scan results, and branch protection enforces separation of duties because the author cannot approve their own merge.
5. Name the trade-off and how you reduce it. Small batches and feature flags let code ship dark and switch on after review. A documented expedited path handles urgent security patches, with the review completed afterwards.

Follow-up

• A high-severity CVE appears in the base image the day before a release. What do you do?
• Scanner false positives start blocking every build. How do you tune the scanner without weakening the control?
• How would you show an assessor that a control works continuously rather than only on audit day?

Describe your process for troubleshooting a failed deployment in a Kubernetes cluster.

Medium · Technical & Domain Expertise

Approach

1. Mitigate first, then diagnose. Use kubectl rollout status and kubectl rollout history to confirm which revision failed, and run kubectl rollout undo if users are affected. A Deployment that passes progressDeadlineSeconds (600 by default) is marked ProgressDeadlineExceeded but is never rolled back automatically.
2. Run kubectl get pods and sort the failures by state. Pending points to scheduling: insufficient CPU or memory, taints, node selectors or an unbound PVC, all visible in the Events section of kubectl describe pod. ImagePullBackOff or ErrImagePull means a wrong tag, registry auth or a missing imagePullSecret. CreateContainerConfigError means a missing ConfigMap or Secret key.
3. For CrashLoopBackOff, read kubectl logs --previous to see the crashed container's output, then check lastState.terminated: exit code 137 is SIGKILL, and a reason of OOMKilled means the memory limit is too low. Exit code 1 usually means the application failed at startup, often on bad config or an unreachable dependency.
4. If pods are Running but not Ready, the readiness probe is failing: check the probe's path, port and timing, and add a startupProbe for slow boots. If pods are Ready but traffic still fails, run kubectl get endpoints to see whether the Service selector matches the pod labels, then check NetworkPolicy and service-account RBAC.
5. Close by diffing the failed manifest against the last good revision (Git history, helm diff or the GitOps tool), sorting events with kubectl get events --sort-by=.lastTimestamp, and naming one guardrail you would add, such as image-tag pinning or a pipeline check.

Follow-up

• The pod is OOMKilled only under load. How do you set its requests and limits?
• The container image has no shell. How do you inspect it (for example with kubectl debug and an ephemeral container)?
• The rollout is stuck with half old and half new pods. What do maxSurge and maxUnavailable do in that state?

Suggested practice checklist

The plan follows the reported rounds: access security and Kubernetes first, then cloud availability and compliance, then the behavioral stories, and a final run that adds a reserve for a coding or design assessment.

Day 1 — Map the loop and your sub-specialty

• Write the four reported rounds in order and note what each is described as covering.
• Read your posting and mark whether it stresses cloud, IAM, Kubernetes or web development.
• Build a tool inventory from your resume with one concrete decision or incident per technology.

Deliverable: A one-page loop map and a resume tool inventory ranked by relevance to the posting.

Day 2 — Identity and access architecture

• Write a least-privilege access model for a data analytics platform: roles, groups, service identities, short-lived credentials, access review and audit logging.
• List encryption at rest and in transit controls and where keys are managed.
• Answer the question on securing an identity management architecture in a high-security, government-adjacent environment aloud, then tighten it.

Deliverable: A written access model and a spoken identity-security answer.

Day 3 — Kubernetes failures and monitoring

• Write your debugging sequence for a failed Kubernetes deployment and what each step rules out.
• Break a deployment on a local cluster in three ways (bad image, failing probe, missing secret) and diagnose each with your sequence.
• List the signals and alerts you would use to watch a cluster and its workloads.

Deliverable: A debugging checklist tested against three deliberately broken deployments, plus a monitoring list.

Day 4 — Cloud availability, disaster recovery and infrastructure as code

• Outline a high availability and disaster recovery design for a cloud web application, with recovery targets and their costs.
• Sketch a secure, multi-region architecture for a data-intensive application.
• Outline a migration plan for a legacy application to a cloud-native environment and note your Terraform or CloudFormation structure.

Deliverable: Two architecture sketches and a migration outline, each with a written trade-off list.

Day 5 — Compliance with delivery speed, and remote workflow

• Write how you would build compliance checks into a CI/CD pipeline and what still needs human approval.
• Answer the rapid-delivery-versus-federal-compliance question aloud, using a decision rule.
• Write your remote, asynchronous workflow answer with real examples: status updates, documentation and handling blockers.

Deliverable: A pipeline-with-checks outline and two spoken answers, one on compliance and one on remote workflow.

Day 6 — Build four stories

• Write structured outlines for the cost-versus-performance, stakeholder-explanation, technical debt and changing-requirements stories.
• Add a measured result and a written artifact to each outline.
• Say each story aloud and cut anything that does not show your own decision.

Deliverable: Four story outlines, each with a decision, a result and a document or message it produced.

Day 7 — Full run and assessment reserve

• Solve the idempotency fingerprint and the overlapping job attempts practice questions as reserve for a technical assessment.
• Run a full mock with a screen share of one architecture diagram.
• Write the two questions you will ask the team.

Deliverable: Two solved practice problems, a recorded mock run and your two questions.

Stories to prepare for Celestar

Candidates report behavioral prompts about explaining technical ideas to non-technical people, taking the initiative on technical debt, staying productive in a remote asynchronous setup and changing technical direction. Reports also say technical leads and project managers join one stage, so choose stories that show your decisions and your written communication.

1. How do you manage your workflow and stay productive while working in a fully remote, asynchronous environment?
2. Tell me about a time you spotted a blocker early and reported it before it delayed the work.

Explain your experience managing cloud-native environments and the trade-offs you have made regarding cost ver

Medium · Technical & Domain Expertise

Explain your experience managing cloud-native environments and the trade-offs you have made regarding cost versus performance.

Approach

1. Choose one environment you actually ran and open with its shape: the provider (AWS or Azure, for example), the workloads, and the service-level target you were held to. Without that target, a cost-versus-performance trade-off has no anchor.
2. Describe one specific decision, such as right-sizing instances, setting autoscaling minimums, choosing on-demand versus committed capacity, tiering storage, or adding a cache instead of a larger database. Give the two quantities you traded, for example monthly spend per environment against p95 latency or error rate.
3. Say how you measured before and after: tagged cost reports, a load test, dashboards. Use only real numbers from your work, and if you cannot recall one, state the direction and the method instead of inventing it.
4. Name what you refused to trade away. In a regulated setting, encryption, logging retention and redundancy usually set a floor under any saving, and saying so shows you treat cost as constrained optimisation.
5. Close with what keeps the saving from eroding: budget alerts, cost tags, a scheduled review or infrastructure-as-code defaults. The common mistake is a cost-cutting story with no performance guardrail, or a performance story with no mention of what it cost.

Follow-up

• How did you decide how much capacity to commit to in advance when your usage forecast was uncertain?
• If the latency target had been cut in half, what would you have changed first, and what would it have cost?
• How did you make sure the saving held up after the original change?

Tell me about a time you had to explain a highly technical concept to a non-technical stakeholder.

Medium · Behavioral & Problem-Solving

Approach

1. Pick a concept that had a decision attached, such as why a release was rolled back, what recovery objectives mean for a budget, or why one person's access request was refused. A story with no decision at the end has no result to show.
2. Start from the audience: who they were, what they needed to decide, and what they already knew. Then say how you translated the concept into their terms, whether cost, risk, schedule or user impact, and which analogy or visual you used.
3. Show that you checked understanding by asking them to restate the trade-off or the next step, and say what you changed when they did not follow.
4. Name what you deliberately left out and the risk of leaving it out, then the written follow-up you sent. Written artifacts matter in a remote team, and the answer is stronger when a summary or decision record exists.
5. The mistakes that sink this answer are a story about simplifying vocabulary with no outcome, and a tone that blames the stakeholder for not understanding.

Follow-up

• How did you know the stakeholder understood, and what did you do when they did not?
• What did you leave out on purpose, and what risk did that leave?
• What would you do if the stakeholder pushed for something that broke a security requirement?

Describe a situation where you identified a significant technical debt issue and took the initiative to resolv

Medium · Behavioral & Problem-Solving

Describe a situation where you identified a significant technical debt issue and took the initiative to resolve it.

Approach

1. Choose debt whose cost you can show: repeated failed deployments, hand-edited infrastructure that drifted from its code, unpatched dependencies, or missing documentation that slowed every new engineer. Say how you spotted it and what it was costing in incidents or lost time.
2. Explain why it was yours to act on without being asked, then how you got time for it: you sized the work, split it into small increments, and agreed with whoever owned the schedule what would slip.
3. Describe how you kept the change safe: tests or a baseline captured first, a staged rollout or canary, a way to roll back, and review by a teammate. A solo, unreviewed cleanup is a weak story in a regulated setting.
4. Give the measured result and the artifact left behind, such as fewer failed deployments, a runbook, or an infrastructure template. Include what you chose not to fix.
5. The failure to avoid is calling a rewrite you wanted debt. The answer works when the cost was visible before you started.

Follow-up

• How did you convince your manager or product owner to spend time on it?
• How did you decide what to leave unfixed?
• What could the change have broken, and how did you contain that risk?

Give an example of a time you had to pivot your technical approach due to shifting project requirements.

Medium · Behavioral & Problem-Solving

Approach

1. State the original requirement and the specific change that forced the pivot, such as a different data source, a new access rule or a changed deployment target. Then say what you had already built.
2. Explain how you made the decision: what you would keep, what you would discard, and how you avoided letting sunk effort drive the choice. Compare extending the existing design with changing direction, and say which criteria decided it.
3. Describe how you told stakeholders about the cost to the schedule, with options rather than just a delay, and how you checked that the new requirement was stable before building on it.
4. Say what you changed so the next shift would be cheaper: parameterised configuration, clearer module boundaries or an interface in front of the volatile part.
5. The mistake is a pivot story with no technical content, or one that claims no cost. State plainly what the change cost and what it saved.

Follow-up

• Looking back, what would you have built differently if you had known the requirement would change?
• How did you tell stakeholders about the schedule impact?
• How did you decide to change direction instead of stretching the existing design?