AARP Software Engineer Interview Guide

The 60-second brief

Candidates describe AARP's Software Engineer role as building and maintaining the technology behind services for its members: enterprise systems, cloud platforms and digital tools aimed at people as they age. The work is said to span cloud services, enterprise platforms and AI-related projects, with typical assignments such as modernizing existing applications, migrating workloads to the cloud, building internal platforms and automating workflows. Day to day, candidates describe writing code, configuring enterprise platforms, joining code reviews, troubleshooting production issues and taking part in architecture discussions alongside product managers, system administrators and other engineers. Reported topics for the loop include AWS, IAM, network services, ServiceNow and cloud computing in general, and the requirements candidates describe also name PeopleSoft.

This guide is for software engineers preparing for AARP's Software Engineer interviews. Candidates describe the level as running from mid-level to senior, depending on the posting, and the focus area as varying by team: cloud infrastructure, enterprise platforms or AI. It covers the six reported rounds, the reported behavioral and technical-discussion questions, the stack topics candidates mention (AWS, IAM, networking, ServiceNow, PeopleSoft) and a plan that turns them into rehearsed answers. It does not cover pay or any role outside software engineering.

Candidates report six rounds over roughly four to six weeks: a Recruiter Screen, a Hiring Manager Conversation, a Panel Stage, a Technical Panel, a Behavioral Panel and a Final Offer Stage.

Focus areas

• AWS
• IAM (Identity and Access Management)
• Network Services (General)

Overview

The reported questions are mostly about your own work. Candidates describe being asked to walk through the architecture of their latest project, explain how they debug a complex production environment, describe how they keep code maintainable and say how they would design for scale on AWS. Alongside those sit the behavioral prompts: why AARP, which of its public initiatives interest you, a conflict with a teammate and a project you are proud of. Candidates describe the loop as conversation-weighted rather than puzzle-driven, but the Technical Panel is reported to include coding exercises described as practical. Keep easy-to-medium array, string and hash-map problems warm, and practise one or two small practical tasks as well, such as parsing a log file or writing a REST endpoint with tests.

The stack topics candidates mention are AWS, IAM, network services, ServiceNow and cloud computing in general, and the requirements they describe also name PeopleSoft and, as nice-to-haves, deployment pipelines, infrastructure as code, machine learning integrations and enterprise identity platforms. Turn each into something you can say aloud. For IAM, that means users versus roles, identity policies versus resource policies, least privilege and how you would diagnose an access-denied error. For networking, it means public versus private subnets, route tables, NAT, security groups versus network ACLs and where a load balancer sits. For the enterprise platforms, it means knowing how ServiceNow is customized and integrated, and having a clear view on when to build a custom service and when to integrate an existing platform.

Treat your projects as the raw material for the whole loop. Pick two or three you can defend in depth and prepare each as a single record: the problem, your own contribution, the architecture, the decisions and the alternatives you rejected, an incident or setback, and the outcome. The same record answers the architecture walkthrough, the debugging question, the pride question and the conflict question. Candidates also report that alignment with the organization's mission matters, so read AARP's public initiatives beforehand and prepare a reason for joining that names something specific rather than a general wish to do meaningful work.

The AARP interview process

These are the six stages candidates describe, in the order they report them, over about four to six weeks. Reports say timing varies with the hiring team and the seniority of the role.

Recruiter Screen

The Recruiter Screen is the first reported stage. Be ready to summarise your background and explain your interest in AARP. Reports say the focus differs by team (cloud infrastructure, enterprise platforms or AI), so know which kind of role you applied for. Location also depends on the posting, with some roles tied to Washington, DC and others remote within the United States, so read the posting closely before the call.

What to demonstrate

• How your background lines up with the posting's requirements
• Whether you can state a specific reason for choosing AARP
• Basic logistics such as location fit for the role you applied to

How to prepare

• Write a short career summary that names the AWS, cloud or enterprise-platform work most relevant to the posting
• Map each requirement in the posting to one project you can point to
• Prepare the answer to "Why do you want to work at AARP?" using something specific you read on its public site
• Check the posting's location terms and have your own constraints ready

Hiring Manager Conversation

Next comes a conversation with the hiring manager, which reports say takes a closer look at your background than the screen did. Have a project walkthrough ready, with two projects prepared as decisions rather than technology lists. It is also your chance to ask about the team's stack, technical debt and deployment pipeline.

What to demonstrate

• Depth of your hands-on experience in the stack the team uses
• How clearly you explain past technical choices and their trade-offs
• Your ability to describe your own contribution to team projects

How to prepare

