Krystyna Ślusarczyk

GET READY FOR

CODING
INTERVIEW
 HELLO!
This e-book is a part of my course "Get
Ready for Coding Interview", which you
can find on Udemy:

https://bit.ly/3LNjxj5
 INTRODUCTION
Hello, I'm Krystyna! I'm a programmer
who loves to write elegant code.
I've been working as a software
developer since 2013. About half of this
time I've been engaged in teaching
programming.
I believe that with a proper
explanation, everyone can understand
even the most advanced topics related
to programming.
I hope I can show you how much fun
programming can be, and that you will
enjoy it as much as I do!
INTRODUCTION
HOW CAN THIS COURSE HELP YOU
HOW THIS COURSE IS ORGANIZED

SECTION 1 - BEFORE THE INTERVIEW

SECTION INTRODUCTION
PREPARE TO ANSWER THE TECHNICAL QUESTIONS
REVIEW YOUR EXPERIENCE
PREPARE TO TALK ABOUT YOUR PORTFOLIO

SECTION 2 - THE INTERVIEW

SECTION INTRODUCTION
WHY NOT ONLY THE TECHNICAL QUESTIONS MATTER - A CASE STUDY
HOW INTERVIEWERS EVALUATE CANDIDATES - INTRODUCTION
HOW INTERVIEWERS EVALUATE CANDIDATES - THE TECHNICAL KNOWLEDGE
HOW INTERVIEWERS EVALUATE CANDIDATES - THE WILL TO LEARN
HOW INTERVIEWERS EVALUATE CANDIDATES - CLEAN CODE & CODE QUALITY
HOW INTERVIEWERS EVALUATE CANDIDATES - SOLID AND TRUSTWORTHY
CANDIDATES
HOW INTERVIEWERS EVALUATE CANDIDATES - CANDIDATES THAT ARE A
PLEASANT TO WORK WITH
WHAT TO DO IF YOU DON’T KNOW THE ANSWER TO THE QUESTION (AND WHAT
NOT TO DO)
MOST COMMON MISTAKES
DIFFERENT INTERVIEWS FOR DIFFERENT LEVELS OF SENIORITY
COMMON NON-TECHNICAL QUESTIONS

SECTION 3 - BEFORE THE INTERVIEW ENDS

BEFORE THE INTERVIEW ENDS - THE INTRODUCTION
BEFORE THE INTERVIEW ENDS - YOUR QUESTIONS
CODING INTERVIEW CHECKLIST
INTRODUCTION

HOW CAN THIS COURSE HELP YOU

Hello! My name is Krystyna and welcome to the “Get Ready for Coding Interview” course!

My purpose here is to help you prepare for your next programming interview. First, let me tell
you a couple of words about me. I’ve been working as a software developer since 2013. I
currently work as a Technical Lead specializing in .NET. Conducting technical interviews is
part of my job, and during my entire career, I’ve done over a hundred of them. I’ve been
interviewing for various companies, different industries, and all candidate levels. I know
exactly what companies expect from candidates during interviews, and I will share this
knowledge with you, so you can use it to your advantage next time you want to get a job.

I probably don’t need to tell you how important the interviews are. Making a good impression
during one can get you a dream job, with the best salary, great culture, and amazing
development opportunities. Preparing for an interview is the investment through which you
can collect revenue for the rest of your career. It’s really worth making an effort. This course
is just a bit longer than 1 hour, and it can help you get ready for an interview that will maybe
change your entire career.

This course is not focused on any particular technology or language, and I will not give you
answers to specific technical questions here. Instead, I will teach you how can you find them
yourself, and also what to expect from the interview exactly. Many people think that an
interview is just a series of technical questions, intending to verify if the candidate knows the
tricks and quirks of some programming language or technology. But this is not exactly
correct. The technical knowledge is, in the end, the most important, but much more than that
is verified during the interview. During this course, I will teach you what exactly the
interviewer verifies during the interview, so no matter what your knowledge is, you can make
the best possible impression and greatly enhance your chances of getting the job you want.

HOW THIS COURSE IS ORGANIZED

Let me show you what are the sections of this course.

First, I will guide you through what to do before the interview even happens. Preparation is
the most important step. We will talk about creating a learning plan, as well as how can you
get ready to discuss your experience and portfolio.

Then, we will talk about the interview itself. We will start by doing a case study, to show that
not only the technical questions matter. Then, we will see what the interview looks like from
the interviewer’s point of view - what they want to achieve, what they focus on, and how they
assess the candidates. We will talk not only about the technical questions themselves but
also about many other aspects that can affect the final result of the interview.
We will also talk about how to deal with questions we simply don't know the answer to, as
well as how to avoid the most common mistakes. I will show you how the interviews differ for
junior, mid, and senior-level candidates. Finally, we will go through the most common,
non-technical questions that you should be ready to answer.

In the last section, we will cover the end part of the interview, where there is time for your
questions to the interviewer. This is a crucial part. The interview is not only about checking if
you are a good match for some company, but also if this company is a good match for you.

So, without further due, let’s jump to the first step - preparation.
SECTION 1 - BEFORE THE INTERVIEW

SECTION INTRODUCTION

So, you’ve been invited to an interview. Let’s make sure you’ll be ready for it. Preparation
takes time and effort, but it is a crucial step. In this section, we will discuss the three most
important phases of it.

First, we will talk about finding out what technical questions can you expect, and how can
you learn the answers to them. If you’ll go to the interview having learned a couple of dozens
of the most common questions from the technologies relevant to the job, you will have a
great chance of actually hearing those questions during the interview. With such preparation,
you will feel much more confident and relaxed.

Secondly, we will discuss how can you get ready to talk about your experience in a way that
will show you in the best possible light.

Even if for now you don’t have any experience, don’t worry. In the third lecture of this
section, we will talk about portfolios, and how to prepare for presenting them.

PREPARE TO ANSWER THE TECHNICAL QUESTIONS

To prepare for answering the technical questions, you should first create a list of those that
you are most likely to be asked. This of course depends on the job you applied for. Let’s
consider this fictional job offer:

Job title: Fullstack .NET developer

Tech stack:
• C#
• .Net Core
• JS
• React
• Entity Framework
• REST
• SQL
• Unit testing (NUnit or XUnit)

All right. This is basically the list of the topics that are most likely going to be discussed during
the interview. Remember that for most job offers, the more important skills and technologies are
listed on the top while the least important on the bottom. In this case, we should focus mostly on
the C# language itself, and if we don’t have enough time for full preparation, we can probably skip
Nunit and Xunit, and there is the lowest chance you will be asked about them.
Remember, even with the best preparation, it’s not possible to predict every question in the
interview. The point is to be as ready as possible, so in practice, learning the answers to the most
common questions regarding the most important technologies.

