The decision to hire in a technical interview is often heavily
predicated on non-technical skills.
Scary.
I know.
Hey everyone, I'm David from Arc.
In this video, we're going to be talking about how to ace technical interviews.
Have you ever wondered how to improve your chances and land that dream job?
Let's get into it!
So when you think about acing a technical interview, you probably think
of algorithms, whiteboarding or so way of demonstrating all that knowledge
that you've amassed over the years.
That makes sense.
You've earned it and that struggle shouldn't go unnoticed right?
And in the same vein, it's also true that the decision to hire in a
technical interview is often heavily predicated on non-technical skills.
Scary, I know.
So when you're in the interview, you might be saying a whole bunch of things
that are technically true, but then not what the interviewer wants to hear.
So let's go through some questions.
When anyone asks you a question during an interview, it's a cool little trick
to try to reverse engineer anything they're actually saying to you.
Now, instead of just simply answering the question, what if
you could try to think about what does the other person want to hear?
What's the reason behind them asking this question?
If anyone's asking you questions about the delivery process, they're probably worried
about three things: delivery on time delivery on spec and at the right quality.
When you now apply this to all of your previous projects, you should be
thinking about how did you define the requirements before you started so you
made sure you were on the right path?
Secondly, how did you ensure you and the rest of your team remained
on track and kept moving forward?
So when it comes to quality, you should be thinking about how did you know
you were delivering the right thing?
And how could you measure the things you were delivering were robust?
It's a common question to get asked about the tooling that you use during a project.
And a lot of the time that was probably out of your control and
the tooling was given to you.
But try to avoid just simply say the tooling was given to me, this was the
language that the company had chosen.
What you're trying to show is there was a conscious decision.
Why did you choose this framework?
Why did you choose this language?
Hopefully there's some technical reason why you did.
And if you can showcase that you did the research, you knew why this was
the right tool, and that shows your moving towards a senior placement.
One other things to consider when you're talking about the tooling
you chose is did you just consider the technical requirements?
Because there are other things to consider time, money, resources.
Do you have enough developers available to help you with the
development of this product if you choose this particular framework?
It's worth considering.
And the last thing I'd say about this is it's okay to have an opinion.
If you have a preference for a particular tool and you're able to
move fast with it, then that's a good enough reason in itself sometimes.
Everyone loves the question about scaling.
If you're a software developer who can build a product that can scale,
then that's the mark of a real senior.
Consider it might not just be enough to say I built a system that could scale
and handle a lot of users simultaneously.
Did you consider this before you started?
How did you plan for the scaling?
Did you look at when the traffic was arriving, was the short burst, or was this
continued traffic all the way through?
The more you can show that you were thinking about these things
before you started building that shows the mark of a senior too.
Questions about testing are extremely common.
And the minefield here is opinion is quite divided on what's
the right way to go about it.
Some people want to test absolutely everything.
And some people think that testing is a waste of time and money.
So when you're talking about your approach to testing, it's good to
consider volunteering your opinion, but being open to the opinions of others.
Again, here is not just about whether you test or not.
It's about your thought process going into the project.
If you can showcase during the planning phase of a project that you're
considering what needs to be tested, what sort of testing is required and
what the benefit of doing those tests are, then you're showing that you're
not just blindly testing things.
You're doing things strategically.
When you're asked about logging and monitoring during an interview, they're
really asking what's your name or plan?
What strategy have you got in place for when all things go right?
This is a good time to showcase your experience and maybe talk about times
when you didn't get things exactly right.
Maybe you started off by logging too little and missed something and you'll
never make that mistake again, right?
And another strategy is maybe to talk about all the things you got
wrong and how that's formulated your strategy moving forward.
When you're asked about systems performance, it's good to think
about this in two separate parts.
Firstly, how did you define good and bad performance?
And these should have been filtered through, into the requirements of the
project, which elements of the project needed to scale and which bits didn't.
So secondly, when you've defined which areas of the system needed to be performed
and you know, at what level they need to perform, then it's okay to add on the
tools you would use to monitor and make sure that those things actually happen.
So my takeaways for acing a technical interview would be: one, think about
the questions being asked and what the interview expects in the response.
Two, you don't have to get everything right.
Sometimes talking through the mistakes you've made and what you've
learned from those mistakes is probably the most valuable thing.
It gives an insight into you as a person, and that's what they
want at the end of the day.
They want to realize that this is a person I want to work with in the long-term.
As always, thank you for watching.
If you liked the content, then please give this video a like.
If you want to see more, then please subscribe and don't forget to hit that
bell to be notified about future content.
I'll catch you next time.