Alter Domus Software Engineer Interview Guide

The 60-second brief

Candidates describe Alter Domus as a firm serving asset managers in the alternative investment industry, with a workforce of more than 6,000 people spread over 24 jurisdictions. The role reported under this listing is Senior System Engineer, specializing in Microsoft 365. The work spans Exchange Online, Intune, Entra ID and Defender XDR, with Active Directory and Group Policy on the requirements list. Reported responsibilities include running the Defender XDR environment, following CIS standards, matching licence purchases to actual usage, and writing the training and documentation that Level 1 and Level 2 support teams rely on.

This guide is for candidates preparing for the Alter Domus role filed under Software Engineer but described by candidates as a Senior System Engineer position on Microsoft 365. It is an administration and security role, not an application-development one. The guide covers the four reported questions (mail flow troubleshooting, Conditional Access, Intune compliance and baselines, PowerShell or Graph automation), the ownership and documentation stories candidates say matter, and a plan to rehearse all of it. Candidates report a requirement of at least 6 years of IT experience, with JAMF for Apple devices and multi-jurisdiction experience listed as extras.

No round count, order or format is reported. Candidates describe a mix of technical screening, deeper architecture discussion and behavioral assessment, all anchored in Microsoft 365 administration and security.

Focus areas

• Microsoft 365 Administration
• Microsoft Entra ID
• Exchange Online

Overview

The reported work is tenant-level administration for a large, regulated organisation: Exchange Online mail flow, Entra ID identity, Intune device management and Defender XDR, automated with PowerShell and the Graph API. The four reported questions follow that split. One is a troubleshooting scenario, one is a policy-design question, one asks about your Intune experience, and one asks how you automate bulk administrative work. Answers built from real tenant changes are easier to defend than lists of features.

Build a one-page map for each area before you rehearse. For Exchange: hybrid configuration, connectors, transport rules, message trace and header analysis. For identity: Entra ID, MFA, identity protection and Conditional Access. For endpoints: Intune compliance policies and security baselines. For security: Defender for Office 365 and Defender for Endpoint configuration, XDR incident triage, and Purview data loss prevention. For automation: PowerShell and Graph for lifecycle tasks and bulk provisioning. Active Directory and Group Policy are also on the must-have list, so prepare the hybrid side: Entra Connect or Cloud Sync scope and source of authority, hybrid join, and moving GPOs to Intune with Group Policy analytics or co-management.

Candidates stress autonomy and documentation for this role: owning a project from implementation through to write-up, explaining technical choices to non-technical stakeholders, and training Level 1 and Level 2 support. Prepare two or three initiatives where you can show the runbook, change record or training material you left behind, and be ready to say why you chose one configuration over the alternatives. Candidates also suggest asking the team about tenant migration or security hardening challenges, so write your own questions on those topics.

Where to focus your preparation

Candidates report no named rounds for this loop, so the guide treats it as one preparation focus that covers every reported question type: technical, design-style, experience-based and behavioral.

Preparation focus

Candidates describe a mix of technical screening, deeper architecture discussion and behavioral assessment, without a stated order, count or duration. Confirm the format with your recruiter, in particular whether you will be asked to write or talk through PowerShell. The reported technical questions cover mail flow troubleshooting with connectors and transport rules, Conditional Access policy design, Intune compliance and security baselines, and PowerShell or Graph automation. Prepare each as a spoken walkthrough: state the situation, the tools you use, the decision and why, and how you verified the result. Candidates also report that questions about security incidents and projects suit the STAR format.

What to demonstrate

• Working fluency across Exchange Online, Entra ID, Intune and Conditional Access, and how they interact in a global tenant
• A stepwise diagnostic approach that names real tools, such as message trace and header analysis, and shows how a fix is validated
• Ability to automate administrative and bulk provisioning work with PowerShell or the Graph API
• Clear explanation for non-technical audiences, and documentation of your own work

How to prepare

• Write a mail flow checklist you can say aloud: scope the failure, run a message trace, read the headers, check connectors, then check transport rule order
• Sketch a Conditional Access policy set on paper, including report-only testing, emergency-access exclusions and the grant controls you would require
• Prepare one Intune story with its compliance policy settings, baseline rollout steps and a before-and-after measure
• Outline a bulk-provisioning script in PowerShell or Graph, including input validation, dry-run mode, error handling and logging

Where candidates lose points

Answering the mail flow question with "I would check the connector" and no order of operations

Give a fixed sequence: scope the failure (one sender or all, inbound or outbound, the NDR code), run a message trace, read the headers, check the relevant connector, then check transport rule priority and whether a rule stops further processing. Finish with how you confirm the fix, such as a fresh test message and a second trace.

