Bluestaq Software Engineer Interview Guide

The 60-second brief

Candidates describe Bluestaq as a company building software for national security, defense and space customers. The product named in their reports is the Unified Data Library (UDL), a platform that brings many data sets together to support decisions in space and government operations. The Software Engineer role in this guide covers cloud automation, platform reliability and application features, so the work sits on both sides of the line between writing a service and running it on Kubernetes and AWS.

This guide is for Software Engineer candidates, whether the team is generalist, platform or DevOps-leaning. It covers the three reported rounds, the five technical and four behavioral questions candidates report, the infrastructure topics they say come up (Kubernetes, AWS, CI/CD, Terraform, incident response), and a seven-day plan that turns those into practice sessions.

Candidates report three rounds over roughly 3-5 weeks: a recruiter screening, a series of technical interviews with engineering teams, and a leadership interview.

Focus areas

• Kubernetes (EKS / cluster operations)
• CI/CD Pipelines
• AWS

Overview

The role as candidates describe it is full-lifecycle: you take a medium-sized feature from design through implementation and follow-up, operate the Kubernetes and AWS environment it runs in, improve code quality through reviews and pair programming, and join an on-call rotation where Grafana and traces are the tools for finding out what is wrong. Preparing for only the coding half or only the infrastructure half leaves a gap, because the reported questions cover both.

The reported technical questions run from small language-level ideas to operations. Expect to name a favorite data structure and defend the choice, describe the parts of a Java EE queue, separate an instance variable from a local variable, explain how you would manage Kubernetes clusters with resource limits and networking, and describe a CI/CD pipeline with multi-stage builds and security scanning. Beyond those, candidates mention microservices, event-driven designs, single-page-application patterns, Terraform, testing strategy and incident response. Nice-to-have items they list are Terragrunt, Argo CD or similar GitOps tooling, and experience in regulated environments.

Because the reported material is conversational rather than a puzzle set, the winning habit is explaining why. For every technology on your resume, be ready to say what problem it solved, what you rejected, and what it cost you. Rehearse two operational stories in particular: a latency spike on a Kubernetes cluster and a deployment that failed in production, since candidates give both as example scenarios.

The behavioral side is short and personal: your background, something you are not good at, why Bluestaq, and the daily work you want. Candidates also say you should be ready to talk about why the defense and space sector appeals to you, and that humility, willingness to learn and a collaborative style matter. Prepare specific, honest answers rather than slogans, and use STAR for project stories.

The Bluestaq interview process

Candidates describe three stages, from a recruiter call through technical interviews to a leadership conversation. The descriptions below reflect what candidates report, not a published process.

Initial Screening

Candidates report that the first stage is a call with a recruiter, used to line up expectations and interest on both sides. They also suggest using early calls to learn about the team and how it works. Treat it as your first chance to deliver a clean background story and to ask questions of your own.

What to demonstrate

• Whether your expectations and interest line up with the role
• How clearly you can summarize your background and your reasons for applying
• Your interest in the defense and space sector, which candidates say to be ready to discuss

How to prepare

• Write a short spoken version of your background that ends on the kind of work you want next, and rehearse it until it sounds natural.
• Prepare a specific answer to why Bluestaq, tied to the Unified Data Library and the Kubernetes and AWS stack candidates mention.
• Bring questions about team dynamics, the on-call burden and how the team balances new features with technical debt.

Technical Deep Dives

Candidates describe a series of technical interviews with engineering teams. The topics they report across the loop include data structures, memory management and scope, microservices and event-driven design, Kubernetes and AWS, Terraform, CI/CD, testing and incident response. The technical questions in this guide are the right practice material for a stage like this, and the emphasis is on reasoning and trade-offs rather than recall.

What to demonstrate

• Technical competency across the engineering topics candidates report
• Whether you can explain the reasons behind your own technical decisions, especially in architecture and infrastructure
• How you handle trade-offs such as performance against maintainability

How to prepare

• Give a spoken answer with a concrete example for each of the five technical questions: favorite data structure, Java EE queue, instance versus local variable, managing Kubernetes clusters, and CI/CD with security scanning.
• Walk through the two example scenarios candidates give: latency spikes in EKS, and a deployment that fails in production. Order your steps from impact check to rollback to root cause.
• For each technology on your resume, write one line on why you chose it, one alternative and one cost.

