how to interview like a Senior Dev (even if you are Junior)

Hi folks. So one of the question that we've seen our mentees struggle with the most when they are doing technical interviews. It's also one of the most obvious one, and that is what are you currently working on? And the problem with this question is that it's so open-ended, right? That many developers fail to answer well, so they fail to proceed to the technical interview. Now, if you are one of them, it's probably because a bunch of different reasons, but number one, it's a lack of preparation, which results in you coming across as overly generic in your answer. So, for example, if you say something like, yeah, I'm working on building features for a full stack application, that's not going to be enough to stand out and to impress your interviewer. And as I said, the key to that is to do a bit of prep work, right? And this is what is going to show you today in this video on how to do for you to have enough ammunition when that question comes in to have enough stuff to talk about. And remember, part of being a senior engineer, it's being able to go deep when you're being asked such questions and being able to go deep technically speaking. Bogdan, so if I were to ask you, right? This is an interview, I'm calling you up and I'm saying, hey Bogdan, so what are you working on right now? Can you tell me more about that? Sure, so the number one thing you want to have ready here, it's a one sentence answer that you can give to what we call a civilian, somebody that's not familiar with your company. They never worked. Imagine you are telling this to your somebody that's not even tech savvy. So if you were to ask me that question, I would have a one sentence written down and it would be something like, well, so right now I'm working um on a finance application where uh our users can basically make payments online and see the payments in their, yeah, you know, in their in their mobile app, for example, that we are building with uh React Native. And then we make a little poll, right? And usually, the interviewer will ask a bunch of follow-ups, but you really want to have a one sentence description of the product and what's the value for like the end user. So that would be um number one. Now, normally the interview will developing on this very same question. So they would ask you things like, okay, so what's your team size? And again, you want to make sure you write this down. So how does your team look like? That's what they usually ask for. Can you tell me what's your

all in a team. And here we want to say things like, well, we are a team of five developers, let's say, different pens, developers, one full stack and a back-end person. We work together with a dedicated product manager and a designer, and we are a cross-functional independent team. So basically we release our features independently, we organize ourselves into two week sprints where we have refining sessions on backlog.

Then we decide what tickets we will commit to in the next sprint, we assign effort points and story points, and we make a sprint commitment. As we deliver our tickets, we um deploy continuously. So we then deploy at the end of the sprint. Uh the bottom line here is you want to know how your teams are organized and it's a combination of the description of the team and a combination of agile practices.

Now, the most common thing people tell us in people we work with is that you might not be working in an agile environment. I was in that situation myself. You might not work for a very professional company, it might be chaotic. In that case, you want to write down the status quo and then inject a bit the best practice. So you always want to present your experience in a way that it does show that you know best practices.

Don't just tell them, well, I'm kind of just picking up tickets from the sprint. Okay, so before we move on to the next part, let me write this down. This will typically happen in a hiring manager interview or one of those question on interviews. So the first thing we want to always have ready, it's like the what, what are you working? And here, you want to write down, you know, kind of your the product and the users and so, you know, a bit about the sector and the company.

But it has to be clear in very short, easy to understand sentences, what what what are you building? Is it an e-commerce? Is it like a store? Is it a SAS product? What are they say? What does your company do? And again, the most important thing here is do not use your company's jargon, make it easy for someone from the outside to understand it. Yeah, that's the biggest mistake developers we work with, we're doing, right? That was keeping it very high level.

Uh not having any specific and keeping this this company jargon that you said, because companies have this our mission is to revolutionize finance. And then you see people coming in a software engineering interview as a software engineering and ask them, what are you working on? Well, I'm working on revolutionizing finance. And that's not true. That they don't want to know that. That's what what your company does, right? You want to talk about the specific, if you can be specific without like spending 30 minutes talking about it, but in a very in a bunch of seconds, if you can be specific and at the same time keep it high level,

that would as Bogdan mentioned, be the best way to go about it. Exactly. And the think the second thing is you are a software engineer. So don't go too much into the business. It's always has to come from your, you know, product development uh software engineering perspective. A lot of people online these days are telling you, oh, if you're an engineer, um you should make sure you know the business and so on.