What we should do now is simply go to any web search engine, and find the most popular
interview questions for the given topic. For example, we can simply type “C# interview questions”
into Google.

And there we will have dozens of articles containing the compilations of the interview questions
for C# and .NET, usually with answers. It will be easy to notice that some of those questions are
repeated between many of those lists. For example, the question about the difference between
the interface and the abstract class in C# will most likely be on most of those compilations, and
from my experience, it is indeed asked during almost every C# interview. For us, it’s a clear sign
that we should make sure to learn the answer to such popular questions before the interview.
And here is a little secret: the interviewers also google the questions, as they prepare for the
interview with the candidate. So it is likely that they will ask you the questions from the first page
of Google results.

If during the interview you won’t know the answer to the questions that appear in almost every
result from the search, for the interviewer it will mean you hadn’t even bothered to do this little
preparation. I probably don't need to tell you that it doesn’t look very well. It will seem like you did
not care about the interview, so perhaps you will also not care about the job?

The web provides us with plenty of materials ready to be used. What might be a good idea is to
use them to create a learning plan. It can simply be a list of questions we want to be ready to
answer, ideally with some kind of way of tracing our learning progress. As I said in the
introduction, this course is language-agnostic, but for example’s sake, I prepared the list I created
for C# interviews. You can find it under this link:

https://bit.ly/3s8rCGX

Here I compiled 50 C#/.NET interview questions that are commonly asked during Junior-level
interviews. At each question we can tick a checkbox, marking how well we know the answer to it.
As you can see, some of those questions are not only specific to C#, and many of them regard
more generic programming topics, like design patterns and coding principles. No programming
interview is about the language alone.

And here is a similar list, but for Mid-level interviews:

https://bit.ly/3kFscbb

We will talk later in the course about how the interviews differ depending on the seniority of the
candidate.
If you would like to learn answers to all those questions in-depth, you can
check out my courses about them:

C#/.NET - 50 Essential Interview Questions (Junior Level): https://bit.ly/3hSRpOq

C#/.NET - 50 Essential Interview Questions (Mid Level): https://bit.ly/3sC7FsW

Having such a list ready, we can start with marking the questions that we already know, to find
the ones that we need to work on. With this knowledge, we can prepare a proper learning plan.
You can plan how many questions a day will you learn, or that you will spend a specific amount of
time every day on learning. Whatever the method, the purpose is to ideally fill this list with ticks.
When this happens, you will feel confident that you are ready for the interview.

Another great technique for making learning easier and faster is using flashcards. Flashcards are
simply pieces of paper with the question on one side, and the answer on the other. It is
scientifically proven that they improve memorizing very much. Here is an interesting article
explaining how this works exactly:

https://ncase.me/remember/

There are also digital flashcards you can use, to learn on your computer or your phone. The app I
prefer is called Anki:

https://ankiweb.net/

Let’s take another look at the job offer. This one, like many others you may see, does not include
the more general programming topics, that you will most likely still be expected to know, and
might be asked about them during the interview. Examples of such topics could be:
● clean code
● good coding practices
● dealing with legacy code
● design patterns
● algorithms and data structures

For all of those topics, you can also simply google interview questions about them. For example,
in my list, I included some design patterns, antipatterns, as well as good (and bad) coding
practices.

Another thing that you should take into consideration when preparing a list of interview questions
to learn, is what questions can be expected in a specific company. Let me give you a couple of
examples. During an interview for a company that builds embedded software, there is a big
chance you will be asked more questions about performance or memory management, as they
are the challenges that embedded software engineers must deal with. On the other hand, in a
financial company, you can expect more questions about security or transactions. Again, it’s best
to look for compilations of interview questions for a specific company type online.
Also, if you go to an interview in a well-known, large company, it doesn’t hurt to google interview
questions exactly for this company. Hundreds of developers went to those interviews before you,
and there is a big chance they shared their experiences online.

