How To Prepare For A Technical Interview

As an engineer (or an aspiring one) you will be faced with several controversial situations when looking for a new job.

Being an engineer as well, I have been in the same boat as you. And I had to develop some little tricks to overcome some difficulties that would eventually appear in my job search.

Today I want to share them with you along with some other thoughts on how to face these kinds of situations. This might even be helpful for recruiters or interviewers to help them understand which points they might get better in their process as well.

So let me start with…

1. Hiring process length and pathway to a proposal

Inquiry about what are the steps until a final proposal is made. It is important to know because if you were trying to apply to different companies, you would need to conciliate time to prepare and rest for each one. Yes, you need to rest as you don’t want to have interviews 30min, one after another, for a straight week. Believe me — you will not want to.

In the first HR interview be as well ready to answer the most known cultural fit questions like:

Can you describe a situation in your latest job that you think you did well?And one that you did bad? What do you think you should have done instead?How would your co-workers describe the role you play on a team?Do you prefer working alone or as part of a team? What percentage of your time would you allocate to each, given a choice?What is your worst defect?

2. Wages

State which salary you are looking for from the beginning. It will save time for both of you. Having clear values from the start will help the recruiter to know if your value is totally out of his budget or if with a little accommodation he might be able to fit you into his budget.

Do not forget to state if the value you have referred already does include taxes or not (you got to do the math for the country you are/will be working for), as this may lead to misinterpretations down in the road and no one wants to break down an offer after 5 or 6 stressful interview phases.

If you are not sure on which salary to ask, you should at least ask for more than what you are currently earning. Otherwise, if the proposal is smaller and you don’t have any good reasons to leave (like a toxic environment), then you would be better off staying where you are.

3. Trivia

If haven’t had one of these yet famous Trivia Questions, you might be surprised that such a thing would exist in an interview, but it does!

Some example of trivia questions you might find would be something in the lines of:

1. The probability of finding the parking slot occupied is 1/3. You find it empty for 9 consecutive days. Find the probability that it will be empty on the 10th day.
2. Mad Ade is waiting for the local Kebab shop to open. He glances at his clock and notices the time is 3:15 pm. Out of sheer boredom, Mad Ade works out the angle between the minute and hour hand. What was the angle between the hour and the minute hands at 3:15 pm?
3. How can 8+8=4?

Usually, the recruiter would tell you about such kind of stuff when providing you details for your phone/in-office interview. In that time you should ask for previous examples of similar trivia questions they have used before. Much probably they will not be the same, but it doesn’t hurt to make a few exercises on it just to get the feel of what you might get asked.

The purpose of these trivia questions is usually to understand how you think logically and how you build up your rationale. In my opinion, these don’t make much sense, as you are doing these in very unnatural and stressful conditions like an interview.

No matter what you do, whenever you are faced with these questions, talk out LOUD, ask questions(!), don’t be afraid to tell exactly what you are thinking, even if it is the most non-sense you might come up with, it might lead the interviewer to provide you a better direction on finding the answer.

4. Take-home assignment

When someone sends you a home assignment, before starting it, be sure it is explicit and you totally understand the deadline, any required languages/frameworks, the goal of the exercise, and which boundaries you should use.

Knowing the boundaries of the exercise will help to know if you should just create a suboptimal function that gets the job done or if the interviewer wants to see a more elaborate approach and understand how you document and create tests for your code.

Watch out for possible traps in the materials the recruiter gives you like malformed data or a web service that might be returning an error. The recruiter might be testing how fast you will be able to overcome a setback.

In my opinion, a good assignment would be one that would take at most 4 hours to complete. Later on, the code would be evaluated in a code review between the candidate and the interviewer, so the interviewer can understand the design decisions and the chosen trade-offs. It might be nice to know which additional improvements would the candidate like to make and how he would do them if he got the time. 

Keep in mind that the main purpose of a take-home assignment is to asynchronously evaluate a candidate without having to schedule an interview, as a first-stage filter.

 🙋‍♂️ Personal Experience Like I have said: state your boundaries!

I had to fly to London once for an interview and they asked me to architect a system. They barely provided me feedback while I was explaining it to them. They ended up declining me with the excuse that I ”complicated too much”.

After a few months, I had an interview with a Portuguese company. To prevent the same mistake, I asked the boundaries to which they replied with a ”do as you please”. Once delivered, I received a ”you should have done harder”.

