Current Project & Day-to-Day Activities
This page is a rehearsal tool, not a script to recite word for word. Everything on it is grounded in real work at _VOIS (Vodafone Intelligent Solutions) — the goal is to trigger your own memory of what you actually did, so you can speak about it fluently and confidently, not to hand you lines to memorise. Anywhere you see a [bracket], that's a real specific only you can fill in — a number, a tool version, a ticket type, a team name. Never let a bracket stand in as a spoken answer; fill it with your own recalled detail before you say it out loud, or speak around it honestly if you genuinely can't recall the exact figure.
These sound similar but want different answers. "Tell me about your project" wants the technical shape — what the system does, what stack it runs on, what you specifically owned. "What does your day-to-day look like" wants the operating rhythm — tickets, ceremonies, the 5 recurring areas (K8s, Terraform, CI/CD, Git, observability), and that it's a cycle, not a one-time build. "Tell me about a POC or something you built from scratch" wants a bounded, self-contained story with a clear before/after — different again from describing an ongoing, shared production system. Confusing these three is the single most common way a genuine, solid answer comes across as vague.
"Tell me about your current/most recent project"
The technical shape: what the system does, what stack it runs on, what you specifically owned — not a chronological life story.
At _VOIS (Vodafone Intelligent Solutions), you worked as a Cloud & DevOps Engineer supporting a landscape of 30+ microservices for [example: a specific Vodafone business unit or product line — fill in what you actually supported]. Your role sat across the full delivery path: CI/CD pipelines, GitOps-driven deployment to Kubernetes, infrastructure provisioning, and the observability that keeps all of it honest in production.
Concretely, the stack: CI/CD pipelines (Jenkins and/or GitHub Actions — [fill in which you actually used, and for which services]) feeding ArgoCD for GitOps-style continuous delivery into Amazon EKS, with Helm charts packaging each service's Kubernetes manifests. Infrastructure itself was provisioned through Terraform modules — cutting environment setup from days to hours — with Ansible for configuration management on top. Security was built into the pipeline with SonarQube (code quality) and Trivy (container/dependency scanning), with secrets handled through [AWS Secrets Manager / whichever secrets tool you actually used]. Observability ran on Prometheus, Grafana, Alertmanager, and Loki — roughly 10 dashboards — which took incident detection from about 30 minutes down to under 10.
"What does your day-to-day look like?"
The operating rhythm — not a one-time build, a cycle you run continuously across five recurring areas.
A typical day moves through JIRA tickets — a mix of planned sprint work (a new service onboarding, a pipeline template improvement) and reactive tasks (an alert that fired overnight, a developer blocked on a Kubernetes issue). The five areas that recur constantly: Kubernetes (debugging pod/deployment/service issues for other teams, since you're often the K8s subject-matter expert they come to), Terraform (extending or reviewing infrastructure modules), CI/CD (maintaining and improving the Jenkins/GitHub Actions pipelines and the ArgoCD GitOps flow), Git (reviewing PRs, managing branching for releases), and observability (tuning alerts, building dashboards, being part of the 24/7 on-call rotation).
A1How big is your team, and how is the work split?reveal ▸
[Fill in: team size, whether it's a dedicated DevOps/platform team serving multiple product teams, or embedded within one product team. Mention roughly how the DevOps/Cloud engineers split ownership — by service, by environment, or by function (pipelines vs infra vs monitoring).]
A2Who do you report to, and who do you work with most closely day to day?reveal ▸
[Fill in your actual reporting line and the roles you interact with most — likely the development teams whose services you support, plus your own DevOps/platform lead.]
A3Is the DevOps function centralized, or does each product team have its own DevOps engineer?reveal ▸
[Fill in: was this a shared/central DevOps team serving the 30+ microservices across multiple product teams, or embedded per-team? This shapes how you describe scale and self-service tooling.]
A4How do you and the development teams typically communicate — tickets, Slack, meetings?reveal ▸
[Fill in the actual mix — JIRA tickets for planned work, a Slack/Teams channel for real-time asks, and whichever recurring syncs actually happened.]
B1Walk me through your JIRA workflow, end to end.reveal ▸
Backlog → refinement with story points (Fibonacci) → sprint planning against capacity → the sprint itself with daily stand-ups and a mid-sprint check → sprint review/retrospective → velocity and burndown tracking. [Confirm this matches what your team actually ran, and adjust for anything different — e.g. if you used Kanban instead of Scrum for some of the work.]
B2Do you use Scrum, Kanban, or a mix?reveal ▸
[Fill in what your team actually ran. A DevOps/platform team often runs more Kanban-like for interrupt-driven support work (production issues, ad hoc requests from other teams) and Scrum-like for planned improvement work — if that matches your experience, say so; it's a genuinely senior distinction to draw.]
B3How do on-call and incident response actually work on your team?reveal ▸
[Fill in: rotation length/frequency, what tool pages you (PagerDuty, Opsgenie, or an internal system), and what the escalation path looks like. Mention the 24/7 on-call responsibility and the ~99.9% uptime target from your resume as the outcome this process supports.]
B4How do code changes actually get from a developer's laptop to production?reveal ▸
A PR against the service's Git repo → CI runs (SonarQube + Trivy scans, tests) → merge → the CI/CD pipeline builds and pushes an image → ArgoCD detects the new manifest/image reference and syncs it into EKS. [Confirm the exact trigger — does merging to main auto-deploy, or is there a manual promotion/approval step per environment?]
C1How do you report status or incidents up to your manager or leadership?reveal ▸
[Fill in: a regular status update format, an incident postmortem template, or a dashboard leadership checks directly. If you led or contributed to postmortems, that's a strong, concrete detail to include here.]
C2How do you measure whether your work is actually improving things?reveal ▸
The concrete numbers from your own experience: environment setup time cut from days to hours via Terraform, incident detection time down from ~30 minutes to under 10 via the monitoring stack, ~60% reduction in manual effort via Python/Shell automation, and ~99.9% uptime maintained. These map directly onto the DORA metrics — lead time, and a stability signal.
C3Who owns the AWS cost/billing conversation, and were you involved in it?reveal ▸
Yes — per your resume, AWS cost cleanup was part of your remit. [Fill in a specific example: identifying idle/oversized resources, right-sizing instances, cleaning up orphaned volumes/snapshots — use the Virtual Machines chapter's fleet-hygiene drills on this site as a prompt for what specifically you did.]
D1You mentioned reusable pipeline and Terraform templates — who uses them, and how did they get adopted?reveal ▸
[Fill in: were these templates built for the whole 30+ microservice landscape as a self-service option? How did a new service onboard — copy a template repo, use a scaffolding tool, request it from your team? This is exactly the kind of "platform engineering" framing from the Fundamentals chapter's DevOps-vs-SRE-vs-Platform-Engineering distinction.]
D2You mentioned mentoring juniors — what did that actually involve?reveal ▸
[Fill in a specific example: pairing on a real Kubernetes/Terraform task, reviewing a junior's PRs with real feedback, walking someone through the on-call process for the first time. A concrete story here is far stronger than "I mentored juniors" as a bare claim.]
D3Which of the ~10 Grafana dashboards do you personally look at most, and why?reveal ▸
[Fill in: which dashboard(s) you actually built or relied on most — a cluster health overview, a specific service's error-rate/latency panel, a cost dashboard. Being able to name one specifically, rather than speaking only in the abstract about "the dashboards," is what makes this claim credible.]
D4How did you actually get incident detection from 30 minutes down to under 10?reveal ▸
[Fill in the specific mechanism: was it adding alerting rules that hadn't existed before, building dashboards that made a slow manual check into an instant visual read, reducing alert noise so a real signal wasn't buried, or a combination? This is the single most interview-worthy number on your resume — have a real, specific story behind it, not just the number.]
D5What did the Python/Shell automation that cut manual effort by ~60% actually automate?reveal ▸
[Fill in a specific script or category of scripts — an AWS resource audit/cleanup script, a repetitive JIRA/GitHub API task, a log-parsing or report-generation script. The Python chapter's Lab section on this site (requests/APIs, boto3) is a good prompt for the shape this likely took.]
D6Is this project a one-time build, or ongoing work?reveal ▸
Ongoing — this is the core distinction from Part 2's mental model. The 30+ microservices, the pipelines, and the monitoring stack are live production systems under continuous maintenance and improvement, not a project that shipped once and stopped. New services onboard, existing ones evolve, and the SDLC keeps cycling for as long as they're in use.
Keep these three cleanly separate in your head before you walk in. Your project answer is the technical shape of the systems you support. Your day-to-day answer is the operating rhythm — tickets, the five recurring areas, on-call, and that it's a cycle. A POC or something built from scratch question wants a different, bounded story with its own before/after — if you don't have a clean one from VOIS, it's fine to say your work has mostly been on live, shared production systems rather than greenfield builds, and pivot to the strongest example you do have.
The hardened, VOIS-grounded deep-dive answers
A note on the bracket convention before you read further: every [example: …] or plain […] below is a placeholder for a real detail from your actual VOIS work. Read through, and next to each one, write down (mentally or literally) what you actually did — then the answer becomes yours, not a script.
The project, hardened against follow-ups: "I was a Cloud and DevOps Engineer at Vodafone Intelligent Solutions from November 2021 to September 2025, supporting a landscape of over 30 microservices for [your business unit]. Deployments went through CI/CD pipelines — [Jenkins / GitHub Actions, whichever you actually ran, and note if it was a mix] — into ArgoCD for GitOps-style delivery onto EKS, with Helm managing the Kubernetes manifests per service. Infrastructure was Terraform, modularised so a new environment went from taking days to taking hours; Ansible handled configuration management on top of that. Security was built into the pipeline itself with SonarQube for code quality and Trivy for container and dependency scanning, with secrets in [your actual secrets tool]. On the operations side, Prometheus, Grafana, Alertmanager, and Loki gave us around ten dashboards, and that observability investment is what took our incident detection time from roughly thirty minutes down to under ten. I also built reusable pipeline and Terraform templates so new services could largely self-serve their setup, and automated a lot of the recurring manual toil with Python and Shell, cutting that effort by around 60% on the tasks we targeted. We ran a 24/7 on-call rotation and held around 99.9% uptime across the services I supported."
The day-to-day, hardened against follow-ups: "Day to day, my work comes out of JIRA — a mix of planned sprint work and reactive tickets, since a lot of what a platform-facing DevOps engineer does is interrupt-driven. It clusters into five recurring areas: Kubernetes, since I'm often the person other teams escalate to when a pod, deployment, or service is misbehaving; Terraform, extending and reviewing our infrastructure modules; the CI/CD pipelines and ArgoCD GitOps flow; Git, mostly PR review and managing release branches; and observability — tuning alerts, building dashboards, and covering on-call. None of this is a one-time build; it's a genuine cycle, where what the monitoring surfaces becomes tomorrow's ticket."
P1Why ArgoCD specifically, rather than a simpler push-based deploy from the CI pipeline?reveal ▸
GitOps with ArgoCD means the Git repo is the single source of truth for what should be running — ArgoCD continuously reconciles the cluster to match it, which catches drift (a manual kubectl change) automatically, and gives a clean audit trail of every deployment as a Git commit. [If your team had a specific reason it was chosen over a push-based approach — an audit/compliance need, self-healing, multi-cluster consistency — name it.]
P2How many environments does a typical service go through before production?reveal ▸
[Fill in your actual environment chain — e.g. dev → staging/UAT → production — and whether promotion between them is automatic or requires manual approval at any stage.]
P3Are the Terraform modules organised per-service, per-environment, or some other split?reveal ▸
[Fill in the actual module structure and state-isolation strategy you used — this maps directly to the Terraform chapter's state-splitting and blast-radius concepts on this site.]
P4What's actually in the ~10 Grafana dashboards?reveal ▸
[Fill in: likely a cluster-health overview (node/pod resource usage), per-service error rate and latency panels, a cost dashboard, and an Alertmanager status view. Name at least one specifically and what it actually shows.]
P5How do SonarQube and Trivy fit into the pipeline — do they block a merge/deploy, or just report?reveal ▸
[Fill in: did a failing quality gate or a critical CVE finding actually block the pipeline, or was it advisory/reported-only at the time? This is a genuine and common maturity distinction worth being honest about.]
P6What's an example of a service that was hard to migrate onto this platform, and why?reveal ▸
[Fill in a real example if you have one — a stateful service, one with an unusual dependency, or one whose team needed convincing. Use the War Stories templates in Part 5 to build this into a full Situation → Action → Tool → Outcome story.]
D1Walk me through what happens from the moment an Alertmanager alert fires.reveal ▸
[Fill in: does it route to Slack/Teams, page via PagerDuty/Opsgenie, or both depending on severity? Who's expected to acknowledge it, and within what time? This is exactly the kind of detail a real practitioner has and a memorised answer doesn't.]
D2When another team escalates a Kubernetes issue to you, what does that conversation actually look like?reveal ▸
[Fill in a real example — a crash-looping pod, a service that couldn't reach another service, a resource-limit issue. Walk through your actual diagnostic steps: kubectl describe/logs, checking recent deployments, checking resource quotas.]
D3How do you decide what to automate with Python/Shell versus what stays manual?reveal ▸
[Fill in your actual rule of thumb — likely: anything repetitive, error-prone by hand, or blocking someone regularly. Name one specific script you wrote and what triggered the decision to automate it.]
D4How do you keep the reusable pipeline/Terraform templates from drifting out of date as the platform evolves?reveal ▸
[Fill in: was there a versioning scheme for the templates, a deprecation/migration process when they changed, or a more ad hoc update-and-notify approach? This maps to the Kubernetes/Docker chapters' golden-image and template-drift concepts.]
D5What's the split between time spent building new things versus keeping existing things running?reveal ▸
[Fill in your honest estimate — a DevOps/platform role supporting 30+ live services is typically weighted toward keeping things running and improving, not constant greenfield building. Being honest about this ratio is more credible than implying it's mostly new development.]
D6What would you say is the single hardest part of supporting 30+ microservices as opposed to just one or two?reveal ▸
[Fill in your real answer — likely something about consistency at scale (why the reusable templates existed in the first place), or the cognitive load of context-switching between different teams' issues, or coordinating changes that touch shared infrastructure across many services.]
Your real war-story bank
4–5 true stories in a Situation → your action → tool → measured outcome shape, so you have proof, not polish. Fill in each one with something that actually happened — these are templates, not answers.
Situation: [A real production incident you were involved in — an outage, a failed deployment, a resource exhaustion event.]
What you did: [Your specific actions — what you checked first, what you found, what you changed.]
Tool: [kubectl, Grafana/Prometheus, CloudWatch, whatever you actually used.]
Measured outcome: [Time to resolution, whether it fed into a postmortem, what changed afterward to prevent a repeat.]
Situation: [The AWS cost cleanup work, or the environment-setup-time reduction, or the ~60% manual-effort cut — pick the one you remember most concretely.]
What you did: [The specific steps — an audit, a Terraform module rewrite, a script.]
Tool: [Terraform, AWS Cost Explorer, Python/boto3, whichever applies.]
Measured outcome: [The actual number — days-to-hours, the 60% figure, or a cost figure if you have one.]
Situation: [A junior engineer you helped, or a development team you unblocked on a Kubernetes/Terraform issue.]
What you did: [Specifically what you explained or paired on.]
Tool: [Whatever the technical context was.]
Measured outcome: [Did they become able to handle it independently afterward? Did it become a documented runbook for the wider team?]
Situation: [A real mistake or close call — a bad deployment, a Terraform apply that did something unexpected, a misconfigured alert that caused noise or silence.]
What you did: [How you recovered, and crucially, what you did afterward — a regression test, a new safeguard, a process change.]
Tool: [Whatever was involved.]
Measured outcome: [The fact that it didn't recur, or a concrete process/tooling change that resulted.]
Situation: [The reusable pipeline or Terraform template work — what problem existed before it (every team building their own pipeline from scratch, inconsistent setups).]
What you did: [What the template actually standardised, and how a new service adopted it.]
Tool: [Terraform modules, a pipeline template repo, Helm chart templates.]
Measured outcome: [How many services adopted it, or the setup-time reduction from days to hours.]
Mapping your real 5 years onto this course's concepts
So "I know what a canary is" becomes "here's a canary I ran and what broke." Fill in the right-hand column with your own recalled specifics.
| Course concept | Your real version (fill in) |
|---|---|
| GitOps / ArgoCD sync | [A time a manual cluster change drifted from Git and ArgoCD corrected it, or a sync failure you had to debug.] |
| Terraform state & blast radius | [How your modules were split per-service/per-environment, and any state issue (lock, drift, a risky apply) you handled.] |
| Kubernetes debugging (crash-loop, OOM, pending pod) | [A specific pod/deployment issue you diagnosed for another team, and the actual root cause.] |
| CI/CD pipeline design | [The stages your Jenkins/GitHub Actions pipeline actually ran — build, scan, test, deploy — and any change you made to it.] |
| Observability (alert fatigue, silent scrape failure, dashboards) | [Any alert you had to tune down, or a dashboard you built that changed how fast an issue was caught.] |
| Security scanning (SonarQube/Trivy) in the pipeline | [A real finding one of these caught before it reached production, if you recall one.] |
| Project management / JIRA workflow | [Your team's actual sprint/Kanban rhythm, story-point sizing, and how on-call tickets fit into it.] |
The messy questions — disaster sprint, biggest mistake, and other curveballs
Answered with your real stories from Part 5, not a script. The framework below is just the shape — the content has to be genuinely yours.
"Tell me about your biggest production mistake." Framework: what happened (briefly, own it directly, no deflecting) → how you triaged/mitigated it in the moment → the root cause once you had time to look → what changed afterward (a test, a safeguard, a process) so it can't recur. Use War Story 4.
"Tell me about a time a sprint or deadline completely fell apart." Framework: what caused it to fall apart (be honest — scope creep, a hidden dependency, an underestimate) → how you and the team responded in real time → what the outcome actually was, including if it wasn't a clean save → what you'd do differently. This is one of the few questions where admitting a genuinely imperfect outcome, handled well, lands better than a suspiciously tidy success story.
"Tell me about a time you disagreed with a technical decision." Framework: the decision and why you disagreed → how you raised it (constructively, with evidence, not just an opinion) → the actual outcome, whether you were overruled or you changed the direction → what you learned either way.
"What's something you'd do differently if you started this project again?" Framework: a genuine, specific thing — not a rehearsed non-answer like "nothing, it all went great." [Fill in something real — perhaps introducing the reusable templates earlier, or building the observability stack before it was needed reactively.]
"How do you handle being paged at 3am for something that turns out to be nothing?" Framework: acknowledge the reality of on-call directly, describe your actual triage process (confirm it's really nothing, don't just dismiss an alert), and connect it back to the alert-fatigue material — a false alarm is itself useful signal about an alert that needs tuning, not just an annoyance to shrug off.
The resume duties-to-outcomes rewrite pass (turning each resume bullet from a duty into an outcome-with-a-metric) is still outstanding — it needs your actual resume text pasted in to work from, since it's a line-by-line edit, not something to template here. The 4 career-highlight bullets already have strong metrics (days→hours, 30min→<10min, ~99.9% uptime, ~60% effort cut); the goal of that pass is bringing the same discipline to the 12 EXPERIENCE bullets under VOIS.