• Prepare two projects, each with the decision you owned, the alternative you rejected and the outcome
• Rehearse the walkthrough behind "Can you walk me through the architecture and technical details of your most recent project?" with a diagram you can sketch from memory
• Write three questions for the manager about team structure, technical debt and how code reaches production

Panel Stage

Candidates report that the Panel Stage is split into distinct sessions, with behavioral conversations in some and technical evaluation in others. Prepare for both behavioral and technical sessions: a debugging scenario in one and a conflict story in another. Your project records should serve both.

What to demonstrate

• Technical reasoning when discussing your own systems
• Behavioral competencies shown through concrete stories
• Consistency between the stories you tell across sessions

How to prepare

• Rehearse a production-debugging answer that follows a fixed sequence: what changed, how you narrowed it, how you mitigated, how you found the root cause
• Have one conflict story and one proud-project story ready, each with an outcome you can state plainly
• Practise explaining a technical decision first to an engineer and then to a non-technical listener

Technical Panel

Reports describe the Technical Panel as a mix of hands-on technical conversation and coding. Separately, the technical topics candidates report for the loop are AWS design, IAM, network services, ServiceNow and cloud computing, and the reported example scenarios also cover code quality and the build-versus-integrate choice for platforms such as ServiceNow or PeopleSoft. Pick the language you are strongest in and be ready to talk while you code.

What to demonstrate

• Working code in a coding exercise
• Cloud design judgment, including scalability and security
• Practical knowledge of IAM and network services as candidates report them
• How you keep code maintainable in daily work

How to prepare

• Work three or four easy-to-medium array, string and hash-map problems aloud in your strongest language, plus one practical task such as parsing a log file, writing a small REST handler with tests, or a Lambda function that calls the AWS SDK
• Prepare a scalable AWS design answer (stateless compute, managed data stores, queues, caching, multi-AZ failure) and be able to explain IAM roles, policies and least privilege and draw a VPC with public and private subnets
• For enterprise-platform postings, review ServiceNow business rules versus client scripts, script includes, Flow Designer and IntegrationHub, the REST and Table APIs, scoped apps and update sets, and ACLs, plus how PeopleSoft integrates through Integration Broker or REST services

Behavioral Panel

The Behavioral Panel is reported to center on questions about how you have handled real situations. The behavioral questions candidates report across the loop include motivation for joining, conflict with a teammate, a project you are proud of, shifting requirements, explaining a technical issue to a non-technical stakeholder and a project that did not go to plan. Use a structure of situation, your actions and a measurable result, and keep stories to what you personally did.

What to demonstrate

• Collaboration and conflict handling
• Communication with non-technical stakeholders
• How you reflect on projects that went badly
• Reasons for wanting this organization specifically

How to prepare

• Write five stories in situation, action, result form: a conflict, a proud project, shifting requirements, an explanation to a non-technical stakeholder and a setback
• Prepare a mission-fit answer that cites one public AARP initiative you can discuss accurately
• Practise each story aloud until the situation takes two sentences and the rest covers your decisions

Final Offer Stage

This is the last reported stage, where the offer and its terms are settled. No technical content is reported here, so use it to confirm the details that depend on your posting: the location arrangement and the other terms in your offer. Have your own priorities decided before the call.

What to demonstrate

• Offer details and employment terms
• Whether the role and location match what you were told during the loop

How to prepare

• Write down the questions you still have about the role, location and deployment practice, and ask for key terms in writing
• Decide beforehand which terms matter most to you and which you can trade
• Reread the posting and your notes from earlier rounds to check that the role described to you matches it

Where candidates lose points

A project walkthrough that lists services and tools but never says why you chose them

For each project, write the two or three decisions you owned, the alternative you rejected and what the choice cost. Practise the architecture story until each component comes with a reason.

A mission answer that could be given to any employer

Read AARP's public initiatives, choose one you can describe accurately and connect it to a specific kind of engineering work you want to do. Say something concrete about what you would build or improve.

Treating IAM and networking as vague background, for instance fixing an access error by granting broad permissions

Be able to explain roles versus users, identity versus resource policies, least privilege and how you would trace an access-denied error. Be able to draw public and private subnets, route tables, NAT and security groups.

A production-incident story that jumps to the fix without a timeline

Tell it in order: how it was detected, what changed, how you narrowed it, how you mitigated, what the root cause was and what you changed afterward. Keep mitigation and root cause separate.

A conflict story that casts the other person as the villain or ends with no resolution

Present both positions fairly, show the evidence you used to decide and report the result and the relationship afterward. Name something you would change in how you handled it.

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

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?

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

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

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

Easy · hashing · at-least-once · aggregation

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

