Interview guides · Armor

Armor Software Engineer Interview Guide

Armor Software Engineer interview guide: four reported rounds, VM storage and RDP troubleshooting, Python, Linux, basic DSA, and a 7-day prep plan.

The 60-second brief

Candidates describe Armor as a company that builds security platforms meant to protect sensitive data and infrastructure for its clients. The Software Engineer role they report covers building, maintaining and tuning those platforms. Examples named for the role include chasing performance bottlenecks, working with storage protocols and automating security updates, alongside regular contact with Systems Engineering, Networking and Product teams.

This guide is for candidates interviewing for a Software Engineer position at Armor. It walks through the four reported stages, prepares you for the reported questions on testing types, storage protocols, VM storage performance, a post-patch RDP failure, your most useful tool and three behavioral prompts, and covers the basic Python and DSA work (sorting, pointer manipulation) that candidates say the role requires.

Candidates report four rounds over roughly 3-5 weeks: Initial Screening, Technical Deep Dives, Phone-Based Technical Discussions, and In-Person or Virtual Panels. Depending on team and level, not every candidate sees every format.

Focus areas

Software Engineering Problem Solving
RDP (Remote Desktop Protocol)
Troubleshooting Methodology

Overview

The reported questions lean toward systems work more than algorithm puzzles. Candidates describe questions about testing types, storage protocols, a slow VM disk, and a Server 2008 machine whose RDP access breaks after a reboot and security updates. The role description they relay lists Python, Linux (CentOS, RHEL, Ubuntu) and Windows, with troubleshooting named as a must-have and basic DSA such as sorting and pointer manipulation alongside it.

That mix shapes preparation. For the troubleshooting questions, a memorised list of fixes is weaker than a repeatable order of checks: what changed, which layer is involved, what single test splits the problem in half. Practise saying that order aloud for a VM with slow storage and for an RDP failure after patching, because both questions invite you to narrate a diagnosis rather than recite a command.

Candidates also report that the technical conversations follow your resume. If you list AI/ML work, networking, database administration, storage or virtualization, expect to go deeper there, and the nice-to-have skills candidates mention include storage protocols, virtualization and customer-facing support experience. Build an inventory of every tool and project you list, with one concrete problem each solved.

Finally, the later stages are reported to include managers and peers from neighboring departments, and the work involves reporting progress on troubleshooting to management. Prepare to explain a technical trade-off in plain language, and keep a short list of the blogs, projects or communities you actually follow, since a question on that is reported.

The Armor interview process

Candidates describe four stages, from an initial screening through technical discussions to panels. The stages below are what candidates report, not a published process, and the format can shift with team and level.

Initial Screening

Candidates describe the Initial Screening as a first conversation that gauges your baseline fit and interest in the role. No specific technical questions are reported for it. Treat it as the place where your background, your motivation for this kind of infrastructure-and-security work and your practical logistics get established, and expect the resume to be the starting point for later technical depth.

What to demonstrate

Baseline fit for a Software Engineer role that mixes coding with systems troubleshooting
Interest in the role, shown through specifics about the work rather than general enthusiasm
How clearly you summarise your own background and interests

How to prepare

Write a short career summary that leads with Python, Linux or Windows administration, and troubleshooting work you have done, ending on why a security-infrastructure team interests you.
Build a resume inventory: for every tool, language and project you list, write one problem it solved, so nothing on the page is a surprise later.
Prepare your answer to the background-and-interests question reported for the loop, plus your questions about the team's challenges.

Technical Deep Dives

Candidates report a series of Technical Deep Dives, which assess your technical skills through discussion. The reported question types for this loop are testing types, storage protocols, troubleshooting a VM storage performance issue, and diagnosing an RDP failure on Server 2008 after a reboot and security updates. Notes do not say which question lands in which round, so prepare the whole set. Answer by naming the layers in play, the first check that splits the problem, and what the result would tell you.

What to demonstrate

Command of Windows and Linux systems, networking and storage fundamentals
Troubleshooting method: isolating one variable at a time in a failing system
Ability to explain configurations and tools and the reasoning behind a choice

How to prepare