You will not be able to please everyone, but knowing from the start what to expect, will help you in the long-term and help keep you sane knowing you did your best and what you were supposed to.

5. Knowing obscure functions

Before even applying for a job, read every single thing in the job description and with which technologies you will be working with.

If the languages aren’t mandatory, explicitly tell the recruiter (in the first stage) which languages you are comfortable with. However, you still might face such an interviewer that would want you to know what the second argument should you pass when invoking strange_function_name_here() and what it does return.

My recommendation here would be to study the main functions of your programming language of choice.

From my experience, the interviewers asking these kinds of questions either are trying to understand which skill level are you in (junior, mid-level, or senior) or are trying to find an excuse to put you out of the interview process. And, I can tell you that if it is the latter, you will be able to see that coming yourself and there is nothing you can do to counter it. Anyway, I assume you would not want to work with such toxic colleagues.

In the end, don’t worry because no matter how well you know a programming language, there will always be something you don’t know, and even then, tech interviews are done in an unnatural condition with little to motivate someone into thinking straight.

 🙋‍♂️ Personal Experience I’ve been to an interview where I have been bombarded with questions regarding some very deep specific PHP functions.

I knew a very specific function that did what I was asked for, but as the 3 interviewers did not know about it they kept telling me I was wrong. As I insisted that I was totally sure I was correct as I used that function daily, after a few minutes they really did Google it, and, for their sadness, they conceded I was right.

Sure, it doesn’t hurt to know such functions, but it will not be them that will define if you are a good engineer or not. As a colleague told me once ”I’m paid not because I know to code, but because I know how to search” (do not take it literally, please — it is a reference!).

If you like what you are reading, subscribe here to get more content like this.

6. Algorithms

This one has been the highest hyped interviewing method in the latest decade. With the appearance of the next big thing every day, every new company (and startup!) deems they should judge all their candidates based on their LeetCode ability instead of their human ability (more on that later).

As much as I would like to criticize this one, I might consider it acceptable for a FAANG to do it taking into consideration the business complexity, but it would not be a thing I would see a startup doing.

If you want to get deep with Algorithms, then you will need to overcome yourself. You should keep practicing them every single day until you can crack LeetCode so easily by identifying what patterns do the problems you solved may have in common. For this one there is no easy solution as you will need to invest a lot of your time practicing.

One of my suggestions would be to grab your copy of Cracking the Code Interview that is an awesome book.

In the end, the company will have the final word. Either they hire you because of your algorithmic skills or they do because of your business domain knowledge and your ability to learn and grow as a professional. LeetCode skills are mainly a good way for a FAANG to quickly rank a bunch of candidates in an hour. If startups are doing this, they end up discarding a bunch of good candidates.

And yes, you probably would not use these same algorithms in your daily job even if you do need to interview using them.

Links worth checking out:

1. https://leetcode.com/ — Algorithm exercises
2. https://www.hackerrank.com/ — Algorithm exercises
3. https://binarysearch.com/ — Learn algorithms together
4. https://www.coursera.org/learn/algorithms-part1 — Algorithms Part 1 from Princeton Universit

7. Boundaries

You will eventually end up facing some awful interviewers. You will easily recognize them by their attitude. They will usually ask you something but won’t let you finish your sentence. Will claim whatever you are saying is wrong and won’t let you explain your rationale neither explain to you why ”you are wrong”. They want to make you feel like crap and you can see in their face they have better things to do at that time and that you are wasting their time.

If you face a situation like this and you want the job, I’m sorry but I don’t have good news. I haven’t been able to break such a situation myself.

The people who are worth it at the senior level, are employed — happily or at least satisfied enough to not leave immediately. Maybe not doing the best, most advanced, or coolest work — but they are respected in their workplace most of the time, and getting them to leave is hard. For a junior, it’s tougher. You don’t have the same self-confidence since you haven’t been there. Just don’t treat yourself like a walk in rug. If interviewers are going to be aggressive, or demean you — their office environment probably isn’t much better. Believe in your self-worth, enter interviews with confidence, be polite, and when appropriate, stick it to the man.

I don’t know how you work with your team and your workmates, but if, when facing a work task you are trying to screw each other instead of trying to build a rational solution to the problem at hands, then, are you sure that is the kind of team you are looking to join?

