Many developers are great when they are in front of a computer with their IDE but put them in front of an interviewer or group of them and they get nervous and make stupid mistakes, especially if going out for the first job or the first one in a new language or framework.
For both the whiteboard and code challenge as well as for answering technical questions during the interview practice will help you move from terrified to competent to comfortable. Before your interview review questions on the languages/frameworks ect you will be using. Get into the habit of doing daily code katas. These will help you with both whiteboard and coding challenges. Also practice explaining the solution to someone even if they are not a technical person. You’d be surprised how well you get to know something when you explain it to other people.
Episodes in the series
- Getting A Job
- Building Your Resume
- Soft Skills to Ace the Interview
- Whiteboards and Coding Challenges
- Bad Interview Questions
- Mock Interviews
The Broken Process
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.
Cognitive Whiteboards from Ricoh with IBM Watson
While not for the average user you might be able to see something like this in a corporate or educational environment. Ricoh has incorporated IBM’s Watson Natural Language Classifier API into their interactive whiteboards. The idea is to create more efficient meetings through the use of technology. One way it does this is through language translation. So if you are in the US talking to clients in Iceland it translates what they see.
Tricks of the Trade
Even if (maybe especially if) a system is broken, you need to learn to exploit its weaknesses. This doesn’t mean that you cheat, only that when you encounter a broke way that people are doing things, that you are better off finding out why and serving that than you are slavishly confusing their attempt at reaching a goal as indicating what their goal is.