Describing Conditional Access as "require MFA for everyone" with no mention of what it could break

Name the safeguards: report-only mode before enforcement, emergency-access accounts excluded, legacy authentication handled, named locations or device state as conditions, and a phased rollout. Then say where you relax a control to protect productivity and why.

Telling an Intune story with no scope, no numbers and no rollback path

State the device count and platforms, the pilot group, the compliance or baseline settings you changed, how you saw conflicts, and what you measured afterwards. Say what you would have reverted had the pilot failed.

Saying you automated tasks with PowerShell or Graph without describing how the script behaves when something goes wrong

Cover input validation, a dry-run or -WhatIf mode, least-privilege permissions for the app or account, handling throttling and partial failures, and a log someone else can read. Be ready to outline the script aloud or on paper.

Explaining what you configured but not why, and having no documentation to show for it

For each answer, name the alternative you rejected and the reason. Bring one or two artefacts from past work, such as a runbook, change record or support-team guide, because candidates stress documentation for this senior role.

Questions & practice

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?

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?

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?

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?

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?

How do you configure Conditional Access policies to balance user productivity with strict security requirement

Medium · Technical & Domain Expertise

How do you configure Conditional Access policies to balance user productivity with strict security requirements?

Approach

1. Start with the safety net: at least two emergency access (break-glass) accounts excluded from every policy, with alerting on their sign-ins. Every new policy runs in report-only mode first, and the What If tool plus sign-in logs show whom it would have hit.
2. Lay down a small baseline: require MFA for all users, block legacy authentication (the 'Exchange ActiveSync clients' and 'Other clients' conditions), and require a stronger authentication strength, such as phishing-resistant methods, for privileged directory roles.
3. Tie access to sensitive apps to the device: require a device marked compliant in Intune or Microsoft Entra hybrid joined. For unmanaged devices, use app-enforced restrictions or a Defender for Cloud Apps session control that allows the browser but blocks downloads, so people keep working without data landing on a personal device.
4. Explain how evaluation works: every policy that matches the user, app and conditions applies, a block wins, and inside one policy you choose whether all grant controls or only one are required. Risk-based policies on user or sign-in risk need Entra ID P2; Conditional Access itself needs P1.
5. Balance prompts against risk with session controls (sign-in frequency, persistent browser session) instead of MFA on every sign-in. Treat named locations as a signal, not a bypass. Roll out to a pilot group first, use a consistent naming scheme, and handle guests and service accounts on purpose rather than through blanket exclusions.

Follow-up

• A user is blocked right after a new policy goes live. How do you find which policy did it and why?
• How do you treat staff who travel or sign in from personal phones?
• Why exclude break-glass accounts, and how do you keep them from becoming the weakest point?

How have you utilized PowerShell or the Graph API to automate repetitive administrative tasks or bulk provisio

Medium · Technical & Domain Expertise

How have you utilized PowerShell or the Graph API to automate repetitive administrative tasks or bulk provisioning?

Approach

1. Name the tooling: the Microsoft Graph PowerShell SDK (Connect-MgGraph, Get-MgUser, New-MgUser) or direct Graph REST calls, since the older AzureAD and MSOnline modules are deprecated. Pick one real task you automated, such as onboarding from an HR CSV, and say what it replaced.
2. For unattended runs, authenticate as an app registration with a certificate or as a managed identity in an Azure Automation runbook, never with a stored user password. Grant only the application permissions the job needs (for example User.ReadWrite.All rather than Directory.ReadWrite.All), with admin consent.
3. Make it safe to rerun: validate each CSV row first, look the user up by UPN or employeeId before creating, and skip or update instead of duplicating. Set usageLocation before assigning a licence (the assignment fails without it), or let group-based licensing handle licences instead.
4. Handle scale: follow @odata.nextLink (or use -All) when reading large sets, group calls with JSON batching (up to 20 requests per $batch), and on HTTP 429 wait for the Retry-After value before retrying instead of hammering the endpoint.
5. Run every row in try/catch with -ErrorAction Stop, write a per-row result log the helpdesk can read, support -WhatIf through SupportsShouldProcess for dry runs, and keep the script in source control with a short runbook so other admins can run and maintain it.

Follow-up

• The script dies after 300 of 500 users. How do you rerun it without creating duplicates or skipping anyone?
• Which Graph permissions does your app hold, and how do you keep its credential from leaking?
• How would you report back which accounts failed and why?

Explain your process for troubleshooting a complex mail flow issue involving connectors and transport rules.

Medium · Technical & Domain Expertise

Approach