State the boundaries in the interview and if something smells off, time to leave!

8. Whiteboard

In these specific problems, you are asked to start coding in a whiteboard the solution to a given problem.

This is the most stressful interviewing situation I know of and this is where you need to keep yourself calm and embrace your interviewers as your team colleagues, like if you were already part of the team and were working together through a solution.

Take some notes on what the problem is (draw, write, whatever!) and keep asking questions on what kind of divergences you see on the problem you have been given (for example different type of data you need to treat, duplicate data, unordered data, hardware limitations regarding the data size, other possible scalability limitations you might encounter using your solution, alternative solutions, etc.).

If you are asked to start writing some code, take attention to the following:

1. Don’t get lost on the semantics of a coding convention. The interviewer does not care if you write my_variable instead of myVariable.
2. If you don’t know a formal diagramming language such as UML, don’t worry and just draw! It is much easier for the interviewer to understand pictures of something than to think in the abstract.
3. Specify/draw the big scope of the problem and the inner scopes that make up the big one. From there, develop a conversation with the interviewer and understand which scope is he more interested in. Listing the scopes might help you (and the interviewer) see other once unknown issues with the problem at hands.
4. Be prepared as these interviews are not easy and will keep you out of your comfort zone, putting you in an uncomfortable state. One thing that usually works good in these is injecting some side discussion that you can drive. This little thing gives you an overwhelming feeling of being in control and helps relax you.
5. Pay attention to the constraints that have been given to you — and write them on the whiteboard to keep conscious of them. These were given to you for a motive and you need to build your solution with them in mind.
6. If you have been given a problem that looks like you need to solve more than one different place at once, always ask if one of those problems is solved by some other API that you can assume is included. This is a good question to know if you might use known solutions or you will be constantly inventing new code. This is a trick question for both the interviewer and the candidate, so use the answer to your advantage!

9. Pair-programming

When I interview (and get interviewed!) for me, this is the most important thing to do.

For starters, please do have your workstation totally prepared to start writing code. You don’t want to fiddle with a language compilation error or a database not reachable in a stressful environment such it is an interview. A Dockerfile/docker-compose setup with a pre-installed framework+DB might help to have things rolling faster.

You would usually be asked to solve a specific problem that the company is having difficulties with or even have already solved, with the goal of seeing your approach on edge cases and how you think about the issue at hands.

Along with the exercise, you should be able to clearly communicate your line of thought, even right before starting to code.

Go through this like if you were right beside your colleague at the office and you needed to start working on such a problem. The first question should be how much time is assigned to the pair-programming exercise. This will help decide if you should take some shortcuts or not. From there, the basics: where would you start? Are there any specific requirements? Any specific restrictions?

Tell your interviewer which do you think would be the better approaches to solve the problem and the issues you might find using each one. Ask the interviewer if you should elaborate on how you might solve each issue at a later stage if the need may come.

It is crucial that a candidate understands the impact the code written today might have in the future. A company does not want a coder. A company wants a solver.

Explain everything to your interviewer. Why you are using an existing library (and how are you choosing it) or why you are creating everything from scratch, why you are creating a new class, a new method, fixing a specific issue, etc. It will tell your recruiter how organized is your mind.

Try to be completely comfortable. Usually, the interviewer will just watch your process, but feel free to ask questions. Be ready to be called out to stop when the time is up and be ready to provide an explanation on which would be the next steps on the code and any kind of improvements you eventually would like to add.

10. Your Speech and Posture

One of the things that really changed me when interviewing was: when starting an interview, keep reminding myself to take the interview like it was a conversation with a group of friends.

Try to have some special attention to your posture. Don’t cross your ankles neither jiggle your legs as it projects nervousness and anxiety. Keep your feet pointing directly at the interviewer.

If you do not know how to stand in the chair ”to appear calm”, mimic the interviewer’s posture.

When an interviewer asks you something that you don’t know, don’t explicitly say “I don’t know”. Refer that you didn’t have an opportunity to work with such a thing, but, you would be eager to learn about it if you were given a chance.

Try to not worry about the outcome. In the worst case, you gain experience. Remember all the past stressful but worthy learnings and accomplishments you had on your career and think like, ”I totally know my stuff and I have done amazing things already, what kind of business problems are they facing that I might help them with?”. This seems kinda arrogant but should be seen as a way of keeping you confident while being put in the lion’s cage with 2 or 3 interviewers at the same time, each one judging you in their own way and pointing fingers at everything you say or do.