But if you're talking too many business terms, they will think uh you're not a real like technical person. Now, a natural follow-up and in most cases the the follow-up on this would be, um can you tell me how does the team look like and your role? And here you want to have ready some number, like what's the team size? How many software engineers are in your team? Are they focused on the back end? Are they focused on the front end? And usually a lot about your agile process.

And so here, you don't want to be vague. You don't want to say, well, we're using agile methodologies. You really want to be specific and write this down way before you start interviewing, which is, hey, you know, are you doing two weeks sprints? Are you doing kanban? Are you deploying continuously? How do you estimate? What are the typical meetings? What is your routine? Do you have daily stand-ups? And what software do you use even?

So, and again, you want to summarize this in a sentence and say things like, well, so right now I'm working in team of five software developers or five engineers. We have a dedicated product manager, we have a dedicated designer and we organize ourselves in two weeks sprints. We release continuously and we usually, you know, have the typical agile rituals. Like we do backlog refinements, estimates, and then we commit to what goes in the next sprint.

And if you did this too well, the next thing will probably, okay, now how does your architecture looks like? system, because they want to get a feeling of, you know, have you worked on a system that's as because otherwise, what is the kind of system you've been working with? And the advice here it's try to prepare a bit your current architecture. Even if you're working, let's say only on the front end or only on the back end. Try to map out the architecture of your whole company. What were the systems you heard people talk about, how do they relate to each other? And then you can basically tell I mean, all things like, well, I'm working on a microservices architecture. We have different services that we are integrating with our front end. We're using micro front ends. Or not. We have a content management system. We have CDNs that we're working with, we're deploying to AWS. So pretty much have a short version of what your current system architecture looks like. And try to map this out way before again you start interviewing. Because if you go in without this prepared, you're just going to go all over the place, you won't be specific enough. There will be too many gaps and you'll come across as someone that has very little experience. And so you really want to draw this. I'll give you a very short example, so let's imagine in one of my previous experience I was working for a banking application, right? So I usually usually have a front end. But of course, we're building this in a scalable way, so people never go direct to the front end. They might have a CDN that's kind of delivering this. front and application in a scalable way. So you want to draw that too. And again, do a bit of a system design exercise, which are old companies. So when a lot a lot of people when they go into system design, they think, oh, I need to know all the, you know, super highly available AWS or Amazon use cases or how did Google or Netflix build what? Most of them that people know like what their current company does. And that's way more important. So we have our front end and usually there's a fleet, it's one or several back end services. So we're going to have a bunch of back end services here. You might have an API gateway. Again, everything you can take from your current architecture. Bob, and just to clarify, we are sketching out by ourselves, this is an exercise that they should do by themselves before the interview, right? Um basically sketching out your current architecture at a at a high level. For you to have enough material to go technically deep when you when they answer this question.

call me from not wrong. But this this question of what are you building on and can you tell us about the architecture? Will come up later in the interview process as well. Right? It's usually, hey, what are you working on right now, early in the interview process, but later on this question will come up again in system design interviews. And this is why this kind of preparation makes a lot of sense. Exactly. The only difference between the interviews is that the more technical you get, and the more you get to the end of the interview process, you need more depth. I need to go much, much in an engineering interview than in the first initial screening call or the hiring manager. But we're always talking about the same thing, you'll always describe the same system. The only thing that changes is the zoom in capability, the specificity. And how how specific you get about things and how in detail you go. So for someone that's doing this for the first time, imagine a software engineer they never did this. They have to open up a T.L. drawer. Right, that's what we advise you to do if you're watching this, after you watch the video, open up a T.L. drawer and try to draft out just like, try to sketch your current architecture. Right, and I see to, please correct me if I'm wrong, I see two challenges. Number one, the parts of the systems that you don't know, which, maybe you can tell us, how do we deal? If we don't know enough, maybe we have to read some documentation, go back to your old company, etc. And the second part is you might have technical gaps about stuff that you know it's there, but you don't know how it works. In that case, you might want to close those technical gaps and speaking which, there is a free tinkle assessment that we put together for you. It's in the comments on the senior dev website that you can use to understand what those gaps are and their knowledge will come very very useful in this kind of scenarios. But going back to the topic at hand, you know, how deep should we go? Should they go when they do this for the first time? How technically deep? And what can they do when they don't know something? How can they deal with that? Okay, so for number one, I would go as deep as you possibly can. Again, this is your kind of interview prep and you want to map out everything you know about your current system. And ideally, you know as much as possible. If you find things that you never touched or you don't know about, try to do as much reading as you can and map out the picture. But when you go in and talk about

