Up next in 10
"Pass CODING INTERVIEWS and Actually Get a Job" is an instructional video aimed at individuals preparing for coding interviews in their job search process. The video likely offers practical advice, tips, and strategies to help viewers succeed in coding interviews and secure job offers. It may cover various aspects of coding interviews, such as algorithmic problem-solving, data structures, technical communication, and behavioral questions. Additionally, the video might provide insights into common interview formats, coding platforms, and best practices for preparation, including practicing coding problems, studying company-specific information, and improving problem-solving skills. By offering actionable guidance and insights based on personal experience or industry expertise, the video aims to empower viewers to navigate coding interviews effectively and land job opportunities in the software development industry.
Show More Show Less View Video Transcript
0:00
The reason 98% of new software developers are not getting job offers is because they are not doing
0:05
these 11 things. You're new so there's a ton of things that you don't know and that's okay
0:10
it's perfectly normal. You're going to make mistakes and forget things during the job
0:14
interview. What is super important is that you demonstrate your confidence in your ability to
0:18
figure it out. Why should we be confident that you will succeed on our team if you aren't even
0:23
confident in yourself? We're probably going to ask you a bunch of questions to figure out two
0:26
things. First, we want to know what areas you're good at and bad at because we want to know if
0:31
your good areas are a match for the skills that we are looking for. Second, we want to know if
0:35
you're a good culture fit and how you respond to tough situations. Do you get incredibly frustrated
0:40
when you get stumped? Do you throw in the towel easily? Do you get confrontational? We really want
0:45
to weed out people who get upset, rude, or just plain give up on hard things because those things
0:51
really hurt the morale and effectiveness of a team. For example, during my first interview for
0:56
a front-end position, the hiring manager spent most of the time grilling me on back-end stuff
1:01
and math problems. I later learned that he wanted to know how I would react in a stressful situation
1:06
when I was out of my element. Also, don't talk badly about past co-workers, bosses, or projects
1:11
We can help you get up to speed learning new technologies, but it is practically impossible
1:16
to teach a toxic person to not be toxic. If you trash talk them, then you're eventually going to
1:21
trash talk us and nobody likes that. Number two, you really need to demonstrate that you are a good
1:25
fit for our team. To do that, you should have spent the time trying to research and figure out
1:30
what it is we are looking for. Then when you get to the interview, you need to ask us early on
1:35
what we're working on and try to show that you are a fit for our needs. Here's a little secret
1:41
Our actual needs might be completely different from whatever HR put on the job listing. Half the
1:46
time, they don't even know what they're trying to find, so they'll just use some boilerplate
1:50
requirements or they're just casting a really wide net. For example, my first job offer was for
1:55
an AngularJS position and the team actually needed someone to work on a Cintia Touch application. So
2:00
I ended up having to learn Cintia Touch and it was several months before I ever even touched
2:04
AngularJS code. Number three, how well do you know the basics of your programming language
2:09
For example, if you're working with JavaScript, you should be comfortable with conditional logic
2:13
using objects, iterating through arrays, and there are a bunch of ways to do this functionally with map, filter, reduce, and similar methods. You can also do it non-functionally with
2:22
for loops and while. Do you know how to add, remove, and replace items from arrays and strings
2:27
How to split and join strings? It is really hard predicting what algorithm problem might be asked
2:32
but it's safe to assume that you will likely be tested on some of these core concepts on a
2:37
regular basis. For each algorithm question that I've received during an interview, I've been asked
2:41
at least 10 to 15 core JavaScript, HTML, and CSS questions. Number four, how well do you know the
2:47
basic functionality of a popular framework? For front-end development, that would include React
2:52
or Angular. Can you explain how the components work? How do you pass data in and out of the
2:57
components? How do you compose larger components from smaller ones? And how do you manage the
3:02
application state? When would you choose to use Angular over React and why? If you're applying
3:07
for back-end work, why would you use Spring Boot over something else? Number five, on paper you
3:12
probably look just like a hundred other new software developer applications. How are we
3:16
supposed to know you got the skills or are you just all talk? The last thing that we want to do
3:21
is to hire you only to find out that you don't know anything and then have to turn around and
3:26
let you go. That's a waste of both of our times and it's not very pleasant. So show, don't tell
3:31
Do you have a portfolio of projects that you've built or worked on and can you explain why you did
3:36
what you did? Why you chose one technology over another technology? Is there something unique or
3:41
complex going on in the code? Tell us about it. After all, we're software engineers not mind readers
3:46
so don't expect us to just know whatever it is you'd like us to find out or notice. When you
3:51
show up to the interview, it's safe to assume that there's a good chance that we may not have even looked at your portfolio or code samples. And even if we did, we may not have looked that closely
4:00
because we're all really busy. So if we forget to bring it up, don't be shy. You want to put your
4:04
best foot forward and show us your portfolio. So bring your own laptop or an iPad and have your
4:10
portfolio ready to go. Number six, play to your strengths. Don't overly focus on your weak areas
4:15
and don't apologize for not knowing something. If you're stumped on something, there are a couple
4:19
ways to approach this. First, if you flat out don't know anything about it, just acknowledge that you
4:24
don't know or remember the answer and let us know that you'll definitely look into it later and just
4:29
let this roll off. Don't let it jar your confidence. It's not game over unless you clam up
4:35
Second, if you happen to get stuck on a part of a problem but you remember the rest of it
4:39
don't just shrug and give up. And now pay attention here. This is a super skill that most people don't
4:45
do. Acknowledge that you don't quite remember this step but then explain everything else that you do
4:50
know and what you would do next and what you would do to find the missing pieces. If you just give up
4:55
we are left to assume the worst about you. This is the exact thing that happened to me during the
4:59
interview that landed me my first dev job. I was totally stumped on some syntax pretty early on into
5:04
solving a problem, so I set down the marker and I verbally explained everything else I could think of
5:10
that was related to that topic. This ended up turning into a conversation that went about 30
5:16
minutes over the set time for the interview. Several years later in the interview, we handed a
5:20
MacBook to an experienced software engineer to do some coding, but he was used to Windows. He kept
5:25
struggling because if you push too hard on the trackpad, it pops up the dictionary and interrupts
5:30
typing. Instead of being frustrated, he ended up laughing and stopped typing and then just started
5:35
explaining things. I'm really glad we ended up hiring him because he ended up becoming one of
5:38
my favorite software developers. Another way to play to your strength is to pretend that you are
5:43
a politician and look for natural ways to steer the conversation to topics that you do know
5:47
Without knowing much about you, we have to just take a stab in the dark a lot of times. We probably
5:52
bring up a bunch of different generic questions and topics to try and figure out what your
5:57
strengths and weaknesses are, so help us out. Be proactive in sharing what you do know. And this
6:02
goes beyond just code. Do you have additional insights? Do you have experience making business
6:06
decisions where you had to balance out doing something perfectly against delivering the most
6:11
return on investment for a business? Let us know about it. Seven, treat the interview like a
6:16
conversation. If we ask you to do a code problem, don't just jump the gun and start answering before
6:20
we've even finished talking or start working through things in your head while we're still
6:24
trying to explain things. Instead, focus on understanding what we're saying and then ask us
6:29
as many follow-up questions as needed until you know exactly what we want and then start solving
6:33
the problem. And this is crucial. In asking questions, you'll find out if we're okay with you using
6:38
libraries or you'll learn about different edge cases that you might need to consider. And basically
6:43
you're demonstrating that you're the type of software developer who's going to take the time
6:47
to really think through a problem first and then write code rather than having to rewrite the same
6:51
code multiple times or worse, miss a really important edge case. Now, you're going to feel
6:56
pressure to answer quickly because it is an interview, but you need to push back against
7:00
that self-imposed pressure. The silence in the room will definitely be awkward for you while
7:04
you're thinking about things, but it will be worth it. And if anyone does give you a hard time for it
7:09
then congrats. You've figured out that that's a place that probably has some dev culture issues
7:14
that you probably don't want to work at. Eight, did you spend too much time on LeetCode instead
7:18
of building a portfolio? Now, this is kind of a tricky one to balance. Spending a lot of time on
7:23
LeetCode can definitely help you develop problem-solving skills that can help you with
7:27
technical interview questions that you will eventually encounter. But this does not mean
7:32
that you're actually going to become good at building applications. And what we do on a day-to-day
7:36
basis is building applications. And for me personally, I would much rather hire someone who
7:41
can demonstrate that they can build apps over someone who has memorized solutions to a ton of
7:46
different LeetCode questions. But admittedly, software development interviews are kind of messed up in a lot of ways. A lot of what you encounter comes down to the people doing the
7:54
interview. Even teams at the same company will often do things differently. For example, is the
7:59
interviewer more interested in discussing everyday situations and code problems, or have they bought
8:04
into the cracking the code interview book paradigm? I think the low-level algorithm approach to
8:09
interviews is often flawed because most of us just don't do this on a regular basis. And besides
8:14
typically the programming languages that we are using have built-in utilities to solve a lot of
8:19
this stuff, or else we will use third-party libraries. And in the case where we actually
8:23
have to come up with an algorithm on our own, we have plenty of time to think through it
8:27
to whiteboard and plan and prepare, and then write the code without the pressure of someone
8:32
just looking over our shoulder so that they can see if we're going to do it exactly the way that
8:36
they want in a super short amount of time, when they've had plenty of time to really refine and
8:41
tweak the problem over the course of several interviews. And yet it's just thrown at you
8:46
without any advance notice, and you're supposed to see things the way that they do. It just doesn't
8:51
make tons of sense. That said, this is one of the competitive advantages that LeetCode experts and
8:56
recent college graduates have who have memorized some of this stuff for quizzes. But even CS grads
9:02
usually forget a lot of this stuff and have to brush up on it when they're going to go into a
9:06
tech interview that is likely to be asking these type of algorithm questions. And trust me, I know
9:12
plenty of senior software engineers who've been rejected for a job because they stumbled on an
9:17
algorithm problem that they haven't even thought about or considered for the last 20 years. But
9:22
sooner or later you are going to encounter these kind of interviews, and you're going to win some
9:26
and you're going to lose some, so don't take it personal. I've even received lots of job offers
9:30
and I've lost some because I didn't quickly solve an algorithm question that had nothing to do with
9:35
anything that I have ever worked on. Then to make things even more confusing, there are a bunch of
9:40
ways to do algorithm tests. You might end up having to write it out on a whiteboard, and this can
9:44
really suck because you can run out of space. I mean, outside of interviews, I rarely write code
9:50
syntax on whiteboards. Most of the time if I'm using a whiteboard, it's because I'm just mapping
9:54
out the relationships between different things and jotting down some concepts and working through
10:00
some of the logic, but I don't actually write code on the whiteboard. I write it in a code editor
10:05
because that's what makes sense. Or they could hand you a laptop to solve a problem on. What if
10:10
it's not that operating system or code editor that you're used to working on? Or they send you one of
10:14
several different online assessments. Now you have to kind of figure out how to actually use the
10:19
testing software in addition to solving the problem all in a short period of time. Just don't
10:23
flip and give up because the difference between a good interview and a bad interview is just a
10:28
matter of the stars lighting up right. There are things that you can do to prepare, and then there's
10:33
just some luck that's involved because out of the thousands of different questions that someone could
10:37
possibly ask you, does the interviewer happen to pick ones that actually align with your skills
10:43
Or do they pick something completely unrelated? And this leads into number nine. You need to come
10:47
into this with the right mindset and expectations. Failing lots of interviews is not a good indication
10:52
of your future as a software developer, so you need to learn from them and move on. I mean, in a few
10:58
years you're going to look back and you're not even going to care about all those interviews
11:01
that you bombed because the only ones that are going to matter are the ones that you actually
11:05
accepted. Frankly, passing interviews is its own skill, and even good software engineers are going
11:10
to bomb interviews. So what you're experiencing is not something new, it's not unique to you
11:14
and sometimes it just comes down to simple math that there could be several really good candidates
11:19
for a job and there's only one position. And the difference between you and the dev that actually
11:24
gets the job might be super, super small. For example, in my last job it was pretty much a draw
11:29
between me and another software developer, and it was a recommendation from another employee that
11:35
ultimately tipped the scale in my favor. Number 10. Ask us thoughtful questions. Show some interest
11:40
in our company and in our team. So ask us things that we like to do, what frameworks and tools the
11:45
team likes to work with, maybe why we chose to work with React over Angular, ask questions about
11:50
the company, and don't be afraid to ask personal questions about us. You got to remember that an
11:55
interview goes both ways. You should be trying to figure out if you even want to work with us
11:59
and also by asking questions you're creating interpersonal connections which can really help
12:03
us to remember you when we're trying to look back over a bunch of different candidates that we've
12:08
interviewed. And then it's also going to help you because you can take these insights and you can
12:11
apply them to future interviews if this one doesn't work out. Number 11. Don't get greedy with your
12:16
first job and don't try to compare yourself to that self-taught Ivy League grad who ended up
12:21
getting his first job at Google at Google Pay. And don't go around throwing some super high crazy
12:26
salary out there because some dude on the internet did and happened to luck out and got it. For most
12:31
of us that first job is probably not going to pay that great, or it's going to be okay pay
12:35
but we just need to get into whatever job we can and start getting experience and then the
12:40
higher pay will come faster than you think. And I'm going to do something that I wish someone
12:44
had done with me and I'm going to be totally transparent here. You can watch this video up
12:47
here where I'm going to share how much I made at each of my jobs as a software developer. Lates
#Jobs
#Career Resources & Planning
#Resumes & Portfolios