I agree it is uttermost stupid of having to think about all of this foremost, but if your mind is not used to seeing an interview room as a friendly place, this will help you in your next interviews to keep a more friendly mindset.

Interview when you don’t need it. Interviewing is hard and it will make you feel like trash. Interview as many times you need until you start not minding the outcome. When that happens you start being ”yourself” in the interview and whether you pass or not, it is just one more.

Make a list of companies that you are interested in and start interviewing for the ones you would rather not work in first, so you can get the feel of what really means being in such a stressful position and at the same time be able to train your interviewing skills without burning yourself.

Do not ever, ever make stuff up or talk about things you don’t have that much experience with. If your interviewer is a picky guy, he will literally crush you on that. He will pick every open sentence you make and if he feels the minimal insecurity of you in any of the things you say, he will want to know everything about that… and when you enter that hole, he will not let you leave it. And it will be stressful, believe me. Don’t try to be the smart guy in the room. Be solely honest.

Keep attention on the face of the interviewer and how he reacts when you talk about your past, specific technologies, and projects you were involved in. More times than not you will be able to understand what triggers more his curiosity. That might embrace yourself in a nice conversation about a specific technology you both have worked with. That connection will help to build a nice ambient for the rest of the interview.

You will find interviewers that will ask you a hell amount of questions, asking you to expand in each one, and in the end, they will eventually refuse you because… ”you talk too much”! Yes, it does happen. Move on!

11. Final questions and feedback

Usually, at the end of a process, you will be asked if you have any questions that you would like to have clarified. In a perfect scenario you had studied about the company, checked your job description in-depth and know by heart the stack you will be working with, and even had a glimpse at the description of the other engineering positions from the company, so you could understand what other pieces of stack they might be using.

You should use the questions time to ask more about some specific stack decision they have made and why they made that choice. For example, why did they go with PostgresSQL instead of MySQL? You can even add when asking the question ”was it because of X (e.g. PostGIS) as you need to handle spatial data?”. That will make you be seen as someone who knows what talks about, and not only asks about the company but knows when some tech decisions make more sense than other ones. Big plus here!

Regardless of the result, the most precious thing you may get out of an interview is the feedback.

Never ever discard an interview outcome (whether it was positive or not!) without having some kind of feedback.

You need to understand what you have done well and what you should prepare better for the next time. An interview is a compromise between the candidate and the interviewer, and the candidate’s time is as much important as the interviewer’s one. 

Respect each other and provide prompt feedback — yes, apart from the candidate receiving feedback from the interviewer, the candidate should provide feedback too on what went well and what should be better (believe me, someone will read it).

If you receive an automated e-mail response, ping your recruiter or your point of contact to understand your situation.

Keep in mind that when you receive the feedback you should acknowledge it and move on. Don’t try to use it to fight back on the interviewing company — you will get nothing of it.

I know there are times you might question your self worth as an engineer, but you should move that energy to keep learning and improving yourself. That is why feedback is of utmost importance so you can understand what to delve into.

Keep in mind that the luck factor in interviews is HUGE. Keep your chin up and keep doing them.

Final Notes

For recruiters: I hope this post gives you some ideas on what you should consider when recruiting. If you have the perfect conditions, giving the candidate multiple options as to what he would prefer would be the best (like a take-home assignment for 2–4 hours or a LeetCode session for an hour)— not everyone has plenty of free time to spend in a take-home assignment. From there you would go on and see if you are a match. It is of utmost importance to understand if you would like to be working together in the next few years.

In my personal experience, the best candidates have always been the ones that show the most passion for building, creating, and hacking things for others. You might argue that that would sometimes mean they might not be the best programmers in the room, sure, but programming is an art and can be learned if you love what you do and you have the right attitude.

In the end, if you were not able to solve any of the interviewing material, don’t worry! I guarantee you that a lot of times even the employers of the interviewing company are not able to solve them as well. Keep trying and if you don’t get an offer at that big company you are applying for, keep trying on other companies from your list. Much probably you will end up with a better paying job in a different company that respects you more.

If you liked this post subscribe here to get more content like this, follow me on Twitter.

This post was originally posted on ivopereira.net.