When it comes to coding exercises and algorithms, remember it’s the practice that makes
perfect. There are plenty of websites offering coding exercises online. One of the most popular
ones is HackerRank ( https://hackerrank.com ). On this page, you can tackle dozens of coding
challenges, choosing from most of the popular programming languages.

Let’s summarize. There are three main aspects of getting ready to answer the technical
questions. First, you must find the questions to learn. To do so, analyze the job offer that you
applied for and search for the questions for the given tech stack online. It’s also a good idea to
look for questions for a specific company type, for example producing embedded software,
financial software, or being in the game dev business. Moreover, if the company you apply to is
well-known, you can simply search for interview questions for this particular company.

Next, you can create a learning plan. You can choose any method, deciding what amount of time
a day you want to spend on learning, on how many questions you want to go over weekly. You
can also try some learning techniques like using flashcards. Whatever the method, remember to
prioritize the most common questions, as there is the greatest chance you will be asked them.

Finally, remember that language and specific technologies are not everything. There are many
other aspects that are commonly discussed during technical interviews, like clean code, design
patterns, or good and bad coding practices. Algorithms and data structures are another common
topic, and to learn them, it’s best to do it by practice. You can look for coding exercises online, as
there are plenty of pages that offer them.

All right, Let’s now move on to the next lecture, where we will continue the topic of preparing for
the interview, but with more focus on your own experience.

REVIEW YOUR EXPERIENCE

The coding interview is not only about checking your programming knowledge in a purely
theoretical context. The future employer will also want to know if you have actual working
experience, how have you dealt with challenges at previous jobs, and what were your greatest
achievements.

When the interviewer asks you about your past projects, there is nothing worse you can do than
make an impression that you barely remember them. That's why it’s a good idea to actually
prepare to talk about your past projects before the interview. Take a look at your resume or your
LinkedIn profile. Try to remember each project you participated in. What were your
responsibilities? What was the tech stack? What challenges did you face, and what were your
greatest achievements? Focus on what was good and what shows you as a good candidate for a
developer in the new company, but keep in mind that employers also want to know about the
hardships you went through, to know how you can deal with the pressure. They also often ask
what was your personal failure, and what lesson did you learn from it.
Let’s see it by an example. I will show you how could I describe one of the projects I’ve been
working on. I will be also pointing out the techniques I use to highlight my achievements.
Remember, an interview is basically advertising yourself as a great employee, so don’t hesitate to
use marketing techniques to show that.

“At my last job I was working on a program processing huge amounts of financial data. The
purpose of this program was to estimate the financial risk related to investments, that in the end
was used by the company to make the best business decisions. It was a backend application
written in pure C#, that connected with an MS SQL database. There was a high focus on the
performance. My work on the project improved the speed of the application by 230%, which I
mostly achieved by introducing caching as well as using multithreading where it was possible.
When I first joined the project there were no unit tests at all, but I raised the test coverage to 95%
while I was working there. “

Let’s break it down. The first two sentences briefly describe the program itself, and underline that
it was an important and big part of the company’s business - this shows I’m not afraid to take
responsibility for projects which may have a true impact on the company’s well-being. I also
underlined that the application was done for a financial domain, which would matter if the
company I apply to now is also from the financial sector. Then I mentioned the core technologies
I was using, and that it was my job to keep the performance high. I mentioned some techniques
for achieving this - the caching and multithreading - and I also presented hard numbers, which
are much better than generic terms like “I improved the performance very much”. I did the same
when mentioning how I raised the test coverage.

So as you can see, the purpose of such a description is to show ourselves as the best possible
candidate for the job. It’s the marketing of course, but remember to keep to the facts.

If I didn’t take the time to remember this project before the interview, my presentation would
most likely be much less attractive. That’s why I recommend you to go through the projects you
participated in, and make sure you remember what you achieved in them. Focus on the most
recent, or the most interesting ones.

The same preparation should be done for challenges and failures. We all had some, but the point
is to be ready to describe one of them in a way that will actually show us in the best possible
light. While the challenges are pretty simple - you just need to remember a situation when you
were under some pressure and dealing with something hard, and describe how you managed to
solve this problem - the question about failures might be a bit intimidating. It’s best to focus on
this part, where you describe what you learned in the process. For example, this is what I usually
say:

“At my first job, I was working on a task that I struggled with. I did not want to ask anybody for
help, as I was scared I will be considered incompetent. This, in the end, lead up to a situation
when some senior developers needed to stay after hours, so the work could be finished before
the next morning when it was going to be shown to the customer. This was, obviously, a big
mistake on my side, but what I learned from this and what I keep practicing till today, was to ask
for help when I really need it, and never to try to pretend that I know everything and that no task is
too hard for me”.
It’s not a coincidence that I describe a situation from my first job - it was a long time ago, and the
interviewer will most likely assume I learned a lot since then, and I will not make the same
mistake in the new job. Then, I honestly describe my failure but focus on what I learned from it,
also underlining that this knowledge stayed with me till today.

If you prepare a similar answer for yourself before the interview, there will be no risk that under
pressure you will talk about a mistake you made that you would actually not want the future
employer to know about.

Let’s summarize. There is a huge chance you will be asked about your experience during the
interview. It’s really worth it to spend sometime before the interview to prepare for that. Try to
remember what were your projects about, what technologies did you use in them, as well as how
you handled the challenges, and what were your greatest achievements. Also, don’t forget to get
ready to talk about some failures you had, so you can show them in the least negative way,
ideally focusing on what you learned from them.

All right. We can now move on to the next lecture, where we will talk about discussing portfolios
during the interview.

PREPARE TO TALK ABOUT YOUR PORTFOLIO

For people looking for their first jobs in programming, interviews are probably the most
challenging. Not only there is usually a big competition for entry-level jobs, but also their
knowledge is not so vast for now, and they don't have any experience to talk about.

Having a portfolio is a great way to improve your chances of being invited for an interview and
hired. A portfolio is just a collection of projects available in some public repository, that the
employer can investigate to assess your coding skills before the interview, and also discuss
during one. I don’t want to go into details on how to prepare such a portfolio, because this would
be a topic for an hour-long lecture. If you are curious, here are some resources about this topic:

https://bit.ly/3vHqY5F
https://bit.ly/3wphlI7
https://bit.ly/3Fi2tiC
https://bit.ly/3vJ9PZe

Let’s focus on how can you prepare to talk about your portfolio before the interview.

The worst thing you can do is not remember what you actually have there. If you hadn’t created it
just recently, there is a big chance you will not remember exactly what you have coded there. If
you can’t talk in detail about your code, it is possible that the interviewer will suspect that those
projects are not really yours and that you simply copied them from somewhere. I probably don’t
need to tell you how it looks.

Open your code before the interview and run it. Learn to describe what the application is doing in
an interesting and concise way. Dive into the project structure and individual classes. If you used
any design patterns, pay close attention to them, as this will look great during the interview if you
can describe how you applied them in your project. Also, expect the interviewer to ask you many
questions like:
● why did you choose such a design?
● why did you choose those frameworks and libraries?
● how did you test this application? Did you create unit tests?
● how would you improve this code?

Preparing to present your portfolio should take a fraction of the time it took to actually create it,
and it will make a much better impression than trying to frantically remember what was the
project about only during the interview.

All right. This closes the section about the preparation for the interview. Let’s move on to the next
one, where we will discuss the interview itself.
SECTION 2 - THE INTERVIEW

SECTION INTRODUCTION

In this section, we will discuss the interview itself. Many candidates think that the only thing that
will be assessed is pure, technical knowledge. It is not correct. Technical knowledge is
important, even crucial, but it’s the interviewer’s job to verify much more than that. In the coming
lectures, we will discuss how to make the best impression possible, no matter how vast your
technical knowledge is. First, we will try to look at the interview from the interviewer’s
perspective, to understand what they expect of candidates. Then we will talk about how to best
deal with questions you don’t know the answers to. We will also go over the most common
mistakes the candidates make, and how to avoid them. Next, we will discuss how interviews
differ for various levels of seniority of the candidate. Finally, we will talk about the most common,
non-technical questions.

WHY NOT ONLY THE TECHNICAL QUESTIONS MATTER - A

CASE STUDY

First, let’s understand why not only purely technical knowledge matters.

Imagine that some company interviewed two developers, but the interviewer only paid
attention to their technical knowledge, nothing else. They were both hired.

The first candidate - let’s call him Robert - was really good during the interview and
answered almost all the interviewer’s questions. He also already has about 8 years of
experience.

The other new joiner is Julie. She’s more junior, and the truth is she simply didn’t know the
answers to about half the questions. She only has one year of professional experience. As
you may guess, Robert was offered a higher salary, as taking a more senior role in the team.

After a couple of weeks, something interesting turns out. It seems like Robert is not as senior
as we expected, and he often needs help with his work. We start to suspect the answers
he’s given us during the interview he simply memorized, without any real understanding. At
work, he’s not very eager to learn new things. He’s also quite arrogant, and he doesn’t get
along with the rest of the team. He’s not trustworthy, as it once turned out that he said that
he tested some code, but in reality, he did not, which caused a really bad demo with the
client. He’s the team’s senior, but he doesn't really like challenges - to be honest, he doesn’t
seem to like programming at all. Due to his long working experience, he wasn’t very happy
when the manager was trying to address those issues, as he was certain that the fact that he
has 8 years of experience made him an expert that should not be criticized.

In the meanwhile, Julie is working really hard. On her first day she mentioned that after the
interview, which did not go so well for her, she found out and learned answers to all
questions that she failed on. She’s clearly fascinated with programming and shows true
passion for it. She often doesn’t know how to do something, but she’s happy to learn from
others, and also not afraid to ask for help when she needs it. She’s always solid and when
she says something will be done, it will be. She learns quickly, and after just a couple of
months, she actually introduces new joiners to the project. Not to mention that everybody
enjoys her company.

So, which employee do you think is better for the company? I think the answer is simple.
Even if during the interview Julie knew answers to fewer technical questions than Robert,
she shows more passion for programming, and she learns really fast. Soon she will be a
better programmer than him. Even if for the first couple of weeks she needed a lot of help,
the company can treat her as an investment, and soon Julie will develop herself into a really
valuable employee.

I hope you now see that technical knowledge is not all there is. But how do the interviewers
assess if the candidate meets both technical and non-technical requirements? We will learn
about it in the next lectures.

HOW INTERVIEWERS EVALUATE CANDIDATES -

INTRODUCTION

As the last lecture showed, the interviewer who only evaluates technical skills is not a very
good one. The employers want to know more about the candidates. Even if the interview is
done in a couple of stages, and there is a separate, soft-skills phase, the technical
interviewers are still expected to provide an evaluation of other aspects of candidates than
the technical knowledge.

Let’s list what the interviewer evaluates:

1) if the candidate knows the technologies he or she will work with
2) if the candidate is interested in programming and will continue to learn and develop in
this area
3) if the candidate knows how to write clean code
4) if the candidate is solid and trustworthy
5) if the candidate will be a good match for the team

