Interview guides · CEMEX

CEMEX Software Engineer Interview Guide

CEMEX Software Engineer interview guide: 4 reported rounds, algorithm and system design prep, and behavioral answer structures for the panel.

The 60-second brief

CEMEX is described to candidates as a building materials company, and the role is framed around the software that supports its supply chain and plant operations. The responsibilities candidates quote cover building and maintaining business applications, backend algorithms for logistics, cloud applications and integration with enterprise resource planning systems. The role also involves code reviews, troubleshooting existing systems, and working with data scientists, plant managers and product owners to pin down requirements. For you that means technical answers should connect to physical operations, existing systems and cross-team requirements, not only to clean code.

This guide is for engineers interviewing for a Software Engineer position at CEMEX. It covers the four rounds candidates report (Recruiter Touchpoint, Technical Assessments, Behavioral Assessments, Panel Interviews), the array, design, debugging, testing and language-experience questions in the technical set, and the behavioral, motivation and ambiguity questions that make up most of the reported list. It ends with a seven-day plan you can start the day the recruiter calls.

Candidates report four rounds: a recruiter touchpoint, technical assessments, behavioral assessments, and panel interviews with a potential direct manager, peers and leaders from adjacent departments. Reported timelines run about three to five weeks, and some loops last several months.

Focus areas

Technical Coding Interviews
Algorithms
Data Structures & Arrays

Overview

Most of the reported question list is behavioral or motivational. Ten of the fourteen reported questions ask for stories, opinions or reasons: leading under pressure, handling conflict, explaining technical ideas to non-engineers, managing priorities, working globally, handling vague requirements, and why you want this employer. The remaining four are technical: your process for array and algorithm problems, optimizing code for performance and scalability, debugging a live production issue, and unit testing and quality assurance. Prepare both halves, and expect the story half to carry real weight.

The technical side is fundamentals plus engineering judgment. Candidates also describe a complexity question on an array problem and a system design scenario about high-frequency data from plant sensors, so practise stating time and space complexity out loud and sketching ingestion, storage and querying for a stream of readings. The role lists Java, Python or ABAP depending on the team, with AWS, Azure, supply chain software and ERP experience as extras. Decide before the call which of those you can discuss with real project detail and which you will describe as adjacent experience.

The work itself shapes the preparation. The reported responsibilities mix maintaining existing systems, optimizing them, reviewing code and negotiating requirements with data scientists, plant managers and product owners. So the strongest examples are ones where you changed something that was already running, explained a trade-off to someone outside engineering, and can state the result. Advice candidates pass on is to explain the reason behind each technical choice, so for every project you plan to discuss, write down the alternative you rejected and why.

The panel is reported to include a potential direct manager, peers and leaders from adjacent departments, which means the same story may be heard by people with different priorities. Practise telling each story twice: once with the technical detail a peer wants, once with the business consequence a leader from another department wants. Some regions are also reported to run group exercises, so rehearse speaking up clearly and listening in a group, not only answering one-to-one.

The CEMEX interview process

Candidates report these four rounds in this order, over roughly three to five weeks, though the process can run to several months depending on the role and location. Treat the stages as what candidates describe, not a published schedule.

Recruiter Touchpoint

Candidates report an initial contact with a recruiter or HR representative to talk through the role and how you fit it. Nothing technical is reported for this stage, so treat it as the place to fix your story: why this role, which of your projects match the work described (supply chain, plant operations, logistics algorithms, ERP integration, cloud applications), and what you need to know about the rest of the process. Because timelines are reported to vary widely, it is also where you set up regular contact with the recruiter.

What to demonstrate

Whether your background fits the role as described
How clearly you explain your own experience and motivation
Practical fit questions such as the team, location and next steps

How to prepare

Write a short walk through your career that ends at this role, and pick the two projects closest to supply chain, operations, logistics or enterprise systems work.
Prepare your honest answer on the languages the role lists (Java, Python, ABAP) and on cloud platforms (AWS, Azure), including where you are strong and where you are adjacent.
Prepare your reasons for choosing CEMEX over a purely tech-focused employer, since that question is reported in the loop.
Ask which languages the team uses, what the technical rounds contain, and who sits on the panel.