Leadership Interview

Candidates report a final conversation with leadership that centers on long-term potential and fit with the company's direction. Expect it to feel less like a technical quiz and more like a discussion of where you are heading, so lean on stories that show ownership and judgment.

What to demonstrate

• Long-term potential, as the stage is described
• Alignment between your goals and the company's direction
• Your reasons for wanting this work in this sector

How to prepare

• Rehearse the behavioral questions in this guide: background, a weakness you are working on, why Bluestaq, and your ideal role.
• Prepare a story where you owned a feature from design through follow-up, and one where you helped a teammate through code review or pairing.
• Write two or three questions about the team's current technical challenges and how responsibility grows over time.

Where candidates lose points

Listing Kubernetes, AWS or Terraform on your resume and then answering with commands instead of reasons

For each tool, prepare the decision behind it, an alternative you rejected and a cost you accepted. Candidates say the reasoning behind choices is what gets explored, so rehearse that rather than syntax.

Answering the Kubernetes management question with a list of kubectl commands

Organize the answer around resource requests and limits, namespace quotas, how traffic reaches pods (Services, Ingress) and how network policy restricts it. Say what happens when a limit is too low or too high.

Skipping the Java and language fundamentals because the loop sounds infrastructure-heavy

Candidates report a Java EE queue question and an instance versus local variable question. Prepare crisp definitions with a short code example each, and be able to explain scope and lifetime in memory terms.

Responding to the EKS latency or failed-deployment scenario by restarting things or jumping to a fix

State a sequence: confirm the impact, check what changed recently, roll back if a deploy is the likely cause, read Grafana dashboards and traces, then identify and prevent the root cause.

Giving a generic answer to why Bluestaq that would fit any employer

Tie your answer to the Unified Data Library, the defense and space sector and the Kubernetes and AWS work. Rehearse it aloud so it sounds like your own reasoning.

Questions & practice

Archive a resource graph without breaking live references or recursing

Medium · graph traversal · topological order · tenant isolation

Resources reference other resources within a tenant; for the largest tenant the reference table holds up to 2,000,000 nodes and 8,000,000 edges. Archiving a resource must archive everything reachable from it that nothing outside the set still references, refuse when a live external referrer exists, and terminate when references form cycles, which they legitimately do. Produce the archive order and the refusal list, targeting O(V+E). Say what stops the traversal crossing a tenant boundary, and why recursion is the wrong control structure at this size.

Approach

1. Load the subgraph with the tenant predicate on both endpoints of the edge, not only on the side you started from. Scoping the left table alone is the classic cross-tenant leak: one mis-entered edge then pulls another tenant's resources into the traversal and, worse, into the archive.
2. Traverse iteratively with an explicit stack. A 2,000,000-node graph can hold a chain deep enough to exhaust a native stack in the low tens of thousands of frames, and that failure is a process crash rather than an error you can return.
3. Treat cycles as data rather than corruption: compute strongly connected components with Tarjan in O(V+E) using its own explicit stack, then condense. The condensation is a DAG, so a topological order over it gives the archive order, and every member of a component archives in one transaction because no order within a cycle is valid.
4. Decide refusals with reverse edges. A candidate is archivable only if every in-edge originates inside the candidate set, so build the transpose or count in-degrees restricted to the visited set, and emit each blocked resource with the id of the external referrer, which is the only part of the answer an operator can act on.

Follow-up

• The graph is read in one query and the archive writes a minute later. What can change in between, and how do you make the write safe?
• The candidate set is 400,000 resources. Is that one transaction, and if not, what does a half-finished archive look like to a reader?

Merge partitioned event streams into one ordered feed with bounded lateness

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

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

Approach

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

Follow-up

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

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

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

Approach

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

Follow-up

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

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

What is your favorite software data structure and why?

Medium · Technical & Domain Knowledge

Approach

