And today I want to talk to you about a topic that comes up a lot.

How does one prepare for a technical interview?

Not super long ago, I was the person who asked that question to a lot of my friends who've done technical interviews before.

And honestly, there was a lot of new information to learn.

And I hope that the tips that I'm gonna give you will actually be useful.

And you will apply them and preparing for your technical interview first and foremost understand the underlying technical concepts that you're applying in solving the technical problems.

Yes, it is definitely true that a lot of problems that are being asked can be categorized in different buckets.

And in those buckets, they're pretty similar to each other.

So why am I saying understand the technical concepts?

Why shouldn't you just memorize a bunch of solutions to a bunch of those problems?

No.

You shouldn't memorize them.

You're gonna be hurting yourself.

And you're gonna be heard in the interviewer because in reality you're probably not gonna solve 1000 different problems.

And most likely, you're gonna get a problem that you haven't seen before and understanding the underlined technical concepts will actually help you problem solve.

And that's what you should be doing.

You should be problem solving in your technical interview.

So how should you study to understand the technical concept?

Ah, lot of you might be coming from a background where you studied software engineering or computer science or something similar, and you've taken algorithmic and data structure courses while you were in school.

I, for instance, didn't come from that background, so I had to self study a lot.

I have a great course recommendation that I've taken personally to understand algorithms and data structures.

The course is on course era.

It's gold algorithms, part one, and it's taught by professors at Princeton University.

It's a great course.

It will explain you why certain algorithm is implemented a certain way, why it works a certain way.

Why you should use and in which case is you should use a certain data structure.

It's fantastic.

I also referenced an introduction to algorithms book that was really great and understanding the same thing.

Once you brush up on your algorithm and data structure knowledge, you should move on to actually practice in problems.

An amazing book that everyone just lives by when they prepare for technical interviews is cracking the code and interview.

I'm sure you've heard about it from a lot of different people, and I'm not going to reinvent the wheel and give you a different book to study.

Cracking the code and interview is absolutely amazing.

It's really relevant.

It categorizes problems into difference technical buckets, and it gives you solutions in the back of the book.

Very important advice that I have for you, though, for when you actually practice solving problems is really, really try to force yourself to solve the problem yourself first and on Lee.

Then look at the solution.

I was so tempted to just read over with solutions.

You read the solution.

You're like, Oh, yeah, poorest.

I should apply the cell grid.

Um, I should use this data structure, and it all seems so easy and so intuitive.

But trust me, it really is different when you try to solve the problem yourself.

So please, please, please really try to solve the problem yourself first before jumping into reading the solution.

And then if you're so tempted to look at the solution of the problem.

Just pee.

Cut it.

Do not read the solution.

Maybe get a hint or two and then try to solve it yourself again.

Besides cracking the code and interview, there are a lot of other grade sources to find interview questions like Geek for gigs.

Sleep code.

Actually, Glass Door is an amazing source to prepare for company specific interviews because people leave the reviews of how their interview went and a lot of the times they spill out.

What questions they were asked.

So you can find a ton of questions from Facebook, Google, Amazon a bunch off.

Obviously, the bigger the company is, the more questions people would post about it.

But you can find really small company questions there as well.

So I found it a great source when I was studying for specific company interview.

An extremely important thing that a lot of people overlooked while they study for technical interviews is, Does your code actually work your technical interviews?

Not gonna be sued a code.

You're gonna pick a language that you actually code in.

You were most likely gonna be in a really editor in a re ally D you were an interview.

Ah, lot of the times will ask you to run your code in the end of the interview, and please make sure that your code actually works.

So while he studied and while you sold different interview questions every time you solved, write the code in your favorite language that you're most comfortable with.

Run the code right.

The code in your favorite language.

Make sure that you don't really have syntax errors.

Be so comfortable with your language that you don't spend time in the real interview Fixing those errors.

Let's view, really, it's not a good use of your interviewers time.

It's not a good use of your time.

It doesn't show.

Cast your technical knowledge.

And while you solve your problems in a re ally D to see whether your code works once the basic solution works, think about ACH cases.

Interviewers love asking you questions about cases.

There is a myriad off questions they can ask you.

So when I interview people, I, for instance, look for them coming up with EJ cases themselves.

Can they think about the cases when the code will break?

If you can do it yourself without your interviewer.

Prompt prompted you to do it.

That would be amazing, and those are definitely brownie points.

Ask your friend to mock interview you.

And if you don't necessarily have friends who have time or have the opportunity to mock interview you, then there's actually plenty of platforms these days that match you with a really interviewer and give you a set up off a riel interview.

One of those websites is in tribune dot io, and it's a platform where you can register for free.

And the interviewers are people who work a software engineers at real companies, and they judge you based on the real interview criteria.

So it's an absolutely amazing experience and amazing practice experience, too.

Fuel out the setup of a really interview and to see how you do because they give you feedback in the end.

And I do truly wish this platform was available at the time when I was studying for technical interviews.

It's actually so useful because talking through your solution and let an interviewer no at all points of times, what you're thinking and why you are sold in the problem a certain way, accomplishes a few things.

First of all, the interviewer knows where your mind is going with respect to solving a certain problem.

And that is very important in team collaboration because you need to be a good communicator to solve riel world real life problems at your real job.

And second of all, you've the interviewer knows what you're thinking because you're communicated it to them.

They can actually help you to They can give you a hint.

They can sway you into the right thinking direction.

So yeah, super important practice with someone.

Make sure that in your solution you use good variable names.

Use wealth after it code.

If the code is pretty complex and has multiple components to it separated into a different function might some really trivial and really basic?

But interviews do look for those things as well.

Can you make your code readable?

Can you write clean code?

Everyone totally understands that you were under pressure and you're under a time limit and all of those factors definitely come into play.

But just be mindful of it.

And my last advice might sound really trivial.

But don't be an asshole.

You might be an absolutely incredible software engineer.

You can kill all your technical interviews.

You can come up with an incredible optimization.

But if you are not nice to your interviewers route in polite to come with a lot of attitude, no one likes that.

Trust me.

I've seen so many people who came with a lot of attitude were rude, and they were They might have been amazing, technically, but in the end of the day, we're all humans.

We're gonna work together.

You're not going to sit in a corner and write code on your own.

We're gonna work within a team.

You're gonna work within different functions.

And if you are an asshole, no one's gonna want to work with you, no matter how sharp you are.

Trust me.

So make sure to bring your best nice smiley positive self to the interview, and I'm sure you'll do.

Great.

And that's a wrap.

I know you guys are gonna kill it.

If you have an interview coming up.

I hope you're gonna use some of the tips or all the tips that I gave you.

If you like what you just saw, please like and subscribe to the channel.

If you have any questions about In Tribune, please leave the wind.

The Commons, down below Hope you enjoyed.

Have a great week.