All Behavioral questions — Blog

Shane's story bank for behavioral interviews, organized by question. Updated whenever a story gets better. Last updated 2026-09-25.

How to use this#

Every answer is STAR: Situation, Task, Action, Result. Say "I", not "we", for what you did.
Toyota maps each question to a Toyota Way value. The value is in brackets after each heading.
Aim for 60 to 90 seconds, then stop talking.
Keep a mix: about half wins, half things that went wrong. Toyota asks for exactly that split.
Anything in [brackets] is not confirmed yet. Don't say a bracketed detail until it's real.
Multi-part questions: say the parts back first ("So: A, B and C. Let me take those in order"), answer each, and end on the yes/no part.

1. Walk me through a project you're proud of#

"Creative Studio is PMG's ad-creative production platform. You give it one HTML ad template and a client's product catalog, and it renders every ad image the client needs, then delivers them for platforms like Meta and Pinterest.

The backend is Django and Postgres, with Redis for render progress and Celery workers on SQS for anything asynchronous. The API never renders anything itself. It creates a tracker in Redis, queues the job, and returns right away. A coordinator task works out what needs rendering and hands batches to a separate ECS fleet running headless Chromium, which uploads images to S3 and calls back as each one finishes.

Most of my time went into the dispatch layer, because that's what was breaking at scale. One client's template came to about 823,000 creatives, and a single Celery task was trying to walk all of them inside a 40-minute limit. It got killed every run, so renders never finished, and the dashboards still looked healthy because the retries kept resetting SQS's receive count.

My teammates wrote the design. I did the diagnosis behind it and built the core: a coordinator that fans the work out into small idempotent batches behind a feature flag, the completion accounting and dead-letter handling, an Athena diff that finds which catalog rows actually changed, and a monitor for renders that get stuck.

Happy to go deeper on any of that."

Credit boundary: teammates designed it (the ADR), you diagnosed and built the core. Say it that way every time.

2. A problem where the root cause wasn't obvious (Drive Curiosity)#

"Large renders at PMG never finished, but they never errored either. They just inched forward every time someone hit Restart Render. The obvious guess was capacity, but the screenshot workers already scaled on queue backlog and were keeping up. So I went to the task logs instead of the dashboards.

Two things came out. First, all the work sat in one Celery task that had to walk about 823,000 combinations inside a fixed time limit, so it was killed mid-run every time. You can't scale your way out of that; one task is one task. Second, the task's retries published a fresh SQS message each time, which reset the receive count, so nothing ever reached the dead-letter queue and every graph looked healthy.

The logs also showed how wasteful it was: by the end, each run walked all 823,000 combinations to find 13 that still needed rendering.

That diagnosis fed the design my teammates wrote, and I built the core of it. Renders at that scale now finish, and failures show up instead of hiding."

3. A time you went and saw for yourself (Observe Thoroughly)#

"Headless Chromium kept crashing in our containers, and nothing in the application code explained it. Instead of reasoning from the code, I looked at the actual running container and found its shared memory, /dev/shm, was at the 64MB default. Chromium needs more than that, and its crash handler also had no writable home directory. Running Chromium with --disable-dev-shm-usage, so it stops relying on /dev/shm, and giving the crash handler a writable home directory fixed the crashes. The answer wasn't in the place everyone was looking."

4. A time a team you were on wasn't working effectively#

Version A: the render pipeline (verified)#

"At PMG, large renders weren't finishing, and for a while the team couldn't tell why. The dashboards were green, the dead-letter queue was empty, and users kept hitting Restart Render. The team wasn't ineffective because of the people. It was ineffective because everything it relied on to spot failures said things were fine.

I went to the task logs and found the retries were resetting the receive count, so failures never reached the dead-letter queue. So I made failures show up honestly. Batches now go back on the queue to retry instead of using Celery's retry, so SQS keeps an accurate count, and batches that really fail land in the dead-letter queue. I built a drainer that reads those, records the batch as failed, and closes out the render. And when a render in staging hung four creatives short of 765,727 with no alert, I added a stuck-render check that alerts in Datadog.

Now a render ends as done or failed, instead of hanging until it silently expires after 24 hours. What I took from it: when a team isn't working well, first check whether they can even see what's happening."

If asked about tension on the team: the team worked well together. The problem was the tools. Don't invent a conflict.

Version B: the Slack bot (human story, brackets to fill)#

"At PMG, I worked on a small internal project with another engineer and someone from our media team. We were asked to build a Slack bot around channel naming conventions, [because channels were being created with inconsistent names, which made them hard to find].

At first we weren't working well as a team. The brief was loose, and instead of pinning down the scope, each of us went off trying different things. We'd all assumed the bot should create channels for people automatically, with the convention built in.

About halfway through, we stepped back and asked: is this actually what they want? [I suggested we show them what we had before building any more.] That's when we found out we'd misunderstood. They didn't want the bot creating channels. They wanted it to guide people: you type a slash command, a form pops up that walks you through naming the channel correctly, and you're still the one who creates it.

So we re-scoped around that. [My part was rebuilding the bot around the slash command and the pop-up form.] [We shipped the guided version, and people started using it.]

The lesson for me was to confirm what 'done' looks like before writing code. Now I write the scope down in a few sentences and check it with whoever asked for it. It also taught me to think from the user's side: they didn't want to lose control of creating their own channels, they just wanted help getting it right."

To fill in: (1) what you personally did at the halfway point, (2) how you found out they wanted a guide, (3) your part in the rebuild, (4) the real result, even if it never shipped.

5. Build consensus among groups with conflicting objectives (Work with Integrity)#

"During the render incident at PMG, the team split into two reasonable positions. One side said Celery itself was the problem: its retry behavior had hidden the failure, so we should replace it with our platform's own SQS consumer. The other side said the real bug was one task doing unbounded work, which would break under any task runner.

What got us to agreement was separating the two. Fix the unbounded work now, behind a feature flag so the old path stayed live and the cutover could be reversed. Treat replacing Celery as its own follow-up, not a prerequisite. Both sides got what they cared about: the people worried about risk had a kill switch, and the people who wanted Celery gone kept it on the roadmap.

My part was building what made that compromise workable: the fan-out coordinator behind that flag. The lesson I took is that most technical disagreements are two people protecting different risks, and if you can protect both, the argument goes away."

Honesty: the "I" is only what you built, not brokering the agreement. If you actually argued one of those positions, say which. It's two camps in one team, not separate work groups; a real cross-team example would fit better.

6. A peer insists his solution is better than yours (Welcome Competition, without ego)#

"First I'd make sure I actually understand his solution, well enough to explain it back to him. A lot of disagreements are two people protecting different risks, so I'd ask what he's optimizing for and tell him what I'm optimizing for.

Then I'd make it about evidence instead of opinions: prototype both, measure them, or find the case that separates them. I saw that work on my team at PMG with batch sizing on the render pipeline. Instead of arguing over the right number, the team made it a setting and let production metrics decide.

If we still disagree, I'd bring it to the tech lead or manager together, openly, with both options written down. And if it goes his way, I commit to it fully and help make it work. My ego isn't in which solution wins, it's in whether the system works. On the render pipeline fix, the design came from my teammates, and I was the one who implemented it."

7. A time you reported something that wasn't good news (Work with Integrity)#

"A bad feed load at PMG dropped 42,600 records. The cause was newline truncation combined with a duplicate same-day feed load landing in one S3 partition. I restored 837,714 of 849,131 records, 98.7%, across a 139,608-product catalog.

I didn't round that to 'fully recovered.' I reported the 1.3% that wasn't, and filed three follow-up items, because the same kind of bug could happen again. The value is in saying the number that isn't 100."

Call it "a bad feed load", not a "data incident", so it doesn't blur with the PMG departure story.

8. A failure, or something you'd do differently (Get Better and Better)#

"I shipped the new dispatch path behind a feature flag and ran it in staging at real scale. It got to 765,723 of 765,727 and stopped. Four short.

The four weren't the real problem. The real problem was that nothing alarmed. A render whose callbacks stop arriving just sits there until a 24-hour cache timeout silently clears it. No error, no alert, and the evidence expires.

So I built a scheduled check that flags every render stuck past a threshold, and a Datadog monitor alerts on it. It scans each client separately, so one Redis hiccup can't blind the whole check.

What I'd do differently: I fixed the original failure without instrumenting the new failure mode my fix created. Now I ask 'how would I find out this broke?' before I call anything done."

9. Eliminating waste (Create Room to Grow)#

"Every render at PMG walked the entire product catalog to decide what to render, even when almost nothing had changed. At the tail of an incident, each run walked about 823,000 combinations to find 13 that needed work.

I built the change-detection piece for the feed side: an Athena query that takes today's catalog snapshot and subtracts yesterday's with an EXCEPT, a set difference across two date partitions that already existed. No new columns, no hashing. That gives the render only the catalog rows that actually changed. It's just-in-time applied to data: stop producing things nobody asked for."

10. A small improvement that mattered (Continue the Quest for Improvement)#

The small, one-line example. #21 is the primary story for this value; use this one when they ask for something small, or as the "regardless of size" half of the answer.

"At PMG, one ticket was to replace single calls to our render API with its batch endpoint, which takes up to 5,000 items per request. It was a one-line change, and it turned up to 5,000 separate requests into one. Not every improvement needs a design doc; some of the best ones are a single line nobody notices."

11. Serving an internal customer (Act for Others)#

