how to have Senior level SWAG (might offend some of you)

to be considered a senior developer, you need to walk the walk and talk the talk. Yet every day I talk to dozen very smart developers who have the knowledge and the skills to become senior developers. But they struggle to express that knowledge in technical discussions and technical interviews, because they don't have the proper vocabulary or technical terminology. Today, I'm going to show you how to express yourself like a senior developer.

My name is Bogdan, I'm a self-taught senior software engineer, and together with my brother Drarosh, I founded the senior dev. Where in the last three years, we had more than 300 developers level up their skills to senior level and beyond. So today we're going through 10 commonly used terms in software development and see how a junior and a senior developer would talk about the same thing. Pay attention because you might want to use these terms if you want to stand out in your next technical interview or technical discussion.

A junior developer would say do later, where a senior developer will use the word defer. For example, a junior developer would say would say, we should do this later, as in this action, and the senior would say we should defer the execution. Or a junior would say, let's show this element later, but the senior developer would say, we should defer the rendering of this component. So use defer whenever you want to say later.

It will show your expertise. A junior developer would use words like change, where a senior developer would use mutate. This one, it's one that Dan Abramov uses a lot if you're into the React ecosystem. But the junior would say something like, well, we need to change the state of this object whenever the user submits the form. Whereas a senior would say, we should mutate the state of this object upon form submission.

A junior would say, I had to change the array values to get the correct result, whereas a senior would say, I had to mutate the array. So, as you see, the senior jargon allows you to be more implicit, to say a lot more with less. Juniors who talk about unexpected things. Where a senior would mention side-effects. Again, this one you'll see a lot in the frontend nowadays. A junior would say things like, hey, this function is causing some unexpecting things when I call it and I don't know why.

The senior would say, this function has unintended side-effects. A junior would say, when I gun this, it affects other parts of the code that I didn't touched. That's how you know someone, regardless of the years of experience, they are still a junior. And the senior would say, executing this function results in side-effects that violate the principle of isolation. So an expert, it's someone that can not only understand what's going on, but express it in the technical dragon that's adequate.

Now, if you are interviewing or you want to check where you are in your journey to senior developer, make sure you take our free technical assessment. We build it with real interview questions and we keep updating it, and it will give you an insight of where you are and what are the next steps you need to close that gap or get better at interviewing. The link is in the comments. A junior would say increase, whereas a senior would talk about scale.

A junior would use things like, hey, we need to grow the number or increase the number of our servers to handle more traffic. This would be kind of a mid-level even, right? It's not so juniorish. A senior would talk about scale, we need to scale our infrastructure to accommodate the increasing traffic. A junior would talk about things like, hey, the algorithm or the code works now, but it will get slower as the data grows or as we add more data.

A senior would say, this algorithm doesn't scale well with larger datasets. Or a junior might talk about database saying, hey, this database is getting slower when we add more data. The senior would say, our database system is not prepared to scale and we are seeing degrading performance. That's another jargon data yard. So as you see, we're talking about the same thing, but when it comes to expertise, talk about a function that gives the same result.

Whereas a senior, we talk about deterministic behavior. So a junior would say a deterministic function gives the same result for the same list every time. Whereas a senior would say the sorting algorithm is deterministic. A junior would say things like, hey, we want our test to give the same result each time we run them. Whereas a senior would say, we need the test to be deterministic and produce consistent outcomes.

A junior would talk about things happening one after the other. But a senior would talk about round robin, which is a load balancing algorithm. But you would see people using this also in a team context, we'll see that in a second. A junior would say things like, hey, we make the server takes turns when we handle requests. Whereas a senior would say, we're using a round Robin load balancing strategy to distribute requests evenly.

A junior would say, everyone takes turns being on call in the team. Whereas a senior would say, we follow a round robin on call rotation. A junior would say, hey, we put some data here and there, um, so we're basically taking turns or where we store things. That's how juniors talk. They talk like a civilian. Whereas a senior would say that we use a round robin sharding strategy to evenly distribute data across multiple database nodes or instances.

Juniors would talk about smaller, big things, like should we log a lot or should we log less, or should we log the big transactions or the small transactions? Whereas seniors would talk about level of granularity. So junior would say, hey, we need to keep track of all the little details or big details, depending on what we need, the senior would say, we need to control the granularity of our logging to balance performance and information depth.

A junior would say, we can't control how much traffic it's in the API response, so we can add more or less. A senior would say, we need to adjust the response granularity to ensure the right amount is that of data is returned to the client. Juniors would talk about idmp or something you can do again. But seniors would talk about idm potency and Idempotent functions, operations, transactions or requests.

A junior would say things like, hey, you can press the button as many times as you want, and it's still do the same thing every time without breaking. So just keep clicking it. A senior would tell you that handle it's idempotency and that's it. Would assume you know what idempotency is. If you mess up the transaction, you can handle it again without breaking it, that's what a junior would say and senior would say that the transaction is idempotency.

And again, you can call you can call the API call again and it will do the same thing without messing anything up. That's kind of mid-level junior language. A senior would say that the API call is idempotency. We already know that idempotency means you can make the same operation without causing unintended side effects, if you don't know what idempotency is. Either watch some of our videos on rest APIs, we have a bunch of those on the channel or just Google it, but make sure you know it.

It's an interview question when it comes to back end interviews. Juniors would talk about passing arguments, so a pass argument, pass this as an argument, but seniors would mention dependency injection. A junior would say that we give the database code, the log in details every time we need to use it. A senior would say that we use dependency injection to supply the database connection object at runtime.

A junior would say that we pass email settings, whenever we want to send an email for example, and the senior would say that we inject the email service as a dependency in our notification system. A junior would say we pass data points as arguments to a chart, whereas a senior would say we inject the data service into the chart component as a runtime dependency. Juniors would talk about timing issues, seniors would talk about race conditions, and this is the last one.

The junior would say, oh, there's a timing issue when we are trying to update the same variable, so it's a bit unpredictable. A senior would say there's a race condition because we are mutating the same variable concurrently, another keyword. A junior would say, we have a timing issue where two clicks are made too quickly and it breaks the website. The senior would say that the race condition occurs when multiple user clicks are processed out of order, causing the UI to enter in an inconsistent state, another senior jargon.

This was pretty much it. But remember, knowing how to talk like a senior is not enough, you also need to have the skills to deliver. So make sure you also check out these two other videos that we put together showing you exactly that.