Approach

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

Follow-up

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

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?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

Can you walk me through the architecture and technical details of your most recent project?

Medium · Technical and Project Deep Dive

Approach

1. Open with one sentence on the problem and who used the system, then lay out the components in request order: client, entry point (load balancer or API gateway), services, data stores, async pieces such as queues, and any external or enterprise integrations.
2. Trace one real request end to end, read path and write path separately, and justify each data store by its access pattern: relational for transactional writes and joins, key-value for single-key lookups at high throughput, a cache only where reads repeat.
3. Name two decisions you owned, the alternative you rejected and what it cost. Example: I put a queue in front of a slow downstream to absorb bursts, which made delivery at-least-once, so I made the consumer idempotent with a dedup key.
4. Give the numbers you actually know (request rate, data volume, latency target, error budget) and how you measured them. Keep your own contribution in the first person singular, separate from the team's.
5. Close with a known limitation and what you would change now, so the follow-ups land on ground you have already thought through.

Follow-up

• Which component fails first if traffic grows ten times, and which metric would show it?
• What happens to in-flight work when the external integration is down for an hour?
• If you rebuilt it today, which decision would you reverse and why?

What strategies do you use to ensure code quality and maintainability in your daily work?

Medium · Technical and Project Deep Dive

Approach

1. Automate the cheap checks so review time goes to logic: a formatter and linter, static type checks, and unit tests run in CI on every pull request, with main kept releasable and merges blocked on a red build.
2. Keep pull requests small and single-purpose. As the author I explain why the change exists and how I tested it. As a reviewer I look at correctness, error handling, naming and missing tests, not style, which the tooling already enforces.
3. Design for change: clear module boundaries, and external systems (cloud SDK calls, enterprise platform APIs) behind a thin interface so tests can fake them. Avoid abstracting before the third real use, since a wrong abstraction costs more than duplication.
4. Shape tests as a pyramid: many fast unit tests on business rules, fewer integration tests at the database and API boundaries, a handful of end-to-end checks. Flaky tests get quarantined and fixed quickly because they teach people to ignore failures.
5. Review infrastructure as code (Terraform or CloudFormation) like application code, and track signals that mean something, such as defects reaching production and coverage on changed lines, rather than a global coverage percentage.

Follow-up

• Give an example where a review or a test caught a defect that would have reached production.
• How do you safely change legacy code that has no tests? (Characterization tests that pin current behaviour first.)
• How do you decide when paying down technical debt beats shipping the next feature?

How do you approach designing scalable systems in cloud environments like AWS?

Medium · Technical and Project Deep Dive

Approach

1. Start from requirements: peak and average read and write rates, latency target, data growth, availability target and consistency needs. Do a rough capacity estimate before picking services, since that estimate drives every later choice.
2. Keep compute stateless behind an Application Load Balancer across multiple Availability Zones, scaling with Auto Scaling groups or ECS/Fargate on CPU or request count per target. Lambda suits spiky event-driven work, with cold starts and concurrency limits as the trade-off.
3. Pick the data layer by access pattern: RDS or Aurora with read replicas for relational, read-heavy loads (replicas lag, so read-your-writes paths go to the primary); DynamoDB with a high-cardinality partition key to avoid hot partitions; ElastiCache for hot reads; S3 plus CloudFront for static content.
4. Decouple with SQS or SNS so bursts queue up instead of overloading downstream services. Standard SQS delivers at least once and does not guarantee order, so consumers must be idempotent, with a dead-letter queue for messages that keep failing.
5. Build security and operations in from the start: a least-privilege IAM role per service instead of long-lived access keys, databases in private subnets behind security groups, CloudWatch metrics and alarms on the scaling signals, and everything defined as code.

Follow-up

• How do you control access between services and to the data, and how do you audit it?
• Which tier becomes the bottleneck at ten times the load, and what does fixing it cost?
• How does the design survive the loss of an Availability Zone, and what would a multi-region setup add in cost and complexity?

How do you handle debugging and troubleshooting in a complex production environment?

Medium · Technical and Project Deep Dive

Approach

1. Triage before diagnosis: size the impact (which users, endpoints, regions) and mitigate first with a rollback, a feature-flag switch-off or extra capacity, because restoring service comes before explaining it.
2. Build a timeline of what changed near the onset: deploys, config, dependency versions, traffic shape, and permission changes. On AWS, CloudTrail records API calls, so an edited IAM policy or security group shows up with who changed it and when.
3. Locate, then explain: per-service rate, error and latency metrics narrow the failing component, a correlation or trace ID finds the failing hop, and logs give the exact error. Confirm the instrumentation is accurate before trusting the symptom.
4. Test one hypothesis at a time with a check that splits the candidates either way: compare a failing host with a healthy one, bisect recent deploys, or reproduce in staging with production-shaped data. For an AccessDenied, the IAM policy simulator shows which statement denies the call.
5. Finish with the root-cause fix, a test or alert that would have caught it earlier, and a blameless write-up with the timeline, keeping the trigger (often a deploy) separate from the underlying cause.

