Behavioural / 11_approach_new_technologies.md

How do you approach working with new technologies?

Updated 4 interview angles 4 min read source
On this page7
  1. What they’re really asking
  2. The strong answer pattern
  3. An answer that works
  4. Anti-patterns
  5. What the answer signals
  6. Related
  7. Interview angle

How do you approach working with new technologies?

What they’re really asking

Two different questions hide in this one, and it helps to notice which you are being asked. How do you learn a tool? is about method and speed. How do you decide whether to adopt one? is about judgement — and it is the one senior interviews care about, because an engineer who reaches for every new thing is expensive.

The honest tell they are listening for: can you argue against a new technology you find interesting? Enthusiasm is easy; the boring option chosen deliberately is the senior signal.

The strong answer pattern

For learning: docs, then a small real thing, then the parts the friction pointed at. Not a tutorial — a tutorial avoids the edge cases that are the actual information.

For adopting, the questions in order:

  1. What problem does it claim to solve, and do we have that problem?
  2. Maturity and maintenance — who runs it, how it is funded, how it breaks.
  3. Who else here will know it, and what happens when the person who introduced it leaves.
  4. What it adds to on-call and to the deploy.
  5. The exit path if it turns out wrong.

Then a bounded introduction: one service, one feature, measured, with clear ownership, before it spreads.

An answer that works

Start with docs and a minimal example. I read official docs and run a minimal 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 (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.

Anti-patterns

  • Adoption by enthusiasm. “It’s what everyone is moving to” is not a reason, and interviewers hear it as a risk to the codebase.
  • No exit path. Introducing something without having asked how you would remove it.
  • Learning by tutorial only. The tutorial path is the one path that works; production is the other ones.
  • The big-bang rewrite. Rewriting the service in the new framework as the way to learn it. Bounded first, always.
  • Never choosing the boring option. A candidate who has no story about deliberately not adopting something reads as someone who has not been the one holding the pager afterwards.

What the answer signals

Method over enthusiasm, and the judgement to weigh operational cost against technical appeal. A story where you evaluated something, wrote down why not, and chose the incumbent is worth more than three stories of successful adoption.

Interview angle 4

  • “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.
Previous
How do you handle not knowing something in an interview or on the job?