Thank you very much for being here. I'm really glad to be part, at Women Tech this year. And, today, we're gonna talk about technical interviews.So we're gonna look at three things. So what they actually evaluate, what strong and weak signals looks like in practice, and how to prepare without burning out. And the goal in the end of this meeting is that interview should feel less like a black box. So this is more like something that you can train for, like any other engineering skill. Yeah. Quick introduction about myself. So I'm software engineer and also technical leader. I've been on both sides of this. So I interviewed in multiple companies at different levels. Some of interviews went well, some didn't. And the ones that didn't go well, they actually taught me even more.

And on the interviewer side, I also conducted interviews at different levels, and I also watched a lot of candidates approach similar problems in very different ways. Outside of that, I also mentor other engineers. I also judge hackathons. And most of prep tells you what to do. And I want to focus today on what is being measured because once you understand this, it should the rest of things should get easier. Yeah. Also quick disclaimer. So everything that I'm sharing today is based on my personal experience. It reflects my own use, so it doesn't represent any official organization. Okay. So let us start with what technical interview is actually designed to measure. So across companies and formats, there are core signals. They are pretty stable. So there are four of them. The first one is how you reason. So not whether you reach the answer, but how you get there.

Second one is how you communicate while you are reasoning. So interviewers can only evaluate what they can observe, and thinking that stays in your head doesn't really count. The third one is how you make trade offs. So real engineering is choices under constraints. And in the interviews, interviewers trying to recreate that. And the fourth one is how you handle pressure and ambiguity because this is also part of the job. So now let us talk about the hidden job of the interview. So in my opinion, interview is not test whether you are smart or not, but it was a structured way to reduce uncertainty and how you would perform a job. So interviewer has one question at the end. Can this person operate at the level we are hiring for?

And there is usually an hour to find enough evidence to answer it. The work doing the work here is signal, and signal is whatever is observable. So what you say, what you write, how you respond, and when something doesn't go your way. And anything that happens silently in your head, and it doesn't matter how good it is, it doesn't show up. So because there is nothing for interviewer to evaluate. So one of the takeaway from this talk is that silent thinking creates uncertainty, and uncertainty gets in the way of offers even for capable engineers. And we will also come back to this in more details. So how do interviewers actually pull out those signals? So there are different formats each turn to different angle. So interviews focus on problem solving, structured reasoning, and writing correct code under time pressure. System design interviews focus on engineering judgment. So architecture, trade offs, reasoning at scale.

Then there is behavioral interviews, which focus on working with people, ownership, collaboration, and learning from experience. There is also object oriented design interviews. They are more rare, but still they exist, and they focus on modeling domains in code, defining responsibility, relationships, and how designs evolve. And, also, one more additional interviews is called project deep dive. So this is focused on real system you build and decision behind them. And today, I'm gonna mostly cover coding, system design, and behavioral because usually they are the backbone almost everywhere. And we also come back to project deep dives a little bit toward the end. So because they are getting more common at senior levels, and most preparation advice ignores them. Alright. Let us now focus how how this focus shifts by level.

Because there are same interview types, but different weights. So for entry level engineers, usually, coding is main signal. System design, it plays small role at most, so it's is limited or nonexistent at all. Behavioral is supporting. They just checking that you can communicate clearly, but not that you can wait. Then at mid level, system design starts mattering. Behavioral gets more substantial because right now you expect it to have stories, not just potential. At senior and above, coding still tested. And in some companies, it's more rigorously than junior level just with different trends. But still, I would say, in average, it's more like baseline expectation. And the question moves, can you produce working code to do you make sound technical decisions while writing it? And system design becomes primary.

Behavioral also becomes more critical because this level, the cost of a bad call scales with the team. And the hiring risk shifts as scope grows, and the interview focus also follow this risk. Now let us talk a little bit what level actually means. So that level matrix translates into something more concrete. So so which actual question interviewers and hiring manager asking themselves at each level? So for junior, it's usually, can this person execute on a well defined task with guidance? So and this is why usually coding is dominating. Mid level asks, can this person make reasonable decision on an ambiguous task without constant supervision? So now trade off reasoning and start mattering. At senior level, the question is, can this person scope and break down the problems for others? And this is why system design becomes primary.