1. Pick one structure you have used in real work and name it precisely, for example a hash map (java.util.HashMap). Start with the problem it solved for you, such as deduplicating records by key or indexing objects by ID. That way the 'why' rests on use, not on taste.
2. Explain how it works. It is an array of buckets indexed by the key's hash. Collisions are handled by chaining (Java's HashMap) or by open addressing (probing). Since Java 8, a bucket that grows past 8 entries becomes a balanced tree once the table has at least 64 buckets (below that, the table resizes instead). A badly colliding bucket then costs O(log n) instead of O(n).
3. State the costs. get, put and remove are O(1) on average and O(n) in the worst case without trees. Insertion is amortized O(1) despite resizing: Java doubles the capacity when size exceeds capacity x load factor, which defaults to 0.75. Memory is O(n) plus per-entry overhead, and iteration order is unspecified.
4. Compare it with the alternatives. TreeMap gives sorted keys and range queries at O(log n). LinkedHashMap keeps insertion or access order, and its removeEldestEntry gives a simple LRU cache. A plain array is better when keys are dense integers. ConcurrentHashMap is the choice when threads share the map.
5. Name the edge cases. Keys need consistent equals and hashCode. Changing a key after insertion makes its entry unreachable. HashMap allows one null key, while ConcurrentHashMap rejects null keys and values. A weak hash function slows down every operation.

Follow-up

• How would you build an LRU cache with O(1) get and put on top of this structure?
• What goes wrong when two threads write to a plain HashMap at the same time, and what would you use instead?
• For what workload would a sorted map or a heap beat your choice?

Could you describe the core components of a Java EE Queue?

Medium · Technical & Domain Knowledge

Approach

1. Clarify the term first. In Java EE (now Jakarta EE), a queue usually means a JMS (Jakarta Messaging) point-to-point destination, not java.util.Queue. Say which one you are answering and offer to cover the other.
2. List the JMS objects in the order a message travels. A ConnectionFactory (looked up through JNDI or injected) opens a Connection to the provider, a broker such as ActiveMQ or IBM MQ. The Connection creates Sessions. A Session creates a MessageProducer or MessageConsumer bound to a Destination, here a Queue. The payload is a Message with headers, properties and a body (TextMessage, BytesMessage, MapMessage, ObjectMessage, StreamMessage).
3. Explain point-to-point semantics. Each message goes to exactly one consumer even when several consumers compete, which spreads the load; a Topic sends every message to every subscriber instead. In an application server, a message-driven bean consumes the queue through MessageListener.onMessage, and the container manages pooling and transactions. JMS 2.0 added the simpler JMSContext, JMSProducer and JMSConsumer API.
4. Cover reliability. PERSISTENT delivery mode survives a broker restart. The acknowledgement modes are AUTO_ACKNOWLEDGE, CLIENT_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE; a transacted session instead commits receives and sends together. Delivery is effectively at-least-once, so redelivered messages (JMSRedelivered, JMSXDeliveryCount) need an idempotent consumer. Dead-letter queues are set up in the provider, not defined by the spec.
5. If the question means java.util.Queue: add, remove and element throw an exception on failure, while offer, poll and peek return false or null. Implementations include ArrayDeque, LinkedList, PriorityQueue (a binary heap with O(log n) offer and poll) and the BlockingQueue family, whose put and take block. BlockingQueue is the usual producer-consumer handoff between threads.

Follow-up

• How do you stop a message that always fails processing from being redelivered forever?
• How would you make a database write and a message send succeed or fail together (XA transaction versus a transactional outbox)?
• When would you choose a topic with durable subscriptions over a queue?

What is the difference between an instance variable and a local variable?

Medium · Technical & Domain Knowledge

Approach

1. Define both by where they are declared. An instance variable (a field) is declared in the class body outside any method, and each object gets its own copy. A local variable is declared inside a method, constructor or block (parameters count as locals) and exists only while that block runs.
2. Contrast storage and lifetime. A field lives inside its object on the heap until the object becomes unreachable and is garbage-collected. A local lives in the method's stack frame and disappears when the method returns. For a reference-typed local, only the reference sits in the frame: the object is on the heap and can outlive the call if it escapes.
3. Contrast initialisation and modifiers. Fields get default values (0, false, null) and can take access modifiers plus static, volatile and transient. Locals have no default: the compiler rejects any read before definite assignment, and final (plus annotations) is the only modifier allowed.
4. Explain what this means for concurrency. Each thread has its own stack, so locals are confined to one thread. A field on a shared object, such as a singleton service or a servlet, is shared by every request thread. Keeping per-request state in a field of a shared component is a classic race condition; use locals or pass the state as parameters.
5. Mention the related rules. A local with the same name as a field shadows it; use this.name to reach the field. Lambdas and anonymous classes can capture only final or effectively final locals, but they can read and change fields through this. Static (class) variables are a third kind, with one copy per class.