that you can mention, hey, um. So I wasn't working myself specifically on that part of the system. But like what I can recall, I do recall some of my teammates working on an A and, you know, and we were using, I know, for the identity server, let's say you never worked with it, but you're using AWS Cognito or you're using Octa. And so you do need to look like you're aware of what other people are around you are doing.

But if it's something you're totally unfamiliar with, then commit, like then say, well, yeah, we use Octa. And then they will ask you, they'll go deeper into that and then you blank out and you look like, you know, you fail and look like a fraud. So, if it's something you had competence on, definitely talk about it, if it's something that it's needed in the system, but you feel like you don't have that much experience, just say, hey, um I wasn't directly working on this part of the system, but I do know some of my teammates were and they had a lot of troubles with whatever, let's say. If it's anything else, we should do so.

So, the fourth part, once you have the system mapped out, it's you want to talk about the software lifecycle. Basically, your deployment and we are in a senior only market, a lot of the companies will only hire people that have deployed software before. And so you really want to know, you had a pipeline, you're probably pushing code, what were the different steps? Where was the software running? Were you using AWS? We're using Google Cloud platform, and what were the different steps to get the software live? Were you running on lambdas or containers or, you know, on premise?

You really want to understand the whole cycle of your code, you know, going all the way to production software. And how you were monitoring and what alarm system you use to to monitor and fix production issue, there's a couple of videos that we have on the channel about CI CD, so make sure you check those out. But do map out your kind of the pipeline you had. And typically, just to put a very short example, there will be some building where you you build the application, then there's some code code quality checks like, you know, if you're doing JavaScript, it's linting.

And then there's usually some unit tests that you run, there's going to be some tests in your pipeline that are running. goes well and then you kind of finish the build. And that's when the deployment starts. Let's say, your company was using Docker, that would be deploying the Docker container, but whatever. There would be a deployment step and you want to go in and map those out. And understand where, you know, like be super specific. Like, okay, deployment. Where were we deploying? Were we deploying to a virtual server, or let's say we use containers? Was it ECS? So exactly what was going on? You really want to be as specific as you can. Uh because again, people will ask you like, hey, so what do you know about deployment? Where are you involved in the deployment? And even if you are a front end developer, if you're going or even a pure back end if you're going for a senior position, they expect you to know how you are deploying your own application. Well I some bug them two questions. Well actually, two two things. Number one, for the people watching us, if you are a front end developer, for example, a full stack developer and you're not involved in the deployment process. Okay? Because the there's a lot of sometimes there's a lot of red tape in companies, only certain teams get access. Other times it's not something I do, so why should I care about it? Like, that's the attitude. We do advise you to get your hands dirty and to understand how is actually software your software, the app you're building being shipped to production after you commit your your code. Right? Number one. And number two, you know, what if my company doesn't have a proper deployment uh pipeline, what if, you know, they're using an FTP server? How how would I deal with that? So, if you've never if you're never involved in this and or your company didn't have the proper process, then the best way that I recommend is create a free account on on GitLab or any of those platforms and try to do a very simple deploy. You're a react developer, deploy your react application to AWS and they to do a bit of research and see how could I deploy it and build a small kind of proof of concept around that because really, it's a bit of a chicken and egg problem. And if you never done it, companies will be very reluctant to even, you know, give you the position. But also even if you have the position, give you the ability to to take that responsibility. So, you need to do it yourself. And it's not as hard, it's it's it is a very intimidating part of the process, but it's not as hard as it looks like. Um, so go ahead,