1. Scope it before touching config: inbound or outbound, internal or external, one sender, one domain or everyone, and when it started. Get the NDR text and status code: a 4.x.x is a deferral that is still retrying, a 5.x.x is a permanent rejection, and the enhanced code (5.7.x is a policy or authentication refusal) narrows where to look.
2. Run a message trace in the Exchange admin center or with Get-MessageTraceV2 in Exchange Online PowerShell, then open the detail for one affected message. The events (Receive, Transport rule, Deliver, Fail, Drop) tell you whether a mail flow rule acted on it or which connector it left through.
3. Read the headers with Message Header Analyzer: the Received hops show the actual path, Authentication-Results shows SPF, DKIM and DMARC, and X-Forefront-Antispam-Report shows the spam verdict. If MX points at a third-party gateway, SPF fails on the gateway's IP unless Enhanced Filtering for Connectors is set on the inbound connector.
4. Check connectors by direction. For inbound mail, confirm that the sending IP or TLS certificate subject in the headers matches the restriction on the inbound connector, and check for an expired certificate. For outbound or on-premises connectors, run 'Validate this connector' against a test recipient. In a hybrid setup, confirm whether centralized mail transport routes outbound mail through on-premises.
5. For mail flow rules, check priority order, conditions and exceptions, the 'stop processing more rules' setting and the mode (Enforce or Test). Fix one thing at a time, send a test message, confirm the change in a fresh trace, and record the cause and the fix.

Follow-up

• Mail from one partner started failing SPF after MX moved to a third-party filtering service. What do you change in Exchange Online?
• A rule should stamp a disclaimer on outbound mail, but some messages leave without it. How do you find out why?
• How would you show that the fault sits on the partner's side and not in your tenant?

Suggested practice checklist

Day 1 confirms the format with your recruiter and maps the stack. Days 2 to 5 take one reported question each: Exchange mail flow, Conditional Access with the hybrid identity side, Intune with GPO migration, and PowerShell or Graph automation. Day 6 covers Defender XDR, DLP and security stories, and day 7 is a spoken mock.

Day 1 — Map the stack and confirm the format

• Ask your recruiter for the sequence of stages, whether you will write or discuss PowerShell, and whether a technical screen comes first.
• Write a one-page map of the areas candidates report: Exchange Online, Entra ID, Intune, Conditional Access, Defender XDR, DLP, Active Directory and Group Policy, PowerShell and Graph.
• Mark each area as strong, rusty or untouched, and list the three real projects you will draw examples from.

Deliverable: A written format confirmation from your recruiter, a one-page stack map with strengths marked, and a list of three projects.

Day 2 — Exchange Online mail flow troubleshooting

• Write your troubleshooting sequence for the mail flow question: scope the failure, run a message trace, read headers, check connectors, then check transport rule order and stop-processing settings.
• In a test tenant you control, create a transport rule and a connector, break each on purpose, and find the fault using message trace and the message headers.
• Say your answer aloud for a hybrid scenario, covering where on-premises routing could be the cause.

Deliverable: A mail flow checklist, a short log of the two faults you created and found, and one spoken answer to the mail flow question.

Day 3 — Entra ID, hybrid identity and Conditional Access

• Design a Conditional Access policy set for a mixed estate on paper: MFA, legacy authentication, device state and location conditions, with emergency-access accounts excluded.
• Write how you would roll it out: report-only mode, sign-in log review, a pilot group, then wider enforcement.
• Review the hybrid identity side: Entra Connect versus Cloud Sync, sync scope by OU or group, which attributes stay mastered in on-premises AD, and how Entra hybrid join is configured and verified.
• Answer the Conditional Access question aloud, explaining where you trade strictness for productivity and why.

Deliverable: A policy table with conditions, grant controls and rollout order, a short hybrid identity summary, and one spoken answer to the Conditional Access question.

Day 4 — Intune compliance, baselines and GPO migration

• List the compliance settings you would set per platform and the noncompliance actions with their grace periods, and show how compliance links to Conditional Access.
• Write the baseline rollout steps you use: pilot group, conflict review, exception tracking, widening rings, version updates.
• Prepare the Group Policy side: import GPO backups into Group Policy analytics to see MDM support, plan co-management workload shifts, and have one GPO versus Intune conflict ready, such as a setting where GPO won until MDMWinsOverGP was set or the GPO was unlinked.
• Write your Intune story in STAR format with scope, decisions, a measured result and the handover documentation.

Deliverable: A compliance and baseline rollout outline, a GPO migration note with one conflict and its fix, and one STAR story with at least one real number.

Day 5 — PowerShell and Graph automation