Follow-up

• Errors appear on only some hosts after a deploy. What do you check first, and what does it rule out?
• How do you debug an intermittent failure you cannot reproduce locally?
• A deploy and a traffic spike happened in the same minute. How do you tell cause from coincidence?

Suggested practice checklist

The plan follows the six reported rounds: project stories first, then AWS design and enterprise platforms, IAM and networking, debugging and code quality, coding and SQL warm-ups, behavioral stories and a mixed dry run.

Day 1 — Map the loop and inventory your projects

• Write the six reported rounds in order and next to each what candidates report about it: the screen, the manager conversation, the split panel sessions, the technical panel with coding, the behavioral panel and the offer stage.
• Read the target posting and highlight the focus area (cloud infrastructure, enterprise platforms or AI), the languages and the location terms.
• Choose three projects and write one record for each: problem, your contribution, architecture, decisions and rejected alternatives, a setback, outcome.

Deliverable: A one-page loop map with the posting's requirements highlighted, plus three project records with decisions and outcomes.

Day 2 — AWS design, enterprise platforms and the architecture walkthrough

• Redraw your strongest project as AWS-style components and write out the read path, the write path and the first bottleneck at ten times the traffic.
• Answer aloud: "Can you walk me through the architecture and technical details of your most recent project?" and "How do you approach designing scalable systems in cloud environments like AWS?"
• Write the criteria you would use to choose between a custom build and an integrated platform such as ServiceNow or PeopleSoft: fit, customization cost, upgrade path, integration surface, security and staff skills.
• For an enterprise-platform posting, write one line each on ServiceNow business rules versus client scripts, script includes, Flow Designer and IntegrationHub, the REST and Table APIs, scoped apps and update sets, and ACLs, plus how PeopleSoft exchanges data through Integration Broker or REST services.

Deliverable: An architecture diagram, a spoken scalable-design answer, a one-paragraph build-versus-integrate rule and, for platform postings, a ServiceNow and PeopleSoft cheat sheet.

Day 3 — IAM and network services

• Write from memory how IAM works: users, groups, roles, trust relationships, identity versus resource policies, least privilege and how you would debug an access-denied error.
• Draw a VPC with public and private subnets, route tables, internet gateway, NAT, a load balancer, security groups and network ACLs, and say which traffic each allows.
• Explain aloud how you would secure access in a cloud architecture for an internal platform, naming the control at each layer.
• If the posting is AI-focused, outline how you would put a hosted model API behind a service: the key held in Secrets Manager and read through an IAM role, rate limits and retries, a fallback when the model is unavailable, and how you would evaluate its outputs.

Deliverable: A one-page IAM and networking sheet in your own words, a spoken security answer and, for AI postings, a short model-integration outline.

Day 4 — Debugging and code quality

• Write one real production incident as a timeline: detection, what changed, how you narrowed it, mitigation, root cause and follow-up.
• Answer aloud: "How do you handle debugging and troubleshooting in a complex production environment?" using that incident as the example.
• List the code-quality practices you actually use, such as review, tests, CI checks, small changes and documentation, and attach a concrete example to each for "What strategies do you use to ensure code quality and maintainability in your daily work?"

Deliverable: An incident timeline, a debugging answer built on it and a list of code-quality practices with an example each.

Day 5 — Coding and SQL warm-up

• Write the SQL for the practice problem on keeping soft-deleted accounts from blocking re-registration, and explain the partial unique constraint you chose.
• Solve the coding practice problem on collapsing a redelivered event batch into per-aggregate high-water marks in your strongest language, stating time and space complexity.
• Finish with one practical task of your own: parse a small log file into per-endpoint error counts, with tests.

Deliverable: Two SQL drills written as queries with the index or partial unique constraint each needs, one coding solution with its complexity and edge cases, and one tested log-parsing script.

Day 6 — Behavioral stories and mission research

• Spend the first part reading AARP's public initiatives and write two you can describe accurately with the engineering angle that interests you.
• Write situation, action and result outlines for the four reported behavioral questions, using your project records; set the conflict story with a system administrator or product manager.
• Add two more stories: a project that went off plan and an explanation of a technical problem to a non-technical stakeholder, then say each aloud.

