You are likely to get questions passed around, and some vague 'documentation' on a complex system. No one gets a chance to review it more than once a year so... That means processes have changed. The coding standards are different now.

These are the general frustrations of the average company, where people focus on velocity more than the comfort of incoming colleagues.

Many new hires will take the time not to rock the boat. To put their head down and build some velocity. And that's a great strategy, if you want to become someone known for pushing good feature code and a 'safe pair of hands.'

The 'safe pair of hands' is someone we can trust to get things done, they are reliable, docile, and mostly invisible.

You can get on just fine as a team member who doesn't go 'above and beyond' but there is always a ceiling. It's simply the wrong approach.

If you think that above and beyond means overtime, late nights, grinding, and burnout, you are wrong.

Going above and beyond isn't about becoming a consumable that spits out code fastest (AI is always going to beat you, for people who aren't looking at the quality).

Going above and beyond is a matter of taste.

It's a matter of sharing impactful opinions, which means it's a matter of persuasion.

Because we aren't really that impactful as individuals, we are impactful when we steer our teams. Being known for opinions that create great outcomes is a skill. Being able to make them happen is a far better metric of seniority than a high velocity.

I know a lot of devs don't love leaning into these things. They are happier buried in the code. And I can understand that. Code is where we live and breathe but increasingly careers are decided outside the IDE by the 'non-technical stakeholders'.

Meetings

Warning: I am going to focus on the most controversial meeting in the dev team.

Be honest, which stand-up personality is yours? Are you more half-baked, boring festival of "err...", "um...." with people zoning out. Or the classic "Yesterday X, today Y. No blockers." Useful stuff, thanks!

I understand that most developers hate Scrum ceremonies. The stand-up more than any. An interruption to talk about work instead of working. It is so easy for it to become a status check in that nobody asked for. However, those are 15 non-negotiable minutes with time to influence.

For example, simply relating your tasks to the experiences you're hearing. If somebody is doing something similar to what you did yesterday, that's a moment to clarify that the pipelines are flaky or whatever. You can offer a hand. And when it comes to the next stand up you can remind people that "Yesterday, I helped with..." This gets you a reputation as being generous with your time, visibly.

Instead of people asking you outside of a meeting and that time disappearing from your velocity, it is acknowledged. Perhaps not for all posterity, but you leave an impression as a particular type of person. One who goes above and beyond for your team.

Even if you aren't eager to share at the stand-up, at its most basic level, communication is two-way. It's about listening as much as talking. Not listening to colleagues and continuing to clack on your mechanical keys is actually just rude. Simple as. People will notice it.

Mentoring

If you are this far into the article, I doubt this is your first rodeo. You already have tech experience. If you have colleagues with shorter tenure either overall or in the company. You can mentor them. If you know there is someone with an interest in coding outside of the dev team, you can mentor them. Potentially, if you are a career changer with some secret knowledge in a tangential field, you can mentor someone.

Mentoring provides outsized impact to your team. You are enabling people to solve problems in the future and to pass that experience forward. It creates institutional knowledge. It creates culture. There is a (clearly massively oversimplified) reason why the octopus is not the master of this planet. They don't live long enough to pass knowledge onward. That's a problem with AI too. However much you prompt it to make no mistakes and act as a senior developer, it resets. Your mentees don't.

You should even be mentoring for one wholly selfish reason, if it isn't something you enjoy. It clarifies your thinking. It makes you better at communicating complex ideas to less technically-able people. It helps you find a range of ways of explaining things that different people understand. And it makes people like you.

When I arrived fresh to my first day as a dev, I lucked out with my mentor. I had someone who told me the same thing way too many times when I asked stupid, stupid questions and rarely took notes. That's not a colleague one forgets!

Metrics

If you do any of the above, and you aren't generally miserable and difficult, your team is probably going to like you. Being well-liked is going to get people on your side.

So, by now you have demonstrated that you are a competent team player who is easy to get along with. So what about that bonus and a juicy senior or staff title?

You probably aren't getting promoted on that alone. You need a little more leverage. When we imagine great communicators we think of compelling public speakers. We overlook ongoing communication with ourselves. Something that allows us to create the story of our work before it is written by someone else.

Especially as we usually end up doing our work and forgetting. Lord knows our inundated managers aren't thinking about it. They might have some general visibility like velocity. But remember, a safe pair of hands is just that. They are doing all the feature work.

It's best not to get into your review or a salary negotiation, or even an interview with a blank canvas of what you've achieved.

So write it down!

A notepad, a word doc, a git repo. It doesn't matter. Write down what you did, what changed. If you have some numerical metrics about performance or business even better. If you have a way to collect them do so. If you don't, try to make a way. Employers salivate over CVs with metrics, like 'reduced login screen load time by 800ms, reducing bounce rate by 1.3%.'

If you are keeping note of all your achievements, not only are you going to feel insanely good, you also have a powerful tool to communicate your value to the company. As Simon Pegg says in Hot Fuzz, "This is the most important piece of equipment you will ever own. This notebook has saved my skin more times than I care to remember."

