strengths
- customer focus (critically identify gaps in technologies for customer exp)
- learning new technologies: agentic workflows (good example of deep dive)
- hiring and mentoring (50 interviews wait no senior? interns..)

"Think about a time you encountered something unfamiliar at work"
- new tech 6 months ago, attended tech talks about agentic workflows
- brainstormed how they could use it for their team
- it's very different from traditional backend REST API calls
- it's a streaming model, it takes a lot longer to run these models, tinkered with test apps on bedrock
- met with senior engineers to learn more about the workflows, document them for the team

"what project are you most proud of"
- on the same track, I've built a ticket auto-triage tool
- I'm not really sure what they said, but eventually they got to outcomes (reducing time to triage)
- still not clear why they are proud of this, feels like they're just giving me a project report
- instead of highlighting "this is how *I* grew from this"
- cost savings projection -> design doc -> iterative development process -> orchestrated 3 engineers
- something about obs, mcp servers, logging, swarm, linear workflows, local development, metrics, graph db...
- getting way too far into the tech without me asking.
- clearly has technical depth, focus on metrics + customer experience, seems like they could have high ownership
- finally identified the shortcomings of overengineering

"Why is overengineering bad"
- didn't answer my question at first
- creating or using unnecessary files
- building fragility into the infrastructure
- example: agentic workflow addressing the problem of placeholder data - only affected one type of component/carousel

"how did you grow from this project?"
- new model of monitoring nondeterministic workflows - model latency, i/o token size
- optimizing prompts is directly correlated with team costs and quality of output
- context management - swarm digging into a deep ticket can ruin its context. there's different approaches here

"You realize your team is sacrificing security/reliability to release a product, how do you bring this up"
- would raise a flag in the doc review, focus on the requirement for scale, is aligned with security guidelines, etc
- these are questions I've added to our team's docs infra myself
- would make sure these are known by the DRI engineers
- would expect that the proposed product has rigorous backup behavior
- would make sure that new services follow golden path recommendations by default
- notably - no talk about how to resolve this after-the-fact
- irl story: they found a service that skipped launch readiness for his service (? lol)
- and worked with them to resolve, make sure they're ready for company-wide load tests
- why was this skipped in the first place? the web engs were new, subject to churn, unaware... and silo'd.

"Tell me about a time you disagreed with someone"
- met with some senior engs to understand perspective on whats blocking engs building features e2e with ai tooling
- prime video put together "ai native framework" but there were q's around what is this actually good at? (lol)
- colleague wanted to pilot ai native framework for a brownfield project, whereas they felt like it's better for greenfield
- team met to decide they will put the 2 in the ring... duke it out... other engineer got tilted and refused to scope down
- therapized the other guy, ultimately demo'd 2 cool projects to the team

meta points
- not bad, but meanders around the point until they eventually get to outcomes
- really just has one story
- impact seems team-scoped
- issue with vocabulary - 'legacy' preferred over "blah blah 3 months 6 months engineers no longer here archaic..."
- needs to focus on the story they're telling, continually engage me - "I can expand on that if you want, but that's the gist"
- seniors are capable of taking a step back and translating tech to english
- comes off as high-energy mid level