6 Interviewing for your place on the team
- How the interview process works
- What to expect from a technical interview
- Things you should and shouldn’t say during an interview
- What to expect from a job offer, and how to sort good from bad company perks
Learning a programming language and its associated best practices is only one step on the journey toward getting your first tech job. If you’re just starting out, and you’re unable to show actual experience for the position you’re applying for, a good CV will only take you to the first interview. After that, you’re on your own, which is not a bad place to be, but it’s important to understand how the interviewing process works and what to expect from it.
Different companies have different hiring processes. Some of them will only perform one interview and make a decision, while others can take up to a month of interviewing and testing. There is no standard, but there are certain patterns of what you’ll find and how you should behave (what you should say or avoid saying), which is what we’ll tackle in this chapter.
By the end of this chapter, you should understand how the interviewing process works in our industry and some key indicators that will let you know whether a company is right for you or not.
6.1 The tech interview experience
Going for your first technical interview can be nerve-racking if you’ve never been through a similar process. Actually, scratch that—I’ve been to quite a few interviews in my 18 year career, and I still get the jitters the day before the interview, so why wouldn’t you? After all, we’re being evaluated by a complete stranger who doesn’t really know us and who has probably not even read our full CV.
The thing you have to remember is that during your interview, you’re not just making sure that this person gets to know the “real” you, but you also have to get to know the company and the workplace through that person. This is a two-way interview, even if you weren’t told this before.
Let’s assume you’ve applied to your first tech role and have successfully booked an interview. It’s for a company you’ve been eyeing for a while—one that provides services you use daily, and you’d love to work for them. What’s your strategy for the interview? Because, yes, you’ll need one. Are you planning on saying yes to anything and everything they say? Are you going in with a set idea of what you want, and you won’t accept anything less?
Let’s cover the basics of what you’ll go through and what you can expect from a first technical interview.
6.1.1 What can you expect from a tech interview?
Expectations, expectations, expectations. It’s all about expectations. If they’re not realistic, your whole experience will be ruined, no matter what you’re trying to do. This is why you need to have your expectations grounded before you go into the interview process, especially if it’s your first time.
There is no standard when it comes to interviews. Each company will have their own set of practices to follow. Technical interviews usually happen after you have a first personal interview with a human resources (HR) person. They will create a generic profile based on your answers, gather some basic data about you and your experience, and send it to the tech interviewer who will decide whether they want to interview you or not. Some companies, however, will mix both interviews into one and have two (or more) people asking questions and getting to know you, or they’ll just go from one session to the next on the same day.
I’ve had some (although not many) interview processes that lasted for four hours due to them arranging different people to have different types of conversations with me. First I’d get the HR person, then a psychotechnical test would be performed to profile me, and then the actual tech interview would begin. While such long processes aren’t the norm, especially now with the possibility of performing the whole thing remotely, they could very well happen to you too.
The entire process is important, but the technical side of it is what makes it unique to developers (all other jobs have a first HR meeting, but none have a tech side like ours), so let’s focus on the technical part of the interview. There are different flavors for you to enjoy, and they have their pros and cons. Ask what the process is like, if you have a chance, so you can better prepare for the day.
Technical conversations are the ones I always like to have, and this is the way I like to perform the tech interviews myself. In a technical conversation, you’ll describe your own experience, highlighting the aspects you feel are most relevant for the position you’re applying for, and the interviewer will pick up on keywords and ask you to elaborate on them.
For instance, something I usually do when a candidate mentions they’ve worked with microservices or APIs is ask if they know what REST is. If they say “Yes,” I try to go deeper with “What is considered a RESTful API, then?” So you have to be careful what you say and how you describe your experience. If you make it sound like you’re an expert and you barely cover the topic, expect to be asked to explain in more detail.
As part of any job application, we tend to lie or stretch the truth as much as we can. In fact, in 2019 the folks at Blind (www.teamblind.com) ran an anonymous survey of 10,364 developers working for various companies in our industry. Of them, 10% confessed they had lied on their resumes to get their jobs.
Am I telling you to lie on your resume? Of course not. All I’m saying is that just like that 10%, you might be tempted to do so, and lying, especially if you’re just getting started, can result in you setting the wrong expectations for the interviewer.
Even lying by omission is a bad practice at this point. For instance, it’s common when writing a CV to list a bunch of skills and technologies you’re supposed to know. Maybe you’re trying to get a frontend developer position, so you list things like these:
For a junior role, that’s an impressive list of skills. The problem with this approach is that you’re playing with the truth. You’re not specifying how much you know about each one, so you’re leaving your interviewer to assume that part. If they decide to call you because they see this list and think you’re an expert on all of these technologies, it’s not your fault, is it? Well, it is, kind of.
I get it, it’s very tempting to play around with the details and leave parts to be figured out during the interview. After all, you want to get that chance to sit in front of your interviewer and show what you know. Right now it might seem more important to get noticed than to be accurate. But if you go and talk to the interviewer creating these expectations, they’ll be very disappointed when they realize the actual skill list looks like this:
When you lie, even if it’s by omitting details, the interviewer will expect an unrealistic amount of experience or technical knowledge from you, which will lead to disappointment. And it’s not their fault; they’re evaluating you based on the fake (or unfinished) profile you presented.
Be up front with your level of understanding of the tech stack. That honesty will pay off. If I see a CV listing a bunch of related technologies without further explanation, I’ll be concerned that this person is just adding things to make it look good. However, if they present the same list with their degree of understanding, I’ll see them as a developer who’s interested in multiple technologies, able to learn on their own and figure out the landscape of their full tech stack. I’ll see this person as someone who’s willing to learn.
It’s common knowledge that recruiters skim through your resume looking for keywords, to see if you might be a fit or not. They even do it on sites like LinkedIn and contact people for jobs using technologies they haven’t touched in years (it happens to me a few times every month). The truth is, if your goal is to get the interview, the details won’t hurt. Those who skim won’t be stopped by those details; they’ll just read the keywords you listed, but the interviewer will gain a more accurate understanding of your skills when they review your resume in detail.
To summarize, technical conversations are all about correctly managing expectations. You need to be careful about the way you describe yourself and your experience. Be honest about the things you know and those you don’t. Saying “I’ve never heard about it” or “I’ve read a bit about it, but I’ve never tried it” is a lot better than saying “Oh yes, I do it all the time, I just don’t remember right now.” Lies have short lives, and the less experience you have to cover them, the more obvious they become, so don’t lie.
Sometimes during an interview, after a short discussion (or none at all), you might be asked to solve a programming problem. They will probably give you a time limit, as well. I personally don’t agree with evaluating people in that way, because there is an added stress factor that has nothing to do with the job you’re applying for, thus rendering the results (especially negative results) unrealistic. However, declining to do the test will not help you, so while this is a less than desirable situation, you’ll have to deal with it.
Some companies will ask you to solve these problems directly on a whiteboard. In these cases you will probably be okay using pseudocode. After all, expecting you to remember a language’s syntax by heart is just plain wrong. However, it’s also a good idea to state that you used pseudocode to solve it—that way everyone understands that the syntax is just a placeholder.
If, on the other hand, you are asked to perform the test on a computer, there are a couple of options:
-
A testing platform—There are sites like Coderbyte (https://coderbyte.com/organizations), CoderPad (https://coderpad.io/), and HackerRank (www.hackerrank.com) that provide you with the ability to read a problem, code the solution, and test it against a limited dataset (the full potential dataset remains hidden from you). These problems are usually time limited and have a very narrow set of solutions, often focusing on very theoretical topics, such as understanding how a sorting algorithm works or how data structures such as lists or trees work.
-
A computer with the usual coding tools you’d use at work—Instead of giving you access to a testing platform, you might be given a computer like the one you’d get if you were to get the job and a problem to solve. These are usually simplified versions of problems the company faces daily, helping them assess more realistically how well you’d do. After all, it makes no sense to test how well you can reverse a linked list (as you would have to do in a testing platform) if you’ll never use them in your day-to-day work.
Either of these scenarios could happen with you coding alone or with someone looking at your screen or asking you questions about what you’re doing. It’s paramount that you understand a few things:
-
It’s okay to Google basic things (unless otherwise stated). Sometimes we tend to get nervous during these types of interviews, and, especially if we’re being watched, we think it will look bad if we Google basic things. That’s not the case—everyone Googles for help, and it’s unrealistic to deem that practice as “bad” or “unworthy of the role.” Did you suddenly forget how the syntax of the for statement is written? Google it! Or maybe how to pass an attribute as a reference instead of a value? Google it! It’s completely fine, and we do it all the time while working.
-
It’s not okay to Google the actual solution. While Googling for help should be allowed, directly Googling the “how to” of the problem you’re trying to solve would be crossing the line. You should avoid getting too close to that one and instead focus on Googling only for the related tasks that you don’t know how to do or don’t remember the exact syntax of.
-
Talk, if the interviewer is there with you. Do you know what the rubber duck technique is? It consists in using someone (or sometimes, something) to describe your actions. The purpose is to externalize what you’re doing as if you were having a dialogue with the duck. Of course, the duck’s not going to answer back, and you should not expect your interviewer to give you any meaningful replies either. However, hearing your ideas out loud will sometimes help you spot errors in your logic. This is a great debugging technique used by many developers around the world. I remember having a tinfoil duck on top of my monitor on my first job. My team and I would talk to it anytime we had a problem we couldn’t solve. It worked every time.
-
Your interviewer will not help you. While your interviewer may be there asking you questions, and they may, in some situations, reply to some of your comments, you should not expect them to give you clues as to what you need to do. Don’t insist; that looks bad. It’s better to accept that you don’t know how to do something than to try to get it out of them through questions.
It’s hard, but the best thing to do during an onsite technical interview is to try to focus only on the problem you need to solve. Pull from previous experience (if you have any), and try to mentally map this problem to other problems you’ve solved in the past. This is why working on personal projects while you’re looking for your first development job is such a great idea; it gives you this “fake experience” to draw from, which you can use in situations such as this.
Some companies will use remote technical tests. In this case, they don’t want to know how quickly you can solve a problem; rather, they’re looking to get an overall profile of your coding skills.
By giving you a few days and the ability to solve it on your own at home, they’re allowing you to get all the help you need, because the fact that you solve the problem is the least important thing for them. Granted, you still need to solve the problem, or you’ll most likely fail the interview, but there are other important indicators they’ll be looking for:
-
Did you add unit tests, even though they never mentioned them? This shows you care about the stability of your code.
-
Did you add comments to your code? This shows you care about other people, that you understand you’re never going to be working alone, and that others need to understand what you’re doing.
-
Does your solution take care of edge cases they never mentioned? This shows you pay attention to detail and that you tried to go beyond the initial request.
-
Are you following coding standards, whether they’re standards provided by the company or from an online source (such as Google or Oracle)? This shows you care about code readability and lets them know you can code as part of a team following the same standard.
Of course, you have to solve the problem, but your focus should also be on these details. That is why you have more time.
On the other hand, here are some practices I would advise against:
-
Delivering sooner than requested—If they give you three days to solve the problem and you deliver it on day one, chances are you’re rushing it, which means you’re not really thinking things through. Maybe you’re not catching all the potential edge cases, or you’ve neglected some of the preceding recommendations. Make extra sure that if you’re finishing the task considerably sooner than requested, it’s not because you’re rushing to get the job done.
-
Delivering a lot more than requested—Going above and beyond the initial request might sound great, but if you go too far you might be showing that you spent very little time on the actual request and a lot more trying to show off. Don’t get me wrong. If you play your cards right, this can be a great bonus, but make sure you’re able to justify the additions and the time spent on them. For instance, if you’re asked to create an API endpoint that pulls data from a third-party service based on a parameter it receives, it’s perfectly fine to go the extra mile and add unit tests and maybe schema validation to the request parameters and the response you provide. However, adding a Redis cache to save those results and a React UI to render them is the definition of “too much.” You added requirements that aren’t trivial to the request, which means you spent a considerable amount of time on them instead of using that time to polish the initial solution. If you want to show your experience and your knowledge, add a “further improvements” document to the deliverable, and explain what else you’d do to this project in order to improve it. But don’t go beyond the document—that will show you know more than you’ve put in your code, but that you focused on the request at hand.
-
Changing some of the requirements—If you change the language, the framework, or even some of the tasks to solve, you’d better have a very good reason for doing so. The test they’re giving you is most likely a simplified version of a task their development team has had to solve in the past, and the overall requirements are there to emulate their working environment. If you change things around, the most likely assumption is that you’re not capable of using their tools. If you don’t know the framework they’re using, or if you’ve never used the database they ask for, just say so up front and let them know you’ll do your best to catch up. That’s much better than going off on your own tangent and redefining the test to suit your skills.
No matter the type of technical interview you get, it’s not just what you do and say that’s important. You should also listen carefully to what your interviewer is telling you about the role and the company culture. You’ll potentially be spending quite some time with them, after all.
6.1.2 Warning signs you should look out for
The promise of working for a great company should not be the only important factor when deciding to take a job. I know this can be hard to believe when you don’t already have a job—in that situation, your first instinct would be to say “yes” to the first available offer. However, passing on an offer that smells funny and then receiving the right one can be worth your while.
In this section, I’ll focus less on the technical side of the process and more on the interviewer. I’ll give you some clues as to what you should look for in what they say to understand if the job is right for you or not.
Being a family is not actually a good thing
I’ve forgotten how many times I’ve been told by an interviewer how much of a family the company is, and how great a feeling that is for the team. Having a family is great, I get it. You feel like everyone’s got your back. I fell for this trap once, but eventually I understood something: companies aren’t families, and they can’t be.
Let’s logically analyze this: if a company works (or feels) like a family, the implications are that
-
You may have a parent-like figure who cares for and looks out for you.
-
You should always listen to this figure, because they know better.
Broadly speaking, that turns into
-
When the company (the family) needs you, you’ll be there for it.
-
When you need help from the company (your family), they’ll be there for you.
-
If you have a question or a request, your boss (your parent) will always be there for you.
That sounds awesome, doesn’t it? But there is a catch. Company and government regulations limit the flexibility a company can have regarding its internal policies—policies such as salary bands, study days, sick leaves, and so on. However, there are no regulations limiting your capacity to work extra hours if required, or to sacrifice family dinners for late-night meetings. You can't say “This isn't what I signed up for.”
By stating that the company is like a family, these companies are advertising the fact that they might require you to go out on a limb more often than not. You may need to work extra hours to reach a deadline, put on multiple hats (being a developer, a tester, a release manager, and a devops), or make any type of sacrifice for the good of the family. However, when it comes to you needing a favor (something that is implied in a family-like structure), they usually won’t be able to help. Need a sick day? You’d better get that doctor’s certificate, or they can’t prove you’re not lying. Want vacation time in the middle of a complicated project? Fine, but stay close to your phone, because they’ll reach out if they need you. In essence, while your focus is on them and the project, their focus is on meeting their own deadlines (around projects and revenues) instead of on you.
Companies aren’t evil—that’s not what I’m saying at all. But you can’t think of them as people. There is a lot more going on inside a company than its people, and for a company to stay active and working, executives need to pay attention to those other needs.
This behavior of trying to seem like a family is very common with small startups because they’re usually made up of between 5 and 20 people, and everyone knows everyone. The bigger the company is, and the more employees they have, the less it’s likely to feel like a family. However, you can still get the same comments from recruiters who are trying to get you to join a team inside a big corporation. The result, though, is the same.
Beware of managers who remove themselves from failures
During the interview process, it is common to be interviewed by your future manager. This allows them to assess how much of a fit you are for their current needs and whether you’ll be able to work with the rest of their team. The questions this person will ask are very important, and you should answer them in as much detail as you can, but usually by the end they’ll ask if you have any questions yourself. This question is meant to see if you actually care about joining their team and if you’ve been paying attention to what they’ve said so far.
This is where you should ask, if they haven’t covered the topic yet, about the types of projects they’ve worked on recently. In theory, you’ll ask this because you care about your future assignments, but in reality you’ll want the manager to speak about the team’s performance. Why? Because the way they do can be very telling.
When a manager shares the wins of their team, they can do it in two main ways:
-
They may include themselves as part of the winning team. They’ll say things like “We completed that project ...” or “We finished that sprint ... .” This suggests they share the workload with their team (or they feel like they do), at least when everything turns out for the better. This is important, because it’s an indicator that the manager will be there to support their team during the whole process.
-
They may not include themselves on the winning team. This is also interesting. It means they give 100% of the credit for the success to their teams, and not themselves. They see themselves as facilitators and don’t like to take credit for their team’s achievements. This is an even better response; it usually shows the manager is not prone to micromanagement and is okay with letting their teams work however they want.
When a manager shares the losses of their team, which you can ask about (for example, “What’s the worst project you’ve been a part of, and why?”), they have the same two options:
-
They may include themselves as part of the losing team. This is crucial, because it shows how involved they are with their team and that they’re humble enough to accept that they’re as responsible for the project as anyone else on the team. They could even go one step further and take all the blame, accepting that whatever problems they encountered were due to their not seeing them coming. As facilitators, they should be aware of what’s happening and try to troubleshoot before things get worse.
-
They may not include themselves as part of the losing team. This is not the same as blaming the failure on an external entity (bad client, terrible deadlines, etc.). This is them 100% blaming the team for their mistakes. I’ve heard things like “Well, the team wasn’t senior enough to cope with the workload” or “I got a team that underestimated the effort every time.” Trust me, that is a manager you do not want to work for. This is the definition of a manager who’s completely fine with throwing their team under the bus to justify their incompetence. Avoid these managers if you can.
Don’t let anybody fool you. The interview process is not just for the company to get to know you; it’s also for you to get to know the company. By the time you arrive at the interview, all they know about you is what they read on your resume, and you only know about the company what you may have read online or been told by a friend. Both parties need to get to know each other before deciding to work together.
Overtime is not mandatory, nor should it be expected of you
Phrases such as “We work hard and party even harder,” or my personal favorite, “We’re looking for people willing to show they care about their work, no matter what,” usually hide the fact that you’ll be working extra hours without getting the extra pay associated with them.
This is highly dependent on where in the world you’re working and the company you’re working for, but software developers tend to work in a salaried capacity. In other words, you get paid a fixed amount every month under the assumption you work 8 or 9 hours a day (depending on your country). This means that you have a fixed window of time when you should be working, and once that time is over, you’re expected to leave.
Sadly, not all companies agree with that. Sometimes the company culture values the project more than anything else, forcing you to either show you agree with them by working extra hours or to be considered the black sheep of the team who cares more about themselves than the group. This is a toxic environment you don’t want to work in. Trust me, I’ve been there.
As an inexperienced developer, you might be convinced that this is the way our industry works: that developers aren’t paid for extra hours, and that we need to get the job done, no matter what. I’ve been there many times. I’ve seen companies push their employees to that point, and after almost 20 years of it, I can safely say there is nothing wrong with leaving once your shift is over. You and your personal time should be your priority. After all, work is your livelihood, not your life.
Granted, this should be your mantra, but exceptions can be made if you’re okay with that. Just remember,
I’ve pulled all-nighters before, due to production deployments gone wrong, or someone thinking that a Friday deployment to production was a good idea, causing the entire team to work over the weekend. But these are exceptions. A continuous overtime policy will only lead to the burnout of the team, which will, in turn, lead to a decrease in their performance, overall bad moods, and eventual attrition, with people leaving the team or even the company.
The next time you have a tech interview, ask about their extra-hours policy. It’s perfectly fair that you do so, and if your interviewer considers the question offensive, you have your answer right there. Otherwise, make sure they’re clear about it. If they acknowledge that extra hours exist but aren’t tracked because “they only happen rarely” or that the company pays for food and drinks when you have to work extra time, you’re better off skipping the offer if you can.
With all that said, the perfect job doesn’t exist. You’ll always find something that you don’t agree with in a company. When it comes to extra hours, your best bet is to go with a company that has a clear policy about them. The key word here is “policy.” If they have a process for dealing with extra hours, it means they acknowledge that they exist, but it also ensures you’ll be treated fairly every time. Mind you, “fairly” can still mean you’ll get free food on the weekends, but at least you’ll be sure you’ll get a free lunch on those days, every time. What you don’t want is a vague response—something that is not clear and that could be interpreted in many ways. That’s a sign that you’ll be pressured into extra hours without any added benefits associated with them.
Beware of unlimited time off: It can be a trap
The concept of unlimited time off is still relatively new, but it’s becoming more common every day. In a nutshell, this means you can take as many vacation days as you like, as long as you complete your goals on time.
On paper, it sounds great. Big companies such as Netflix apply this policy, and employees are in charge of deciding how many days off they take during the year and when. The idea behind it is simple: they know they’re hiring responsible adults who can make a conscious decision about when and for how long they can take a vacation. That sounds reasonable, doesn’t it? Are you a responsible adult, though?
Answer me this question: when do you think it would be best to take a one-month vacation? Would it be right at the start of a project, so you miss all the starting details and return to an established team as if you were the pariah who decided to ditch them for a summer vacation? Or maybe right in the middle, when things start speeding up and features start going into production? Or heck, maybe right at the end, when the project is closing up and you can show you don’t really care how it ends?
Don’t worry, you don’t have to answer that question. I’m setting you up to show you how our perception of freedom can easily work against us. If we can quickly decide that there is no good moment to take a vacation, then it’s easy to assume your manager will think the same way. And if your manager thinks you’re being irresponsible for taking advantage of the company’s unlimited time off, then when are you going to take it? Never, that’s when. Thus it’s a “trap.”
The same argument could be made for a company that provides regular vacations (such as one or two weeks of paid time off). But in those situations, you’re usually forced to take the days off or they expire over time, so this illusion of freedom doesn’t exist.
Unlimited time off sounds AMAZING, with capital letters, but it needs to be implemented properly. In his book No Rules Rules, Netflix’s CEO Reed Hasting explains how they arrived at the current iteration of their “unlimited vacations” policy, and he attributes their current success to the inclusion of emotional intelligence into the mix. This means having their leaders take into consideration the emotions and feelings of their teams. It involves measures like these:
-
Avoiding promoting a workaholic culture by rewarding those who never leave or those who put in extra effort every day
-
Caring for their team and making sure everyone else is doing the same
Without these measures, instead of giving employees the freedom to rest whenever they’re burned out, companies are locking them out of their vacations, making them fearful of being identified as irresponsible or self-centered for leaving when they’re most needed. Ironic, isn’t it?
The next time you’re presented with the option of unlimited vacation in an interview, make sure you ask about it. Ask how the company deals with people who don’t take the vacation for fear of being replaced. Ask about their leaders and how often they take vacations. This will show that you’ve given some thought to the idea and that you’re the sort of responsible adult they’re looking to give this benefit to. In the end, if the answer you’re given doesn’t sound right, you may face a mandatory-overtime situation. We covered this scenario in the previous section—it’s not a healthy environment to work in, and it’s one you should avoid.
6.2 Things you should never say during a tech interview
During your interview you’ll have plenty of opportunities to talk, either while answering a direct question, or when given the option to talk a bit about yourself, or at the end, when prompted to ask whatever questions you have about the role, the company, or the project. You should definitely speak and be yourself during those moments, but sometimes being too relaxed can be a problem. Not every hiring manager or tech interviewer has your sense of humor (don’t I know it!) or will understand your pop culture references. This is why there are some things you should never do or say during a tech interview if you want to create the right impression and show you’re the right developer for the job.
Let’s take a quick look at my personal top 10 phrases I don’t enjoy hearing during a tech interview.
6.2.1 What do you do here, exactly?
You may think this question shows you’re interested in your interviewer, but in reality you’re showing that you didn’t come prepared for the interview. These days, and especially in tech, everyone’s online. Everyone has an online profile—it can be more or less detailed, but IT professionals will at least have a LinkedIn profile or be listed on their company’s website. Take two minutes to Google your interviewer’s name (ask whoever set up the interview with you, if you don’t already know the name) and cyberstalk them! Or, you know, find out who they are, what they do, and how long they’ve been with the company.
It creates a completely different impression if you’re asked, “What do you do here exactly?” versus “What’s it like to work with Node.js? I read you’ve been leading teams using that technology for the past three years here.” The first question shows mild interest about the interviewer, while the second shows that you did your research and are interested in the work they do.
Of course, going the extra mile here and asking an interviewer you just met, “How’s Deborah and the kids? Do they care that you spend 12 hours at work every day?” is too much, and a sign that you did your research a little too well. Keep it professional.
6.2.2 I don’t know, I’ve never done that before
As a junior or future developer, you may be tempted to answer some of the technical questions by saying “I don’t know.” It’s true, after all, that you have very little experience, and chances are you’ll be asked to solve a problem that you’ve never encountered.
However, by giving an answer like that, you might as well get up and leave. You’ve just told your potential new manager that whenever you face an unknown problem, you’re blocked and can’t solve it. The specific problem with this answer, if you haven’t spotted it yet, is that you’re not saying what you would try to do. There is a big difference between saying “I don’t know” and “I don’t know, but I would try to ...”
This might sound like a minor distinction, but if you try to reason around the problem with the knowledge you have, you’re showing you’re capable of adapting and learning. Granted, during your workday you’ll usually have access to Google, and you’ll be able to use it to research your problems. But take it from someone who’s been Googling for almost two decades: Google doesn’t have all the answers. Your interviewer knows this as well, so be open to the idea of putting your neurons to work during the interview.
Sometimes asking your interviewer follow-up questions can help you to solve the problem and your interviewer to understand how your problem-solving skills work. For instance, when interviewing data architect candidates, I tend to propose a simple scenario where they have to capture real-time data and store it somewhere to be exploited. If they start asking about time restrictions, tech stack limitations, or available protocols, I can see that they’re into it and trying to solve it. Even if they arrive at a solution that is suboptimal, at least I got to see how their problem-solving skills work. This is a lot more valuable than getting, “Well, I’ve never had to do it, so I don’t know. I’d have to Google for an example.”
6.2.3 I hated that place because ...
One classic question that can pop up during an interview (and which I personally hate being asked) is about your reasons for leaving your current (or previous) workplace. Are you not happy there? Is there a problem, or are you lacking something? Depending on how you feel about your old workplace, this can be a trap, so be careful when answering the question.
If you’re looking for a new job and coming from another company, you do not hate the old company (not “officially” anyway). Your previous workplace could have been hell on earth for all I care, but you can’t say that. Instead, you should focus on finding the positive aspects of that experience. Maybe say something like, “I feel I’ve learned all I can from that experience, and I’m ready for new challenges.” See where I’m going with this?
Hate is a strong and negative word. You’re entitled to feel hatred toward your previous employer, but your potential new employer sitting in front of you doesn’t have the full story. If you try to convey what it was like and why you feel that way about the company, all you’ll end up doing is showing the worst side of your personality.
Instead, try to focus on what you learned from the previous job and how you tried to turn a challenging situation into a learning experience. That will show that you’re a mature adult who doesn’t hold a grudge. Is it true? Heck if I know, but it’s a great image to transmit to your new manager, so make sure they see that side of you.
6.2.4 I’ve built multiple SPAs using SSR with MERN
Clearly you know your acronyms; just turn them down a notch. The point of the tech interview is to show the person in front of you that you know your stuff, but that doesn’t mean memorizing a bunch of acronyms or buzzwords.
Whenever I interview someone, I always start the same way: “If you don’t remember a specific term, don’t worry about it. Just explain it with your own words.” Why do I say that? Because I don’t care if the person knows how to say “closure” or “fault tolerant” as long as they can explain those concepts to me using their own words. Anybody can memorize a few words and spit them out during an interview, but if you can explain a concept to me without using those words, then I know you understand it.
6.2.5 Well, nobody uses that anymore
This answer can take many forms, but the point is to try to stay away from absolutes. The problem with the phrase here is the “nobody” part. Making a statement in the name of the entire software development industry is a huge endeavor, even for someone who’s been part of it for 20 years. Imagine how that might sound coming from a person who’s just trying to get into the industry.
Have you heard of COBOL before? It’s a programming language that was created in 1959, and it’s perfectly fine if you haven’t heard about it, because it’s currently only used in a few places, like bank mainframes. Or have you heard of Prolog? That’s another programming language, but one that’s not very popular because it follows a logical programming paradigm instead of following functional, procedural, or even object-oriented paradigms.
Why am I mentioning these languages? Because when they’re asked about these technologies, a lot of developers are tempted to say, “Well, that’s older than I am; nobody uses COBOL anymore.” However, it’s not only used, but it’s a very sought-after skill because there are very few COBOL developers still around.
This is all to say that absolutes are dangerous because they’re either true or false—there are no in-betweens. You’re either making a true statement and showing you know your stuff, or you’re completely and utterly wrong and showing you don’t even realize it (like with the Cobol example). I try to avoid absolutes like the plague, unless I’m 100% sure of what I’m saying (like when I can tell my kids haven’t brushed their teeth just by looking at them).
By making absolute statements about the IT industry, all you show is that you’re too full of yourself to accept that maybe you don’t know everything. That’s not a great quality to show during your tech interview.
Instead, try to prepend it with a humble “As far as I understand ...” or maybe a “Last I heard ...” That shows you have an opinion on the matter and at the same time are open to being wrong: a great quality to have.
6.2.6 It’s listed on my resume
Often during an interview you’ll be asked about facts you have on your resume, and especially those you took the time to elaborate and explain. Do not answer these questions with “It’s right there on my resume.”
Your interviewer isn’t lazy. They went over the information you sent, and if they’re anything like me, they even tried to dig a bit deeper to verify some of your statements. So why are they asking about something they already read? Because they’re giving you a chance to use your own words.
Nobody can tell if you spent 10 minutes or 3 days writing your resume, or even if you wrote it yourself or asked someone else to do it. By answering with your own words, two things will happen:
-
The interviewer will know how well you know the topic or how fresh the experience is in your mind.
-
During your explanation, you might mention topics that you left out of your resume. This will be a great cue for them to go deeper and ask more about them. One thing I always listen for is the word “microservice” or “API,” because they might not be listed as part of the candidate’s skills. If I hear them, I’ll ask about REST and what that means to the candidate.
Is this a trap? It can be if you don’t expect it, but it can also be an opportunity to cover other areas of interest and show you’re not a one-dimensional candidate. Imagine having on your resume a personal project you created around Pokemon. It’s not a game—it’s just a website listing the first 150 Pokemons and their main characteristics (which, by the way, is a very popular first project for people learning web development). On the resume, you’ll have listed all the technologies you used, such as Next.js, HTML, CSS, maybe even MongoDB for storage. That yells “web development” to anyone reading it. However, maybe when asked about it, you’ll elaborate on the topic and Pokemon and show you’ve read a thing or two about game mechanics or even game development. Who knows, maybe you’ve even coded a game or two—this is a great moment to bring that up.
Take these opportunities to add extra flavor to the answer you’re giving, and show that there is more to you than what’s listed on those pages your interviewer is reading.
6.2.7 No, I don’t have any questions
When I’m conducting tech interviews, I always like to end by asking the candidate if they have any questions for me. But even if you aren’t asked that question, you should try to find a way to ask a few of your own at the end. Remember, this interview is not just for them to get to know you; you need to get to know them too, and the best way to do that is by asking questions.
I’m not suggesting you interview your interviewer, but there are certainly questions you can ask about their role, their job, the type of projects they work on, and the company culture. Saying you don’t have any questions suggests you’re not really interested in the position, so make sure you at least drop one question before you go.
We’ve covered a few important questions you can ask in this chapter already. For instance, you can ask about overtime policies, or vacation days and how they are handled. Your question can be as specific as “Do you use scrum or waterfall for your projects?” or as broad as “What’s the best part of working here?” This is all useful information that might not come up during the interview but that’s important for you to gather before making your decision. So make sure you ask.
6.2.8 I’m a React developer
There’s nothing wrong with React, but you’re selling yourself short with an answer like this. You’re not an “[insert tech here] developer,” you’re “a developer,” and there is a huge difference.
Whenever I hear a candidate say something like this, I can’t help but put them in a box, because that’s what they’re doing to themselves. This is one thing you’ll have to remember throughout your career: programming is your trade; technologies come and go, paradigms come and go, but the underlying principles remain the same. If you tell me you’re an X developer, that means you haven’t realized this yet. You haven’t really understood programming, and you have a lot more to learn.
Instead, be clear that you’re “a developer,” which means you understand the practice of programming to be something abstract that can be applied to many situations and technologies. This shows you’re versatile and willing to learn, which are two major points in your favor. I would pick a candidate like that anytime over a “React expert” who’s not willing to switch to AngularJS.
6.2.9 Oh Linux? I hate Linux, I’m a Windows guy
There are so many things wrong with this line that I don’t know where to begin. But in the context of a tech interview, hating technology is a big no-no.
I get it, I was that guy too. I hated Windows so much I couldn’t stand using it for more than 10 minutes. I was a Linux guy for years (macOS guy, if you forced my hand too), but then I understood one tiny detail: it doesn’t matter. Tech is a tool, and if you have a choice, you should pick the one that feels more comfortable in your hand (or rather, fingers), but if you don’t have a choice, you have to keep moving.
“Hate” is subjective, it comes from a place where reason doesn’t exist. Instead, if you think you have a strong argument against the technology, explain yourself: “I haven’t had good experiences with Linux when it comes to game development because I’ve been learning Unity, and the port for Linux is quite unstable.” An explanation like this shows you’ve given it a try and that you’re willing to back up your claims with evidence. That’s very different—that’s not “hating” it, that’s experience.
Declining a job offer with great benefits and interesting growth opportunities just because you’re not willing to learn a new technology or because you “hate” it only shows you’re close-minded. That’s harsh, I know, but true. Until you realize that, learning will not be easy, and improving your skills will come at a slower pace. The more tech you try, the more you’ll learn—it’s that simple. Be open to new opportunities and welcome the unknown; that is the sign of a great developer in training.
6.2.10 I don’t know what unit tests are
Yes, you’re just getting started, but if you don’t know what unit tests are, you really haven’t learned the basics of programming. I’m not saying don’t apply, but maybe stop wasting time on Netflix and read up on the fundamentals of the profession instead.
Why do you think a book like this—one that’s not code-focused—dedicates a full chapter to unit tests? Because it is such a fundamental practice in our profession that everyone needs to know it.
Granted, you can’t be expected to be an expert unit tester when you’re in your first tech interview. There is a lot about the practice that you’ll have to learn through experience. However, if you’re able to speak about the process, it shows you care about the quality of the code you create. I can’t begin to express how valuable that is in a developer, and trust me when I say that not all senior developers care about it that much. If you’re looking into unit testing at this stage in your career, you have a great head start.
Finally, there is one last aspect of the interview process that you need to consider: the offering.
6.3 What to expect from the offering after your interview process is over
The last leg of your interview process, after everything’s been said and done, is the actual offer. Usually it will come from a human resources professional, and it will come a few days after you’ve completed the tech interview.
The usual interview process is as follows:
-
You have a quick interview with someone from recruiting, human resources, or even an external psychologist who will create a basic profile about you. The profile will be sent to the tech interviewer to screen.
-
If they deem it interesting, they’ll coordinate the tech interview.
-
After the tech interview, they’ll send feedback about you to the hiring manager to decide whether or not they make an offer.
There might be other steps between those, depending on the company and how long they think their hiring process should take. But those three basic steps are almost always included.
The first thing you need to do is ask for a few days to study and consider the offer. The company will be expecting a response from you, but you’re not obligated to give one right away, especially if the information is conveyed over the phone. This is in no way an attempt to play “hard to get.” The point of this time is to weigh the offer against what you have right now. Of course, if this is your first job, chances are you’re going to take it, but there are some conditions that can be red flags, so be careful.
If you’re just getting started with your career, you can’t expect the salary or the overall offer to be great and have all the perks in the world. However, based on what I’ve covered so far, you should be able to pick up on potential problems with the company or its culture. Don’t let the perks disguise a bad offer. Learn to see through them and understand what it really means to work for that company.
6.3.1 Not everything that shines is gold
There are “perks,” and then there are “Perks.” The problem is that sometimes the former group looks a lot shinier than the latter, so you might end up accepting a sub-par offer because of a few things you can easily get on your own.
For instance, these are classic perks listed in offers that you should really ignore for the time being:
-
Relax zones with ping-pong tables, comfortable couches, and 100-inch flat screens—That sounds fantastic, but when are you really going to take advantage of that area? When you’re working on something, you can’t be playing ping-pong or laying on the couch to relieve stress—you need to be working on your deliverable. And if you’re currently unassigned because either your project just ended or you’ve just started working for the company, you’d better be learning something new. Yes, those spaces are awesome for taking five minutes off from your stressful routine and relaxing, but that’s all the time you’re going to be spending there during your day (or week, really). So don’t let that lure you. Understand that while this might sound like a huge perk, it’s minor compared to others.
-
Free donut Wednesdays—I mean, who doesn’t like donuts? I love them, and whenever I get one (or as many as I can) for free, you can be sure you’ll see me there. That being said, I wouldn’t let it be a decisive factor in my decision to take or reject a job offer. I can get donuts on my own just as well, thank you. Substitute donuts for any other type of meal, and you’ll have another common perk that’s not really a big deal. Free food does not substitute for an increase of 20% on your paycheck, for instance.
-
Working with extremely bright minds—I’m happy if a team is filled with such individuals, and I will definitely benefit from working with them. However, listing that as a benefit means you’re really out of ideas. If your team includes the creators of popular open source frameworks that everyone is using, that’s definitely a fact you should drop during the interview, but it’s not a perk, and you, as a candidate, should not fall for it. There is no guarantee that any of those “great minds” will have an emotional intelligence high enough to guide you or be a great mentor to you. Good mentors can be found in other places with less “bright” people as well. So let me say this again: this is not a perk, and if you’re told it is, you’re being mocked.
-
The freedom to travel whenever you want and work from wherever you are—I was personally offered this perk. I originally thought this person was telling me they flew their employees for things like mass meetups, or something like that. But no, he was just telling me that since I was going to be working remotely, I was free to travel and work from anywhere in the world. “Fantastic,” I thought, “I can’t really pay rent right now, and this person is telling me I can travel the world. Really?” More and more companies are hiring remote workers these days, and saying that their freedom to work from wherever they want is a “perk” is another big insult, if you ask me. That’s not a perk, it’s just how “working remote” works. And the worst part? Some companies will list it as a perk, and then once you join will tell you that it’s dependent on the project, and if the client doesn’t want you to be in the wrong time zone, you can’t do it.
I could keep listing examples, but you get the point. A perk is not anything other than your salary. Instead, it should be something that really benefits you. Perks are what the company offers to lure you to work for them. However, perks need to be useful to you.
6.3.2 Actually useful perks
This list could also be endless, because it’s up to the company’s imagination what they offer. However, let’s cover a few that I’ve seen in my years of jumping between companies:
-
Flexible hours—Real flexible hours mean you work whenever you can (or want), as long as you either deliver your work on time or complete the allotted working hours every day. This is usually a perk for remote workers, and it’s great because it allows you to organize your work around your daily routine. For instance, I used to be able to take my kids to school every morning, and I would start working after that. I would work until it was time to pick them up, and I would do so with my wife. I was part of their routine, even though I was working from home. I really enjoyed that flexibility and that time with them. That’s an actual perk.
-
Company gear—A laptop, and probably a phone if you’re expected to travel, are usual perks that most tech companies offer their employees. This is a fairly standard perk, and it’s great because you shouldn’t be expected to buy your own gear. Not when you’re going to use it to create intellectual property (the software you’ll write) that’s not yours.
-
Paid parental leave—This is a real perk that more and more companies are starting to offer. Having a child is no easy task, and even if you’re not the mother, you’ll still need time to be there for everyone, so having paid parental leave (whether you’re the mother or the father) is a great opportunity. In my case, when my first kid was born, I had three days off paid by the company—that was it. I had to take all my pending vacation days so I could take two weeks off to be home with them. Did I regret not having vacations that year? Heck no, but if your company is capable of acknowledging that you’ll need the time off, that’s a much better deal.
-
On-site, free gyms—Working as a developer is a very sedentary profession, and we tend to spend most of our days sitting in the same exact position. But we’re humans (no matter how much we’d like to deny that fact), and we need physical activity. The problem is that sometimes we don’t have enough time, especially if we have long commute hours. This is why on-site gyms are a great opportunity to get some exercise over lunch time or even after work. Having the gym right there for free removes every single excuse for avoiding it. Companies like Google are starting to implement this in all their offices. It shows they care about their employees’ health. A perk that benefits your health? Yes please!
Notice how I didn’t mention anything about free meals or relax rooms in that list. That’s because actual perks try to benefit your work/life balance by giving you time off when you need it (like when a new baby is born) or helping you improve the way you live. Perks aren’t about giving stuff for free, but rather about companies showing their employees they care about them.
The next time you receive an offer from a company with a sub-par monetary offer, check out their perks and consider what you’ve learned here. Maybe that company isn’t worth your while, or maybe they are, and the low salary can be compensated for by the great perks. In the end, only you know what your dream job is and what’s most important to you. So ask yourself the following questions (or similar ones that matter to you):
-
Where do I see myself in five years? Can I get there with this job? Or is this job a starting point to get there eventually?
-
What’s the most important thing for me right now? Is it money? Freedom to work from home? Making my own work schedule?
-
Do I want to work for a big company where I’m one of many, or do I want to go through the startup experience and be part of a small group of developers doing everything themselves?
If you think your answers are compatible with the offer, then you’ve got your “Yes!” Otherwise, it should be a “Thanks, but no thanks,” and you can keep on looking.
Summary
-
The interview process is not only meant for the company to get to know you. It’s also a great opportunity for you to get to know them, so make sure you ask questions and get all the details you need to make an informed decision.
-
Don’t lie during the interview or in your resume. Lies have very short lives, and they only help to create wrong expectations about you. Try to show your worth through other means. If you don’t have any, then it might be a sign that you’re not doing enough.
-
Be careful what you say during the interview. Showing interest about things you can’t possibly know, like their day-to-day tasks and company culture, is a great idea. Asking about obvious or easy-to-find information shows you haven’t done your homework.
-
Try to stay away from absolute statements. You probably lack the experience to back them up, and that’s perfectly fine. There is nothing wrong with giving your opinion about a subject; just make sure it’s clear that you’re basing it on your limited experience.
-
Watch out for classic red flags like improperly implemented unlimited time off, mandatory overtime, and managers who won’t share the burden of a failed project with their teams.
-
Finally, not every perk is worth your time, and you need to sort the good ones from the easy and not really useful ones. Remember, flexible work hours are fantastic, but free donuts shouldn’t be considered a perk.