And designing system is fundamentally scoping exercise. When it comes to staff level and higher, the question is more like, can this person set technical direction and influence outcomes across teams? And this is why behavioral judgment often outweighed all technical debts here. So one of the practical takeaways is figured out which of this question is most likely being asked of you given the role and the level you're applying for. And this will tell you where to put your preparation time and what kind of signal to focus on. Okay. So now let us talk about every interview type. So let us get started from coding. And the most misunderstood part here is that coding interviews are not checklist.

So they are not waiting for you to type the optimal solution. But what they are looking at is whether you understand the problem before you start, whether you reason in a structured way, and whether you make sensible decisions when there are trade offs. Quoting quality, correctness also matter, but usually it's under constraints. So there is limited time, a missing context, some ambiguity in the prompt, and this is also tests. So and, also, communication run to all of it. So like I mentioned, junior mid level, coding based execution and fundamentals get measured more directly. Let us take a look at some coding question examples. So on the slides, you can see two kind of problems. So the first one is so the first one is to some problem, and the second one is long and some string without repeating characters.

So both of these problems sound simple. And one of the trap is treating them as a recall. For example, I already know this one. Here is the answer. So this is usually not being tested. And what is tested is how you approach problem when you see this for the first time even for familiar question. So the good way here is to clarify, restate, evoke the brute force, and then optimize. So signal lives in the process, but not in the destination. And sometimes, it can be also some an ambiguous prompt and given to you. It might be no no constraints, no input output data. So all of that is expected that candidate will figure it out. And if you want to learn more about this, you can also find more examples of on LeadCode or HackerRank on websites like that.

So now let's talk what strong signal look like in coding. So strong signal is observable. So, typically, candidates clarify and restate the problem. So they think out loud. So for sure, they don't comment every keystroke, but they explain decisions. So they walk through trade offs. They write link link code. They typically verify these examples, so they come up with own test cases. And, also, when interviewers drop a hint, strong candidates pick up and adjust. And this kind of responsiveness is a big signal on its own. When it comes to weak signal, it's it's not usually about being wrong, but it's more about being silent. So jumping into code without clarification, solving slightly different problem because you misread the prompt, then also put forcing without acknowledging it, and not testing your code, ignoring hints because you already have plan how to solve it.

So notice that most weak signal is invisible thinking, and strong signal is visible thinking. So the same brain, but different interview. So let us take a look at the small example to make it a little bit more concrete. So let's assume there are two candidates. There is the same coding problem, the same final solution, but a very different amount of signal generated. So candidate a spends the first two minutes restating the problem, ask it about input size, about edge cases, about use cases, and all of that. And then they propose a brute force solution first. They explain by it, for example, often square, and then they walk through the optimal solution explaining the trade offs. And then they run different test cases out loud and including edge cases like null, empty, and put, and so on and so forth.

Candidate b reads the problem, think for thirty seconds in silence, and then generate the optimal solution directly, which is correct, and they say it's done. So in fact, in the end, they have same answer, so roughly the same time, But the interviewer is left with very different amount of evidence how each candidate thinks. And what actually happens with each of two candidates, of course, it depends on interviewer, on the level, hiring manager, and actually who's required for the role. And for sure, it's not like one of them automatically pass and another one not pass. But on average, what I noticed, the less observable reasoning gives interior less work less to work with. And at the higher levels, that gap widens fast because in the highest seniority, the the more they judge how you think, not just what you produce.

