And today we're gonna be talking about what nobody tells you about the software engineering interviews, and this is coming from me, someone who has conducted over 100 interviews over Google.

So I see a lot of misinformation out there and people making so many mistakes.

Some people think that all you need is leaked coat and you just do a bunch of lead code questions and I'll get you going.

Well, that's not quite true.

I have a colleague, actually, who did like 400 leads Koth questions.

He was very good at these white boarding questions, but his communication skills were total garbage.

And I knew from the outset he would not land any job offers.

Given his current attitude, which was very arrogant, his communication style And, you know, sure enough, he went out interviewed, didn't land a single offer out there, even though I'm sure he aced all of those lied to both questions.

So this is the first thing to know.

A lot of junior engineers think that that whiteboard encoding practice is all that they need to ace the interviews just do 400 leads code questions, and you're good if you know breath for search that for surgery, incursion, your data structures, hash tables, stacks in queues.

Then I'll get you go.

And that's just not how it works.

Because usually within the 1st 1 to 2 minutes of media candidate, I already know whether I would be giving the candidate recommendation to move forward or a rejection.

Because the fact is, the interview process is very human.

It is not objective, and you can either have me on your side or against you.

I could be giving you all sorts of hints give you the benefit of without giving you the easier questions and just rooting for you through the whole process.

Or I could be against you trying to make you feel give you very difficult questions, not giving you a single hint, making the question intentionally as ambiguous as possible.

So, in fact, here's how it works.

You know how they say within the 1st 5 10 seconds of meeting someone you are, Do you know whether you'd like somebody or not?

Well, that does not change for interviews as well, so you need to make yourself presentable and already have an idea in my head after I talk to you for, say, 10 15 minutes, I hear about your backstory.

I already know with, say, 90% certainty, whether I'm going to move you forward or not.

And while I have not even ask you your Little League coach coding question, the decision's already pretty much been made.

Now, at this point, I just want to get rid of you.

I have, like, 30 more minutes to burn, So what I really do is I just try and preoccupy you with a code in question.

I just throw something your way.

And the real purpose of this is so that I could just go and check my phone and read, ready or check my email because I'm pretty much done talking with you, and I just don't know how to burn the rest of the time.

Meanwhile, the candidate things that at this point the interview has actually begun.

This is when the real work starts.

They aced the coding question, and still they get completely rejected because of entirely other reasons.

Life stuff, isn't it?

But you need to know that when people are evaluating you.

They're evaluating your ability to become a senior engineer.

What does it take to become a senior engineer?

Well, coding ability alone gets you to say l four, which is not senior.

That's like standard software engineer.

In order to become a senior engineer, or at least to show that potential, you need to show leadership qualities, ability to tackle complexity, ambiguity, teamwork, skills, collaborations goes communication skills, friendliness, charm, enthusiasm, passion for learning.

And in fact, passion for learning is a big one, actually, because when you think about it, when I give you a coding question, I'm not interested in hearing you regurgitate a memory solution actually without wanna know is your process for reaching a solution?

Because oftentimes in actual software engineering there is no predefined solution.

You have to work towards that and that processing reaching that solution often requires a lot of analysis balancing tradeoffs, discussing alternatives, teamwork, collaboration, accepting feedback, and I want to see that process occur as you're coming up with the solution.

So if I give you a question, I wanna know how you reach the answer.

Not if you can reach the answer.

If you reach the answer you just answer a single question?

Yes or no?

Yes.

You've got the answer.

If you tell me how you reached it, the way you trade off time and space, how you present alternative solutions thoughtfully discussed the algorithm and come up with an actual solution.

That entire process is actually what is far more interesting.

And by the way, this is what we teach over in our program.

Tech Interview pro dot com where we will fast track you into a top tier tech company.

So we've got this whole interview training program with a private Facebook community group.

Students are helping each other out.

I do bi weekly life cure Naser.

Answer questions.

If you're interested, check it out.

A tech in every pro dot com.

Now, speaking of that, another tip it There was a posted in a group where somebody went to Amazon interview and then the interviewer was late for like, 20 minutes.

They finally show up, and then they do the interview with half the time I love it and the person fails because they just don't have enough time to finish the problem.

And this actually happens.

And then, you know, they're trying to work with the recruiter and the recruiters not really responding.

So I've seen mishaps like this where, through no fault of the candidate, their chances of passing are just dramatically reduced.

For example, there's no white bored markers, and then people spend like 10 minutes looking for good markers.

The wrong resume could be printed.

Or perhaps somebody just forgot to print it all together.

And then people are going through the interview just winging it without really knowing the candidates background or school or education.

And then they're wasting a bunch of time going over just these basic details.