In the next lectures, we will see how can the interviewer verify those things, and what can
you do to pass such verification.

HOW INTERVIEWERS EVALUATE CANDIDATES - THE

TECHNICAL KNOWLEDGE

Let’s start with the first, most crucial aspect - technical knowledge. The interviewer could
simply ask the question, and check the checkbox if the candidate knew the answer. But
usually, this is not enough. First of all, the interviewer wants to verify if you truly know what
you are talking about. After all, you could have just memorized the answer without
understanding its meaning. Secondly, the interviewer often wants to gauge your level of
knowledge about some topic. Do you know a little bit about it, do you have average
knowledge, or are you an expert? Such information is very valuable for the employer -
perhaps, even if you apply for a mid-level role, your knowledge is enough to offer you a
senior role in the team?

So how can the interviewer find out if you really know what you are talking about? Well,
there are a couple of techniques to do that.

First of all, you can expect the interviewer to circle around some topic, instead of asking a
question in a straightforward way. For example, you may not be asked “What is the
Dependency Inversion principle from SOLID?” but rather be shown a piece of code and
asked, “Which of the SOLID principles is broken here?” This way, the interviewer will have
the opportunity to check if you really understand this principle, and not just memorized it
before the interview, without ever thinking about how it actually looks in the code. So the
advice for you here is this: don’t simply memorize the answers without understanding
them. It will always show up during the interview.

Another technique the interviewers use is going deeper and deeper into the topic, to see at
what level the candidate stops to follow. For example, you might be asked “What does the
“goto” keyword do?” After you answer, the interviewer might go into further details: what are
the disadvantages of using goto? What are the scenarios in which it is acceptable? How
would you refactor a particular piece of code that is using goto? Or even, what would you tell
a colleague that notoriously uses goto? This way, the interviewer can measure how deep
your knowledge about this particular topic is. It will also, again, verify if you truly understand
what you are talking about.

When learning about a particular topic before the interview, try to look at it from different
angles. Play with it on some code, and think about the advantages and disadvantages of
different solutions. If you are learning about it from some blogs or books, try to also check
out other points of view in other sources. Many topics in programming are disputable, and
showing that you see different points of view looks very good during the interview.

For example, when I was first learning about the Singleton design pattern, I simply learned
how to implement it and what it gives. I was baffled during one of my first interviews when
the interviewer said that this is actually an antipattern. I discussed it with him, and then
learned more about it at home, and it turned out this is very much right. From then on,
whenever the Singleton topic was touched during the interviews I was participating in, I was
saying that this is more of an antipattern than a pattern, which was always appreciated by
the interviewers, and lead to interesting discussions, which is always a good thing during the
interview.

HOW INTERVIEWERS EVALUATE CANDIDATES - THE WILL

TO LEARN
The interviewer also wants to verify your potential for further development. An employee with
a passion for programming and a will to continue learning it is much more attractive than
one who isn’t really interested in software development. This is especially true for junior
developers, who often don’t yet have vast knowledge, and the employer expects them to
learn a lot on the job. So, the advice here is this: make sure to show that you care about the
topics you discuss and present yourself as someone with a will to learn. Look interested and
engaged. For that, you can use a couple of simple techniques.

First of all, if you don't know the answer to some question, don’t say something like “I have
no idea, let’s move on” because it shows that you don’t care. Instead, ask for an
explanation. We will discuss it further later in the course when we will talk about dealing
with questions that we don’t know the answer to.

Secondly, when answering a question, you can slip the information about how you learned
the answer. Think of phrases like:
1) “I remember reading the article from Edsger Dijkstra criticizing the use of the goto
keyword.”
2) “On my favorite blog XYZ I’ve read that one of the common use cases for using goto
is breaking from nested loops.”
3) “In “Clean Code” Robert C. Martin makes a pretty strong statement about not ever
using goto”.

This way you show that you like to learn and that you are really interested in programming.
You also point out that you are open to exploring various sources of knowledge. Of course,
don’t do it with every question. Once or twice during the interview should be enough.

Even more important than showing interest is what you don’t show - the lack of it. Think of
statements like:
1) “I never thought about reading about that”.
2) “The solution I’ve found on StackOverflow worked for me, so I didn’t need to check
why it works”.
3) “This seems like a technicality of the language, and the compiler takes care of it for
me, so I don't really need to understand how it works”.

All those statements show a lack of interest in programming, and you should avoid them.
Of course, I’m not saying that from day one of your programming adventure you should dig
into details of absolutely every topic, and for example, read how compilers work even before
you learn how to write the for loop. There will always be topics you simply did not have a
chance to dig into, no matter how senior you are. But it’s much better to say something like,
“Unfortunately, I don’t know. Can you tell me the answer?” than just saying “No idea, next
question, please”.