"At a shared-services team, your customers are other engineers. At PMG, our dead-letter queue had been undecodable for eight days, which meant nobody on the team could see what was failing. I made it decodable, and it now drains in about 60 seconds.

While I was in there, I found a missing IAM permission, sqs:SendMessage, that was blocking the workers from sending. Our infrastructure is Terraform, so I added the one line that grants it, and it went through PR review and Atlantis plan and apply to staging, then prod."

IAM gap (corrected by Shane 2026-10-13): he made the one-line Terraform change himself (PR review, Atlantis plan/apply, staging, prod). The earlier "handed it to the owner" version was wrong. Do not claim he designed the IAM setup, only that he added the permission.

12. Respecting your teammates' work (Show Respect for People)#

"On a platform, respect for people looks like not breaking the teams downstream of you. When I changed how the render pipeline dispatched work, I wrote tests alongside every change, especially the failure paths, and put the whole thing behind a feature flag. The flag wasn't for me. It meant that if I was wrong, turning it off was a config change, and nobody else's work had to go down with mine."

13. Learning something new fast (Get Better and Better)#

"At Arch Capital I interned for about six months on the claims side, on the backend, in Java and Spring Boot with MySQL and Elasticsearch. I came in needing to get productive in an existing Java codebase quickly, in a large regulated insurance company with a real review process. In those six months I shipped 73 pull requests across four production repositories. [One specific PR you're proud of, in two sentences.]"

To fill in: one real PR from Arch, in case they ask for specifics. Don't mention Kubernetes unless you can back it up.

14. Why Toyota? Why not a startup? (plus the downtime question)#

Take it in order, end on the yes/no:

"Two reasons. First, the kind of work. The work I liked most at an insurance company and at an agency was the enterprise side: systems a lot of other people depend on, where correctness and review really matter. Enterprise Shared Services is exactly that: platforms that teams across TFS build on. At a startup I'd be building one product fast. Here I'd be building things other teams trust.

Second, how Toyota works. I want strong engineers around me, real code review, and a clear process. What happened at PMG taught me how much I value working inside a process instead of around it. I'm looking for a place to build a career, not a stopgap.

And to your question about a month or two without much work: yes, completely. I'd use it to go deeper on the platform, the codebase and the docs, and ask you where I can help, and keep it inside what you've asked for."

Don't say you've never considered startups. "I've looked at both, and here's why this fits me now" is honest.

15. Giving credit (Thank People)#

"The render pipeline fix wasn't mine alone. The design came from two senior engineers on my team, and I implemented it. I try to say those things out loud, because the easiest way to lose a team's trust is to take credit for their part."

16. Solving a problem with incomplete or conflicting information (Observe Thoroughly)#

Version A: the render pipeline (verified)#

"At PMG, large renders weren't finishing, and the information I had conflicted. Users were telling us renders never completed. But every dashboard said the system was healthy: queue traffic looked normal, and the dead-letter queue, where failed work normally ends up, was empty.

When two sources disagree, I go to the most direct evidence I can find. The dashboards were summaries. The task logs were what actually happened. So I read the logs for the renders that weren't finishing. They showed the work was running in one long task that kept getting killed at its time limit, and that every retry published a fresh message, which reset SQS's receive count. Nothing ever looked like a failure. The dashboards weren't wrong about what they measured; they were measuring the wrong thing.

To decide what to do, I separated what I knew from what I was guessing. I knew the task was being killed and that the retries hid it. So the fix had to do two things: break the work into small batches that finish inside the limit, and make failures show up honestly. That became the design my teammates wrote, and I built the core of it.

What I took from it: when information conflicts, don't pick the source you like. Find the one closest to what actually happened."

Version B: the Slack bot (use this if the render story is already taken in the same interview loop)#

"On a small internal project at PMG, our brief for a Slack bot was vague, and the three of us each filled the gaps with our own assumptions. We all assumed the bot should create channels automatically. Halfway through, [I noticed we couldn't point to anything in the brief that actually said that]. The missing information was what the people asking for it wanted, and the only reliable source for that was them. So [I suggested we demo what we had and ask].

They wanted a guide, not automation: a slash command that opens a form and walks you through naming the channel, with the person still creating it. We decided to re-scope around that instead of defending what we'd built.

The lesson: when requirements are incomplete, the cheapest fix is asking the person who wrote them, before you build more."

Don't use the render story for more than two questions in one interview loop. Toyota asks for diverse examples.

17. Circumstances changed, or something didn't go as planned (Get Better and Better)#

Version A: the staging stall (verified)#

"At PMG, I was about to ship the new fan-out dispatch for the render pipeline. The plan was straightforward: finish the code, run it in staging at real scale, then merge it and turn it on with a feature flag.

Staging didn't go as planned. A large render got to 765,723 of 765,727 creatives and stopped. Four short. The worse part was that nothing alerted. A render stuck like that would just sit until a 24-hour timeout quietly cleared it.

In code review, the question came up: how would we even know if this happened in production? So the plan changed. Instead of merging the fan-out and adding monitoring later, I built the monitoring first: a scheduled check that flags any render stuck past a threshold, with a Datadog alert on it. That merged the day before the fan-out did. Then the fan-out went in behind its feature flag, and the completion accounting followed.

The outcome: the new path shipped with its main failure mode already visible, and turning it off was a config change, not a deploy. What I learned: when staging surprises you, the fix isn't just the bug. It's making sure you'd see the next surprise."

Version B: my personal site (a different project, for variety)#

"On my personal site, saves from the browser started reporting failures even though they'd actually gone through, so retrying wrote them twice. [Your part: whether you caught it, or your coding agent did.] The cause was the hosting provider's edge. We used a standard If-Match header so two edits can't overwrite each other, and the edge was checking that header itself and turning a successful save into an error.

Rather than fight the edge, or track which kinds of requests it touched, the fix was to send the version in our own X-If-Match header, which only our server reads.

The outcome: saves report correctly, no more double writes, and the site's API docs say which header to use, so the next person doesn't hit it. The lesson: when a platform you don't control changes the rules, route around it in the simplest way that can't break again."

18. Making sure everyone felt welcome, safe and heard (Show Respect for People)#

The primary story for this value; #12 is the backup. About 90 seconds.

"In college I was a regular member of a dance team, not a leader. At our senior send-off, nine seniors were graduating. The tradition is that everyone gathers, and people go around giving speeches and gifts to the seniors, and naturally most people only did that for the seniors they were close to. The team was pretty split into friend groups that year, and I knew a few of the seniors didn't have many close friends on it. I didn't want anyone to sit through their own send-off with nothing said to them.

So I bought a gift for all nine, and gave a short speech to each of them, not just the ones I was close to. Nobody asked me to. One senior in particular had had a hard year: a lot of friction with other people on the team, and people didn't always listen to her, but she kept doing the work for the team anyway. I told her I'd seen that: how hard she worked for the team, and how strong a dancer she was. I knew she'd been under a lot of stress, so my gift to her was a small plushie, something comforting.

She hugged me, and we'd never hugged before. And a year later, at my own send-off, people brought it up: that I'd done it for everyone.

I bring the same thing to work. On a group project at PMG, when we were preparing a presentation for stakeholders, I made sure everyone had a real part and their name on the slides, and I asked our quieter engineer to open it, so the first voice the stakeholders heard was his. After that the team started giving me honest feedback, and we worked better together. The people who are easiest to overlook are usually the ones who most need to be seen."

If asked "did it change the team?": "The team did get calmer the next year, but honestly that was mostly a new group of people, so I won't take credit for it. What I can say is it mattered to the people it was for." Not claiming credit you didn't earn is part of the answer.

Keep it humble. Don't say "I was the only one who did it", don't say you did most of the work on the PMG project, and don't criticize teammates for only honoring their friends; that's normal.

19. Sharpening your skills to meet a changing need (Get Better and Better)#

The primary story for this value; #13 (Arch Capital) is the backup. About 90 seconds.

"When I joined PMG, I knew Python, but not Django or Redis, and I'd used MySQL at Arch Capital, not Postgres. I had to get productive in that stack quickly, and I wanted to actually understand it, not just follow patterns in the existing code.

I did it two ways at once. I learn fastest by building, so I set things up locally and experimented, Redis especially, until I understood what our code was actually doing. And I read to pin down the vocabulary: I bought O'Reilly books on Django, Redis and Postgres, and worked through them in Nibbler, a PDF reading app I built to track my reading.

It paid off in a design review about how we stored templates. Each template has versions, and the obvious design has the template point at its current version while every version points back at its template. That's a circular foreign key, and it makes inserts and deletes awkward. I proposed a separate table that just tracks which version is current, so the references only go one way. The senior engineer pushed on it, and I could explain the trade-off term by term. They approved it, and after that my pull requests started coming back 'LGTM' much faster. As a new engineer, that trust was the real result.

It's how I'd close my gaps here too. I haven't used Lambda or DynamoDB hands-on yet, and this is how I'd learn them: build with them, and read to get the definitions right."

If a technical interviewer asks why a circular foreign key is a problem: "When two tables point at each other, neither row can be inserted first without making a column nullable or deferring the constraint, deleting either one needs special handling, and the ORM migrations get messy. Moving the 'current version' pointer into its own table makes every reference one-directional: versions point at the template, and the pointer table points at the template and its current version. Switching versions is updating one row, and you keep the full version history for free."