and just take, you know, a simple app that you had and tight deployed the life cycle mapped out, right? You have a pipeline that every time you push code, it does all those things automatically. But if you've never done it, you need to start somewhere and it's better to start now. And finally, if you had all these mapped out, you already had of 90% of the people. But what will happen is that in a specific more kind of technical uh interviews like uh the question around or when you're interviewed by the engineers themselves, they will go more specific into API design.

And a lot of people when I say API, they think rest API. But when I say API, I mean what were the different interfaces in your system. So if you were consuming backend APIs, where they rest, where they graphQL, and how do they look more or less, right? So we need to know, okay, what were you using? This is a bit more of a detail component design, but what were you using rest, graphQL? And where are you using, you know, what kind of databases you're using and where you're using like kind of event streaming, all these kind of things.

Um, the more you know, the better. But as you see, this is more the granular detail. So it's at the very end. And just to recap, basically, whenever you get one of those interviews, the most important thing is that you know what were you exactly working on, right? What were the products, users? What was the company doing to to make money from a learning engineering perspective? Right. We don't want you're not a business person.

You're a software engineer. How did the team look like? So write these things down. What was the team size? Do you use Kanban? Did you use Agile? Um, did you do Sprints? How did you what were the different meetings you had with the team? You have you probably had the weekly standup, refinement, and so on. And then moving on to, okay, what was the architecture of your system and try to draw this to the highest level you possibly can.

And then what was the software life cycle to deploy that system you're working on? If you've never done this, try to build a small proof of concept yourself. And then finally, go into, okay, specific API design. and for those of you that are watching us, do make sure to adjust the depth kind of the stage of the interview you are at. So if you're being asked if this is something you're being asked by a recruiter, then don't talk about load balancer, basically. Just to make it clear. And the second part would be I think a good frame of mind to something to keep in mind as you as you answer these kind of questions, it's to do not put yourself in a position where you're being where where you're being easily attackable. What do I mean by that? If you go in the into the interview and you say, no, this is what we are doing and this is what it should be done and blah blah blah blah blah, then it's very easy for the interviewer to jump in and say, you know, what do you mean this is done like this? It should be done like this. And that's a lose lose, right? Because you, you know, you put yourself in a in a in a top position, a better way to to work around that, it's to just frame these things as, hey, look, this is what we were doing. This is what the kind of best practices are. This is what I know. You know, this is what we were doing, this is what I know. This is how I think it should be improved. Do not think that you you have to be some kind of authority, right? Because that will lead to a conflict with the interviewer, and you don't want that. You just want them to know, hey, I know the best practices. This is my current experience and this is how I would be doing and you want them to be part of that. Hey, with that being said, is there anything else we should keep in mind? When asking, when answering the question, you know, what are you working on right now as a software engineer? Like you mentioned, um there's you don't want to be attackable. You don't want to make too many big claims and that's why it's important to talk in terms of, well, so my understanding or you know, my last position, this is what we are doing and then invite them to add their feedback. Most interviewers, um they're not so experienced interviewing and they do want to have the last word. So they want to look like the smartest person in the room and you want to give them that privilege. And so that's why you always want to come in from the angle of, okay, this is my experience, this is our understanding, this is what we're doing. What are you folks working on? And that would allow you to have this back and forth without you being making big claims that are easily attackable, as you mentioned, and putting yourself in a position where you're like an easy target. Awesome. Okay, folks. Well, uh two questions for the people watching us. Number one, do your homework

Just watching content, watching Bugden and I solving interview questions or answering these things, it's not going to magically upskill you. So I invite you to do the homework, I invite you to go to Tiel, open it up and start answering the questions that Bugden was mentioning. You can rewatch this video if that's going to help you. And the second part is, if you want Bugden and I to keep making these kind of videos, just let us know in the comments.

We are reading all of them, we try to answer all of them, sometimes we can't because we have a lot of stuff in our hands. But we're going to pay attention and make another video if you want us to make another video going more in depth with this kind of answering this kind of questions. With that being said, Bugden has always, thank you so much and we will see you folks in the next one. By the way, if you're interviewing right now, check out this playlist where you can find a lot of interesting interview questions that are being answered by Bugden and I. Cheers.