Another way of showing interest - and also of becoming more knowledgeable - is writing
down the questions, especially the ones you don’t know the answer to. Don’t hesitate to do
it, and take your time. The interviewer will appreciate your interest. After the interview, you
can review those questions and learn the answers to those you failed on.
Not doing so can lead to one of the worst things you can do. Let’s say the interview has
several phases, and during the first one, you failed on some questions. Nevertheless, you
were invited to the next phase taking place a couple of days later, and exactly the same
question was asked. If you fail again, it will look really bad. It will show that you didn’t
care that you were lacking some knowledge and that you didn’t make the effort to find out
about the questions you were asked and failed to answer. Actually, the interviewers often
know what questions you were asked during previous interviews for the same company, and
are very likely to ask you again those questions that you had difficulty answering, so you
should definitely get prepared for that.

Let’s summarize. Companies are more likely to hire developers who are willing to learn and
have a true passion for programming, as they want to have employees that will get better
and better over time. That’s why it’s a good idea to show yourself as a software development
enthusiast during the interview. To do so, you can use a couple of techniques:
1) When you don’t know the answer to some question, show that you would like to learn
it
2) When answering the question, mention how did you learn the answer - for example
from a book or a blog
3) Don't show a lack of interest
4) Write down the questions, especially the ones you find problematic
5) Make sure to learn the answers to the questions that you failed to answer before the
next interview in the same company

HOW INTERVIEWERS EVALUATE CANDIDATES - CLEAN

CODE & CODE QUALITY

Another thing the interviewer will most likely want to verify is if you are able to create a code
of high quality.

If you provided a portfolio, you can expect the interviewer to check it out and assess the
code quality in your repository, so make sure that the code there is top-notch. What it means
exactly is a topic for a whole separate course. If you want to learn more about creating
high-quality code, I recommend starting with reading “Clean Code” by Robert C. Martin.

If you don’t have a portfolio, the way of verifying if you can create a clean code depends on
the format of the interview.

If you do some live coding, either by simply being with the interviewer in the same room or
with an online tool, then the interviewer will pay close attention to how you organize your
code, name your methods and variables, design your classes, etc, so try to keep the code
quality high even for small, simple coding exercises.

If there is no live coding, you might simply be drawn into a discussion about the code quality,
and, for example, discuss naming, patterns, antipatterns, common code smells, etc. Also,
there is almost always some discussion about unit testing. Before the interview, make sure
you understand how unit tests and code quality are related. The most important thing you
need to know about that is that it’s hard to keep the quality high without unit testing because
then, it is risky to introduce code refactorings, as we are afraid that they may break
something. Unit tests guard us against that, ensuring us that after the refactorings are done,
the code still works. And without refactorings, the code quality will continue to decline.

HOW INTERVIEWERS EVALUATE CANDIDATES - SOLID

AND TRUSTWORTHY CANDIDATES

Verifying if you are truthful and trustworthy is hard for the interviewer, but for you, it boils
down to simple advice: don’t lie. Whether it’s about projects and achievements, the books
you’ve read, or simply that you are familiar with some technology when actually, you are not.
If the lie is exposed, you will be done. If you lied about one thing, you might have made your
entire resume up. Also, maybe as an employee, you will lie that your tasks are done, or your
code is tested. Not only will you not be offered the job, but you will most likely be blacklisted
for this company or hiring agency. Don’t ever lie during the interview.

HOW INTERVIEWERS EVALUATE CANDIDATES -

CANDIDATES THAT ARE A PLEASANT TO WORK WITH

Finally, the interviewer will want to see if you will be pleasant to work with, especially if he or
she is your potential future colleague or manager. In this case, the advice is simple as well:
be nice and respectful. Treat others like you would like to be treated. There is no particular
moment of the interview you can show that. Be nice from the very beginning (for example,
don’t be late) till the very end. Always assume that possibly one day you will be working with
the person you are talking to now, so it’s better to start off on the right foot.

WHAT TO DO IF YOU DON’T KNOW THE ANSWER TO THE

QUESTION (AND WHAT NOT TO DO)

In this lecture, we will talk about what you can do if you don’t know the answer to some
questions. Such a situation is perfectly normal and happens even to the most experienced
and knowledgeable developers. I will tell you a secret: the interviewers actually like to
sometimes ask a question they don’t expect the candidate to be able to answer. The reason
for that is simple - they want to see how the candidate will handle such a situation and the
pressure.

Let’s analyze some possible reactions to such a question from worst to best:
1) Lying that you know the answer. Absurd as it seems, I’ve seen it many times
during the interviews I conducted. The candidate says that he knows something - for
example, a design pattern - while actually having no idea about it. To be honest, I’m
not sure what they count on. It is obvious to me that I, as the interviewer, actually
expect a little more than “sure, I know it” and I actually want to hear what this design
 pattern is, how it’s used and how can it be implemented. So, don’t lie, ever. The
interviewer will see that, and you will make a really bad impression.
2) Losing temper and saying that the question is stupid or should not be asked
for other reasons. I can’t count how many times I’ve heard comments like that. “This
is a low-level question and I will never need to know it, why do you ask me this?”.
“Who cares how the compiler works? It compiles the code and that’s all I need to
know”. Or even “If I knew such things, I would not be applying for this job but rather
selling scientific books”. (And this was the question about the basic binary search
algorithm!). Just don't say such things. First of all, it would show you as short-sighted,
if you think that low-level details of the language can not affect our everyday work.
Secondly, it’s disrespectful, and thirdly, it shows your lack of interest in programming.
Even if you just don’t like the question, keep it to yourself.
3) Admitting that you don’t know the answer, but not being interested at all in
finding it. This also looks bad. It’s OK to admit that you simply do not know the
answer, but showing interest in it would make you look better. You can simply say
“can you explain it to me?” and 99% of the interviewers will do it with pleasure. Most
of the interviewers will try to give you some tips, hoping that something will click in
your head and you will be able to finish the answer yourself. Also, you can ask for a
tip yourself, or if you feel that you’ve heard some term before but you are not sure in
what context, to be provided with one. Giving a partial answer to the question is
better than no answer at all, which brings us to the next point.
4) Admitting that you don't know the full answer, but trying to answer as much as
possible. This is a very good tactic. First of all, the candidates sometimes think that
the interviewer expects a very detailed answer, and panic if they don’t have one, not
even trying to say a little bit. But the interviewer is often satisfied with just a short,
basic answer and will move on to the next question without digging deeper into the
subject. Also, it's better to say whatever you know about the subject, even if it’s not
much than nothing at all. For example, if you are asked what is the “goto” keyword,
you can simply say something like “I don’t know, but I’ve heard it should be avoided”.
Many interviewers use some kind of scale to measure how good the answer was.
Personally, I use a 6-grade scale from “Fail” to “Excellent”. It’s much better to be at
“Almost good” than “Fail”. Just a word of caution. When giving a partial answer, don’t
drag it. There is no point in having a 5-minute monologue about a topic you barely
know. Just say all you know and be done with it.