The last paragraph of the story matters: it turns a known gap (serverless) into proof of how you learn.

20. Recognizing someone's contribution (Thank People)#

The primary story for this value; #15 is the backup. Also works as a backup for Work with Integrity. About 75 seconds.

"At Arch Capital, QA filed a ticket on me for a 500 error. Around the same time, a fellow intern was working on a ticket that went beyond its original scope: as part of it, he fixed how the backend split a full name into first and last name.

When I looked into my bug, the 500 was coming from that exact name-splitting path, so his change had already fixed it. From QA's side there was no way to know that; they looked like two unrelated tickets.

In the sprint retro, I said it plainly: his fix resolved my ticket. And I asked the team to cancel my ticket instead of closing it as done, so it wouldn't count toward the sprint's velocity or toward my own work.

That did two things. He got credit for the contribution he actually made, and the sprint's numbers stayed honest, with no story points for a fix that only happened once. The way I see it, if credit doesn't follow the work, people stop going beyond their ticket, and that extra-mile work is exactly what a team needs most."

21. Continuous improvement: the self-improving dev loop (Continue the Quest for Improvement)#

The primary story for this value. About 90 seconds. All numbers verified against the SHAN board and the scheduled tasks (registered 2026-03-27).

"On my personal site, I wanted to see how far an AI coding agent could take a real project without me prompting it every time. I didn't design the whole system up front. I built the simplest version, watched where it got stuck, and fixed that one thing, over and over.

Version one: a scheduled job runs the agent four times a day, and it picks up tickets from my Jira board. The bottleneck was me: it could only do what I'd written a ticket for.

So I let it scan the codebase and file its own bug tickets, and I only write the feature tickets. It started finding real bugs, but deep technical ones, nothing a user would ever see.

So I gave it an end-to-end testing standard: open the live site in a real browser and use it the way a user would. Then it started finding UI and quality-of-life bugs. For example, it measured every page in a real browser and found the whole site was failing one of Google's Core Web Vitals: each page jumped 8 pixels while loading, because the sign-in area in the nav bar didn't reserve its space. It fixed that the same day and re-measured: the layout shift went from 0.127 to zero.

Then the tickets piled up faster than they closed, so I added a verification agent that re-checks each fix and archives tickets that are no longer needed. And once, the scheduler reported success for about a week while nothing had actually run: the login had expired and every run failed within seconds. So I added a preflight check, and now a broken run fails loudly instead of looking green.

It's been running on its own four times a day since March. Every change has to pass the full test suite before it ships, and the board has gone through 441 tickets, 429 of them done. What I took from it: each fix exposed the next bottleneck. Improvement isn't one big redesign, it's removing the current constraint, then the next one."

If they ask for an example where you were the one who noticed: "The periodic table on my homepage used to shuffle itself on every load, because it drew the default layout and then moved each tile into the user's saved spot. I filed it in one line, and the agent fixed it the same day so the page loads already in the saved arrangement, then proved it in a real browser, including with the network slowed down on purpose. That's the split: I notice what feels wrong as a user, it does the digging."

If they ask "how do you keep it from breaking things?": the full test suite has to pass, the verification agent re-checks fixes, and the browser checks run against the live site. It's a personal project, so it ships straight to main; at work there'd be code review, and I'd follow it.

Close with this if it fits: "At work, I'd only use tools like this the way the company approves. Your CTO has talked about protecting customer data first with AI, and I agree with that order."

22. Someone else's idea was better, and I went with it (Welcome Competition)#

The primary story for this value; #6 (how you'd handle a peer who disagrees) is the backup. About 90 seconds.

"At Arch Capital, my manager asked me to build an architecture chatbot using MCP, the Model Context Protocol, which was very new at the time. As an intern, my instinct was to build the finished thing on the first try: fully integrated with our enterprise application from day one. I used Copilot to scaffold it and spent two days fighting it. Part of the problem was that MCP was so new the AI didn't really know it, so it kept generating a conventional chatbot instead of an MCP integration.

In my one-on-one, my manager asked how it was going, and I told him the truth: I was stuck. He suggested something much simpler than anything I'd tried: forget the integration, build a hello-world MCP server in a sandbox, and just prove the concept works. His idea was better than mine, so I dropped my approach. I spent a whole day reading the MCP documentation instead of coding, and the next day I wrote a minimal prototype that worked locally with a couple of sample tools.

From there it was just adding tools and their descriptions, and we ended up connecting Ardoq, Confluence and Jira into the bot. The project was a success.

What I took from it: I was trying to prove everything at once. Now, especially with new technology, I prove the core idea in the smallest sandbox first, I read the primary docs instead of trusting an AI that may not know the tool yet, and I say 'I'm stuck' on day one, not day three."

Say "MCP server" or "the Model Context Protocol", never "MCP model": MCP is an open standard for connecting an AI assistant to tools and data, not a model.

23. Delivering an exceptional customer experience (Act for Others)#

The primary story for this value; #11 is the backup. About 100 seconds.

"At PMG, I supported our media team, and they asked me to move a hotel brand's monthly report out of a Google Sheet and into a dashboard on Alli, our internal marketing platform. The media team were my customers.

My first version had all the data, but I wanted to see it from their side, so I ran the monthly report myself, the way they did. That's when I felt the pain: for every campaign, you clicked around Alli to set the right filters, pulled the data, pasted it into a spreadsheet, then went back, changed the filters for the next campaign, and repeated, one at a time. And you had to remember all those filters or keep them in your own notes.

So I put the filter rules in code once, so nobody would set them up by hand again, and documented them anyway. Then I built it around what they cared about: metrics like pixel fires and room bookings that were already in our BigQuery data, connected TV and click-through rate, a breakdown by hotel location, and the hotel brand's colors, so it was obviously that brand's report. I checked each change with the media team before adding it.

After a few rounds of check-ins with my buddy and their manager, the team completely dropped their Google Sheet, a well-organized one they'd put real work into, because the dashboard was easier to present to the client and handled all the logic for them. The media manager leading the team's automation work gave me a shout-out at a company all-hands.

What I took from it: the fastest way to understand a customer is to do their job once yourself. And internal teams are customers too, which is exactly who Enterprise Shared Services serves."

Say "connected TV" (streaming TV ads), not "cable TV". Call the client "a hotel brand"; don't name a former employer's client. Only quote a time-saved percentage if someone actually measured it.

24. Being honest when "done" would have been easier (Work with Integrity)#

The primary integrity story; #7 (reporting 98.7%) and #20 (giving away credit) are backups. About 75 seconds.

"At PMG, I was fixing the counting in our render pipeline. On the surface it looked like one bug, but it turned out to be several: duplicates, over-counting, and creatives being skipped entirely. And it mattered beyond our team, because the product was still labeled beta, partly because of exactly these counting problems.

Every standup, my manager asked how it was going. There were days when the implementation was done and it would have been easy to just say 'done'. But the testing wasn't finished, so that's what I said: 'the code is in, the testing isn't done yet.' Every time.

Because of that, the team didn't count my fix as a reason to drop the beta label until it was actually tested. We kept working through the issues one at a time, and we didn't overpromise to anyone.

For me, 'done' means tested. If I say done and it isn't, the cost doesn't land on me; it lands on whoever makes a decision based on my word."

25. Building consensus between groups that wanted different things (Work with Integrity)#

The answer to Toyota's sample question "Describe a time when you had to build consensus among conflicting groups." #5 is the backup. About 100 seconds.

"At PMG, our media team wanted their Google Campaign Manager 360 work folded into Creative Studio. Their process jumped between tools: render the creatives in Creative Studio, paste the preview links into a spreadsheet for the client to approve, then set everything up again in Campaign Manager. My own engineering team pushed back, for a real reason: Creative Studio delivered straight to platforms like Meta and Pinterest, and Campaign Manager is a completely different architecture.

Our product manager set up a meeting to work it out, and as a junior developer, my part was making sure the right people and the right facts were in the room. I'd worked with the media team on the travel accounts, so I knew who actually used Campaign Manager every day, and I recommended bringing them in. And as a backend developer, I explained how our rendering worked, so the engineering constraints were concrete instead of abstract.

When the media team walked through their real workflow step by step, it was clear that most of the manual work was in the setup, all the steps you click through to configure a campaign, while the final delivery was something Campaign Manager already handled. So both sides agreed: Creative Studio would take over the setup and hand off to Campaign Manager's existing delivery, instead of rebuilding everything. We wrote it up as an architecture doc, started building, and demoed an early version. It was still in progress when my time at PMG ended.

What I took from it: as a junior engineer, my lever isn't authority. It's getting the right people and the right facts into the room. Once everyone was looking at the same steps, most of the disagreement went away."

Never claim you organized the meeting; the product manager did. Don't use template phrases ("structured setting", "data-driven discussion", "listen actively and incorporate multiple perspectives").

26. Building consensus: the college project that was stuck arguing (Work with Integrity)#

The strongest answer to "build consensus among conflicting groups", because it has a clear result. #25 is the work-based backup. About 80 seconds.

"In a software engineering course at UNC, our final project was a full-stack website, built agile, in sprints. Early on, the team was stuck. Nobody agreed on what to build it with, and instead of deciding, people went off in different directions: one person was hunting for header images, another was writing loose Python scripts with no backend structure. Lots of opinions, no shared starting point.