• Outline a bulk-provisioning script that reads a CSV, validates each row, creates or updates users through Graph, logs every result and supports a dry run.
• Write down how it handles throttling, partial failures and re-runs, and which permissions the app or account needs.
• Prepare a real automation example from your own work, with the manual effort it replaced.

Deliverable: A script outline with error handling and logging, plus one spoken answer to the automation question.

Day 6 — Defender XDR, DLP and security stories

• Defender for Office 365: compare the Standard and Strict preset policies, then cover anti-phishing impersonation protection, Safe Links and Safe Attachments. Defender for Endpoint: onboarding through an Intune EDR policy and the Intune connector, and ASR rules moved from audit to block mode after review.
• Walk through triaging one XDR incident (alert correlation, affected user and device, isolation or remediation, closure note), then a Purview DLP policy run in simulation mode before enforcement. Map one setting from each area to a CIS Microsoft 365 benchmark control.
• Practise one question aloud, for example how you would harden email against phishing: start from a preset policy, add impersonation protection for executives and domains, enable Safe Links and Safe Attachments, check results in Threat Explorer, compare against CIS, and record exceptions.

Deliverable: A Defender and DLP summary with CIS mappings, one spoken answer on phishing hardening, two STAR stories with their documentation named, and two spoken practice answers.

Day 7 — Full spoken mock and questions to ask

• Answer the four reported questions back to back, aloud, and record yourself.
• Replay the recording and mark any answer that lacks an order of steps, a reason for a choice or a measure.
• Explain one Conditional Access or mail flow change in plain language, as you would to a non-technical stakeholder.
• Write two questions for the team about tenant migration or security hardening, as candidates suggest.

Deliverable: One recorded mock covering all four reported questions, a list of fixes, a plain-language explanation of one change, and two questions to ask the team.

Ownership and documentation stories

Candidates report behavioral assessment as part of the loop and recommend the STAR format, especially for security incidents and projects. They also describe ownership from implementation to documentation, mentoring others and explaining technical choices to non-technical stakeholders. Prepare stories where you made the decision, name the alternative you rejected, and show the documentation you left.

1. Walk through an IT initiative you owned from implementation to documentation. What did you leave behind for the support team?
2. Describe a security incident or hardening project you handled. How did you confirm the fix worked?
3. Tell me about a time you explained a Conditional Access or mail flow change to a non-technical stakeholder.
4. Describe a configuration or protocol choice where you picked one option over alternatives, and explain why.

Describe your experience with Intune—specifically, how do you handle device compliance and the deployment of s

Medium · Technical & Domain Expertise

Describe your experience with Intune—specifically, how do you handle device compliance and the deployment of security baselines?

Approach

1. Answer the "how do you handle" half with a repeatable process, then anchor it in one real Intune programme you owned. Give the scope in two sentences: platforms, rough device count and who was affected. Spend the rest on your decisions, speaking as "I" for the parts you personally decided and naming teammates for the parts you did not.
2. For compliance, name the policy content: encryption, minimum OS version, passcode rules, a Defender-reported device risk level, and jailbreak or root detection. Then cover noncompliance actions: a grace period, user notification, and what happens after it ends. Explain how compliance feeds Conditional Access through a require-compliant-device grant, and why you check compliance reporting is healthy before enforcing it, so you do not lock out users.
3. For security baselines, describe the rollout: assign the baseline to a pilot group, review per-setting status and conflicts with existing configuration profiles, record each exception with an owner, then widen in rings. Say how you handle baseline version updates and, if it applies, how you mapped settings to CIS standards. Keep the same structure for Apple devices only if you have real JAMF or Apple experience.
4. Close with results and the artefacts you left. Quote measures you really have: compliance rate before and after, devices blocked, tickets raised. Mention the runbook or training you gave Level 1 and Level 2 support. Stories are stronger when they include a decision, a number and a documented handover.

Follow-up

• A user in your pilot group was blocked from email after their device went noncompliant. How did you diagnose it and what did you change?
• How do you handle a device or team that cannot meet a baseline setting?
• What would you do differently if you ran that rollout again?

Argue against a design, lose, and commit anyway

Medium · disagreement · service boundaries · decision records

Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.

Approach

1. State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
2. Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
3. Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
4. Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.

Follow-up

• What threshold on that alert would have proved you right, and did anyone ever look at it?
• If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?

Narrate an outage you owned from page to postmortem

Hard · incident response · blast radius · postmortems

Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.

Approach

1. Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
2. Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
3. Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
4. Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.

Follow-up

• What would you do differently in the first five minutes, given the same dashboard and no more information?
• Which follow-up action did you deliberately not take, and why was dropping it the right call?