As mentioned before, you should always note down questions on which you failed, so you
can learn the answers later. Doing this and asking for explanations is a great way of showing
your interest in programming, engagement in the recruitment process itself, and also
expanding your knowledge.

MOST COMMON MISTAKES

All right. In this lecture, we will discuss the most common mistakes made during interviews,
and learn how to avoid them. Some of them we mentioned before, but it’s really worth
making sure you are aware of all of them.
 1) Lying. This is simple as that. Don’t lie. If it is uncovered, you will lose any chance of
being employed by this company ever again. Whether it’s about your skills, projects
you’ve done, or achievements you earned - it’s just not worth it.
2) Cheating during the interview. You would be surprised how many times I had a
phone interview with a candidate, and after I asked a question I heard a long pause
and faint typing on the keyboard in the background. Then, miraculously, the
candidate gave me an answer, by accident almost the same as the first result shown
when typing this question in Google. I hope I don’t need to explain that this tactic is
not the best. Another kind of cheating I’ve heard of, but hopefully never had seen in
person, is asking a more experienced friend to participate in the interview instead of
the actual candidate. I don’t even understand why one wants to do so. Even if one
gets a job this way, he or she will most likely not succeed in it, if the requirements
were above his or her skills. Also, what if another step of the recruitment process will
be in person? The cheating will be revealed, and the candidate will be totally
compromised. Again, just not worth the risk.
3) Being late or not showing up at all. I hope this one doesn’t need an explanation. If
you have an emergency, at least send a text with information about that and ask for
rescheduling. If you changed your mind about participating in the interview, just call
the company and cancel it.
4) Showing a lack of interest. As mentioned before, showing that you don't care about
the interview or the topics that are being discussed is a bad omen. You will most
likely not be interested in the work you will do and the applications you will be
responsible for. Also, if you are not interested in programming, there is little hope that
you will actually keep improving yourself in this area while working.
5) Lack of respect. For me, the interviewer and the interviewee are in equal positions
and should be respectful towards each other. I don’t mean to give you a lesson on
manners, I simply want to warn you to not be a pain in the interviewer’s neck. When I
was conducting the interviews, I had a couple of unpleasant situations, from the
candidate yelling at me, through the candidate saying that my questions are stupid,
to even the case when the candidate was intoxicated. I probably won’t surprise you
by telling you that they didn’t get the job.

DIFFERENT INTERVIEWS FOR DIFFERENT LEVELS OF

SENIORITY

As your career progresses, and you advance from junior to mid, and from mid to senior, the
interviews you will participate in will change too. In this lecture, I will describe what they look
like in most typical cases.

1) Entry-level or Junior. Although different companies define Juniors differently -

sometimes as someone with no experience at all, and sometimes even with up to 2
years of it - the profile of a Junior is always similar: it’s an unexperienced developer
who will most likely need a lot of help and for some time will not be fully self-reliant.
The truth is, most companies are not even expecting the juniors to bring any revenue
in the first weeks or even months of their employment. They look at juniors as
investments - they hope that with proper guidance a junior one day will become a
 valuable developer. Because of that, during the interview usually, there are not so
many purely technical questions - sure, there will be some, to verify if the candidate
has the basics of the technology he or she will work with, but no one expects the
junior to know every quirk of the programming language, or to be able to explain the
most sophisticated mechanisms of it. So, make sure to be well-prepared with the
basics, and don't worry about the most complicated and tricky questions. It might be
a good idea to search for phrases like “junior interview programming questions” as
some of them are repeated throughout most of the interviews. For example, one of
the most common topics during interviews, no matter the language, are SOLID
principles.

We said that the employer looks at a junior as an investment. But how can it be
verified if such an investment will pay off? Well, the interviewer must evaluate a
couple of things: if the candidate is passionate about programming and is willing to
keep learning if he or she is open-minded and will easily and willingly absorb the
knowledge the team members can share. We will talk more about those topics in the
next lecture when we will discuss non-technical questions. For now, just remember
that as a junior, you should present yourself as a person with a passion for
technology and a zeal for learning, as those are the traits the employers search for in
candidates with little or no experience.

Also, if you linked a portfolio to your CV, you should expect that it will be discussed
during the interview.

2) Mid-level. This is probably the widest category of developers, for some people
covering programmers from as little as 2, to as much as 7 years of experience.
Because of that, many people like to consider themselves mids earlier than
employers would do. That’s why mid interviews are usually the most technical - the
interviewer wants to verify if you truly have the mid-level of knowledge and
experience that will guarantee that you will be able to perform tasks by yourself, or
with little help from senior developers in case of some hard cases. Also, as a mid
developer you will most likely be a teacher for the team’s juniors’, so it’s important
that you guide them properly. So during the mid-level interview expect to be asked
questions from all levels - the easy ones, to make sure you have solid bases, the
medium ones to see if you are truly a mid, and hard ones too, to see how you deal
with the pressure and also if there are any topics that you are particularly interested
in and thus good at.

Also, you will definitely be asked about your experience, how you contributed to the
projects you worked on and what were your achievements, as well as what are your
plans for further development. As a mid, you still have plenty to learn, so be ready for
questions about favorite books or other sources of knowledge. We will talk more
about that in the next lecture.

3) Senior-level. Seniors are experienced developers, that should be ready for taking
responsibility for the hardest parts of the project, as well as guiding less experienced
team members. The senior-level interviews vary very much. Some employers, who
want to hire someone with extraordinary technical skills, will make sure a lot of hard
 technical questions will be asked during the interview. The questions will most likely
go beyond plain language-specific topics and will touch on matters such as
architecture, system design, etc.

On the other hand, I’ve been interviewed for some senior positions in .NET, when not
a single question related strictly to this technology was asked. This is not unusual. If
the candidate has many years of experience and worked on many projects, it can be
inferred that his or her technical skills must be really good. Such interviews are often
more focused on describing projects from the candidate's experience, but unlike
Mid-level interviews, you should expect detailed and in-depth questions about the
architecture, challenges, and most of all - what was your role in handling them. It is
often expected from seniors to take a guiding role in the team, and to show a lot of
initiative when solving issues - not only waiting to be told what to do. Also, many
employers want to check if the candidate would be a match to take even more
leading roles, such as tech leads, or managers. In this case, a lot of questions related
to team management, personal issues solving or relationships with clients can be
asked.

COMMON NON-TECHNICAL QUESTIONS