I happened to have full-stack experience, but I didn't want to win the argument by insisting on my stack. So I built a hello-world version instead: a small React frontend talking to a FastAPI backend, pushed to our repo. I walked everyone through it: here's where pages go, here's how you add an endpoint, here's a snippet you can copy. And I framed it as a proposal: if this works for everyone, let's build from here.

Once there was something concrete to react to, the debate ended fast. Everyone took a piece: one teammate owned the design and front page, another handled networking and deploying it on a server, and everyone contributed code. We shipped the full site, got top marks, and our professor singled our project out for praise.

What I learned: when a group is stuck arguing in the abstract, the fastest way to agreement is a small working example everyone can look at."

Say "a VPS" (virtual private server) if hosting comes up, not "a VPC", which is an AWS networking concept. Don't say you were the only one who knew React. Both this and #22 are "start with a hello world"; don't tell both to the same interviewer.

27. Going to see the problem for yourself: the Labor Day render incident (Observe Thoroughly)#

The strongest genchi genbutsu story; #3 (Chromium) and #16 are backups. About 90 seconds.

"Right before Labor Day at PMG, a travel client's ads were rendering wrong. I was on call that week, but the incident had started the week before, so I had no context.

Instead of working from the ticket description, I went and saw it three ways. First, I sat with the engineer who'd handled it the week before and had him reproduce the whole workflow while I recorded it, with his permission. Second, I asked [the person who reported it] to show me exactly how she used it. Third, I reproduced it myself in the render pipeline and read the logs.

Doing it myself showed me it wasn't one problem, it was several: text landing in the wrong fields, so a call to action that should say '20% off' said 'Saturday, 9 AM'; some creatives rendering completely blank; and the progress bar showing 0% when a render was actually half done. Nobody had seen all of that from the ticket.

So I filed each one as its own ticket, with a screen recording showing how to reproduce it, and we fixed them one at a time. Meanwhile I sent her a short update every day: what's fixed, what's next. Even when it's not done, people want to see the progress bar moving.

What I learned: a bug report is someone's summary of a problem. You only see the real problem when you reproduce it yourself."

