Surviving the Whiteboard Interview Page 3

  Second, interviews involving a language or major cultural barrier are more difficult. This doesn’t mean that you should avoid interviewing somewhere where the interviewers speak a different language or come from a different culture. Rather, it means that communications will be more difficult. Besides miscommunication from language barriers, cultural barriers can also make things more challenging. Even cultural differences within the same country can represent large differences in manners, ways of communication, and even ways of expressing yourself. These problems easily result in miscommunication, as well as being possible sources of bias.

  Third, interviews conducted by nontechnical personnel create a lot of challenges. Besides simply not knowing enough about the technology being used, nontechnical interviewers will often fixate on the things that they do know, even if those things have nothing to do with the job in question. While this doesn’t necessarily work to your advantage, it does mean that the interviewer may not be able to answer many of your questions. This can make it more difficult to decide if the job is worthwhile.

  Finally, if the interviewers don’t agree on what constitutes a good candidate, it gets much more challenging to be perceived as one. This can happen because of a lack of clear organizational structure, a “hybrid” job, or because of internal politics, but it will make the interview more difficult no matter the reason. You may find that some of your answers please one party and irritate the other. It’s a difficult situation, made more difficult because you don’t understand the situation that caused it.

  Characteristics of Good Evaluations

  Many companies are also terrible at evaluating soft skills. While your ability to work well with people is often given less emphasis for technical jobs, it is still critical to the success of any project in which you are involved. There are a lot of reasons that companies have difficulty with evaluating soft skills.

  The first (and simplest) reason that companies aren’t good judges of soft skills is that at least some percentage of job candidates are dishonest. Developers command high salaries, and this money provides incentives for less-than-scrupulous people to act deceptively in interviews. Whether they are lying about previous situations, providing an inaccurate view of how they would really handle a job situation, or simply relying on flattery to get through the interview, the results are often the same. Six months after hiring such an individual, the company is often left trying to figure out how to fire them without getting sued. Even worse, such an individual can cause so many interpersonal problems in an office that the best staff members leave.

  Secondly, interviews are usually short by design. Neither the interviewer nor the interviewee can afford to have their time wasted. It takes a while to get a good view of someone’s personality, and such extended conversations are difficult in an interview. Many people with truly bad soft skills and interpersonal habits can come across as charming, fun people when you first meet them, and only become an obvious problem later when things start falling apart.

  Third, interviewers often can’t get a complete picture of a person’s personality even by contacting references. It’s especially difficult to find out about character flaws from references, either because they don’t know or refuse to tell you. There is a legal risk to disclosing negative information that keeps someone from getting a job. While a lawsuit is not particularly likely, many companies are justifiably paranoid about giving any negative information about anyone when a stranger calls for a reference. It’s fairly common practice, especially with larger companies, to only confirm that you worked for them and when—they won’t tell anything else at all.

  Finally, work habits are often very tricky to evaluate. Take, for instance, an employee that is frequently late to work. Are they late because they are inconsiderate and hate their job? Do they have a short-term family situation that is making it impossible to arrive on time? Are they just disorganized? The first case might get better if they were in a more satisfying job, while the second might get better on its own. The third situation might get better with time and maturity, or it might not… An employer might be more or less willing to work with someone in each of these situations, but they may not even know that punctuality is a problem for weeks or months after hiring someone.

  While soft skills are critical for being a successful software developer, they are one of the most difficult and risky things for an employer to evaluate. The damage caused by employees with poor (or nonexistent) soft skills can last for years after those people are gone. In a later section, we will discuss some things you can do to make sure that you make a good impression.

  Other Methods of Evaluation

  While whiteboards are almost certainly the most common way to evaluate developer skills, there are a few other approaches that are better. Typically, these approaches attempt to combine the best of earlier approaches with good techniques for determining culture fit. You won’t see these often, but they frequently are a sign of a forward-looking company.

  First, a good evaluation method will show your problem-solving skills on a real problem. This means that it will show your design skills, your debugging skills, and your ability to deal with ambiguous (or even changing) requirements. Such an approach should show off your ability to ask relevant questions and show how quickly you can understand the underlying business requirements. This shows that you can be a useful team member, who doesn’t simply lock themselves in an office and write code.

  Second, a good evaluation method will show how you interact with a team. It should incorporate giving and receiving feedback. It should show your reaction to corrections and suggestions. It should also show how you interact with team members and whether you can do so in a healthy manner. This shows that you won’t upset the existing team dynamics (if healthy) or, at the least, won’t make them worse (if unhealthy). It also allows you to evaluate whether you can stand to work with these people.

  Third, it should show that you can actually do the work. While many people think that the purpose of an interview is determining whether you can do the work, it is not the only consideration. However, you do need to show that you can actually get work done. A good evaluation should definitively prove that, without it being a matter of guesswork.

  Fourth, a good evaluation process should give you an idea of what it is really like to work at a company. While you can get hints of that in an interview, the day-to-day grind of many jobs is something you have to experience firsthand to understand. Many companies have processes or just general ways of working that make them unpleasant. These seldom come up in interviews, but most are pretty obvious within a month or so of starting.

  Given the previous points, one excellent way to evaluate developers is to actually hire them on a contract basis for a small chunk of work. Not only does the developer get exposure to the team, internal processes, and the problem space, but they do so for a longer period of time than a standard interview. If done correctly, both parties will know whether they can work well together (or not) by the end of the engagement. While this process doesn’t scale, if prior screening mechanisms work well, it can often produce better results than an interview. I’ve worked at several companies that have done this and they have been some of the best ones. Not only do you get a real feel for how the company works, but you also get enough exposure to potential coworkers that you can truly tell whether you’ll get along with them or not.

  Summary

  It is difficult for many companies to hire well. Whether it is because of the general difficulty of evaluating a candidate’s suitability, various situational problems that complicate the process, or simply because evaluating a candidate’s personality is simply a hard problem, most companies find the process difficult. While these all sound like problems for the employer, they also represent an opportunity for the interviewee. If you are conscious of the things that make interviewing difficult for the interviewer, you will have many opportunities to stand out from the rest of the candidates. Most people go into interviews thi