Even if you are invited for a technical interview conducted by a developer, you should expect
some questions that are not purely technical. I of course don’t mean things like a discussion
about hobbies or expected salary, but rather the questions that are not meant to expose your
knowledge but rather your areas of professional interest, aspirations for development, or
personal traits that are desirable for candidates. Many people don't really get ready for such
questions before the interview, but this is a big mistake. Even if the purely technical part
did not go so well for you, you can still show yourself as a valuable addition to the team
during the less technical part. And the opposite - you might have nailed the questions about
the language, but then it turns out that you’ve never read a single programming book, you
dislike learning new things and you secretly hate coding.

Let’s go through some of the most common questions from this area:

1) What’s your favorite book about programming? For this question, there are only
two bad answers:
a) saying “I’ve never read any book about programming”
b) lying that you’ve read some book and then not knowing what it was about.

So, do yourself a favor, and even if you didn’t really read a single book about
programming, do it before the interview. Even if you prefer to learn from videos or
tutorials, it’s still often considered that the person reading books about some topic
treats it more seriously. If you have no idea where to start, I would recommend you
read at least “Clean Code” by Robert C. Martin, which is one of the most popular
books in the programming community. It is a bit of an obvious choice, but on the
other hand, it’s lightweight and you can read it in a couple of days. Of course, you
can also pick something a bit more advanced, and not only gain some in-depth
knowledge but truly impress the interviewer. Make sure to have an opinion of it, as
 the interviewer will most likely ask you what you liked about the book, and if there
was something you did not agree with.
2) What's your favorite source of knowledge? This question is a bit similar to the
previous one, just more generic. Again, any answer except “none” is good: you can
mention learning on Udemy, a favorite programming blog, or a Youtube Channel
about programming. Again, be ready to not only mention the name but discuss why
this particular thing is your favorite.
3) Why do you want to change jobs? This question is very likely to show up during
the interview. Don’t sweat about it - it’s usually just an excuse to discuss your
ambitions, aspirations, and what your dream job would look like. Make sure not to
make it negative - don’t say how much you hated your last manager or how terrible
the project was. Focus on the future - for example, say that you seek a chance to
develop your programming skills, learn from experienced developers, etc.
4) What are your strengths/weaknesses? The question about strengths is a great
opportunity to do a little marketing of yourself. I won’t tell you what you should say
exactly, just try to be genuine and not say anything completely generic. For example,
I usually say that my strength is that I like teaching other people and that I don’t mind
taking responsibility related to that, whether it is conducting training or introducing a
new member to the project.

The question about weaknesses is a bit more tricky. First of all, don't say anything
like “my biggest weakness is that I am too passionate about programming” because it
will just cause the interviewer to roll his or her eyes. Say something true, but also
mention how you deal with it. For example, I usually say that my weakness is that I
have a bad memory and struggle with remembering pieces of information, but
because of that I developed a system of notes that works great for me.
5) What is your dream project? This is another question that is meant to check your
attitude towards programming but also to get to know you a little bit better. Try to be
true to yourself, but realistic. Don’t say things, like “a project where there is no
interaction with anyone but other programmers” or “a project where requirements
never change” as this shows that you might not be happy with real projects, where,
well - there are always some other people to deal with, and requirements always
change (and we, as programmers, should be ready for that). For example, you can
say that it would be a greenfield project in technologies X, Y, and Z, with a precise
and accessible Product Owner, a lot of time for tests, refactorings, and
improvements, and a team that you can learn a lot from.
6) How do you deal with conflicts within the team? Questions like that are quite
popular, especially for senior-level candidates, as they are often expected to take a
leading role within the team. The expected answer should be, as you probably guess,
focused on calm discussion, proposing solutions, working the issues out together as
a team, etc. You might be also asked about an example of a conflict from your
career, and how you dealt with it. It’s a good idea to prepare for this question before
the interview, as it will help you pick the situation when the conflict was indeed
mitigated and solved in a cultural manner.
7) How would you convince the business owner that backups are important? This
is just an example of a question, but it can be about anything else - how would you
convince that unit testing, refactoring, or training are important. The purpose of this
question is to, firstly, see if you also consider those things important (tip: if the
 interviewer asks this question, he or she most likely expects you to agree with that)
but mostly how can you communicate with non-developers. This is again a category
of questions that seniors are more likely to hear. As a senior member of the team,
you will often be expected to be a link between the development team and the
business, and the person who explains technical topics to non-technical people. This
is not an easy task, and if you are 100% sure you don't want to do that, you should
communicate it clearly before accepting the job offer, so there are no
misunderstandings later. From my experience, discussions with business people are
easiest when both sides operate with common, non-technical language, and when
proper examples and risks are clearly shown. For example, when discussing
backups don't go into details about how they work in databases. Just explain what
“backup” means, and show what could be the consequences when the backups
would not be performed, for example, that if the client would experience a power loss
in the office, the results of a couple of days of work could be lost.

There were just a couple of examples of non-technical questions. Under those links you can
find more detailed articles about that.

https://indeedhi.re/3vJ9Jkk
https://bit.ly/38UoiZh
https://bit.ly/3N9CZa3
SECTION 3 - BEFORE THE INTERVIEW ENDS

BEFORE THE INTERVIEW ENDS - THE INTRODUCTION

At the end of each interview, there is time for your questions. Use it. The interview is not
only about checking if the employee will be a valuable addition to the company, but also if
the company will be a valuable addition to someone’s life and career. If the interviewer did
not reserve any time for your questions, ask for it. If they refuse, you may want to not take
this job. If the company doesn’t care about your questions and your needs now, it will not
care about your well-being in the future.

Asking questions has one more great benefit, other than letting you find out if the company is
worth your attention - it again, shows you as an engaged professional, who cares about what
kind of job he or she will accept. If you don’t ask any questions, it looks like you don’t care,
or perhaps you already accepted another offer and came to this interview only as an
exercise.

From what I observed, the more experienced the candidate is, the more questions he or she
asks. Having already worked at several companies makes developers realize what can be
good, and what can be bad at work. The experienced developers know what kind of projects
they feel good at, so they want to make sure the next project they join will meet their
expectations.

What questions exactly you should ask heavily depends on the profile of the work you are
going to do, and your personal choices and preferences. That’s why I will only show you
some of the questions that are frequently asked by candidates, but please treat them only as
suggestions. It’s a very good idea to prepare your own list of questions before the interview.
Write them down and take the notes with you to the interview, leaving some space for the
answers.

BEFORE THE INTERVIEW ENDS - YOUR QUESTIONS