Technical Assessments

Candidates describe a series of technical evaluations rather than a single interview. The reported technical topics are algorithm and data structure efficiency, experience with enterprise-level systems, and practices for documentation and code maintenance, and reported scenarios include explaining the time complexity of an array solution and designing for high-frequency data from plant sensors. The technical questions in this guide (array and algorithm process, performance and scalability, debugging a live production issue, unit testing) are the ones to practise for this stage. Solve out loud, state complexity every time, and give the reason for each choice.

What to demonstrate

Working code and sound reasoning about algorithms and data structures
Ability to state and justify time and space complexity
Engineering practice around testing, debugging and maintaining existing systems

How to prepare

Solve array problems aloud, naming the brute-force approach, the improved one, and the complexity of both, in the language you would use on the job.
Sketch a design for a stream of sensor readings: ingestion, buffering, storage, aggregation and what happens when a plant loses connectivity and later sends a backlog.
Prepare a debugging story from a live system and a short description of how you decide what to unit test.
Be ready to talk about the enterprise systems, ERP integrations or cloud services you have actually worked with.

Behavioral Assessments

Candidates describe a separate assessment of behavioral competencies, used to judge fit with the team. The reported behavioral material is leadership and initiative, conflict in cross-functional teams, explaining technical ideas to non-technical people, time management, and handling ambiguity, plus an example about convincing a skeptical teammate to adopt a technical recommendation. Prepare four or five stories that can each answer several of these prompts, with your own decision at the centre and a result you can state.

What to demonstrate

Collaboration with people outside your own discipline
Ownership of decisions and results in your past projects
Communication and conflict resolution as reported behavioral competencies

How to prepare

Write four stories in situation, action, result form and map each to two or more reported prompts, so none of them is told twice in the same loop.
For every story, state your personal decision, the alternative you rejected, and a measurable or observable outcome.
Rehearse the skeptical-teammate story with the evidence you used to persuade, not only the fact that you were right.
Practise the explain-to-a-non-technical-person story with one analogy and one concrete number.

Panel Interviews

Candidates report panel interviews conducted by a potential direct manager, peers, and leaders from adjacent departments. The mix of listeners is the main thing to prepare for: the same project will be heard by someone who will work next to you and someone who cares how it affects another department. Some regions are reported to include group exercises, so be ready to collaborate with other candidates as well. Bring technical and behavioral material, plus questions about the team's work.

What to demonstrate

How you communicate with listeners from different functions at once
Consistency between your technical answers and your stories
Fit with the team and the adjacent departments you would work with

How to prepare

Prepare each major project in two versions, one with architecture and trade-offs for peers and one with business impact for leaders from other departments.
Rehearse the culture and motivation answers: why CEMEX, career goals, working in a diverse global environment and what you know about digital transformation.
Write three questions for the manager and peers about how engineering works with plant operations and product owners.
If a group exercise is mentioned, practise summarizing others' points before adding yours and keeping contributions short.

Where candidates lose points

Solving an array problem without ever stating its time and space complexity

Finish every practice problem with a spoken line on time and space complexity, and the complexity of the brute-force version you started from. A complexity question on an array solution is among the reported scenarios, so make the habit automatic.

Answering the plant-sensor design scenario as a generic web application

Ask about volume, ordering, late or duplicate readings and what users need from the data. Then cover ingestion, buffering, storage and aggregation, and what happens after a connectivity loss. Say which choices you would revisit as volume grows.

Giving a vague answer about ABAP, ERP or cloud experience, or claiming experience you cannot defend

List what you have shipped, what you maintained and what you only studied, and answer follow-ups from the first two. Pair any gap with a time you ramped up on an unfamiliar stack and what you delivered.

Telling stories in the team's voice, without your own decision or a result

For each story, write the decision you personally made, the alternative you rejected, and the outcome. Mixed panels hear the story from different angles, so every detail has to hold up under a follow-up.