Like Which school did you go to?

Where did you work previously?

So for me, if I go into an interview, I'll actually bring my own backpack, my own markers, my own eraser backup resumes that are the most up to date, such that everything goes as smoothly as possible.

And we waste as little time as we can on all the other random stuff that could get into the way, because at the end of the day, you are going to be the one being held accountable.

The interviewers, they don't care.

Nobody cares about your performance as much as you do now.

If you're an American, you may not be aware, but American schools are actually terrible.

And if you were to take a look at the international candidates coming out of, say, India, China, they're white board coding.

Performance is stellar like they're really good, and they could blow out so many other people.

So a lot of the international candidates, they're just willing to work harder and longer to attain that American dream.

They will do 1000 leagues code questions, for example.

And yet, as an interviewer, I come across these people, and many still do not pass for other reasons besides just coding ability.

Perhaps one of the top reasons is ambiguity.

So if all you know is test taking ability, and you could just answer a whole bunch of questions about Davis directors and algorithms, and yet you don't really know how to apply them, given a ambiguous question where I don't even give you the method signature, I don't tell you what the inputs and outputs are with the data format is going to look like, and I've heard this from colleagues.

Interviewers will sometimes intentionally give you a very vague and biggest question just to see how you can tackle that just to try to throw you off like that.

So the ability to tackle ambiguity is actually one of the performance.

Actually, that you are being graded on another one is time, efficiency and this nightmare that it is actually about practicality.

So I remember over our Facebook, there's this question about Quick, Select, and you can approach this problem in the number of ways to get through brute force.

You could create a heap, or you can even implement the partition in algorithm.

Now the problem is that this partition in our them it is the most optimal format.

But it is quite difficult to write.

It takes way too much time, and actually what will happen is if you try to solve it in this most up the whole manner, you may not be able to solve it within the time.

Given what interviewers really want is for you to use the less optimal approach and say, using a heap and then to just quickly mention like, Hey, yet there's also this other more optimal algorithm, quick, slick with partitioning.

But we're not going to do that that just seems a little bit way too complicated.

Listers do the simpler heap algorithm that can be written much quicker.

So it's this ability to recognize practicality and simplicity over, say, always coming up with the most optimal time efficient algorithm.

And it could be the simplest algorithm that you can actually write, given your deadline of about 30 minutes.

Now, most interviewers were actually know the answers to the questions that they're asking, but occasionally there will be interviews who they just add some random question each time.

And they like to work through the problem with the candidate So you can see that it becomes extremely annoying when the candidate begins asking questions like, Is this the right answer?

How about this?

How does this sound?

Is this good?

What do you think about this?

Do you think that's the most optimal?

I think that the most Optimus dynamic programming, but I'm not sure if I should do that yet.

Should I approach with this chap?

Proceed.

This is okay.

And the problem here is this is not how co workers work together.

It is more about being collaborative and having that teamwork ability not really asking for permission to move forward with something but to discuss the alternatives and solutions and reach a consensus together.

And by the way, sometimes the interviewer may not even want to collaborate with you.

They just want to see you approach the problem as if you were on your own.

That's kind of the approach I would do, especially if it seems like the kid is quite strong and seems like they can pretty much do on their own.

I rather just see what they could do and the fact Sometimes candidates surprised me with a completely new and interesting answer or different way of approaching problem.

And then they get bonus points for that because they actually surprised me and one up me in my own head and one more tip here.

Too many people, especially junior engineers.

They think they're being evaluated for their past experiences, whereas actually they're being evaluated for their future potential, especially to be able to learn and execute on the project.

So it's not really about coming up with a laundry list of all of your prior accomplishments in some other technology that simply cannot be applied to the current row.

So it's not about the What is more about the how, because whatever you accomplished was probably not very important anyway.

But I want to know how you were able to accomplish that.

Were you able to teach yourself new language?

Is bringing your passion exploring new technologies, work with other people, share your teamwork and collaboration skills and just bring that enthusiasm to learn technical, caress the and teamwork skills in order to accomplish a project?

If you can show that that I think you will be go then before even the whiteboard important starts, you will have me on your side.

I will be reading for you give you as many hints as I can to make sure that this whole whiteboard encoding question goes as smoothly as possible.

That said, you still need to be good that that menu junior candid this welfare at this portion, you still have to get that right, because if you felt at that, then even I can't help you so still, make sure that you're doing other preparation and granting on the league coach questions.

Just know that there's much more to it than that, so they'll do for me.

But let me know what?

Some of your uncommon interview tips.

Maybe if you like the video, give the like and subscribe.

And I'll see you next time.

Thanks.

Bye.