So same code, same complexity, but different signal here. And the gap is between being capable and being legibly capable. And interviews must mostly measuring the second one. Okay. So let us move on to another interview. This is called system design. So here, again, interviewers not looking for the right architecture, but they looking at how you reason about systems. Again, they watch how you turn ambiguous prompt into clear requirements. They typically expect high level designs first, components, responsibilities, how think connected, and only then how you go deeper. And big chunk of signal is data. So how this is stored, how you read, how you write, so how it flows through the system. As the most senior part of the signals also comes from trade offs and bottlenecks.

So strong candidates can tell you exactly where their design breaks first as a lot grows and what they would do about this. At the higher level, this open up in scalability, reliability, performance, operational concerns, but always grounded in the constraints of the problem. And, again, bound of it is communication. So if you cannot explain this clearly, it would be very hard for interviewer to evaluate. Let us take a look at the example of questions. So it might be designing some generic ecommerce marketplace like Amazon. It might be chat application like WhatsApp, might be YouTube, Uber, etcetera. And, also, what I noticed, quite common, especially if they're always more senior, You might be asked to design piece of existing system, not the whole thing. For example, it might be search index or rate limiter or maybe some notification layer.

But the thing is that part of the system already given to you, and you just need to design some additional components. And this narrow scope questions can be a little bit more demanding because there is less room to fall back on generic boxes, and every component has to earn its place. Alright. So moving to strong versus weak signals. So again, strong system design signal starts with clarity. So candidates clarify requirements, they restate them, and only then start drawing. So, typically, these candidates that produce strong signal, they start high level, structure it well, and then go deeper where it actually wins. Most senior candidates, they allow two or three reasonable options. They walk through trade offs, and they pick one for given constraints, and they don't pretend that their choice is the only choice. So they give components clear responsibilities.

They proactively look for bottlenecks, and the more failure points candidate can surface and reason about, the more senior they are being read. Big signal, again, this is not about being wrong. So it's more like a missing scope or missed requirements. So working into one option without considering alternatives. Also, adding components, for example, Kafka, Radius, queues, without being able to explain what problem they actually solve. Also, bottleneck analysis, shallow trade offs. For example, we use this database because this is better, without saying better at what and worse at what. And goal, again, not perfect system, but rather clear reasoning, sound judgment, inability to defend decisions when you've been challenged by why you choose that specific solution. Okay. When it comes to behavioral interviews, I would also say this is one of the most underestimated interview type.

So people often prepare for it is wrong, or they might not prepare to this at all. So let's talk what is being measured. So, typically, this is how you work with other So ownership, how you take responsibility, especially when things go wrong or break, then collaboration, how you handle disagreements and shared decisions, then decision making under pressure. So how, you act when things are ambiguous or going badly. Also, learning and adaptation. So engineering change, changes constantly, and they want to see how you change with that. And communication, influence, it might be not formal leadership, but the ability to move work forward to other people. And one thing to flag as you move up the ladder, the behavioral signal carries more weight. So sing senior and above, they involve more ambiguity, more cross functional work. So more decisions where there is there isn't clearly a right answer. And how you communicate, how you make this code become bigger part of the evaluation.

So some examples of those questions. So it might be a question how you disagreed with a coworker tell me about time when you failed or tell me about time when you had to make heart rate off or how you influence someone without authority. And the pattern in all of this, so they're asking for evidence, not opinions, but rather specific situations which you had with specific decisions. If you answer in abstract, that most of signal is already gone. So let's talk about strong and weak signal for behavioral one. So I think it's clear ownership. These are very specific examples. This is structural storytelling, and this is real reflection on outcomes. So strong candidates can describe disagreement calmly. I would call it reason disagreement because they explain the other side fairly, explain own position, and they focus on outcome for the team, for the product, but not on who was right or not.

And weak signal is rarely about lack of experience. It's because almost everyone has stories. But the thing is that it can affect this weak signal is weak stories. Also hiding behind the entire time, so it's unclear what exactly you did. Also, blaming, defection, victim framing, conflict described without any reasoning or learning. And all of this, one killer. So one one of the keywords is that answers also could sound memorized. So, typically, yeah, this is quite easy to spot for hiring manager, and this is also can affect it. And, again, this is not about telling the most impressive story, but it's about telling the real one well. And, typically, what can help here, so the simplest tool, this is called STAR. Maybe most of you already heard of it.