Giving a motivation or digital-transformation answer that could apply to any company, or that claims knowledge you do not have

Read the company's public material, cite what you found, link it to the work the role lists, and mark your own inferences as inferences. Prepare one question to ask back.

Questions & practice

Can you walk me through your process for solving complex array and algorithm-based problems?

Medium · Technical and Coding Fundamentals

Approach

Pin down the input before coding: array length range, sorted or not, duplicates, negative values, and whether I may modify it in place. Then state the brute force (usually nested loops, O(n^2)) with its cost, so I have a baseline that is known to be correct.
Pick the pattern from the access need. Hash map for complement or frequency lookups: O(n) time, O(n) space. Two pointers on a sorted array: O(n) after an O(n log n) sort. Binary search when the array or a predicate over it is monotonic: O(log n).
For contiguous subarrays, use a sliding window only when values are non-negative, because the window sum then grows as it extends. With negative values, switch to prefix sums plus a hash map of prefix counts, which is still O(n).
Before running anything, trace a small example by hand. Then check the edges: empty array, one element, all duplicates, all negative, target absent, and integer overflow when summing in Java.
Close with time and space complexity and the trade-off I chose, for example extra O(n) memory to drop from O(n^2) to O(n), or an in-place sort that destroys the original order.

Follow-up

Can you solve it in O(1) extra space, and what does that cost you in time or in mutating the input?
Your sliding window assumes non-negative values; what breaks with negatives, and how do you fix it?
What changes if the array arrives as a stream too large to hold in memory?

How do you approach unit testing and code quality assurance?

Medium · Technical and Coding Fundamentals

Approach

Describe the test pyramid I work to: many fast, isolated unit tests; fewer integration tests against a real database or service in a container; a small set of end-to-end tests on the most important user paths. Each layer catches a different kind of defect at a different cost.
A good unit test covers one behaviour, follows arrange-act-assert, and is deterministic. I inject the clock and seed any randomness. I mock only at real boundaries such as the network, the database or the file system, because mocking internal classes ties the test to the implementation and breaks on every refactor.
Choose cases on purpose: boundaries, empty and null inputs, error paths and invalid states. I use parameterised tests (pytest.mark.parametrize, or JUnit 5 @ParameterizedTest) to cover them without copy-paste. On an ABAP team the equivalent is ABAP Unit test classes declared FOR TESTING.
Treat coverage as a way to find gaps, not as a target. Line coverage shows that code ran, not that anything was asserted. Mutation testing (PIT for Java, mutmut for Python) shows whether the tests would actually catch a change in behaviour.
Back quality with automation and review: tests, linters and static analysis run on every pull request in CI and block the merge; code review covers design and readability; every escaped bug gets a failing test written before the fix.

Follow-up

How would you unit test code that depends on the current time or on an external API?
Coverage is at 90% but bugs still reach production; what do you change?
How do you add tests to a legacy module that has no seams for injection?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

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

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

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

How do you optimize code for performance and scalability in a production environment?

Medium · Technical and Coding Fundamentals

Approach

Measure before changing anything. I define the target as a number (p95 or p99 latency, throughput, memory ceiling), then profile the hot path with real load, using cProfile or py-spy for Python and JFR or async-profiler for Java, so I fix the real bottleneck rather than a guessed one.
Fix the algorithm and data access first. Examples: replace a nested-loop lookup with a hash map, and remove N+1 query patterns by batching or joining. Add an index only after EXPLAIN shows a sequential scan on a selective filter, and replace OFFSET pagination with keyset pagination on large tables.
Add caching only where reads dominate and slightly stale data is acceptable. I state the TTL and the invalidation path, and treat cache stampede on expiry as a risk to handle.
For scale, keep services stateless so they can sit behind a load balancer and scale horizontally. Move slow or bursty work onto a queue with idempotent consumers, and batch writes. Every layer added this way trades simplicity for throughput.
Prove the result with a before-and-after load test and production metrics, and keep a regression alert on the metric I improved so a later change cannot quietly undo it.

Follow-up

