Having worked at a few big tech companies and having interviewed candidates for them as well, here are some things I wish more candidates knew going in.
How decisions are actually made
Each interviewer is assigned a round and for every round, there are specific signals they need to collect. For example, in a coding round, they are looking for things like clean code practices, sufficient test coverage and edge case handling, awareness of algorithmic complexity, and how you communicate your thought process. In a system design round, they care about trade-off analysis, scalability thinking, and whether you can identify bottlenecks before being prompted.
The interviewers don't know how you performed in your other rounds. This is intentional. Each round is evaluated independently so that a rough start doesn't bias the rest of your loop.
After the interview, they submit feedback as Strong Hire, Hire, No Hire, or Strong No Hire.
Once all rounds are over, there is a panel discussion where all the interviewers meet to discuss. This is where it gets interesting. Even if one interviewer marks you as No Hire, the panel checks whether the skill that was flagged was demonstrated in a different round. For example, if you got a No Hire in the coding round because your edge case handling was weak, but the system design interviewer noted that you proactively identified edge cases in your design, the panel takes that into account.
Solving the question correctly is not the whole picture. I have seen candidates who solved the problem but got a No Hire because they couldn't explain their approach, or they wrote code that worked but was completely unreadable, or they didn't consider any edge cases until prompted. Conversely, I have seen candidates who didn't fully finish the problem but got a Hire because they demonstrated strong problem-solving instincts, communicated clearly, and showed they knew where they were heading.
The interviewers are collecting signals throughout the entire interview. If they have received all the required signals, congrats, you are in.
The rounds are standardised
Most companies run the same set of rounds regardless of team: DSA, system design, and project deep dives. These common rounds exist to ensure every candidate clears a baseline bar of expertise. It doesn't matter if you are joining the payments team or the infrastructure team, the bar is the same.
Some companies hold additional specialised rounds like API integration or bug squash, which are more representative of actual day-to-day work. These rounds tend to give a better signal of how the candidate will actually perform on the job, but they are harder to standardise and harder to evaluate without bias. That's why they are less common.
Based on the role they are hiring for, there may also be team-specific rounds to understand which team the candidate is more suitable for. These usually happen after the common rounds and are more conversational.
Startup vs MNC interviews are fundamentally different
This is something a lot of candidates don't appreciate, and it costs them.
Startup interviewers go in with open ended questions. The direction of the interview can be controlled by you based on your answers. If you bring up an interesting tangent about a past project, the interviewer might follow that thread for 15 minutes because they found it relevant. The interview is more of a conversation.
MNC interviewers don't have that freedom. They have a specific set of questions, a specific set of signals to look for, and a structured rubric to fill out. They cannot deviate from the plan even if they want to. This is by design because structure removes bias and ensures consistency across thousands of interviews.
Why is this important to know? I have seen candidates who go into tangential answers during MNC interviews, spending 10 minutes on something that doesn't map to any signal the interviewer is collecting. The interviewer can't redirect you because they are not supposed to lead you. You just lost 10 minutes of a 45-minute interview, and those minutes are not coming back.
Keep your answers to the point. If the interviewer asks about time complexity, give them the time complexity. Don't launch into a story about how you optimised a similar problem at your last job unless they ask. The interview is time-boxed and every minute counts.
The poker face is by design
This one throws off a lot of candidates.
MNC interviewers go through extensive bias training. They are trained to not react positively or negatively to your answers because their reactions can influence your performance. A smile after a correct answer makes you confident. A frown after a wrong one makes you spiral. Both are forms of bias.
What this means in practice is that the interviewer will maintain a completely neutral expression for the entire interview. They won't nod approvingly when you are on the right track. They won't give you a concerned look when you are going down the wrong path. They will just sit there, take notes, and ask their next question.
This makes it extremely hard to gauge how you are doing, and that is the point. The interview is designed to evaluate you in a controlled environment, not to give you real-time feedback.
Don't get disheartened by it. The lack of reaction doesn't mean you are doing poorly. It means the interviewer is doing their job correctly. I have given interviews where I maintained a complete poker face for 45 minutes and then submitted a Strong Hire. The candidate had no idea.
Pick the right language
This sounds obvious but I see candidates get this wrong all the time.
Pick the language you use daily. I have seen candidates choose Rust or C++ because they think it "looks impressive" and then struggle with basic string operations during the interview. They spend 5 minutes trying to split a string or figure out how hashmaps work in that language. C++ doesn't even have a split function.
Even if internet access is allowed during the interview, spending 2-3 minutes looking up a basic stdlib helper is not a good signal. It tells the interviewer that you are not comfortable with your tools, which raises questions about your day-to-day coding fluency.
Python, Go, Java, JavaScript, pick whichever one you write code in every day. The interviewer does not care which language you use. They care about whether you can solve the problem correctly and communicate your thought process clearly within the time limit.
It doesn't matter how elegant your code looks if you can't finish the solution in time. Speed and correctness beat aesthetics every single time.
Don't underestimate the behavioural round
A lot of engineers treat the behavioural round as a formality. It is not. This round often has veto power, especially at senior levels. The interviewer is trying to understand how you handle conflict, how you deal with ambiguity, how you influence without authority, and whether you have self-awareness about your own mistakes.
Prepare concrete examples from your past work. The STAR format (Situation, Task, Action, Result) works well here, not because it is clever, but because it forces you to be specific instead of giving vague answers like "I am a team player."
The worst thing you can do in a behavioural round is say you have never had a conflict with a colleague or that you have never failed at anything. Nobody believes that, and it signals a lack of self-awareness.
After the interview
Once you are done, let it go. You cannot change the outcome by replaying the interview in your head. The panel will meet, the decision will be made, and you will hear back.
If you get rejected, ask for feedback if the company offers it. Not all do, but when they do, the feedback is usually specific enough to be actionable. I have seen candidates come back after 6 months, address the exact gaps that were flagged, and clear the interview on their second attempt.
The process is not perfect. No interview process is. But understanding how it works from the inside gives you a real advantage over candidates who walk in blind.