Write an ordered checklist for slow VM storage covering guest OS, hypervisor, network path and storage backend, with the tool or metric you would read at each layer.
Write an ordered checklist for the post-patch RDP failure, including whether the added route survived the reboot, the listener, the firewall rule and authentication changes from the updates.
Pick one storage protocol you would defend and be ready to compare it with two others on latency, sharing model and operational cost.

Phone-Based Technical Discussions

Phone-Based Technical Discussions are described as phone interviews focused on technical expertise. With no screen to share, the answer has to be structured in speech: state the layers, the order of checks and the conclusion each check would lead to. Candidates also report a question about your most useful tool, so have one tool and a real situation where it solved something.

What to demonstrate

Technical expertise explained verbally and clearly, without a whiteboard
Practical knowledge of the tools you use daily
Basic DSA fluency, since candidates report basic to medium sorting and pointer questions

How to prepare

Rehearse the VM storage and RDP answers aloud as a numbered sequence, so a listener can follow without diagrams.
Prepare the most-useful-tool answer: what the tool does, a concrete case where it exposed the cause of a problem, and one limitation.
Be able to describe merge sort, quicksort and linked-list reversal in words, with complexity and edge cases, in case a phone discussion includes basic DSA.

In-Person or Virtual Panels

In-Person or Virtual Panels are reported to bring in managers and peers from neighboring departments. Candidates describe this stage as more culture-focused, covering teamwork, how you learn, and how you handle pressure and ambiguity. Because the work involves several teams, expect to explain technical trade-offs to people outside your specialty and to keep a professional tone even in casual conversation.

What to demonstrate

Communication across teams, including explaining technical concepts to non-specialists
Teamwork style and professional relationships
How you handle high-pressure situations and ambiguous technical problems

How to prepare

Prepare one structured story about an ambiguous or high-pressure technical problem: symptoms, how you narrowed it, who you updated, result and what you changed afterwards.
Prepare a short answer on the blogs, communities or personal projects you follow, naming specific sources and one thing you learned from them.
Practise explaining a trade-off, such as one storage protocol over another, to a listener with no storage background.

Where candidates lose points

Answering the slow VM storage question with one favourite fix, such as adding disk, instead of a diagnosis

Open with what changed and where the slowness shows up, then walk the layers in order: guest OS, hypervisor, network path to storage, storage backend. Name a metric for each, such as queue depth, latency versus throughput, and contention from other VMs.

Treating the RDP question as only a firewall question

Cover the whole chain: whether the route you added persisted across the reboot, whether the Remote Desktop service is running and listening, firewall rules and profile, and whether the security updates changed authentication or encryption requirements. Say which check you run first and what each result rules out.

Saying you prefer a storage protocol without trade-offs

Choose one and compare it with two others on block versus file access, latency, sharing model, network requirements and operational burden. State the workload where your preference would flip.

Listing resume items you cannot discuss in depth, especially AI/ML, networking or virtualization

Build an inventory of each listed tool with one problem solved, one thing that went wrong and one thing you would change. Cut anything you cannot defend.

Under-preparing the basic DSA by assuming it is trivial

Write merge sort, quicksort, linked-list reversal and cycle detection in Python without help, stating complexity and stability. Check empty input, a single node, duplicates and already-sorted data before you call it done.

Questions & practice

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

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

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

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

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?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
A dashboard runs this for 40 owners in one page load. What changes about the design?

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

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.
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.
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.
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 are the types of testing you know about?

Medium · Technical & Domain Expertise

Approach

Sort testing along two axes. By scope: unit (one function, dependencies faked), integration (real modules talking to a real database or service), system or end-to-end (the deployed stack driven like a user), and acceptance (does it meet the requirement). By purpose: functional checks versus non-functional ones such as performance, load, stress, security and recovery.
Name the cross-cutting kinds and when each runs: smoke tests right after a deploy, regression suites on every change, and canary or post-deploy health checks in production. Explain the test pyramid: many fast unit tests, fewer integration tests, few slow and brittle end-to-end tests.
Cover security testing explicitly: static analysis (SAST) on code, dynamic scanning (DAST) against a running service, dependency and CVE scanning, fuzzing of parsers and inputs, and penetration testing by a separate party.
Ground it in Python, since the role lists it: pytest with fixtures and parametrize for unit tests, unittest.mock to isolate I/O, and a containerised database or service for integration tests. Then give one real example of a bug each layer caught or missed.
State the trade-off: mocks keep tests fast but can drift from real behaviour, so contract or integration tests must back them. Coverage percentage measures lines executed, not behaviour verified.

