Analysis, Custom Resume & Interview Prep
Each job posting has its own workspace with three stages. You unlock them in order — analysis first, then the customized resume, then interview prep when you've applied.
The three stages
Stage 1: Analysis
From the dashboard, click View on any Good match, then click Analyze this role.
INAJ runs a detailed fit assessment covering: Role Summary, Fit Assessment (what matches and what doesn't), Skill Gaps, Strengths (what in your background is particularly relevant), and a Customization Plan for your resume.
While it runs, a progress banner appears at the top of the same page, showing your position in the queue and an estimated wait time. You can keep reading the rest of the page while you wait — the page refreshes itself with the results when it's done. Most analyses complete within 1–3 minutes.
Takes 1–3 minutes · You'll see your results on this page when it's done.
Here's what a completed analysis looks like:
Role Summary
| Attribute | Detail |
|---|---|
| Role type | Individual Contributor |
| Domain | Infrastructure / Platform |
| Function | Site Reliability / Platform Engineering |
| Seniority | Staff |
| Work mode | Remote (US timezone overlap required) |
| Team size | 10–15 engineers across two sub-teams |
| TL;DR | Own reliability and capacity planning for a distributed data pipeline serving 50 M events/day; drive the on-call rotation overhaul the team has been deferring. |
Match with CV
| JD Requirement | Your Experience |
|---|---|
| 5+ years SRE or platform engineering at scale | 7 years; Acme Corp platform team (2022–present) + prior infra role at Initech |
| Led migration of a monolithic system to distributed architecture | Drove monolith→microservices migration at Acme — directly matches the TL;DR ask |
| Kubernetes (EKS or GKE) — production ownership | Owns EKS clusters at Acme; authored cluster autoscaler runbooks |
| On-call program design or overhaul | Not explicitly stated in CV — worth surfacing if you have informal experience here |
| Strong written communication / RFC authorship | CV lists two architecture RFCs merged to company standards; strong match |
Fit Assessment
Strengths: The platform migration experience is the strongest signal — the JD spells out that problem explicitly. Your Kubernetes ownership and tenure are direct matches for the level and scope. Written communication history differentiates you at Staff level where influence-without-authority matters.
Gaps: On-call program design is the only named requirement that doesn't appear in your CV. If you've touched this informally, the custom resume will add a bullet; if not, be ready to address it in screening.
Skill Gaps
No hard blockers. The on-call program gap is soft — the JD frames it as a project to drive, not a baseline credential. Strong overall fit.
Stage 2: Custom Resume
Once the analysis is complete, the "Generate customized resume" button unlocks.
The generated PDF is the same resume you uploaded, re-emphasized for this specific posting — the same accomplishments, re-framed around what this hiring manager is scanning for.
Download the PDF and apply directly.
Produces a PDF tailored to this posting · Usually ready in under a minute.
Along with the PDF, INAJ shows you a change log explaining every edit it made and why — so you know exactly what was re-framed and what the risk is if you revert it:
What we tailored for this role
| Section | Original | Tailored | Why | Risk if you reverse it |
|---|---|---|---|---|
| Summary | ‘Led platform migration from monolith to distributed system across Acme Corp’s infrastructure…’ | ‘Staff Platform Engineer with 7 years leading reliability and migration programs for distributed systems at scale…shifting teams from ad-hoc deployments to SLO-driven, automated delivery…’ | The JD’s first requirement is SLO ownership; adds that vocabulary and the reactive→proactive narrative that appears verbatim in the key responsibilities section. | Generic framing applies to a wider range of roles; reverting keeps you competitive for non-SLO-focused infrastructure positions. |
| Skills section | Not present in original | Added 6 keyword-dense phrases: SLO & Error Budget Design, Kubernetes (EKS) Ownership, CI/CD Consolidation, Platform Migration, On-Call Program Design, RFC Authorship. | ATS keyword density and hiring panel scanability; all 6 map directly to named sections in the JD. | These phrases are tuned to this platform/SRE role; a broader skills list performs better for general software engineering applications. |
| Acme Corp bullet 1 | ‘Responsible for the installation, configuration, and maintenance of the platform infrastructure’ | ‘Owned platform reliability for 15 internal product teams; drove monolith→microservices migration over 14 months with zero SLA breaches…’ | Replaces operational/maintenance framing with outcome-ownership language that matches Staff-level scope expectations; Staff is defined as owning results, not executing tasks. | Operational framing is accurate and appropriate for Senior IC or M3-adjacent roles; reverting reads as executor rather than owner. |
| Acme Corp bullet 3 | ‘Reduced deployment incidents by implementing rollback automation’ | ‘Designed automated canary rollback triggers; cut mean time to recovery from 22 min to under 4 min across 15 teams…’ | The posting explicitly names on-call process design; adding MTTR numbers and the canary detail mirrors the key responsibilities language directly. | The original customer-impact framing is broader; reverting preserves applicability to infrastructure roles where MTTR framing is less central. |
LinkedIn outreach contacts
When you generate the customized resume, INAJ also looks up the people worth contacting at that company — the hiring manager, a recruiter, and a few people on the team you'd be joining — and adds a LinkedIn Outreach Contacts section to the bottom of the report. For the best target it drafts a ready-to-send LinkedIn connection message (under 300 characters) you can copy, tweak, and send, plus a couple of alternates.
Titles change, so verify each person's current role on LinkedIn before you reach out. If INAJ can't confidently find anyone, the section tells you so and points you at a LinkedIn search to run yourself.
LinkedIn Outreach Contacts
Here are the people worth contacting at Acme Robotics about the Staff Platform Engineer role. Verify each person's current title on LinkedIn before reaching out.
- Dana Reyes — hiring manager (Director, Platform Engineering) · primary target
- Sam Olufemi — recruiter (Technical Recruiter)
- Priya Natarajan — team peer (Senior SRE)
Suggested message to Dana (the hiring manager):
Hi Dana — I saw the Staff Platform Engineer opening on your team. I led a monolith-to-microservices migration with a 99.9% SLA at Acme Corp, which lines up closely with the reliability and migration work in the posting. Would love to connect and learn more about what you're building.
Stage 3: Interview Prep
After marking a role applied, the "Got an interview?" button unlocks on the workspace.
INAJ generates a prep brief covering: company background and recent news, the team you'd be joining, likely interview questions for this role, and your strongest answers based on your background.
Generates a prep brief · Covers company research, team background, and likely questions.
Here's what a completed interview prep brief looks like:
Company Deep Dive
Strategy and Product
Acme Robotics is a mid-stage industrial automation company ($180 M ARR, Series D) building warehouse automation systems for e-commerce fulfillment centers. Their core product is an orchestration layer that coordinates fleets of autonomous mobile robots (AMRs) across large facilities. The platform engineering role sits inside the infrastructure org that keeps that orchestration layer running — 99.9 % uptime is a contractual SLA, not an aspiration.
Their stated roadmap priorities are expanding into cold-storage facilities (harder real-time constraints) and building a multi-tenant SaaS offering on top of their existing on-premise platform. The platform migration experience in your background is directly relevant to the second priority.
Recent Moves (last 6 months)
Acme Robotics does not publish engineering-level technology news at the cadence of a software company. The signals below are drawn from job postings, LinkedIn activity, and press releases. Treat anything here as directional and verify against recent news before your interview.
- Kubernetes-first hiring wave: Four of the last six infrastructure hires listed Kubernetes as a primary requirement — consistent with a team standardizing on container orchestration ahead of the SaaS buildout.
- SOC 2 Type II certification announced: Press release from March 2026 cites completion of their first SOC 2 audit. Expect compliance guardrails to be part of the conversation — they've recently learned what "audit-ready infrastructure" costs in practice.
- Parallel VP Engineering hire: LinkedIn shows they posted a VP Engineering (Platform) role alongside this one — a signal that this team is being stood up deliberately, not backfilling an existing org.
Engineering Culture
The JD signals a team that is in the process of building discipline, not one that already has it. Expect inconsistent IaC maturity across services, a mix of handcrafted and automated deployments, and a strong emphasis on reliability over velocity given the SLA commitments. You'd be arriving to create the standards, not enforce ones that already exist.
Tech stack signals from the JD:
- Cloud: AWS primary; some GCP workloads for ML inference.
- Orchestration: Kubernetes (EKS), moving from Docker Compose on-premise deployments.
- CI/CD: GitHub Actions listed; Jenkins implied by legacy references — a heterogeneous mix that is part of what this role is meant to consolidate.
- Observability: Datadog mentioned; some teams still on home-built alerting.
Likely Challenges
- Legacy on-premise install base: Existing customers run on-premise. Any SaaS migration involves parallel maintenance and careful customer migration sequencing — exactly the problem you solved at Acme Corp.
- On-call culture reset: The JD calls out "on-call program overhaul" explicitly. Expect the current rotation to be ad-hoc and pain to be high.
- Cross-team IaC adoption: Standardizing Terraform across teams that have been writing their own CloudFormation is a change management problem as much as a technical one.
Interview Plan
Likely Questions (with your strongest answers)
Q: How would you approach migrating a platform from on-premise to a multi-tenant SaaS architecture?
A: At Acme Corp I led a monolith-to-microservices migration that covered roughly the same set of concerns — decomposing a tightly coupled system, maintaining existing customers during the transition, and building the observability and deployment tooling to operate the new architecture safely. My approach was: first build the shared infrastructure plane (networking, secrets, observability) before moving any workloads, so each migration is a lift-and-shift into a known-good environment rather than discovering infrastructure gaps mid-migration. The mistake I'd avoid is letting the scope creep into feature parity work — the first SaaS milestone should be "operationally equivalent to what customers have today," not "and here are three new features."
Q: Tell me about a time you owned reliability for a system with contractual SLA commitments.
A: The platform at Acme Corp serves internal product teams with a 99.9 % availability commitment. The biggest reliability lesson I took from that was that most SLA breaches trace back to deployment risk, not hardware failure. I drove the team to instrument every deployment with automated rollback triggers — if error rate climbs more than X % within five minutes of a deploy, we roll back automatically without a human decision. That change cut our mean time to recovery from 22 minutes to under 4 because we stopped waiting for an on-call engineer to diagnose before acting.
Q: What's your approach to getting a team that's resistant to IaC adoption on board?
A: Resistance usually comes from one of two places: engineers who feel like IaC is overhead that slows them down, or engineers who've been burned by IaC tooling that was more complex than the problem it was solving. The approach that's worked for me is starting with the infrastructure that already causes the most pain — if provisioning a new environment takes three days of ticket-passing today, automating that first creates a win the skeptics can point to. I've found that the second or third person to use a module you built is more persuasive than anything you can say about best practices.
STAR Stories from Your Resume
Monolith-to-microservices migration at Acme Corp
- Situation: Acme Corp's platform was a monolithic Rails application serving 15 internal product teams. Deployment windows required coordinating across all teams, a single failure could affect the entire platform, and scaling any component meant scaling the whole application.
- Task: Lead the architectural migration to a microservices-based platform while maintaining 99.9 % availability for existing teams and without a feature freeze — product teams continued shipping throughout the migration.
- Action: Defined service boundaries with domain leads, established the shared infrastructure plane (EKS, service mesh, centralized secrets), migrated services in dependency order starting with the least-coupled leaf services, and built automated canary deployments so each migration could be validated before cutover.
- Result: Completed the migration over 14 months. Deployment frequency increased from weekly coordinated releases to per-team continuous delivery. P95 latency for the highest-traffic services dropped 40 % after right-sizing. No SLA breach during the migration period.
- Reflection: The hardest part wasn't technical — it was getting teams to own their own deployment pipelines when they'd always had a central team do it. I would have started the team enablement work earlier rather than treating it as something that would happen naturally once the infrastructure was ready.
Waiting for a stage
When any stage job runs, a progress banner appears at the top of the workspace showing your position in the queue ("N jobs ahead of yours") and an estimated wait time. You stay on the page — the rest of it stays readable, and it refreshes itself with the new results when the job finishes. If it gets stuck, use the Retry button. The queue is shared across all stages — analyses, resume generations, and interview preps all go through the same pipeline.