If this is the same late-August incident as the 98.7% story (#7), you can end with "we restored 98.7% of the affected records", and then use #24, not #7, for integrity. Say "idempotency" clearly. Leave out the theory that part of it was a platform issue unless asked.

28. Situational: you find a teammate's bug on release day#

Toyota also asks "what would you do" questions. The backbone for any of them: contain the damage or get the facts, talk to the person directly, escalate openly, then fix the process so it can't happen again. Add a real example if you have one.

"It's release day, and right before shipping you find a bug in a teammate's code that would break a service another team depends on. Your teammate is in meetings all afternoon."

"First, I wouldn't ship something I know breaks another team's service. On a shared-services team, the other teams' trust is the product.

So I'd message my teammate right away, even mid-meeting, so they're not surprised, and tell our tech lead at the same time, because delaying a release isn't my call alone.

Then I'd pick the safest fix, not the cleverest one. If the bad change is isolated, revert that commit or turn it off behind its flag, and ship everything else. I wouldn't rewrite my teammate's code on release day unless it's a genuine one-liner that someone else reviews. If we can't separate it cleanly, we hold the release and tell the other team when to expect it.

Afterwards I'd sit down with my teammate, not to blame, but to figure out how it got so close to shipping, and add a test or check so it can't happen again.

Something similar happened on my last team: we did an internal demo right before each release, and once it caught a bug from a recent push. We rolled back to the previous version, which still had most of the new features, and shipped the fix after."

Never "ship it anyway and tell the other team after". Revert rather than rewrite, and tell the lead before acting, not after.

29. What is your biggest strength? And your biggest weakness?#

Say the parts back first ("So: a strength and a weakness. Strength first"). About 45 seconds each. Both answers are in Shane's own words; the only bracketed line is a proof point to confirm.

Strength: I think like an architect.

"My strength, and what I think sets me apart from other early-career candidates, is that I think like an architect. At Arch Capital I was a software development and architect intern, and I shadowed the company's principal architect. We went through the whole life cycle of an application: how a legacy application gets integrated with a new system, how you migrate from the old system to the new one, and the hard part, how you slowly sunset the old systems, which takes a lot of preparation.

I bring that view into my code. I write code that is maintainable, clean and simple, because I'm picturing the person who has to extend it, integrate it or retire it later.

It matters more now with AI. Most people don't really evaluate the code when they generate it. I read and judge every change against how the system will live, not just whether it runs today."

[Proof point to confirm before you say it: at PMG the new dispatch path shipped behind a feature flag and ran in staging at real scale before it became the default, so the old path was never ripped out blind. Only say this if it is how you actually think about it.]

Weakness: I don't think fast on my feet.

"My weakness is that I'm a slow thinker, not a fast one. That's fine when I'm coding at my desk, but in a presentation, a Q&A, or a live coding question I can get nervous, and I may take longer to answer than I'd like.

What I'm doing about it: I deliberately practice under pressure. I live stream my coding practice every day, so people can watch me work, and that gives me the pressure of being observed. I also put a timer on my practice problems to train fast thinking. There's fast thinking and slow thinking, and I'm building the fast one on purpose."

How to deliver it in a live interview: if you need a moment, say it out loud ("let me think for a second"), then narrate your reasoning as you go. It turns "slow" into "careful and transparent". Don't apologize for the weakness; the practice routine is the point of the answer.

Change log#

2026-09-25: first version. Built from the Toyota prep doc, corrected against the actual Creative Studio code (no watermark claim, no 1,983-test claim, no "tracing hooks" claim, staging wedge told the right way round). Added the Slack bot story (brackets to fill) and the downtime answer.
2026-09-25: published. Added "incomplete or conflicting information".
2026-09-25: added "circumstances changed, or something didn't go as planned".
2026-09-26: Chromium story corrected against the record: the fix was the --disable-dev-shm-usage flag plus a writable home directory for the crash handler, not resizing /dev/shm.
2026-09-29: added "made sure everyone felt welcome, safe and heard" (dance team senior send-off), brackets open.
2026-09-29: #18 completed from Shane's answers (a regular member, the senior who'd had a hard year, the hug, remembered a year later, the PMG presentation bridge). Kept third-party details non-identifying.
2026-09-29: added #19 "sharpening your skills to meet a changing need" (Java to Python at PMG, Nibbler, the design review), brackets open.
2026-09-29: #19 completed from Shane's answers (knew Python, new to Django, Redis and Postgres; O'Reilly books; the circular-foreign-key design review; reviews started coming back LGTM).
2026-10-01: added #20 "recognizing someone's contribution" (the fellow intern whose fix resolved my ticket, cancelled to keep velocity honest).
2026-10-02: #10 finished (the one-line batch endpoint change). Added #21, the self-improving AI dev loop, as the primary story for Continue the Quest for Improvement; two brackets open.
2026-10-02: #21 completed: the Core Web Vitals bug the agent found by measuring the live site (0.127 to zero), running since March, 429 of 441 tickets done; the self-noticed periodic-table bug as a backup example.
2026-10-02: added #22, the Arch Capital MCP chatbot (manager's hello-world sandbox idea beat my build-it-all-at-once approach) as the primary story for Welcome Competition.
2026-10-02: added #23, the hotel brand's monthly dashboard on Alli (ran the monthly reporting myself; made it brand-aware), as the primary story for Act for Others; brackets open.
2026-10-02: #23 updated: the customer was the PMG media team; before, they copied data out of Alli into the sheet by hand every month; after, the dashboard pulls it itself. Three brackets left.
2026-10-02: #23 completed: the manual filter-copy-paste loop he felt by running the report himself, rules moved into code, the team dropped their Google Sheet, shout-out at an all-hands.
2026-10-05: added #24 (honest status in standup: "the code is in, the testing isn't done") and drafted #25 (media team vs engineering on Campaign Manager), brackets open.
2026-10-05: #25 completed: the product manager set up the meeting; my part was bringing in the real Campaign Manager users and explaining the rendering constraints; agreed compromise, architecture doc, early demo, unfinished when my time at PMG ended.
2026-10-06: from the morning mock before the onsite: #23 gained pixel fires, room bookings and the check-ins; added #26 (college project consensus), #27 (Labor Day incident, genchi genbutsu) and #28 (situational: teammate's bug on release day). Restored section dividers lost in earlier edits.
2026-10-21: added #29, strengths and weakness, from Shane's own words (strength: thinks like an architect from shadowing the principal architect at Arch Capital, application life cycle, legacy integration, migration and sunsetting, maintainable code, judging AI-generated code; weakness: not a fast thinker on his feet, daily live-streamed timed practice). One proof point left in brackets.

Shane's story bank for behavioral interviews, organized by question. Updated whenever a story gets better. Last updated 2026-09-25.

How to use this#

Every answer is STAR: Situation, Task, Action, Result. Say "I", not "we", for what you did.
Toyota maps each question to a Toyota Way value. The value is in brackets after each heading.
Aim for 60 to 90 seconds, then stop talking.
Keep a mix: about half wins, half things that went wrong. Toyota asks for exactly that split.
Anything in [brackets] is not confirmed yet. Don't say a bracketed detail until it's real.
Multi-part questions: say the parts back first ("So: A, B and C. Let me take those in order"), answer each, and end on the yes/no part.

1. Walk me through a project you're proud of#

"Creative Studio is PMG's ad-creative production platform. You give it one HTML ad template and a client's product catalog, and it renders every ad image the client needs, then delivers them for platforms like Meta and Pinterest.

The backend is Django and Postgres, with Redis for render progress and Celery workers on SQS for anything asynchronous. The API never renders anything itself. It creates a tracker in Redis, queues the job, and returns right away. A coordinator task works out what needs rendering and hands batches to a separate ECS fleet running headless Chromium, which uploads images to S3 and calls back as each one finishes.

Most of my time went into the dispatch layer, because that's what was breaking at scale. One client's template came to about 823,000 creatives, and a single Celery task was trying to walk all of them inside a 40-minute limit. It got killed every run, so renders never finished, and the dashboards still looked healthy because the retries kept resetting SQS's receive count.

My teammates wrote the design. I did the diagnosis behind it and built the core: a coordinator that fans the work out into small idempotent batches behind a feature flag, the completion accounting and dead-letter handling, an Athena diff that finds which catalog rows actually changed, and a monitor for renders that get stuck.

Happy to go deeper on any of that."

Credit boundary: teammates designed it (the ADR), you diagnosed and built the core. Say it that way every time.

2. A problem where the root cause wasn't obvious (Drive Curiosity)#

"Large renders at PMG never finished, but they never errored either. They just inched forward every time someone hit Restart Render. The obvious guess was capacity, but the screenshot workers already scaled on queue backlog and were keeping up. So I went to the task logs instead of the dashboards.

Two things came out. First, all the work sat in one Celery task that had to walk about 823,000 combinations inside a fixed time limit, so it was killed mid-run every time. You can't scale your way out of that; one task is one task. Second, the task's retries published a fresh SQS message each time, which reset the receive count, so nothing ever reached the dead-letter queue and every graph looked healthy.

The logs also showed how wasteful it was: by the end, each run walked all 823,000 combinations to find 13 that still needed rendering.

That diagnosis fed the design my teammates wrote, and I built the core of it. Renders at that scale now finish, and failures show up instead of hiding."

3. A time you went and saw for yourself (Observe Thoroughly)#

"Headless Chromium kept crashing in our containers, and nothing in the application code explained it. Instead of reasoning from the code, I looked at the actual running container and found its shared memory, /dev/shm, was at the 64MB default. Chromium needs more than that, and its crash handler also had no writable home directory. Running Chromium with --disable-dev-shm-usage, so it stops relying on /dev/shm, and giving the crash handler a writable home directory fixed the crashes. The answer wasn't in the place everyone was looking."

4. A time a team you were on wasn't working effectively#

Version A: the render pipeline (verified)#

"At PMG, large renders weren't finishing, and for a while the team couldn't tell why. The dashboards were green, the dead-letter queue was empty, and users kept hitting Restart Render. The team wasn't ineffective because of the people. It was ineffective because everything it relied on to spot failures said things were fine.

I went to the task logs and found the retries were resetting the receive count, so failures never reached the dead-letter queue. So I made failures show up honestly. Batches now go back on the queue to retry instead of using Celery's retry, so SQS keeps an accurate count, and batches that really fail land in the dead-letter queue. I built a drainer that reads those, records the batch as failed, and closes out the render. And when a render in staging hung four creatives short of 765,727 with no alert, I added a stuck-render check that alerts in Datadog.

Now a render ends as done or failed, instead of hanging until it silently expires after 24 hours. What I took from it: when a team isn't working well, first check whether they can even see what's happening."

If asked about tension on the team: the team worked well together. The problem was the tools. Don't invent a conflict.

Version B: the Slack bot (human story, brackets to fill)#

"At PMG, I worked on a small internal project with another engineer and someone from our media team. We were asked to build a Slack bot around channel naming conventions, [because channels were being created with inconsistent names, which made them hard to find].

At first we weren't working well as a team. The brief was loose, and instead of pinning down the scope, each of us went off trying different things. We'd all assumed the bot should create channels for people automatically, with the convention built in.

About halfway through, we stepped back and asked: is this actually what they want? [I suggested we show them what we had before building any more.] That's when we found out we'd misunderstood. They didn't want the bot creating channels. They wanted it to guide people: you type a slash command, a form pops up that walks you through naming the channel correctly, and you're still the one who creates it.

So we re-scoped around that. [My part was rebuilding the bot around the slash command and the pop-up form.] [We shipped the guided version, and people started using it.]

The lesson for me was to confirm what 'done' looks like before writing code. Now I write the scope down in a few sentences and check it with whoever asked for it. It also taught me to think from the user's side: they didn't want to lose control of creating their own channels, they just wanted help getting it right."

To fill in: (1) what you personally did at the halfway point, (2) how you found out they wanted a guide, (3) your part in the rebuild, (4) the real result, even if it never shipped.

5. Build consensus among groups with conflicting objectives (Work with Integrity)#

"During the render incident at PMG, the team split into two reasonable positions. One side said Celery itself was the problem: its retry behavior had hidden the failure, so we should replace it with our platform's own SQS consumer. The other side said the real bug was one task doing unbounded work, which would break under any task runner.

What got us to agreement was separating the two. Fix the unbounded work now, behind a feature flag so the old path stayed live and the cutover could be reversed. Treat replacing Celery as its own follow-up, not a prerequisite. Both sides got what they cared about: the people worried about risk had a kill switch, and the people who wanted Celery gone kept it on the roadmap.

My part was building what made that compromise workable: the fan-out coordinator behind that flag. The lesson I took is that most technical disagreements are two people protecting different risks, and if you can protect both, the argument goes away."

6. A peer insists his solution is better than yours (Welcome Competition, without ego)#

"First I'd make sure I actually understand his solution, well enough to explain it back to him. A lot of disagreements are two people protecting different risks, so I'd ask what he's optimizing for and tell him what I'm optimizing for.

Then I'd make it about evidence instead of opinions: prototype both, measure them, or find the case that separates them. I saw that work on my team at PMG with batch sizing on the render pipeline. Instead of arguing over the right number, the team made it a setting and let production metrics decide.

If we still disagree, I'd bring it to the tech lead or manager together, openly, with both options written down. And if it goes his way, I commit to it fully and help make it work. My ego isn't in which solution wins, it's in whether the system works. On the render pipeline fix, the design came from my teammates, and I was the one who implemented it."

7. A time you reported something that wasn't good news (Work with Integrity)#

"A bad feed load at PMG dropped 42,600 records. The cause was newline truncation combined with a duplicate same-day feed load landing in one S3 partition. I restored 837,714 of 849,131 records, 98.7%, across a 139,608-product catalog.

I didn't round that to 'fully recovered.' I reported the 1.3% that wasn't, and filed three follow-up items, because the same kind of bug could happen again. The value is in saying the number that isn't 100."

Call it "a bad feed load", not a "data incident", so it doesn't blur with the PMG departure story.

8. A failure, or something you'd do differently (Get Better and Better)#

"I shipped the new dispatch path behind a feature flag and ran it in staging at real scale. It got to 765,723 of 765,727 and stopped. Four short.

The four weren't the real problem. The real problem was that nothing alarmed. A render whose callbacks stop arriving just sits there until a 24-hour cache timeout silently clears it. No error, no alert, and the evidence expires.

So I built a scheduled check that flags every render stuck past a threshold, and a Datadog monitor alerts on it. It scans each client separately, so one Redis hiccup can't blind the whole check.

What I'd do differently: I fixed the original failure without instrumenting the new failure mode my fix created. Now I ask 'how would I find out this broke?' before I call anything done."

9. Eliminating waste (Create Room to Grow)#

"Every render at PMG walked the entire product catalog to decide what to render, even when almost nothing had changed. At the tail of an incident, each run walked about 823,000 combinations to find 13 that needed work.

I built the change-detection piece for the feed side: an Athena query that takes today's catalog snapshot and subtracts yesterday's with an EXCEPT, a set difference across two date partitions that already existed. No new columns, no hashing. That gives the render only the catalog rows that actually changed. It's just-in-time applied to data: stop producing things nobody asked for."

10. A small improvement that mattered (Continue the Quest for Improvement)#

The small, one-line example. #21 is the primary story for this value; use this one when they ask for something small, or as the "regardless of size" half of the answer.

"At PMG, one ticket was to replace single calls to our render API with its batch endpoint, which takes up to 5,000 items per request. It was a one-line change, and it turned up to 5,000 separate requests into one. Not every improvement needs a design doc; some of the best ones are a single line nobody notices."

11. Serving an internal customer (Act for Others)#

"At a shared-services team, your customers are other engineers. At PMG, our dead-letter queue had been undecodable for eight days, which meant nobody on the team could see what was failing. I made it decodable, and it now drains in about 60 seconds.

While I was in there, I found a missing IAM permission, sqs:SendMessage, that was blocking the workers from sending. Our infrastructure is Terraform, so I added the one line that grants it, and it went through PR review and Atlantis plan and apply to staging, then prod."

12. Respecting your teammates' work (Show Respect for People)#

"On a platform, respect for people looks like not breaking the teams downstream of you. When I changed how the render pipeline dispatched work, I wrote tests alongside every change, especially the failure paths, and put the whole thing behind a feature flag. The flag wasn't for me. It meant that if I was wrong, turning it off was a config change, and nobody else's work had to go down with mine."

13. Learning something new fast (Get Better and Better)#

"At Arch Capital I interned for about six months on the claims side, on the backend, in Java and Spring Boot with MySQL and Elasticsearch. I came in needing to get productive in an existing Java codebase quickly, in a large regulated insurance company with a real review process. In those six months I shipped 73 pull requests across four production repositories. [One specific PR you're proud of, in two sentences.]"

To fill in: one real PR from Arch, in case they ask for specifics. Don't mention Kubernetes unless you can back it up.

14. Why Toyota? Why not a startup? (plus the downtime question)#

Take it in order, end on the yes/no:

"Two reasons. First, the kind of work. The work I liked most at an insurance company and at an agency was the enterprise side: systems a lot of other people depend on, where correctness and review really matter. Enterprise Shared Services is exactly that: platforms that teams across TFS build on. At a startup I'd be building one product fast. Here I'd be building things other teams trust.

Second, how Toyota works. I want strong engineers around me, real code review, and a clear process. What happened at PMG taught me how much I value working inside a process instead of around it. I'm looking for a place to build a career, not a stopgap.

And to your question about a month or two without much work: yes, completely. I'd use it to go deeper on the platform, the codebase and the docs, and ask you where I can help, and keep it inside what you've asked for."

Don't say you've never considered startups. "I've looked at both, and here's why this fits me now" is honest.

15. Giving credit (Thank People)#

"The render pipeline fix wasn't mine alone. The design came from two senior engineers on my team, and I implemented it. I try to say those things out loud, because the easiest way to lose a team's trust is to take credit for their part."

16. Solving a problem with incomplete or conflicting information (Observe Thoroughly)#

Version A: the render pipeline (verified)#

"At PMG, large renders weren't finishing, and the information I had conflicted. Users were telling us renders never completed. But every dashboard said the system was healthy: queue traffic looked normal, and the dead-letter queue, where failed work normally ends up, was empty.

When two sources disagree, I go to the most direct evidence I can find. The dashboards were summaries. The task logs were what actually happened. So I read the logs for the renders that weren't finishing. They showed the work was running in one long task that kept getting killed at its time limit, and that every retry published a fresh message, which reset SQS's receive count. Nothing ever looked like a failure. The dashboards weren't wrong about what they measured; they were measuring the wrong thing.

To decide what to do, I separated what I knew from what I was guessing. I knew the task was being killed and that the retries hid it. So the fix had to do two things: break the work into small batches that finish inside the limit, and make failures show up honestly. That became the design my teammates wrote, and I built the core of it.

What I took from it: when information conflicts, don't pick the source you like. Find the one closest to what actually happened."

Version B: the Slack bot (use this if the render story is already taken in the same interview loop)#

"On a small internal project at PMG, our brief for a Slack bot was vague, and the three of us each filled the gaps with our own assumptions. We all assumed the bot should create channels automatically. Halfway through, [I noticed we couldn't point to anything in the brief that actually said that]. The missing information was what the people asking for it wanted, and the only reliable source for that was them. So [I suggested we demo what we had and ask].

They wanted a guide, not automation: a slash command that opens a form and walks you through naming the channel, with the person still creating it. We decided to re-scope around that instead of defending what we'd built.

The lesson: when requirements are incomplete, the cheapest fix is asking the person who wrote them, before you build more."

Don't use the render story for more than two questions in one interview loop. Toyota asks for diverse examples.

17. Circumstances changed, or something didn't go as planned (Get Better and Better)#

Version A: the staging stall (verified)#

"At PMG, I was about to ship the new fan-out dispatch for the render pipeline. The plan was straightforward: finish the code, run it in staging at real scale, then merge it and turn it on with a feature flag.

Staging didn't go as planned. A large render got to 765,723 of 765,727 creatives and stopped. Four short. The worse part was that nothing alerted. A render stuck like that would just sit until a 24-hour timeout quietly cleared it.

In code review, the question came up: how would we even know if this happened in production? So the plan changed. Instead of merging the fan-out and adding monitoring later, I built the monitoring first: a scheduled check that flags any render stuck past a threshold, with a Datadog alert on it. That merged the day before the fan-out did. Then the fan-out went in behind its feature flag, and the completion accounting followed.

The outcome: the new path shipped with its main failure mode already visible, and turning it off was a config change, not a deploy. What I learned: when staging surprises you, the fix isn't just the bug. It's making sure you'd see the next surprise."

Version B: my personal site (a different project, for variety)#

"On my personal site, saves from the browser started reporting failures even though they'd actually gone through, so retrying wrote them twice. [Your part: whether you caught it, or your coding agent did.] The cause was the hosting provider's edge. We used a standard If-Match header so two edits can't overwrite each other, and the edge was checking that header itself and turning a successful save into an error.

Rather than fight the edge, or track which kinds of requests it touched, the fix was to send the version in our own X-If-Match header, which only our server reads.

The outcome: saves report correctly, no more double writes, and the site's API docs say which header to use, so the next person doesn't hit it. The lesson: when a platform you don't control changes the rules, route around it in the simplest way that can't break again."

18. Making sure everyone felt welcome, safe and heard (Show Respect for People)#

The primary story for this value; #12 is the backup. About 90 seconds.

"In college I was a regular member of a dance team, not a leader. At our senior send-off, nine seniors were graduating. The tradition is that everyone gathers, and people go around giving speeches and gifts to the seniors, and naturally most people only did that for the seniors they were close to. The team was pretty split into friend groups that year, and I knew a few of the seniors didn't have many close friends on it. I didn't want anyone to sit through their own send-off with nothing said to them.

So I bought a gift for all nine, and gave a short speech to each of them, not just the ones I was close to. Nobody asked me to. One senior in particular had had a hard year: a lot of friction with other people on the team, and people didn't always listen to her, but she kept doing the work for the team anyway. I told her I'd seen that: how hard she worked for the team, and how strong a dancer she was. I knew she'd been under a lot of stress, so my gift to her was a small plushie, something comforting.

She hugged me, and we'd never hugged before. And a year later, at my own send-off, people brought it up: that I'd done it for everyone.

I bring the same thing to work. On a group project at PMG, when we were preparing a presentation for stakeholders, I made sure everyone had a real part and their name on the slides, and I asked our quieter engineer to open it, so the first voice the stakeholders heard was his. After that the team started giving me honest feedback, and we worked better together. The people who are easiest to overlook are usually the ones who most need to be seen."

Keep it humble. Don't say "I was the only one who did it", don't say you did most of the work on the PMG project, and don't criticize teammates for only honoring their friends; that's normal.

19. Sharpening your skills to meet a changing need (Get Better and Better)#

The primary story for this value; #13 (Arch Capital) is the backup. About 90 seconds.

"When I joined PMG, I knew Python, but not Django or Redis, and I'd used MySQL at Arch Capital, not Postgres. I had to get productive in that stack quickly, and I wanted to actually understand it, not just follow patterns in the existing code.

I did it two ways at once. I learn fastest by building, so I set things up locally and experimented, Redis especially, until I understood what our code was actually doing. And I read to pin down the vocabulary: I bought O'Reilly books on Django, Redis and Postgres, and worked through them in Nibbler, a PDF reading app I built to track my reading.

It paid off in a design review about how we stored templates. Each template has versions, and the obvious design has the template point at its current version while every version points back at its template. That's a circular foreign key, and it makes inserts and deletes awkward. I proposed a separate table that just tracks which version is current, so the references only go one way. The senior engineer pushed on it, and I could explain the trade-off term by term. They approved it, and after that my pull requests started coming back 'LGTM' much faster. As a new engineer, that trust was the real result.

It's how I'd close my gaps here too. I haven't used Lambda or DynamoDB hands-on yet, and this is how I'd learn them: build with them, and read to get the definitions right."

The last paragraph of the story matters: it turns a known gap (serverless) into proof of how you learn.

20. Recognizing someone's contribution (Thank People)#

The primary story for this value; #15 is the backup. Also works as a backup for Work with Integrity. About 75 seconds.

"At Arch Capital, QA filed a ticket on me for a 500 error. Around the same time, a fellow intern was working on a ticket that went beyond its original scope: as part of it, he fixed how the backend split a full name into first and last name.

When I looked into my bug, the 500 was coming from that exact name-splitting path, so his change had already fixed it. From QA's side there was no way to know that; they looked like two unrelated tickets.

In the sprint retro, I said it plainly: his fix resolved my ticket. And I asked the team to cancel my ticket instead of closing it as done, so it wouldn't count toward the sprint's velocity or toward my own work.

That did two things. He got credit for the contribution he actually made, and the sprint's numbers stayed honest, with no story points for a fix that only happened once. The way I see it, if credit doesn't follow the work, people stop going beyond their ticket, and that extra-mile work is exactly what a team needs most."

21. Continuous improvement: the self-improving dev loop (Continue the Quest for Improvement)#

The primary story for this value. About 90 seconds. All numbers verified against the SHAN board and the scheduled tasks (registered 2026-03-27).

"On my personal site, I wanted to see how far an AI coding agent could take a real project without me prompting it every time. I didn't design the whole system up front. I built the simplest version, watched where it got stuck, and fixed that one thing, over and over.

Version one: a scheduled job runs the agent four times a day, and it picks up tickets from my Jira board. The bottleneck was me: it could only do what I'd written a ticket for.

So I let it scan the codebase and file its own bug tickets, and I only write the feature tickets. It started finding real bugs, but deep technical ones, nothing a user would ever see.

So I gave it an end-to-end testing standard: open the live site in a real browser and use it the way a user would. Then it started finding UI and quality-of-life bugs. For example, it measured every page in a real browser and found the whole site was failing one of Google's Core Web Vitals: each page jumped 8 pixels while loading, because the sign-in area in the nav bar didn't reserve its space. It fixed that the same day and re-measured: the layout shift went from 0.127 to zero.

Then the tickets piled up faster than they closed, so I added a verification agent that re-checks each fix and archives tickets that are no longer needed. And once, the scheduler reported success for about a week while nothing had actually run: the login had expired and every run failed within seconds. So I added a preflight check, and now a broken run fails loudly instead of looking green.

It's been running on its own four times a day since March. Every change has to pass the full test suite before it ships, and the board has gone through 441 tickets, 429 of them done. What I took from it: each fix exposed the next bottleneck. Improvement isn't one big redesign, it's removing the current constraint, then the next one."

Close with this if it fits: "At work, I'd only use tools like this the way the company approves. Your CTO has talked about protecting customer data first with AI, and I agree with that order."

22. Someone else's idea was better, and I went with it (Welcome Competition)#

The primary story for this value; #6 (how you'd handle a peer who disagrees) is the backup. About 90 seconds.

"At Arch Capital, my manager asked me to build an architecture chatbot using MCP, the Model Context Protocol, which was very new at the time. As an intern, my instinct was to build the finished thing on the first try: fully integrated with our enterprise application from day one. I used Copilot to scaffold it and spent two days fighting it. Part of the problem was that MCP was so new the AI didn't really know it, so it kept generating a conventional chatbot instead of an MCP integration.

In my one-on-one, my manager asked how it was going, and I told him the truth: I was stuck. He suggested something much simpler than anything I'd tried: forget the integration, build a hello-world MCP server in a sandbox, and just prove the concept works. His idea was better than mine, so I dropped my approach. I spent a whole day reading the MCP documentation instead of coding, and the next day I wrote a minimal prototype that worked locally with a couple of sample tools.

From there it was just adding tools and their descriptions, and we ended up connecting Ardoq, Confluence and Jira into the bot. The project was a success.

What I took from it: I was trying to prove everything at once. Now, especially with new technology, I prove the core idea in the smallest sandbox first, I read the primary docs instead of trusting an AI that may not know the tool yet, and I say 'I'm stuck' on day one, not day three."

Say "MCP server" or "the Model Context Protocol", never "MCP model": MCP is an open standard for connecting an AI assistant to tools and data, not a model.

23. Delivering an exceptional customer experience (Act for Others)#

The primary story for this value; #11 is the backup. About 100 seconds.

"At PMG, I supported our media team, and they asked me to move a hotel brand's monthly report out of a Google Sheet and into a dashboard on Alli, our internal marketing platform. The media team were my customers.

My first version had all the data, but I wanted to see it from their side, so I ran the monthly report myself, the way they did. That's when I felt the pain: for every campaign, you clicked around Alli to set the right filters, pulled the data, pasted it into a spreadsheet, then went back, changed the filters for the next campaign, and repeated, one at a time. And you had to remember all those filters or keep them in your own notes.

So I put the filter rules in code once, so nobody would set them up by hand again, and documented them anyway. Then I built it around what they cared about: metrics like pixel fires and room bookings that were already in our BigQuery data, connected TV and click-through rate, a breakdown by hotel location, and the hotel brand's colors, so it was obviously that brand's report. I checked each change with the media team before adding it.

After a few rounds of check-ins with my buddy and their manager, the team completely dropped their Google Sheet, a well-organized one they'd put real work into, because the dashboard was easier to present to the client and handled all the logic for them. The media manager leading the team's automation work gave me a shout-out at a company all-hands.

What I took from it: the fastest way to understand a customer is to do their job once yourself. And internal teams are customers too, which is exactly who Enterprise Shared Services serves."

Say "connected TV" (streaming TV ads), not "cable TV". Call the client "a hotel brand"; don't name a former employer's client. Only quote a time-saved percentage if someone actually measured it.

24. Being honest when "done" would have been easier (Work with Integrity)#

The primary integrity story; #7 (reporting 98.7%) and #20 (giving away credit) are backups. About 75 seconds.

"At PMG, I was fixing the counting in our render pipeline. On the surface it looked like one bug, but it turned out to be several: duplicates, over-counting, and creatives being skipped entirely. And it mattered beyond our team, because the product was still labeled beta, partly because of exactly these counting problems.

Every standup, my manager asked how it was going. There were days when the implementation was done and it would have been easy to just say 'done'. But the testing wasn't finished, so that's what I said: 'the code is in, the testing isn't done yet.' Every time.

Because of that, the team didn't count my fix as a reason to drop the beta label until it was actually tested. We kept working through the issues one at a time, and we didn't overpromise to anyone.

For me, 'done' means tested. If I say done and it isn't, the cost doesn't land on me; it lands on whoever makes a decision based on my word."

25. Building consensus between groups that wanted different things (Work with Integrity)#

The answer to Toyota's sample question "Describe a time when you had to build consensus among conflicting groups." #5 is the backup. About 100 seconds.

"At PMG, our media team wanted their Google Campaign Manager 360 work folded into Creative Studio. Their process jumped between tools: render the creatives in Creative Studio, paste the preview links into a spreadsheet for the client to approve, then set everything up again in Campaign Manager. My own engineering team pushed back, for a real reason: Creative Studio delivered straight to platforms like Meta and Pinterest, and Campaign Manager is a completely different architecture.

Our product manager set up a meeting to work it out, and as a junior developer, my part was making sure the right people and the right facts were in the room. I'd worked with the media team on the travel accounts, so I knew who actually used Campaign Manager every day, and I recommended bringing them in. And as a backend developer, I explained how our rendering worked, so the engineering constraints were concrete instead of abstract.

When the media team walked through their real workflow step by step, it was clear that most of the manual work was in the setup, all the steps you click through to configure a campaign, while the final delivery was something Campaign Manager already handled. So both sides agreed: Creative Studio would take over the setup and hand off to Campaign Manager's existing delivery, instead of rebuilding everything. We wrote it up as an architecture doc, started building, and demoed an early version. It was still in progress when my time at PMG ended.

What I took from it: as a junior engineer, my lever isn't authority. It's getting the right people and the right facts into the room. Once everyone was looking at the same steps, most of the disagreement went away."

Never claim you organized the meeting; the product manager did. Don't use template phrases ("structured setting", "data-driven discussion", "listen actively and incorporate multiple perspectives").

26. Building consensus: the college project that was stuck arguing (Work with Integrity)#

The strongest answer to "build consensus among conflicting groups", because it has a clear result. #25 is the work-based backup. About 80 seconds.

"In a software engineering course at UNC, our final project was a full-stack website, built agile, in sprints. Early on, the team was stuck. Nobody agreed on what to build it with, and instead of deciding, people went off in different directions: one person was hunting for header images, another was writing loose Python scripts with no backend structure. Lots of opinions, no shared starting point.

I happened to have full-stack experience, but I didn't want to win the argument by insisting on my stack. So I built a hello-world version instead: a small React frontend talking to a FastAPI backend, pushed to our repo. I walked everyone through it: here's where pages go, here's how you add an endpoint, here's a snippet you can copy. And I framed it as a proposal: if this works for everyone, let's build from here.

Once there was something concrete to react to, the debate ended fast. Everyone took a piece: one teammate owned the design and front page, another handled networking and deploying it on a server, and everyone contributed code. We shipped the full site, got top marks, and our professor singled our project out for praise.

What I learned: when a group is stuck arguing in the abstract, the fastest way to agreement is a small working example everyone can look at."

27. Going to see the problem for yourself: the Labor Day render incident (Observe Thoroughly)#

The strongest genchi genbutsu story; #3 (Chromium) and #16 are backups. About 90 seconds.

"Right before Labor Day at PMG, a travel client's ads were rendering wrong. I was on call that week, but the incident had started the week before, so I had no context.

Instead of working from the ticket description, I went and saw it three ways. First, I sat with the engineer who'd handled it the week before and had him reproduce the whole workflow while I recorded it, with his permission. Second, I asked [the person who reported it] to show me exactly how she used it. Third, I reproduced it myself in the render pipeline and read the logs.

Doing it myself showed me it wasn't one problem, it was several: text landing in the wrong fields, so a call to action that should say '20% off' said 'Saturday, 9 AM'; some creatives rendering completely blank; and the progress bar showing 0% when a render was actually half done. Nobody had seen all of that from the ticket.

So I filed each one as its own ticket, with a screen recording showing how to reproduce it, and we fixed them one at a time. Meanwhile I sent her a short update every day: what's fixed, what's next. Even when it's not done, people want to see the progress bar moving.

What I learned: a bug report is someone's summary of a problem. You only see the real problem when you reproduce it yourself."

28. Situational: you find a teammate's bug on release day#

"It's release day, and right before shipping you find a bug in a teammate's code that would break a service another team depends on. Your teammate is in meetings all afternoon."

"First, I wouldn't ship something I know breaks another team's service. On a shared-services team, the other teams' trust is the product.

So I'd message my teammate right away, even mid-meeting, so they're not surprised, and tell our tech lead at the same time, because delaying a release isn't my call alone.

Then I'd pick the safest fix, not the cleverest one. If the bad change is isolated, revert that commit or turn it off behind its flag, and ship everything else. I wouldn't rewrite my teammate's code on release day unless it's a genuine one-liner that someone else reviews. If we can't separate it cleanly, we hold the release and tell the other team when to expect it.

Afterwards I'd sit down with my teammate, not to blame, but to figure out how it got so close to shipping, and add a test or check so it can't happen again.

Something similar happened on my last team: we did an internal demo right before each release, and once it caught a bug from a recent push. We rolled back to the previous version, which still had most of the new features, and shipped the fix after."

Never "ship it anyway and tell the other team after". Revert rather than rewrite, and tell the lead before acting, not after.

29. What is your biggest strength? And your biggest weakness?#

Say the parts back first ("So: a strength and a weakness. Strength first"). About 45 seconds each. Both answers are in Shane's own words; the only bracketed line is a proof point to confirm.

Strength: I think like an architect.

"My strength, and what I think sets me apart from other early-career candidates, is that I think like an architect. At Arch Capital I was a software development and architect intern, and I shadowed the company's principal architect. We went through the whole life cycle of an application: how a legacy application gets integrated with a new system, how you migrate from the old system to the new one, and the hard part, how you slowly sunset the old systems, which takes a lot of preparation.

I bring that view into my code. I write code that is maintainable, clean and simple, because I'm picturing the person who has to extend it, integrate it or retire it later.

It matters more now with AI. Most people don't really evaluate the code when they generate it. I read and judge every change against how the system will live, not just whether it runs today."

Weakness: I don't think fast on my feet.

"My weakness is that I'm a slow thinker, not a fast one. That's fine when I'm coding at my desk, but in a presentation, a Q&A, or a live coding question I can get nervous, and I may take longer to answer than I'd like.

What I'm doing about it: I deliberately practice under pressure. I live stream my coding practice every day, so people can watch me work, and that gives me the pressure of being observed. I also put a timer on my practice problems to train fast thinking. There's fast thinking and slow thinking, and I'm building the fast one on purpose."

Change log#

2026-09-25: first version. Built from the Toyota prep doc, corrected against the actual Creative Studio code (no watermark claim, no 1,983-test claim, no "tracing hooks" claim, staging wedge told the right way round). Added the Slack bot story (brackets to fill) and the downtime answer.
2026-09-25: published. Added "incomplete or conflicting information".
2026-09-25: added "circumstances changed, or something didn't go as planned".
2026-09-26: Chromium story corrected against the record: the fix was the --disable-dev-shm-usage flag plus a writable home directory for the crash handler, not resizing /dev/shm.
2026-09-29: added "made sure everyone felt welcome, safe and heard" (dance team senior send-off), brackets open.
2026-09-29: #18 completed from Shane's answers (a regular member, the senior who'd had a hard year, the hug, remembered a year later, the PMG presentation bridge). Kept third-party details non-identifying.
2026-09-29: added #19 "sharpening your skills to meet a changing need" (Java to Python at PMG, Nibbler, the design review), brackets open.
2026-09-29: #19 completed from Shane's answers (knew Python, new to Django, Redis and Postgres; O'Reilly books; the circular-foreign-key design review; reviews started coming back LGTM).
2026-10-01: added #20 "recognizing someone's contribution" (the fellow intern whose fix resolved my ticket, cancelled to keep velocity honest).
2026-10-02: #10 finished (the one-line batch endpoint change). Added #21, the self-improving AI dev loop, as the primary story for Continue the Quest for Improvement; two brackets open.
2026-10-02: #21 completed: the Core Web Vitals bug the agent found by measuring the live site (0.127 to zero), running since March, 429 of 441 tickets done; the self-noticed periodic-table bug as a backup example.
2026-10-02: added #22, the Arch Capital MCP chatbot (manager's hello-world sandbox idea beat my build-it-all-at-once approach) as the primary story for Welcome Competition.
2026-10-02: added #23, the hotel brand's monthly dashboard on Alli (ran the monthly reporting myself; made it brand-aware), as the primary story for Act for Others; brackets open.
2026-10-02: #23 updated: the customer was the PMG media team; before, they copied data out of Alli into the sheet by hand every month; after, the dashboard pulls it itself. Three brackets left.
2026-10-02: #23 completed: the manual filter-copy-paste loop he felt by running the report himself, rules moved into code, the team dropped their Google Sheet, shout-out at an all-hands.
2026-10-05: added #24 (honest status in standup: "the code is in, the testing isn't done") and drafted #25 (media team vs engineering on Campaign Manager), brackets open.
2026-10-05: #25 completed: the product manager set up the meeting; my part was bringing in the real Campaign Manager users and explaining the rendering constraints; agreed compromise, architecture doc, early demo, unfinished when my time at PMG ended.
2026-10-06: from the morning mock before the onsite: #23 gained pixel fires, room bookings and the check-ins; added #26 (college project consensus), #27 (Labor Day incident, genchi genbutsu) and #28 (situational: teammate's bug on release day). Restored section dividers lost in earlier edits.
2026-10-21: added #29, strengths and weakness, from Shane's own words (strength: thinks like an architect from shadowing the principal architect at Arch Capital, application life cycle, legacy integration, migration and sunsetting, maintainable code, judging AI-generated code; weakness: not a fast thinker on his feet, daily live-streamed timed practice). One proof point left in brackets.

How to use this#

1. Walk me through a project you're proud of#

2. A problem where the root cause wasn't obvious (Drive Curiosity)#

3. A time you went and saw for yourself (Observe Thoroughly)#

4. A time a team you were on wasn't working effectively#

Version A: the render pipeline (verified)#

Version B: the Slack bot (human story, brackets to fill)#

5. Build consensus among groups with conflicting objectives (Work with Integrity)#

6. A peer insists his solution is better than yours (Welcome Competition, without ego)#

7. A time you reported something that wasn't good news (Work with Integrity)#

8. A failure, or something you'd do differently (Get Better and Better)#

9. Eliminating waste (Create Room to Grow)#

10. A small improvement that mattered (Continue the Quest for Improvement)#

11. Serving an internal customer (Act for Others)#

12. Respecting your teammates' work (Show Respect for People)#

13. Learning something new fast (Get Better and Better)#

14. Why Toyota? Why not a startup? (plus the downtime question)#

15. Giving credit (Thank People)#

16. Solving a problem with incomplete or conflicting information (Observe Thoroughly)#

Version A: the render pipeline (verified)#

Version B: the Slack bot (use this if the render story is already taken in the same interview loop)#

17. Circumstances changed, or something didn't go as planned (Get Better and Better)#

Version A: the staging stall (verified)#

Version B: my personal site (a different project, for variety)#

18. Making sure everyone felt welcome, safe and heard (Show Respect for People)#

19. Sharpening your skills to meet a changing need (Get Better and Better)#

20. Recognizing someone's contribution (Thank People)#

21. Continuous improvement: the self-improving dev loop (Continue the Quest for Improvement)#

22. Someone else's idea was better, and I went with it (Welcome Competition)#

23. Delivering an exceptional customer experience (Act for Others)#

24. Being honest when "done" would have been easier (Work with Integrity)#

25. Building consensus between groups that wanted different things (Work with Integrity)#

26. Building consensus: the college project that was stuck arguing (Work with Integrity)#

27. Going to see the problem for yourself: the Labor Day render incident (Observe Thoroughly)#

28. Situational: you find a teammate's bug on release day#

29. What is your biggest strength? And your biggest weakness?#

Change log#

Comments

How to use this#

1. Walk me through a project you're proud of#

2. A problem where the root cause wasn't obvious (Drive Curiosity)#

3. A time you went and saw for yourself (Observe Thoroughly)#

4. A time a team you were on wasn't working effectively#

Version A: the render pipeline (verified)#

Version B: the Slack bot (human story, brackets to fill)#

5. Build consensus among groups with conflicting objectives (Work with Integrity)#

6. A peer insists his solution is better than yours (Welcome Competition, without ego)#

7. A time you reported something that wasn't good news (Work with Integrity)#

8. A failure, or something you'd do differently (Get Better and Better)#

9. Eliminating waste (Create Room to Grow)#

10. A small improvement that mattered (Continue the Quest for Improvement)#

11. Serving an internal customer (Act for Others)#

12. Respecting your teammates' work (Show Respect for People)#

13. Learning something new fast (Get Better and Better)#

14. Why Toyota? Why not a startup? (plus the downtime question)#

15. Giving credit (Thank People)#

16. Solving a problem with incomplete or conflicting information (Observe Thoroughly)#

Version A: the render pipeline (verified)#

Version B: the Slack bot (use this if the render story is already taken in the same interview loop)#

17. Circumstances changed, or something didn't go as planned (Get Better and Better)#

Version A: the staging stall (verified)#

Version B: my personal site (a different project, for variety)#

18. Making sure everyone felt welcome, safe and heard (Show Respect for People)#

19. Sharpening your skills to meet a changing need (Get Better and Better)#

20. Recognizing someone's contribution (Thank People)#

21. Continuous improvement: the self-improving dev loop (Continue the Quest for Improvement)#

22. Someone else's idea was better, and I went with it (Welcome Competition)#

23. Delivering an exceptional customer experience (Act for Others)#

24. Being honest when "done" would have been easier (Work with Integrity)#

25. Building consensus between groups that wanted different things (Work with Integrity)#

26. Building consensus: the college project that was stuck arguing (Work with Integrity)#

27. Going to see the problem for yourself: the Labor Day render incident (Observe Thoroughly)#

28. Situational: you find a teammate's bug on release day#

29. What is your biggest strength? And your biggest weakness?#

Change log#

Comments