So let let me talk about the version what actually work in this STAR format. So first of all, talk about the situation. So, typically, one or two sentences of context don't get lost in this tab. So interviewer typically doesn't want to know about org charts. Then you talk about the task. So what specifically you did, what specifically you were responsible for. So pronounce here matters. So in if every sentence is we, then your personal contribution disappears. So be very deliberate about I versus we. Then talk about action. So what specifically you did? So decisions you made, not not things that happened around, and this should be longest part of the story. Then result is outcome. It's great that you if you have numbers. Quality of impact is also fine if you don't, but be specific. And, also, in the end, it's nice to have reflection.

Typically, most of templates keep this, but it's nice to share what you learn from the story. What would you do differently? And this is also the line between mid level and more senior signal. So mid levels tell what happened, but the seniors typically tell what you took away from it. Practically, try to prepare eight to 10 stories using the structure. Don't memorize them, but rather memorize structure and key bits, and then try to deliver them fresh each time. Okay. So, also, one of the interviews that I wanted to mention, this is called project deep dive. We will go really quickly through that. So, usually, most of preparation guides keep this, and they are showing up more often in senior groups. Perma is typically simple. So you ask to prepare one project or enter your pick up one project from your resume or background, and then they start digging into this.

And it might be for the whole hour. So they will ask you things. Why did you work on this project? So what is ROI? Then it might be more technical questions. So why did you pick that database? What broke first? What you pushed back? So what would you do differently today? And all of those questions probably depends on company, but all those would be around one specific project. And, typically, with Litcot won't help here much because I would say the real preparation here is having actually built something and also sitting with this long enough to understand decisions you made and what would you do differently. So more like reflection. And the signal is engineering judgment on the depths. So strong candidates, again, they explain why they choose a over b, which assumption to now turn, what they changed today. And big candidates, they just list features, name tools.

So they struggle also when interviewer ask why you did this. So there is a focus on what. So I would say if you're targeting senior or above role, some companies really can ask these questions. And if you never been asked this, it might be a gap that was closing. Okay. Now let us talk about why strong candidates fail. So most failures not about skill, but they are rather about signal. So, usually, there are similar patterns that I saw. And the first one is insufficient signal. So capable candidate, but not enough observable evidence in the hour. So their thinking is invisible. They avoid thinking out loud, and they don't really explain why behind behind their decisions. Second one is poor problem alignment.

So they start solving before they understood what is being asked. So in fact, they deliver brilliant solution, but to the wrong problem. So it can be avoid by by restating the problem in your own words and also confirming before you write a single line. The third one is weak decision narrative. So they make choices, but don't explain why those choices make sense or what they're given up. So decision just appear from nowhere, and you can avoid this by communicating it clearly. So I'm choosing x because y, and I know that trade off is set. So make every decision audible. And the fourth one, low quality interaction. So that means silent reasoning, ignoring hints, also treating interviewer performance. So you can avoid this by treating the interviewer as a teammate. You can pause. You can check-in.

You can ask for feedback or ask, does it make sense or not? So just treat interviewer as a teammate because this is also might be very important. And back to the earlier point, so interviewer is designed to reduce uncertainty in many rigorous interview processes. When signal states unclear, the bar leans no, not always, but pretty often. And generating clear signal is one of the highest leverage things you can do as a candidate. So when you get stuck so sometimes like, not sometimes, I would say even pretty often. So I also had the situation quite some time. You can just stuck in the interview. And for sure, it's hard to avoid it because you might not know what to do. But what can help here? So you can do the post out loud. You can say, let me think for a moment, and this say this sentence also buys you time without creating silence.