Follow-up

What is the difference between an integration test and an end-to-end test, and where would you test a call to an external API?
How would you check that a security patch actually took effect after you deployed it?
Your end-to-end suite is flaky. How do you find out whether the test or the system is at fault?

What storage protocol do you prefer to work with?

Medium · Technical & Domain Expertise

Approach

Frame the answer by storage type before naming a favourite: block protocols (iSCSI over TCP/IP, Fibre Channel on a dedicated SAN fabric, NVMe over Fabrics), file protocols (NFS, mostly on Linux; SMB, mostly on Windows) and object storage (S3-style APIs over HTTP).
Pick one you have actually run and justify it by workload. For example: NFS for VM datastores or shared Linux data because it is simple to provision and grow; iSCSI when a guest or database needs a raw block device and its own filesystem, with MPIO multipathing for redundancy and throughput.
Give the version and security details that show real use: NFSv3 is stateless and relies on separate locking services, while NFSv4 is stateful, uses a single port (2049) and supports Kerberos (sec=krb5, krb5i, krb5p). iSCSI uses CHAP for authentication; SMB 3 adds encryption and multichannel.
Name the operational traps: MTU must match end to end if you enable jumbo frames, storage traffic belongs on its own VLAN or network, and an iSCSI LUN mounted read-write by two hosts without a cluster-aware filesystem corrupts it.
Close with when you would choose differently: Fibre Channel for latency-sensitive workloads where a separate fabric is affordable, object storage for backups and large unstructured data where POSIX semantics are not needed.

Follow-up

How would you configure and verify multipathing for an iSCSI target?
What changes between NFSv3 and NFSv4 when a firewall sits between client and server?
How would you secure storage traffic that crosses a shared network?

You have added a route in Server 2008 to allow RDP sessions, but after a reboot and security updates, RDP fail

Medium · Technical & Domain Expertise

You have added a route in Server 2008 to allow RDP sessions, but after a reboot and security updates, RDP fails. What would you check?

Approach

Start with the change that most often explains a reboot-only failure: a route added with plain route add is not persistent on Windows. Run route print and check the Persistent Routes section; the fix is route -p add, which stores the entry under the Tcpip Parameters PersistentRoutes registry key. Confirm the gateway it points at is still reachable.
Test reachability from the client side before touching the server: tracert to confirm the path uses the intended route, then a TCP check on port 3389 (Test-NetConnection -Port 3389 or telnet). A refused or timed-out connection separates network and firewall issues from authentication issues.
On the server, confirm the listener and the policy: the Remote Desktop Services service (TermService) is running, netstat -ano shows 3389 listening, the PortNumber value under the RDP-Tcp WinStations key was not changed, and remote connections are still allowed in System Properties or Group Policy.
Check the firewall after the updates: the Remote Desktop (TCP-In) rule must be enabled for the active profile, and a reboot can move the NIC into the Public profile if network location detection changes. Inspect with netsh advfirewall show currentprofile and the rule list.
If the TCP connection succeeds but login fails, look at the update itself: the 2018 CredSSP fix (CVE-2018-0886) produces an authentication error when client and server patch levels differ, and NLA or TLS certificate changes have a similar effect. Read the System log and the TerminalServices-RemoteConnectionManager and LocalSessionManager logs. Patch both sides rather than loosening the encryption oracle policy.

Follow-up

How would you make this check part of every patch cycle so the next update does not take RDP down?
The client shows a CredSSP encryption oracle error. What are the options, and which would you refuse to use permanently?
Windows Server 2008 is past end of extended support. How would you raise that risk while still fixing the outage?

What is your most useful tool?

Medium · Technical & Domain Expertise

Approach

Pick one tool you use weekly and can go deep on, not a list. Tie it to the troubleshooting work this role describes, for example tcpdump or Wireshark for network issues, strace for Linux process behaviour, journalctl and the Windows Event Viewer for logs, or Python for automating checks.
Tell one concrete incident where the tool found the root cause: the symptom, the exact command (for example tcpdump -i eth0 -nn port 3389 -w rdp.pcap, or strace -f -e trace=file -p PID), what the output showed, and the fix that followed.
Explain why this tool and not the alternatives: what it shows that logs or dashboards do not (packets on the wire, syscalls actually made), and what it costs (overhead in production, capture size, the need for root).
State its limits and what you reach for next, such as moving from tcpdump to an application trace when the payload is TLS-encrypted, or from strace to perf when the problem is CPU time rather than syscalls.
Expect depth on whatever you name: if your resume lists it, be ready for flags, output fields and a failure you debugged with it.