And don't forget to keep it backed up to a personally accessible spot.

If you can manage these, you are in the top-tier of communicators in your team. Sometimes the bar is quite low.

These three Ms are simple areas that create a big change in one's communication habits. None of them involve drilling grammar and practising in the mirror or flashcards. They involve performing simple maintenance on the relationships at work. They involve setting an example for the team. These are the difference between a safe pair of hands who is given more velocity and an asset who is trusted with responsibility.

If this is something you would like help putting into practice for yourself, don't be a stranger. I work with devs on precisely that.

Interviewers are probably using this dreaded phrase, "talk through your thinking." In a high stress situation like live-coding, talking about what you are doing is pretty difficult (at least, I find it to be). If you are being asked to do this in English and you are nervous that is normal. But the problem is if you can't do it, that your 'communication skills aren't good enough' to get the job. You don't get through to the next round. Maybe you don't even want to apply. You are spending too much time thinking about how to say, not what to say. And that is stopping you from showing your technical value.

It's unfair, like a lot of things in interviews. But employers can be picky.

Personally I prepare and rehearse interview answers even in English. I have also interviewed in French to an offer and that was much, much harder to prepare so I understand. One of the problems is that, while there are themes of what we are normally asked, it's not possible to know exactly what the question will be. This gap means that there is always something we don't know, which can create anxiety. But the trick is to be able to move the interview question to our story.

The easiest thing to do, is to prepare a few flexible answers. Those that can answer STAR answers based on a couple of themes: what went well, what went badly but you learnt from etc. The best way to prep this is to simply look at your CV, and create a story from each point you make about what you have achieved at the job. It's also worth looking at the job description and seeing how your experience connects with it. If you have that skill, perfect! You can use the language in the description and connect it to your story. If there is a gap, prepare a 'bridging phrase', something that says "while I don't X, I do Y" (If you aren't familiar with STAR, the below example shows how it works. It's about outlining a situation, task, action, and result and honestly, an LLM is a great starting point for writing them.)

Let's look at an example:

In the job description: "Experience mentoring juniors as direct reports" for a senior role. But maybe this is your first senior role. This kind of requirement is usually a 'nice to have' rather than a deal-breaker. If you don't have this how can we prepare a great answer?

Think about what you do have. You're very active in code reviews, for example. Perhaps you would write something like this:

• Situation: During a routine code review, I noticed a junior developer had written a database query inside a loop, something that would work fine in testing but would cause serious performance problems in production at scale.
• Task: I needed to flag the issue in a way that was clear and educational, not just a rejection of their work.
• Action: Instead of simply commenting "this will cause an N+1 problem," I left a comment explaining what would happen at scale, linked a short article on the N+1 problem, and suggested we pair for 20 minutes to look at it together. In that session I walked through how to move the query outside the loop and why the database cares about that.
• Result: They fixed it confidently and independently caught a similar issue themselves two weeks later.

Now this is something you can use with a bridging phrase:

• "While I don't have any formal reports at my current role, I am an active participant in code review."
• "I haven't held a senior title yet, but mentoring has been a natural part of how I work with the team."
• "Formal line management hasn't been part of my role, but I've taken ownership of bringing junior developers up to speed on our codebase."
• "I don't have direct reports, but I'm often the person juniors come to before they open a PR or ask a question in standup."

This means you can give a proper answer like this. "While I don't have formal direct reports yet, mentoring has been a natural part of how I work. Once I was reviewing a PR from a junior on the team and spotted a database query inside a loop. It would have passed testing fine but would have been a real problem in production. I didn't want to just reject the PR so I left a detailed comment explaining what would happen at scale, linked some reading on it, and suggested we pair for twenty minutes. We walked through the fix together and I explained the reasoning behind it rather than just showing them what to change. Two weeks later they caught a similar issue themselves in someone else's review. That's the outcome I care about, not just fixing the problem but making sure they understand it."

Now, even in English, I have my answers well-rehearsed because I've worked with a coach who would spring questions on me. These are your stories so they should feel like a part of you. If speaking English doesn't fully feel like your natural personality it can create a barrier. The best thing to do is simply practice and record these answers. Listen back to them (which I know a lot of people hate) and look for where you are hesitating or using filler.

Don't worry about a perfect accent, or 100% accuracy to the script. Look for where the idea in the answer isn't coming naturally. Reciting a script from memory is not good communication, so make sure to just learn the ideas. Being comfortable with the idea is what creates confidence.

The goal is to speak confidently about what you did, without getting stuck on how to say it. Even a couple of good, practised interview stories can make a big difference. And, if you're smart about what you pick, you can almost always use the same ones.

If you are interested in a more structured approach to feeling confident about English software interviews, I offer an English review to see if you're ready to interview and secure a role. We will talk about any difficulties, practice some real answers based on your CV, and create a plan to get you to your dream job. I've helped dozens of professionals improve their interview skills in more than just the tech industry, and I've also been in awful technical interviews myself, in English and a second language so I understand the pain. If that sounds useful, you can book here, or have a low-pressure 20 min chat if you're not sure what's right.

Let's Talk