Because silent thinking looks like nothing, but pausing out loud looks like reasoning. Second one, you can restate what you already know. So you can say we have x, so I'm trying to get to y. I'm missing that. And you basically trying to reorganize what you have already on the table. Third one, you can ask also for input. You can say, I'm considering a and b. Does easy makes more sense what we are solving, and good interviewer typically help. And don't treat this as a weakness signal. This is more collaboration and an interaction signal. Fourth one is you can try on a smaller version. It might be the case that the full problem given to you is hard enough, and you can solve simple case first. And often, once you do this, it will unlock you to the general one.

And even if not, you can also show to the interviewer that you can decompose a task. So, again, getting stuck is normal, but going silent and panicking, this is something that best to avoid. Okay. So now let us talk quickly about preparation. So one of the biggest mistake that I see, and I also did this mistake before. So I see that people green in 300 random with code problems. They're trying to do this in one month, and they just burn out. So this is not preparation. This is more like anxiety wearing productivity costume. And five things that actually work a little bit better in my opinion. So the first one, do self assessment. So before you touch single problem, identify your weakest interior type for your target level. So are you targeting senior and your last system design was from college?

So this is where you should spend more time, but don't don't solve another 50 array problems. Then realistic horizon. So solid preparation, I would say it's eight to twelve week. It depends on your level from the first from self assessment. But I wouldn't say it's, like, a week or two weeks of of panic. If you have only few weeks, you can just accept the constraint and prioritize, ruthlessly. Then focus on patterns but not problems. For example, for coding interviews, there are roughly 15 to 20 core patterns depending on whose list you read. So it might be sliding window, two pointers, might be BFS, DFS, sometimes even dynamic programming. And mastering them deeply, it outperforms 300 problems shallowly. And the first one, this is really awesome thing.

So weekly mock interviews, and I would recommend even starting this not in the end of this preparation, but as early as possible. And because mock interviews, they reveal communication gaps that solo practice never will because gap is absent of another human in the room. And when there is someone else in the room sitting and looking how you solve the problem, it becomes more stressful than just sitting alone and just trying to solve some problem and then get okay from LeadCode or from any other website. And, also, reflection after every session is pretty important. So let us talk about this one. So the single highest leverage habit in the interview prep, no almost no one does it, is reflection. So after every practice problem and every mock, try to spend three minutes three line. So what did I miss? What I would do differently?

And what pattern was this instance of? So this is the hope. Three lines not the same. And for weeks in, you will have personal map of your weaknesses, and your practice can target them. So eight weeks in, you start catching yourself making the same mistake mid interview and self correcting in real time. So I would say this is how you can prepare without burning out, not by doing less, but extracting more from each session. Okay. So what if you got no after interview? So this is absolutely normal situation. So failing interview hurts. There there is no refrain that make it no hard. But if you stay in this long enough, it will happen for sure. So how you respond to this matters more than result itself.

So first, treat the z data, not a verdict. So one interview gives you information about the process, not a judgment on you as an engineer. And most engineers, they failed interviews before they pass the one day the one day matters. Second, one process doesn't predict the next. So different bars, different teams, different problems, different interviewers No in one place. It's not know everywhere. The third one, refine and then retry again. So pull out reflection log. We talk about what actually needs work. Pick one or two things, practice them deliberately, and then go again. And reflection is a stop on the way, but not the end of the road. Okay. So let us talk about the key takeaways. So the first one, interviews, they measure signals. They don't measure memorization. So they want to see how you think, not what you remember. Second one, reasoning come first.

So this is clear reasoning always beats a log on code with no explanation every time. Third one, interaction really matters. So not solo performance, but rather forty five minutes or one hour of collaboration. Fourth one, be aware about level expectation. So what's strong signal junior level? This is baseline for senior level. And calibrate to where you are applying. Five is sustainable preparation with intense. So eight to twelve weeks of focused practice with reflection. It always beats three weeks or months of grading all the time. So if you if those five frame, your prep, they should show up as a US legibly capable. And, yeah, I would say this is the most important thing that I wanted to cover today.