How do you keep your technical skills current?
answer
- two or three habits, not a list
- how you choose what to learn
- one habit, one level deep
- the opinion it changed
- tie it to this team's stack
basics
~20 sProbes genuine curiosity and whether you will keep growing with the team. Answer with two or three habits you actually practise, one taken a level deep, and a link to the stack this role runs.
how to answer
5 beats- the two or three habits you actually keepName a small number of habits you genuinely practised in the last few months, not an aspirational list. Include at least one that has a rhythm to it — weekly, per release, per project — because a rhythm is harder to fake than a subscription.
- how you choose what to spend learning time onSay out loud what your filter is: what your systems depend on, what your next year of work will demand, and a deliberately small allowance for things outside your lane. Naming what you ignore reads as judgement, and it pre-empts the follow-up probe.
- one habit taken a level deepPick a single source and say what you actually took from it — the assumption it overturned, the setting you had been misusing, the thing you now do differently. This is the beat that separates you from every candidate who answered with a reading list.
- what you are working through right nowGive one current, unfinished thing and be honest about how far in you are. Present tense makes the habit real, and admitting you are three modules into something is more credible than claiming mastery of it.
- the link to what this team runsClose by connecting one habit to a technology or problem this role involves, conceding any gap plainly. Even a toy-project level of exposure lands well when you say it is a toy-project level of exposure.
your answer
4 story prompts- List the learning habits you actually kept in the last three months, not the ones you intend to keep.
- Pick one source you consumed recently and name the specific opinion it changed.
- Find one habit that produced a change in shipped code, and attach a number to it.
- Name one technology in this role's stack you have touched, even only in a side project.
draft and rehearse your own answer in a learn session
go deeper
The axis is motivation and growth trajectory. The interviewer is testing whether curiosity is a habit you practise or a word on your resume, and whether your learning aims anywhere near the problems this team has. A strong answer proves self-direction with checkable specifics rather than volume, and shows judgement about what is worth ignoring.
Three things, and they are all small enough that I actually do them. Before I touch a system I read its documentation properly rather than the quickstart. I keep a running notes file of things I did not understand that week, and on Friday afternoons I pick one and chase it down. And I have been working through a streaming-systems course, one module a week, for the last few months. The chasing-it-down habit is the one that has paid off. On the data team I am on — about twelve of us, running the feature pipelines behind the product — our nightly refresh had crept from roughly forty minutes to over two hours, and features were reaching the app up to twenty-six hours old. I had written 'why does the nightly job re-read everything' in my notes weeks earlier. I spent one Friday in the warehouse's incremental-load documentation and found we were doing a full scan of a partitioned table because our filter was not on the partition column. I brought it to my tech lead with the query plan, he agreed, and I made the change. The refresh came back down to fifty-one minutes. The reason I mention the course is that this role involves moving ingestion to streaming. I have only built toy pipelines with it on my own time, but I would rather arrive already knowing the vocabulary than start from zero.
Three habits a person could actually keep, one of them chased to a concrete outcome, and an honest concession about the toy-project depth. The refresh number is what makes the habit believable. Naming the course with no project and no vocabulary behind it would drop this back to a reading list.
I split learning time into two buckets and I am deliberate about the ratio. Most of it aims at what we run: release notes and design documents for the two or three systems my team depends on, and I will read another engineer's incident write-up before I watch a conference talk. The smaller bucket is one thing a quarter that is outside my lane, because otherwise I only ever get better at what I am already good at. A concrete case. Our feature-store milestone slipped twice because backfills kept blocking live writes, and staleness at the ninety-fifth percentile sat around nine hours. Rather than guess, I spent two evenings on how a couple of open-source engines handle incremental materialisation and late-arriving data, wrote a two-page comparison for the four of us on the pipeline side, and we chose the option with the weaker consistency guarantee on purpose, because our consumers tolerate it. Staleness settled near seventy minutes. The habit I am least willing to give up is writing the thing down. Half of what I read I misunderstand until I try to explain it to somebody else. That two-pager is still the document people open before touching that pipeline, which tells me the learning landed somewhere other than my own head. Right now the outside-my-lane thing is query optimisation internals, and I am early in it.
The ratio and the filter carry the signal here: this is judgement about what to ignore, not appetite. The written comparison shows the learning reaching teammates and a shipped decision. Dropping the trade-off that was accepted on purpose would leave a story about reading, not deciding.
Your habits are allowed to be modest and recent: docs read properly, a course you finished, a side project. What carries the answer at this level is one specific thing you changed in your own code because of something you read.
Show a filter, not an appetite. Say how you decide what deserves your learning time against what your team actually runs, and give evidence that something you learned reached shipped work and at least one teammate.
Aim the learning at decisions you own. Talk about evaluating an approach before adopting it, what you tried and rejected, and how you avoid adopting things on enthusiasm alone in systems you are accountable for.
Talk about mechanism as well as appetite: how learning spreads past you, such as a written evaluation standard or a forum where options get compared. Say how you keep any real technical depth while your surface area widens.
saying these in an interview costs you the question
- Reciting blogs, podcasts and newsletters with nothing learned from any of them
- Naming a habit you cannot produce a single specific from
- Chasing only trend topics unrelated to what the role actually runs
- Courses started and never finished, offered as evidence of learning
- Answering in one sentence, as if the question were box-ticking
- Claiming you never need to learn outside work without showing what you learn inside it
- What is the last thing you read or watched that changed how you work?Have one ready that is not from years ago. Name the source, the specific idea, and the concrete thing you did differently afterwards, even if small. If nothing changed, pick a different source rather than inflating the impact of this one.
- How do you decide what is worth learning and what to ignore?Describe an actual filter rather than saying you follow your curiosity. Anchor it in what your systems depend on, what your next twelve months will demand, and a deliberately small allowance for things outside your lane. Admitting you ignore most of the noise reads as judgement, not disinterest.
- Who do you learn from on your current team?Name a role and what you learn from that person, not a personality assessment. Then show the reciprocal direction: something you have taught or written up. Learning only from consumption and never from colleagues is a signal interviewers notice.
## What the interviewer is actually estimating This question is rarely about your reading list. The specific skills a team hires for age quickly, so the interviewer is estimating what you will look like in eighteen months: whether you will still be the engineer they hired, or a better one. **Self-directed learning** is the cheapest available proxy for that, because nobody assigns it to you. The corollary is that a long list of sources proves nothing — it is a claim about consumption, and consumption is not the signal. ## Variants you should recognise as the same prompt - 'How do you stay up to date?', - 'How do you keep your skills sharp?', - 'What are you learning right now?', - 'Where do you go when you need to learn something you do not know?', - and the most dangerous phrasing, 'What blogs or people do you follow?' — dangerous because its grammar invites a list and most candidates give one. Answer the last variant with one or two sources plus what you took from them, and you have quietly converted a list question into an evidence question. ## The evidence ladder Rank what you can offer, weakest to strongest. 1. **Consumption** ('I read X') is the floor. 2. **Application** ('I read X and changed how I wrote Y') is the working bar. 3. **Changed opinion** ('I used to think A, then reading X and testing it convinced me of B') is stronger, because it proves you processed the material rather than absorbed it. 4. **Propagation** ('I wrote it up and now the team uses it') is the ceiling and is what distinguishes senior answers. Aim one rung above your level and support it with a specific, and the answer stops sounding rehearsed. ## Weak versus strong, in one contrast - **Weak**: 'I read a lot of engineering blogs, listen to a couple of podcasts on my commute, and I am doing a course on distributed systems.' Nothing there is false, and nothing is checkable. - **Strong**: the same three habits, plus one sentence that only someone who actually did it could say — the specific thing that surprised you, the setting you found, the assumption it overturned, the number that moved afterwards. One verifiable specific beats four unverifiable habits. ## Tie it to the stack in the room The second half of the signal is **fit**. If you know the team runs streaming ingestion, or that they are migrating a warehouse, say which of your habits already points there — even if the honest version is 'I have only built toy versions of this on my own time'. That sentence is credible precisely because it concedes the limit, and it tells the interviewer your curiosity happens to aim where their problems are. ## How the bar moves by level - **Early on**, the question is whether you have any self-directed habit at all; a finished course and a real change in your own code clears it. - In the **middle**, the interviewer wants a filter — the ability to say no to most of what is interesting because it is not what your systems need. - At **senior level**, learning is expected to feed decisions you are accountable for, so the interesting content is what you evaluated and rejected. - At **principal level**, personal habits matter less than whether learning becomes repeatable for other people. ## Delivery Sixty to ninety seconds. - Two or three habits, - one of them taken a level deep, - one link to this team. Then stop — the follow-up probes are where the rest of your material belongs, and leaving room for them is a better use of the airtime than a fourth habit.