nking only about themselves, their skills, and how they are going to get the job. If you go in instead thinking about the problems the interviewer (and the company) is facing, you will make better decisions during the interview. When you are deeply aware of the problems faced by others, you can often find ways to work together to create a better situation for everyone involved, and this extends to the process of interviewing.

  © William Gant 2019

  William GantSurviving the Whiteboard Interviewhttps://doi.org/10.1007/978-1-4842-5007-5_3

  3. The First Steps for Getting Ready

  William Gant1

  (1)Nashville, TN, USA

  In this chapter and the next few, we’ll talk about what to do to prepare for the interview. This chapter will center on the things you need to do to make the process as painless as possible. In the next chapter, we’ll discuss in depth how to practice well before interviewing. The goal here is to practice until the real thing feels easier than the practice.

  Search for Common Questions and Problems

  Here’s a secret that the folks interviewing you won’t tell you—interviewers are busy people. The fact that we’re hiring is evidence that there is more stuff to do than we can get done. We don’t have time to put a lot of thought into creating new interview questions and whiteboard problems. If we feel that the rest of our interviewing practices are good enough, we can just do an Internet search to find some suitable questions and problems. So, it’s in your best interest to do an Internet search for questions as well.

  Start off by searching for “Interview Questions for [framework/language/platform/database]” where the items in brackets are the framework(s), language(s), platform(s), and database(s) that you will likely be working with for your job. For instance, if you are an ASP.NET developer using Angular and SQL Server, you might make separate searches for the following:ASP.NET interview questions

  C# interview questions

  Angular interview questions

  SQL Server interview questions

  IIS Interview questions

  Make sure you can answer the most common questions you find with these searches, as you probably will be seeing them again. If you have to research the answers, take the time to do so, because this will help you get through the interview long enough to get to the parts where you can truly differentiate yourself. It will also help you a little bit later if you actually practice with a whiteboard. If you see any short coding problems here, hang on to them for later.

  This whole thing may feel like cheating. However, the idea here isn’t to memorize the answers; the idea is to internalize them. Not only can these answers help you in the interview, but there are pretty good odds that you’ll use the information in your job as well. You have tools that can help you—use them.

  FizzBuzz

  There is a particular type of whiteboard problem that is used a lot and is perfect for early practice with the whiteboard. That problem is known as FizzBuzz. First proposed by Joel Spolsky, FizzBuzz is a very basic coding exercise that shows you at least have the beginnings of thinking like a programmer. By itself, it’s not enough to prove that you can code in a real environment, but it is still used to screen job applicants.

  Besides being simple enough to start with, FizzBuzz offers a number of other advantages. For one, there are versions for most programming languages, and if there aren’t, you can probably still figure it out without much trouble. Second, FizzBuzz problems in another programming language are still understandable, even if your friends don’t program in the same language as you do. This makes it easier to find a practice partner for the whiteboard. Finally, FizzBuzz does show familiarity with things like loops, the console, arithmetic operators, and strings.

  Again, do an Internet search and get the basic outline of FizzBuzz in your language of choice and set it aside. We’ll be using it in Chapter 4 as a code kata.

  Code Katas

  In addition to practicing whiteboard problems on occasion with a friend, it will help you a lot to practice code katas daily. The main goal with continual practice of code katas is to get you into a headspace that is effective for getting through technical interviews and keep you there. You should also revisit the concept once you have a job, as they can help you a lot when you are trying to learn new skills as well.

  Katas in the martial arts are prearranged sequences of movements to help you practice. They help improve a lot of things like footwork, balance, body structure while doing a technique, and flexibility. While not directly helping with getting through actual combat, they are quite good for developing ancillary skills that are still really useful. The same practice can be applied in coding.

  Again, to get some reasonable code katas to begin, go to Google and search for “[framework/language/platform] code katas” for each framework, language, or platform that you use. Pick one that looks a little challenging to you (but don’t overdo it) and practice it every day. The idea here is to use the same example over and over, working it all the way through and trying to improve your approach. You might think that most of the value of a kata is gone after the first time you complete the problem, but nothing could be further from the truth. After you get done solving the problem, try to solve it faster, more eloquently, with unit tests, using less code, and so on. You can learn a lot from a single problem practiced in this fashion, and the lessons thus learned will improve your skill. Keep practicing until you are sure you have wrung everything out of the kata that you can get, then pick another and do it again. Periodically revisit the katas you’ve worked through before and see if you’ve picked up anything new. You might be surprised. We’ll spend some time in the next chapter explaining how to really improve your skillset with code katas, but for now just pick one and try out the concept.

  This all sounds corny, doesn’t it? However, it’s a trick I’ve used on a regular basis over my entire career, both to sharpen my skills and to bring new techniques into my practice. Even in my current role as a software architect, I still periodically go through a period of practicing code katas to tighten up my skills. If you do this as an aspiring developer before you get your first job, you’ll rapidly stand out from the crowd. Whiteboard problems are often very similar to code katas, and consistent practice with code katas will make you better at getting through whiteboard problems.

  My friend BJ, who is my partner on “The Complete Developer Podcast,” among other ventures, was one of the first people I worked with on surviving whiteboard interviews. We drilled whiteboard problems. We drilled code katas. I was tough on him on both—in fact I was far tougher on him than an interviewer would be. When it came time to interview and he was given a whiteboard problem to solve, he laughed. The interviewer picked a problem that he had been working on as a code kata for a couple of weeks. He solved it in a single line of code, as the interviewer stood by, mouth agape. Needless to say, he got the job. Even better, his skills stood up to the test of the job after he got it. We will discuss code katas and FizzBuzz in Chapter 4.

  Find a Study Partner

  Another thing you need to do is practice for whiteboard tests. It’s going to require working with someone else, but it is worth the trouble. Practice actual whiteboarding problems with a friend, as often as possible, until you actually manage to land a job.

  Each time you practice, each of you will present the other with a problem to solve on the whiteboard. When it is your turn, you will solve the problem as if it was a real interview. You’ll get some advice on how to get through a real interview in a later chapter. Practice on the whiteboard with a friend who is acting like an interviewer. This is not a joke, so be serious. Your goal is to practice in such a way that when you encounter the real thing, you are ready.

  When it is your turn to be the interviewer, your job is to be a challenging interviewer. You’ll have to vary this depending on your partner’s tolerance, but your job is to press them to the point of mild discomfort. Question what they are doing, and why. Make noise, joke, talk on your phone, an
d do all the stuff that you would imagine a terrible interviewer doing. Give your partner the opportunity to practice under pressure, especially irritation and emotional pressure.

  When I worked through this with BJ, I was a jerk toward him, on purpose (I had a blast though). I can remember one day when he made a mistake, when I threw an eraser at the back of his head, telling him to pick it up and erase the memory leak he had just written. While I don’t necessarily recommend taking it that far (we’d known each other for 15 years at that point), I will tell you that getting through such an experience in practice makes it far easier to get through it in a real interview, when the interviewer is probably far nicer. Practice hard, so that the real thing is easy.

  The idea behind doing this is that exposure to a harder version of a whiteboard interview with nothing at stake will make it easier to emotionally and intellectually handle the real thing when your ability to pay the rent is on the line. You don’t want your first experience with a whiteboard interview to be during a real interview for a job that you actually want. Take the pressure off in advance by practice.

  Write Code Every Day

  I almost hesitate to mention this, but you really do need to try and write code several times a week, if not daily, while you are interviewing. It’s not just that practice is important, but that your skills will atrophy faster than you think if you aren’t using them regularly. If you’re lucky, your job search for your first development job will only take a couple of months, but it might end up being six months or longer.