Follow-up

Walk me through the last bug this tool found for you, step by step.
Where does this tool fall short, and what do you use instead?
How would you turn the check you ran by hand into a repeatable Python script?

How would you go about troubleshooting a storage performance issue for a VM?

Medium · Technical & Domain Expertise

Approach

Pin down the symptom and scope first: is it latency, throughput or IOPS, is it one VM or every VM on the same datastore or host, and did it start after a change (migration, snapshot, patch, new neighbour)? Compare against a baseline before forming a theory.
Measure inside the guest. On Linux, run iostat -x and read r_await and w_await (per-request latency), aqu-sz (queue depth) and %util, then iotop or pidstat -d to find the process. On Windows, use Performance Monitor counters Avg. Disk sec/Read, Avg. Disk sec/Write and Current Disk Queue Length.
Measure at the hypervisor to split the latency by layer. On a VMware host, for example, esxtop's disk view shows DAVG (device and array), KAVG (hypervisor kernel, including queueing) and GAVG, which is roughly DAVG plus KAVG. High DAVG points at the array or fabric; high KAVG points at host-side queueing or limits.
Then check the usual causes layer by layer: long snapshot chains, thin-provisioned disks growing, storage I/O limits or a noisy neighbour on the same datastore, a degraded path or link errors, an MTU mismatch, and array-side cache or rebuild activity.
Reproduce with a controlled load generator such as fio, using the same block size and read/write mix as the workload, change one variable at a time, and confirm the fix against the baseline. Note that %util near 100 is misleading on SSDs and RAID sets, because they serve requests in parallel.

Follow-up

Guest latency is high but the hypervisor reports low device latency. Where do you look next?
How would you prove that another VM on the same datastore is causing the slowdown?
Once fixed, what would you monitor so you catch the regression before users do?

Suggested practice checklist

The plan follows the reported loop: system troubleshooting and storage first, then RDP, basic DSA, behavioral stories and a full dry run. Each day ends with something written or recorded, not just read.

Day 1 — Map the loop and build your resume inventory

Write the four reported stages in order, noting which are technical and which are culture-focused, and mark the one you feel least ready for.
List every language, tool and project on your resume and write one concrete problem each solved.
Write your background-and-interests answer in present, past, future order, then say it aloud.

Deliverable: A one-page loop map, a resume inventory with one solved problem per item, and a written background answer.

Day 2 — Testing types and your most useful tool

Write a taxonomy of testing types (unit, integration, system, regression, smoke, acceptance, performance, security) with a one-line example of each applied to a security patch or platform change.
Choose your most useful tool and write a real case where it exposed a root cause, plus one limitation of the tool.
Say both answers aloud as you would on a phone discussion.

Deliverable: A testing-types sheet with examples, and a most-useful-tool answer with a real case and a limitation.

Day 3 — Storage protocols and slow VM storage

Compare NFS, iSCSI, SMB and Fibre Channel on block versus file access, latency, sharing model and network needs, then pick the one you would defend.
Write an ordered checklist for a VM with slow storage: guest OS, hypervisor, network path, storage backend, and the metric you would read at each.
Add how to tell a latency problem from a throughput or contention problem.

Deliverable: A protocol comparison with your preference and reasons, and a layered VM storage checklist.

Day 4 — The post-patch RDP failure on Server 2008

Write a decision tree for RDP failing after a reboot and security updates: route persistence, service state, listener, firewall rule, remote-access settings, authentication changes and event logs.
If you have a spare Windows VM, break and repair RDP on purpose (disable the service, block the port) and record what each failure looks like.
Rehearse the answer aloud as a numbered sequence of checks, each with the result that would rule it in or out.

Deliverable: A one-page RDP decision tree and a recorded spoken answer that names each check and what it rules out.

Day 5 — Basic DSA in Python