Follow-up

• Why must a local captured by a lambda be effectively final when a field does not have to be?
• Where does an object created inside a method live, and can the JIT avoid the heap allocation (escape analysis and scalar replacement)?
• How does a static variable differ from both in lifetime and thread safety?

Can you explain how you would manage Kubernetes clusters, including resource limits and networking?

Medium · Technical & Domain Knowledge

Approach

1. Separate requests from limits. The scheduler places pods by their requests. A CPU limit is enforced by CFS throttling, so a container over its quota slows down; a container over its memory limit is OOMKilled. Requests and limits together set the QoS class, which decides eviction order when a node runs short. It is Guaranteed when every container's CPU and memory requests equal its limits, otherwise Burstable or BestEffort.
2. Set guardrails per namespace. A LimitRange fills in default requests and limits and caps per-container values. A ResourceQuota caps a namespace's total CPU, memory and object counts. The Horizontal Pod Autoscaler measures CPU utilisation against requests, so wrong requests break scaling. Nodes are added by Cluster Autoscaler or, on EKS, by Karpenter.
3. Walk the network path. Every pod gets its own IP from the CNI. On EKS the Amazon VPC CNI assigns real VPC addresses, so running out of subnet IPs is a real limit; prefix delegation helps. A Service gives a stable virtual IP and a DNS name (through CoreDNS), implemented by kube-proxy rules (iptables or IPVS). Outside traffic enters through an Ingress or a LoadBalancer Service, on EKS usually via the AWS Load Balancer Controller (ALB or NLB).
4. Lock traffic down. By default any pod can reach any other, so apply a default-deny NetworkPolicy in each namespace and allow flows explicitly. Policies only take effect with a CNI or add-on that enforces them (Calico, Cilium, or the VPC CNI's network policy mode). Add RBAC per team, and give workloads IAM Roles for Service Accounts or EKS Pod Identity instead of node-wide IAM credentials.
5. Describe day-2 operations. Define the cluster and its add-ons as code (Terraform or Terragrunt) and sync workloads with a GitOps tool such as Argo CD. Upgrade the control plane one minor version at a time, then roll the node groups, with PodDisruptionBudgets and readiness probes keeping services up. Alert on CPU throttling, OOMKills, pending pods and node pressure.

Follow-up

• A service on EKS shows latency spikes while its average CPU is well under its limit. What do you check?
• A pod keeps getting OOMKilled after a release. How do you find the cause?
• How would you upgrade an EKS cluster's Kubernetes version without downtime?

How do you approach designing CI/CD pipelines with multi-stage builds and security scanning?

Medium · Technical & Domain Knowledge

Approach

1. Lay out the stages in order: lint and unit tests, build, scan, integration tests, push to a registry, deploy to staging, promote to production. Put the cheap checks first so a broken commit fails early. Run independent jobs, such as tests, SAST and the dependency scan, in parallel.
2. Explain the multi-stage Dockerfile. A builder stage with the full toolchain (JDK, Maven or Gradle) compiles and tests the code. The final stage starts from a minimal runtime image (a slim JRE or distroless) and copies in only the artifact with COPY --from=builder. The image is smaller, has fewer packages that can carry CVEs, and ships no compilers. Copy the dependency manifest before the source so dependency layers stay cached.
3. Run each scanner on the thing it checks: secret scanning (gitleaks) and SAST (Semgrep, CodeQL or SonarQube) on source code; dependency scanning (OWASP Dependency-Check, Snyk) on the manifest; image scanning (Trivy, Grype or ECR scanning) on the built image; IaC scanning (Checkov, tfsec) on Terraform; DAST (OWASP ZAP) against staging.
4. Define the gate. Fail the build on critical or high findings that have a fix available. Record accepted risks in an allowlist with an owner and an expiry date. Rescan images already in the registry on a schedule, because new CVEs are published after the build. Pass build credentials with BuildKit secret mounts so they never land in a layer.
5. Protect the supply chain and the release. Pin base images by digest, generate an SBOM (Syft), sign the image (cosign) and verify the signature at admission (Kyverno or Gatekeeper). Build once and promote the same digest through every environment. Give the pipeline short-lived AWS credentials through OIDC instead of stored keys. Deploy through GitOps (Argo CD) so a rollback is a git revert.

Follow-up

• The image scan flags a critical CVE in the base image and no fix exists yet. What happens to the release?
• The pipeline has become slow. Where do you cut time without dropping a security check?
• A deployment has failed in production. What do you do first, and how does the pipeline make rollback safe?

Read latency spikes on a sixty-second sawtooth

Medium · cache stampede · single-flight · ttl

The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.

Approach

1. Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
2. Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
3. Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
4. De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.

Follow-up

• The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
• How does your answer change if the recompute takes 4 seconds instead of 250 ms?

Suggested practice checklist

The plan starts with the loop and your own resume, spends days 2 through 5 on the reported technical areas (Java fundamentals, Kubernetes, CI/CD, incident response), then turns to the behavioral questions and a full mock.

Day 1 — Map the loop and inventory your resume

• Write the three reported rounds (Initial Screening, Technical Deep Dives, Leadership Interview) on one page with the topics candidates report for each.
• List every technology on your resume and write one line on why you chose it, one alternative and one cost.

Deliverable: A one-page loop map and a resume inventory with a reason, alternative and cost for each technology.

Day 2 — Language fundamentals and data structures

• Write a spoken answer to your favorite data structure: its operations and complexity, a real case where you used it, and one case where it was the wrong choice.
• Write definitions for instance variable versus local variable covering lifetime, default values, where each lives in memory and thread safety, with a short code example.
• List the parts of a Java EE queue (connection factory, destination, producer, consumer, message, session) and explain delivery and acknowledgement.

Deliverable: Three written-then-spoken answers (data structure, variable scope, Java EE queue) with one code example each.

Day 3 — Kubernetes cluster management

• Write a Deployment manifest with requests and limits and explain what happens on CPU throttling and on memory overrun.
• Add a namespace ResourceQuota and LimitRange and explain when each applies.
• Draw how traffic reaches a pod (Service, Ingress) and add a NetworkPolicy that restricts it.
• Write the first five checks you would run on an EKS cluster whose latency is spiking.

Deliverable: A manifest, a traffic diagram and a five-step latency checklist, plus a spoken answer to the cluster management question.

Day 4 — CI/CD, security scanning and infrastructure as code

• Sketch a pipeline with stages for build, test, scan and deploy, showing where a multi-stage container build fits.
• Decide where dependency scanning, image scanning and secret scanning run, and what fails the build.
• Write the rollback steps for a bad deployment, then read a short Terraform module and explain what Terragrunt or Argo CD would add.

Deliverable: A pipeline diagram with scanning gates marked, a rollback checklist and a spoken answer to the CI/CD question.

Day 5 — Incident response and testing

• Write a post-incident summary for a failed production deployment: impact, timeline, root cause and prevention.
• List which unit, integration and end-to-end tests you would write for a service you own, and why.

Deliverable: A hypothesis log, a one-page post-incident summary and a test plan for one service.

Day 6 — Behavioral answers

• Write and rehearse a background answer using the present, past, future shape.
• Choose a real weakness and write the example, the action you took and the evidence of progress.
• Write your reasons for Bluestaq and your ideal role, each tied to the Unified Data Library, the sector and the stack.
• Write one STAR story about refactoring code for readability and performance.

Deliverable: Four rehearsed behavioral answers and one STAR story.

Day 7 — Full dry run

• Run a mock from screening through technical questions to leadership questions, answering aloud without notes.
• Write the two or three questions you will ask about team challenges, on-call burden and technical debt.

Deliverable: A recorded or reviewed mock with weak answers marked, and a final list of questions to ask.

Behavioral preparation for Bluestaq

Candidates describe the behavioral questions as personal and open: your background, something you are not good at, why Bluestaq and the role you want. Reports also say to be ready to discuss interest in the defense and space sector, to show humility and a collaborative style, and to structure project stories with STAR. Prepare specific, honest answers tied to the work of owning features and operating infrastructure.

1. Describe a time you had to refactor a piece of code to improve readability and performance.
2. What steps do you take when you realize a deployment has failed in production?

Describe yourself and your background.

Medium · Behavioral & Situational

Approach

1. Use a present, past, future shape: what you do now, the one or two experiences that explain it, and what you want next. End on why that points to a Software Engineer role at Bluestaq so the answer lands on the job rather than ending with your last employer.
2. Choose the experiences that match the reported work: shipping a feature end to end, operating something on Kubernetes or AWS, improving CI/CD, or taking part in on-call. One concrete decision you made, with the trade-off, is worth more than a list of tools.
3. Keep it spoken-length and skip chronology. A sample opener: 'I am a software engineer who has spent the last few years owning services from design to on-call, and the part I enjoy most is making them easier to deploy and debug.'
4. The common failure is reciting the resume in order. Cut anything you cannot support with a follow-up question, because every technology you mention can be probed.

Follow-up

• Which project on your resume are you proudest of, and what did you decide in it?
• What would you change about that project if you rebuilt it today?
• Which technology you listed are you least deep in?

What is something you are not good at, and how are you actively improving on it?

Medium · Behavioral & Situational

Approach

1. Pick a real weakness that is not central to the role. 'I do not like being on call' sinks you for this job, while 'I used to under-document design decisions' is honest and fixable.
2. Structure it as the weakness, one specific moment where it cost you something, and what you changed. Concrete actions beat intentions: for example, writing a short decision record before starting a feature and asking a reviewer to challenge it.
3. Show how you know you are improving. Name a signal such as review comments on missing context becoming rarer, or a teammate able to pick up your work without a handover call.
4. Avoid humble-brag answers such as 'I work too hard' and answers with no action. Candidates are told humility and willingness to learn matter, so sound curious rather than defensive.

Follow-up

• How has this weakness affected a teammate or a project?
• What feedback did you receive about it, and who gave it?
• How will you know in six months that it has improved?

Why do you want to work for Bluestaq?

Medium · Behavioral & Situational

Approach

1. Build the answer from three parts you can defend: the product (the Unified Data Library, which brings data sets together for space and government operations), the sector (defense and space, which candidates say to be ready to discuss) and the engineering work (Kubernetes, AWS, platform reliability).
2. Make the link personal and checkable. Name a project of yours where reliability mattered and say why that experience makes you want to work where an outage has real consequences for users.
3. Read what Bluestaq publishes about its work before the call and refer to one thing you learned, but do not claim detailed knowledge of its internals that you cannot have.
4. Avoid answers about pay, perks or brand, and avoid generic mission statements that could be pasted into any company's interview. Have an honest answer ready if you are asked about working in a defense setting.

Follow-up

• What do you already know about the Unified Data Library?
• What would you want to learn in your first months here?
• What concerns, if any, do you have about working in the defense sector?

What does your ideal role look like in terms of daily responsibilities and team interaction?

Medium · Behavioral & Situational

Approach

1. Describe the week you want, using the same activities candidates report for the role: owning a feature through design, implementation and follow-up, operating Kubernetes and AWS infrastructure, reviewing code or pairing, and taking part in on-call.
2. For team interaction, be specific about how you work: written design notes, pairing, review habits, and how you coordinate with product and design. Mention you are comfortable in distributed teams, since candidates are told to expect remote collaboration over documentation and video meetings.
3. Be honest about proportions. If you want most of the week on feature work with some infrastructure, say so and explain why that mix lets you do good work.
4. Avoid describing a role that does not exist here, such as pure heads-down coding with no operations, and avoid a vague 'a collaborative team' answer. Close by asking how the team's actual week compares.

Follow-up

• How much of your ideal week would be features versus infrastructure and on-call?
• How do you stay productive and visible on a distributed team?
• What would make you want to leave a role like this?