behavioral / 11_approach_new_technologies.md

How do you approach working with new technologies?

4 interview angles 2 min read source

How do you approach working with new technologies?

Answer

Start with docs and a minimal example

I read official docs and run a minimal “hello world” example to understand basics: setup, core API, and lifecycle. On the Invest Planning Platform, I picked up LangChain/LangGraph, AWS (SNS, SQS, Cognito), and Vue 3 this way—get something running, then iterate.

Learn by building

I apply the tech to a small, real feature rather than only tutorials. For the AI chatbot, I started with a simple LangChain chain, then added tools, consent flows, and guardrails. Building forces me to handle edge cases, errors, and integration.

Use patterns I already know

I map new tools to familiar patterns: LangGraph graphs to state machines, Celery to async task queues, Vue to component-based UI. That accelerates learning and keeps designs consistent with the rest of the system.

Incremental adoption

I avoid big rewrites. I introduce new tech in bounded areas (e.g. one service, one feature), validate it, then expand. Docker, Pytest, and CI/CD were added step by step; each step had tests and clear ownership.

Docs and sharing

I document setup, decisions, and gotchas so the team can use the new tech without repeating my mistakes. I’m comfortable pairing or doing short demos to onboard others.

Interview angle

  • “How do you evaluate a new technology?” - start with the problem it claims to solve and whether you have that problem. Then: maturity and maintenance, ecosystem and hiring pool, operational cost, and the exit path if it’s wrong. Novelty is not a reason.
  • “How do you learn one?” - build something small and real with it rather than following a tutorial, because the friction you hit is the information you needed. Then read the parts of the docs the friction pointed at.
  • “How do you decide whether to introduce it to the team?” - a written comparison against the incumbent, a spike with measurements, and an honest account of the cost: who else knows it, what happens when the person who introduced it leaves, and what it adds to on-call.
  • “When do you deliberately choose the boring option?” - most of the time. Ecosystem size, team familiarity and operational maturity usually outweigh a technical edge, and being able to argue that is a stronger signal than enthusiasm for the new thing.