Whiteboards and Code Challenges

10:06 Technical interviewing is a broken process for employers.

“When I was coming up they would give you a list of quesions.”

A sizable minority, if not a majority, of people in software development enter the field with no formal credentials to indicate skill and the jobs pay well. As a result, employers have no easy way to determine whether you meet their needs and many interviewees are incentivized to deceive them.

14:25 The process is broken for interviewees as well.

It’s hard to prove tech skill in an interview lasting an hour or two and the field is crowded with poor candidates. As a result, it’s relatively common to have multiple interviews with the same company, wasting hours and hours of time, only to get turned down. This makes job searching painful and potentially very expensive if you are out of work.

17:45 Broken processes can be hacked to your advantage.

“Broken processes MUST be hacked to your advantage.”

If you know what the employer is actually looking for versus what they are asking for, you’re ahead of 90% of the candidates. If you are prepared in advance for the routine, the interview is much easier to survive.

21:55 You can practice for these parts of the interview.

“I could look this up on my phone but my ethics won’t let me.”

The technical side of interviewing is the easiest part to practice. Get into the habit of doing code katas or challenges on a regular basis. Look up technical interview questions in your area of expertise. BJ would create a review sheet of common questions and answers to go over the night before interviewing.

25:35 The whiteboard interview is all about the process.

You’ll be given a problem that should be solveable in less than an hour at most. At more junior levels, it should be easier. The problem will typically have some relevance to the sort of problems the organization typically deals with.

“Interviewing’s hard bro.”

You’ll start solving the problem on the board, being occasionally prompted by the interviewer. If there is time, the interviewer will look at your completed solution and prompt you to make it more elegant. If you do not do well, they will also typically prompt you towards a desired solution.

32:26 There are multiple goals for the interviewer.

“This is what people seem to be getting wrong when they get all freaked out about the whiteboard.”

The most obvious is to show that you know how to think programmatically. The second is that you can clearly communicate your ideas. Finally, they want to see how you respond to feedback on your ideas (aka, how you work with a team).

33:57 You need to practice for whiteboard questions.

Look up common whiteboard problems for your language or languages and practice doing them like they are code katas. Get a whiteboard to practice on. This will help you become more comfortable with writing on one and solving problems. If you can’t then use printer paper to practice writing out solutions without your IDE.

“You have all the parables and stuff from the Bible and you learn this is a really good way to get points across to people.”

Explain it to someone even if they are not technically savvy. Especially if they are not technically savvy. You can use a “rubber duck” but it’s better to get used to doing these in front of real people.

36:30 Important things to realize in order to win.

“Whiteboard’s don’t compile.”

These kind of tests show next to nothing about how productive you will be or how you use an IDE. Whiteboard interviews are highly reliant upon memory. If you are doing a whiteboard interview, your personality is a much bigger asset than it is in a coding challenge.

40:38 The Coding Challenge interview has it’s own process.

“Coding challenges is probably the next phase in interviewing.”

You may do this on site or remotely with remote desktop. Sometimes they just send you the problem to do. Essentially, they give you a software problem to solve and have you code up the answer. Sometimes these are timed, sometimes they are not.

Sometimes you’ll be observed solving the problem and sometimes you’ll just be handed the work with a deadline. It is possible to use google while doing this in many cases. In fact, it may be expected. You will typically not be prompted or prodded along while doing this unless it is done live.

45:20 Interviewer’s have different goals with a Coding Challenge.

They want to see that you can solve an actual software development problem, using actual software development tools. They also typically want to see that you can solve a problem using a particular toolchain and language, rather than looking for general development thought processes.

“I solved a problem in their codebase they had found that day.”

If you are not being observed, they want to make sure that you don’t just copy the first answer you see on Stackoverflow. Unobserved tests are also a good way to test your communication skills in a disconnected environment. If you are being observed, it’s likely that this is either just a slightly nicer whiteboarding problem, or the interviewer doesn’t know how to do a coding challenge problem properly. Sometimes an observed coding challenge problem is an attempt to see how you code under pressure. If you think it is, you should think about what that implies.

53:00 You also need to practice for Coding Challenges.

“I cannot repeat this enough, Do Code Katas!”

Do code katas. This is where they come in most helpful as you will be in the same type of environment doing them as doing the code challenge. Look up common code challenges used for interviews and create your own code katas from them. Do these on a regular basis. Set aside some time each day to practice for upcoming interviews.

55:40 Important things to realize in order to win.

These sort of tests don’t do a very good job of showing how you will interact with a team. Coding challenges are highly reliant on your ability to execute and write code that other people like. Personality barely comes into it. You will frequently be given coding challenges for jobs where you will be working alone, remote, or leading a team.