What fails first when traffic grows tenfold, and how would you find out before users do?
How would you handle high-frequency data coming in from plant sensors without losing readings when a downstream store slows down?
When would you decide not to optimise a slow path at all?

Rebuild the search projection while it serves nine thousand queries

Medium · projections · eventual consistency · rebuild

The read-model service answers about 9k queries/second at a 120 ms p99 from a projection built off the event log, normally under 2 seconds behind. A mapping change forces a full rebuild from resource_revision, during which apply lag rises to minutes. Writes continue at 1.2k/second and events at 4k/second. Design the rebuild: how the new index is populated and cut over, how position is tracked per log partition, what the API returns alongside results so a client can tell a stale answer from a current one, and the criterion for cutting over.

Approach

Build into a second index and swap an alias rather than mutating the live one. The rebuild is then reversible by pointing the alias back, so a bad mapping costs a wasted rebuild instead of an outage. The price is peak storage for two full copies and double apply load during catch-up, and both numbers should be stated up front rather than discovered when disk fills.
Track position per log partition, not globally. Order is guaranteed only within an aggregate's partition, so progress is a vector, and the only number safe to publish is taken from the least advanced partition - the slowest one is what bounds completeness. Publishing the most advanced partition's position declares the projection current while another partition sits twenty minutes behind.
Make apply idempotent so the backfill and the live tail can overlap without a freeze. Each document records the aggregate_version it reflects, and any event at or below that version is discarded. This is why the event carries the full fact and not a delta: a delta cannot be discarded safely, and a consumer that calls back to read current state applies a state newer than the event it is processing, which is how a projection ends up with changes applied out of order.
Turn lag into a contract instead of a surprise. Return the watermark with every result set, and return the version produced by a write so the client can compare the two. A client that wrote version 7 and receives results at a watermark older than its own commit can show that its change is still landing, rather than rendering the previous value as current. Blocking the read until the projection catches up would convert a staleness problem into an availability problem at 9k queries/second, and choosing not to do that is the trade.

Follow-up

The rebuilt index disagrees with the primary tables for 300 documents. Which is authoritative, and how do you decide without freezing writes?
The rebuild doubles load on the log and pushes the projection p99 from 120 ms to 400 ms. What do you throttle, and which signal sets how much?

Can you explain a time you had to debug a critical issue in a live production system?

Medium · Technical and Coding Fundamentals

Approach

Lead with impact and mitigation: what broke, for whom, and how I stopped the damage first, whether by rolling back, switching off a feature flag or failing over, before I hunted for the root cause.
Build a timeline from evidence. I line up logs, metrics and traces against recent deploys, config changes, data volume shifts and dependency incidents, and check that the alert or dashboard itself was not wrong.
Narrow it down by bisection: one host or all, one release or several, one input shape or every request. Each check should rule out about half of the candidate causes, whichever way it comes out.
Reproduce the failure outside production with the triggering input or data before I trust a fix. Then separate the trigger, such as a deploy or a traffic spike, from the underlying defect, such as a race, an unbounded query or a missing timeout.
Close the loop with a regression test for the exact failure, monitoring that would have caught it earlier, and a blameless write-up. Give concrete numbers: time to detect, time to mitigate, and the users or orders affected.

Follow-up

What was the first signal you checked, and what did it rule out?
How did you confirm your fix addressed the cause and not just the symptom?
What would you change in monitoring or deployment so this class of issue is caught before production?

Suggested practice checklist

The plan starts with your stories and the loop, spends the middle days on the technical question types candidates report (array process, sensor-data design, debugging, testing), and ends with behavioral and motivation answers spoken aloud.

Day 1 — Map the loop and inventory your experience

Write the four reported rounds on one page and mark which of them (recruiter, technical, behavioral, panel) you are least ready for.
List every language, cloud platform and enterprise system you have used, with one project each, and mark Java, Python, ABAP, AWS and Azure as strong, adjacent or none.
Write your career walk-through and your answer to why this role, using only facts you can verify.

Deliverable: A one-page loop map, a skills inventory with strong, adjacent or none marked, and a written career walk-through.