Implement merge sort and quicksort without help, then write complexity, stability and the case where each is the better choice.
Write linked-list reversal, middle-node and cycle-detection functions, covering empty list, single node and cycle at the head.

Deliverable: Working Python for two sorts and three list functions, with complexity and edge cases written beside each, plus the practice solution.

Day 6 — Behavioral stories and learning habits

Write your pressure-and-ambiguity story: symptoms, isolation order, updates to others, result and lasting change.
Write your answer on the blogs and communities you follow, with one article and what you did afterward.
Practise explaining a storage-protocol trade-off to a non-specialist in plain language.

Deliverable: A written pressure story, a learning-habits answer with a real example, and a plain-language trade-off explanation.

Day 7 — Full dry run

Run a mock that mixes the VM storage question, the RDP question, one basic sort or list problem and the background question, answering aloud in order.
Review your weakest answer and rewrite it with a clearer order of checks.
Write two questions for your interviewers about the team's current challenges and how Systems Engineering, Networking and Product teams work together.

Deliverable: A completed mock, a rewritten weakest answer and two questions to ask the team.

Background, learning habits and pressure

Candidates describe the later stages as culture-focused conversations about how you work with a team, how you keep learning and how you handle pressure and ambiguity. The role involves troubleshooting with several teams and reporting progress to management, so stories should show clear thinking and clear communication.

Tell me about a time you had to explain a complex technical trade-off to a teammate.
What technology trends are you currently following, and why?

What blogs do you read to stay updated on technology?

Medium · Behavioral & Cultural Fit

Approach

Name two or three sources you actually read: specific blogs, newsletters, vendor engineering posts, release notes or community forums. A list of famous names you cannot discuss is easy to expose.
Pick one recent article and give the loop: what it said, what you tried or checked afterward, and whether it changed anything in your work, such as a monitoring tweak or a storage or security practice.
Connect at least one source to the work reported for this role: Linux or Windows administration, storage and virtualization, security updates or, if you list it, AI/ML.
Show how you judge a source: you cross-check claims against documentation or a test in a lab, rather than copying a configuration from a post.
Mention non-reading habits briefly, such as a home lab, personal projects or community involvement, since learning outside blogs can be part of the same answer.

Follow-up

What is the last thing you read that changed how you did something at work?
Tell me about an article you disagreed with, and how you checked it.
How do you decide whether a technical source is trustworthy before you act on it?

Can you walk us through your professional background and interests?

Medium · Behavioral & Cultural Fit

Approach

Use a present, past, future structure: what you do now, how your previous roles built toward it, and why this Software Engineer role is the next step. Do not read the resume in chronological order.
Choose the two or three experiences closest to the reported requirements, such as Python scripting, Linux or Windows administration, troubleshooting production problems, storage or virtualization, and give each one concrete result.
Be ready to go deep on every item you mention. Candidates are told that anything on the resume can be discussed in detail, so omit or downplay what you cannot defend.
Make the interests part genuine and specific: a home lab, security reading, an automation project. Tie one of them to the role without claiming knowledge of the company's internals.
Finish with an invitation, such as the area you would like to go deeper on, which lets the panel pick a topic from your strengths.

Follow-up

Which item on your resume are you least current on, and why?
Tell me about the hardest troubleshooting problem on the project you just described.
What draws you to infrastructure and security work specifically, rather than application development?

How do you handle high-pressure situations or complex, ambiguous technical problems?

Medium · Behavioral & Cultural Fit

Approach

Choose a real incident where you made decisions. Give the situation in two sentences: what was failing, who was affected and what made it ambiguous, such as unclear symptoms or several layers that could be at fault.
Spend most of the answer on method: what changed recently, which variable you isolated first, which checks you ran in what order, and how you ruled hypotheses out. This matches the isolate-variables troubleshooting reported for the loop.
Show how you stayed steady and communicated: how you gave progress updates to management or other teams while the cause was still unknown, and how you separated mitigation from the final fix.
Close with the result and a lasting change: a runbook, an alert, an automated check or a patch-verification step. Give a number or observable outcome if you have one.
Avoid the heroics trap: a story where you worked alone through the night without telling anyone shows the pressure but not good judgment.

Follow-up

What did you rule out first, and what made that the right first check?
How did you keep stakeholders informed while you did not yet know the cause?
If you faced the same incident again, what would you do differently?