Here are some questions you may want to ask before the interview ends:
● “What does the introduction to the project look like?” Each company should
have a plan for introducing new employees to the project. Whether it is by assigning
a “buddy” who takes care of you, or by some targeted training.
● “Is there a training budget?” Good companies reserve some money for employees'
training. Also, asking this question shows you as someone who wants to continue
learning, which is always a good thing.
● “How experienced are the people I will work with?” Be careful with companies
with teams composed only of juniors. You want to have some experienced
developers on board, so you can learn from them and also count on their support.
Unless of course, you are meant to be the team’s senior or lead, but still, you will
want to have some mids in your team, or ideally another senior too.
● “What is the average length of time the employees stay with this company?”
This is an important, but also a tricky question. If this time is long - let’s say, more
than 3-4 years - it is great news for you. People stay long in companies they feel
good at. If this time is very short, run away. Also, be careful - this is the question
some unfair interviewers may want to lie about because they know very well that if
they say “5 months” no one will want to join them.
● “Should I ever expect overtime? If so, how is it compensated?” A lot of overtime
is always a bad thing, not only exhausting for employees but also showing that
something doesn’t work in general in the company. Some overtime may happen in
companies that are not necessarily terrible, especially startups, but it should not be
treated as something normal. I know some people who don’t mind the overtime,
especially if it’s paid extra. What answer is acceptable for you is a matter of your
personal preference.
● “How many hours of meetings a week should I expect?” For me personally, this
is the most important question of all. I don’t accept the overgrowth of meetings. If the
interviewer tells you there will be a lot of meetings, be very careful. Ask why is that
so, and what makes them necessary. It may be a case when they really are, for
example, if the project is very new and there are a lot of important decisions being
made every day. But from my experience, a lot of meetings usually mean there is
some underlying issue with how the project is organized.
● “Do you work in Scrum or any other agile methodology?” Not everybody likes
Scrum, but it’s worth asking if it is used, no matter if you are a fan or the opposite of
one.
● “What format is your documentation and how complete it is?” How important
this question is highly depends on what project you will work on. I am not a fanatic
about documentation. When it comes to code itself, I believe it should be
self-documenting, unless, of course, it implements some complicated algorithms or
business rules. But when it comes to the documentation about using internal tools,
integrating the project with others, and also the manuals given to the users, I think
they are valuable and it is a good sign if the company keeps such documentation
complete and up-to-date.
● “Do you have any way of encouraging the developers to use good coding
practices?” This question is great to see if the company cares about the quality of
the product.
● “How is the code review performed?” If you hear the answer “what code review?”
best run away. Code review is a crucial practice, and if a company can’t find time to
perform it, it is a very bad sign. You would probably end up working on some messy,
ugly, unmaintainable code. It’s not worth your time.
● “Do you have any coding workshops, like Coding Dojo?” If they do, it’s a great
sign. The company reserves time for employees' development and cares about code
quality.
● “What is the test coverage? What kind of tests do you create for your
software?” If they say there are no tests at all, better choose another company.
Tests are important. They give you the certainty that the code does what it is
supposed to be doing, and also allow you to refactor it without fear, thus keeping the
quality high in a long run. What kinds of tests exactly are done is more
project-specific. I usually expect at least solid coverage with unit tests, and ideally,
some integration, regression, or manual tests too.
 ● “How long does it take to compile the application I will work on?” I started to
ask this question after I shortly joined the project that was so huge, that the
compilation was taking over 40 minutes. It was driving me insane.
● “If I want to use some specific IDE or a plugin, like for example ReSharper, will
the company pay for the license?” This question can show if the company is
supportive of the developer’s needs, and is able to spend some money on it.
● “What will I learn here?” The question that I noticed first surprises the interviewers
very much, but in the end, they are most often happy to answer it. If the company is
in a good shape, with the right team structure and some time reserved for
development, they should easily answer this question in a way you will like.
● “If I don't like the project for some reason, will I have the opportunity to switch
it to another?” This question is not always applicable, for example, if the company
only creates a single project. But for larger companies, it’s always good to know that
in case of a project we just don’t like, we can have an alternative to it.
● “If the team notices the code quality is degrading and the technical debt is
growing, will there be the time to stop adding new functionalities and improve
the existing code?” This is another question that can tell you a lot about the
company. If they seem to not like it and avoid the straight answer, it is a bad sign for
you. If the company cares about the code quality, as well as the developers’
well-being, it will find some time to improve the code. Of course, they are situations
when it is not possible right away, for example, if there is a very short deadline to
deliver the product to the client. But in such a situation, the company still can plan
some time after the delivery to improve the code before releasing the next version.
● “Can we now take a look at the source code of the project I will work on?” This
is perhaps the best way to find out what will be the quality of the code you will work
with. When simply asking questions about quality, the interviewers may lie. The code
doesn’t lie. If you take a look into it and see a big pile of mess, you know right away
what awaits you in this company. On the other hand, if you open a random class, and
you see a neat, nice code with full unit test coverage, you will know it is probably a
good place to be. One remark - not all companies will allow you to take a look, not
necessarily out of a need to keep you in the dark, but rather due to confidentiality
policy. Nevertheless, it’s always worth asking.

Please notice that most of those questions are somewhat technical, and it’s best to ask a
developer to answer them, ideally one that works on the same project that you might. If no
such person is present during the interview, don’t hesitate to ask for an extra meeting.

There are also a couple of less technical questions you should remember, like:
● “What are the non-wage benefits?”
● “Is there the possibility to work remotely?”
● “Will there be a need to travel?”
● “What will I need to do to get a promotion?”
● “What is the career path for this position?”

Remember, the interview is not only for the company, it is also for you. Ask all the questions
that matter to you, and don't hesitate to take time for that. Choosing a job without actually
checking if it has a chance of being a good place for you may result in either suffering there
for the next couple of years, or quick change of it for another, which doesn't look very good in
the resume. On the other hand, careful examination of the future employer may lead you to
have a wonderful, interesting job that you will be satisfied with, and that will let you become a
better programmer.

CODING INTERVIEW CHECKLIST

All right! We are almost at the end of this course. I know it has been a lot of knowledge.
Don’t worry if you don’t remember all those things I said you should do or prepare before the
interview. To make it easier, I created a checklist for you:

https://bit.ly/3MV8sN4

I want you to be able to edit this document, so you can modify it to your needs. To do so, you
must simply select File -> Make a Copy.

And there you have all the things that if done before the interview, will make it much, much
easier for you.

Good luck!
 FINAL WORD
Thanks for reading this ebook! I hope it will
help you during your next interview.

Check out my Udemy courses:

Get Ready for Coding Interview

Link: https://bit.ly/3LNjxj5

C#/.NET - 50 Essential Interview

Questions (Junior Level)

Link: https://bit.ly/3hSRpOq

C#/.NET - 50 Essential Interview

Questions (Mid Level)

Link: https://bit.ly/3sC7FsW

LINQ Tutorial: Master the Key C#

Library

Link: https://bit.ly/3HqGR33