Day 2 — Array and algorithm process, spoken aloud

Solve three array problems aloud: restate the input, name the brute force, improve it, and state time and space complexity at the end.
Redo one of them in the language you would use on the job and write the edge cases you would test: empty input, duplicates, a single element, very large input.

Deliverable: Three solved array problems with spoken complexity statements, an edge-case list for one, and a worked solution to the projection-diff practice question.

Day 3 — Sensor-data design and performance

Design a pipeline for high-frequency plant sensor readings: write the ingestion path, buffering, storage, aggregation and the read path on one page, with the clarifying questions you would ask first.
Add failure handling: a plant goes offline and later sends a backlog, duplicate readings arrive, a downstream consumer is slow.
Practise the performance question: choose one slow endpoint or query you have worked on and write how you measured it, what you changed and what the result was.

Deliverable: A one-page sensor pipeline design with failure handling, a measure-change-result write-up for a performance fix, and a solved keyset paging practice question.

Day 4 — Debugging, testing and language experience

Write the debugging story for a live production issue: what changed, how you narrowed it, how you confirmed the cause and what you added to prevent a repeat.
Write a short unit-test plan for a function you wrote recently: cases, edge cases, what you would mock and what coverage means to you.
Prepare the answer on specific languages and cloud-native stacks, with one project for each.

Deliverable: A written debugging story, a unit-test plan for one real function and a language and stack answer with one project per entry.

Day 5 — Leadership, conflict and explaining to non-engineers

Write three stories in situation, action, result form: leading or taking initiative, a cross-functional disagreement and an explanation to a non-technical person.
Write the skeptical-teammate story, naming the evidence you used to persuade.
Say each story aloud and trim until your own decision and the result come first.

Deliverable: Three written stories plus the skeptical-teammate story, each with a stated decision and result, and one recording to review.

Day 6 — Priorities, ambiguity and global teams

Write a story where several priorities collided and describe how you decided the order and communicated it.
Write an ambiguity story, with the questions you asked and the thin slice you built.
Write your global teamwork answer around three habits and one example of a misunderstanding.

Deliverable: Three written stories (priorities, ambiguity, global collaboration), each with a concrete example and an outcome.

Day 7 — Motivation, company research and a full run-through

Read the company's public material on digital and technology work and write three attributed facts with a link to the role's work areas.
Write your answers to why CEMEX, your career goals and the digital transformation question using those facts.
Do a spoken run-through for a mixed panel: one technical answer, one story told twice (once for peers, once for a leader from another department), and the motivation answers; write three questions to ask the panel.

Deliverable: A one-page research sheet with three attributed facts, written answers to the three motivation questions and three questions for the panel.

Stories for the CEMEX behavioral and panel rounds

Candidates report that most of the CEMEX question list asks for stories and motivation rather than code, and the panel is reported to include a potential direct manager, peers and leaders from adjacent departments. Prepare stories where you made the decision and can state the result, and be ready to tell them to listeners from different functions.

Describe a time you had to convince a skeptical teammate to adopt your technical recommendation.

What is your experience with specific languages like ABAP or modern cloud-native stacks?

Medium · Technical and Coding Fundamentals

Approach

Start with an honest inventory: list the languages and platforms you have shipped to production, say which are strongest, and give one line on scale or purpose for each. Do not claim ABAP or a cloud platform you have only read about.
Pick the one project that best matches the role (a backend, logistics, integration or enterprise system) and spend most of the answer on it: what you built, what you owned, one design decision and the trade-off behind it.
For a cloud-native stack, name concrete elements: how it was deployed, how configuration and secrets were handled, how you monitored it, and what you changed after an incident or cost surprise. The role lists AWS and Azure as extras, so say which one you used.
If there is a gap, such as no ABAP or no ERP work, name your closest experience and a time you became productive in an unfamiliar stack, with what you shipped as proof.

Follow-up

Which would you pick for a new logistics service, and why?
What was hardest when you first moved into that stack?
How would you approach changing a system whose rules you did not set?