Deliverable: Four reported answers and two extra stories written as outlines and rehearsed aloud, plus two mission notes.

Day 7 — Mixed dry run

• Run a mock that alternates technical and behavioral questions, with one question from each day's material.
• Write the questions you will ask about team culture, technical debt and deployment pipelines.

Deliverable: A completed mixed mock with a list of weak spots to fix, one more coding solution and your interview questions.

Mission, conflict and project stories

Candidates report behavioral questions about why you want to work at AARP, which of its initiatives interest you, conflict with a teammate, a project you are proud of and how you handled changing requirements. Prepare stories that show your own decisions, how you work with product managers, administrators and other engineers, and what you learned. Use situation, action and result, and give the outcome plainly.

1. Describe a project that went off plan and what you took from it.
2. Explain a complex technical problem you had to describe to a non-technical stakeholder.

Why do you want to work at AARP?

Medium · Behavioral and Culture Fit

Approach

1. Give the answer three parts: a personal reason you care about the mission, what you know about the work, and what you bring. A reason that could be pasted into any employer's application is the one to avoid.
2. Do the research ahead: read AARP's public site and note one or two initiatives or member-facing services. Describe them accurately and connect them to your own engineering interests, for example modernizing legacy applications, cloud migration or access security for large user populations.
3. Link your experience to the work candidates describe: AWS, enterprise platforms such as ServiceNow or PeopleSoft, automation. Name one project that shows it.
4. Keep it short and finish on what you want to build there, not on what the job would give you.
5. If you have a personal connection to the mission, such as a family member who used a service, say so briefly and truthfully.

Follow-up

• What do you know about how members use AARP's digital services?
• What would you want to work on in your first months here?
• What would make you choose this role over a similar one at another organization?

What specific projects or initiatives at AARP are memorable or interesting to you?

Medium · Behavioral and Culture Fit

Approach

1. Choose one or two initiatives or services that you read about on AARP's public channels and can describe correctly in a sentence. If you cannot explain it without notes, pick a different one.
2. State what drew you to it and add an engineering angle in your own words: what you think makes it technically hard, such as accessibility, traffic spikes, identity and access, or integrating older enterprise systems.
3. Tie it to something you have built, so the answer shows how your skills would apply instead of reading as general admiration.
4. Do not invent knowledge of internal projects or claim to know how a service is built. Ask a question about it instead, which shows curiosity without overclaiming.
5. Avoid flattery. A precise detail and a thoughtful question carry more than praise.

Follow-up

• How would you improve that service from an engineering point of view?
• How would you measure whether it is working for the people who use it?
• Why that initiative and not one of the others?

Tell me about a time you had a conflict with a team member and how you resolved it.

Medium · Behavioral and Culture Fit

Approach

1. Choose a real disagreement with someone from another function, which fits the cross-functional work candidates describe: for example a system administrator over the cutover plan for a cloud migration or an access-control change, or a product manager over customizing an enterprise platform versus keeping it out of the box. Avoid a personality clash where the other person is simply the problem.
2. Describe the situation in two sentences, then each position fairly: what the other person wanted, why it was reasonable (an administrator protecting stability, a product manager protecting a deadline) and what each option would have cost.
3. Show what you did: you asked questions to understand their view, restated it, then moved the conversation from opinion to evidence, such as a rehearsal of the cutover in staging, a rollback plan, a list of upgrade risks from a customization, or a written decision note. Bring in a manager only if you were genuinely stuck, and say so.
4. State the result, including the relationship afterward and what changed in how you work. A story where you won tells less than one where you and the other person reached a better decision.
5. Do not make yourself right in every detail. Name one thing you would do differently.

Follow-up

• What if the other person had still disagreed after you showed the evidence?
• How is your working relationship with that person now?
• Did you involve your manager, and when would you?

Describe a project you worked on previously that you are most proud of.

Medium · Behavioral and Culture Fit

Approach

1. Choose a project you can defend technically, because the same story may be pulled into an architecture discussion. Pride is easier to believe when the details hold up.
2. Open with the problem and who used the result, then your specific role. Separate what you owned from what the team did.
3. Cover two or three decisions with the alternative you rejected and why. Include a setback and how you handled it, since a project with no difficulty sounds rehearsed.
4. Give the outcome with numbers you actually have, such as latency, cost, incidents or adoption. If you have no measurement, say what you observed rather than inventing a figure.
5. Finish with maintainability: how others took it over, how it was tested and monitored, and what you would change now.

Follow-up

• What was the hardest decision, and what did you give up?
• How did you know the project succeeded?
• What would you do differently if you built it again?