Beat the technical interview! (Part 2)

Here's an article that makes the process of securing a software development job (which for us usually lands on the .NET/C# side of things) more fun by treating it like the "cheat codes" to a game in which you're the protagonist preparing to go up against hiring managers.

Level 2: Boss, The Senior Developer

By: Gayle McDowell, Author of Cracking the Coding Interview and Founder/CEO of CareerCup

Just as actors have to audition for a part in a play, developers also need to audition. Of course, a developer’s “audition” will be a series of technical questions designed to test technical expertise. 

Can’t they just know you’re good from your resume and background? You would think so, but unfortunately, you can’t make any assumptions. You could be lying or exaggerating on your resume. Or, your resume could be ambiguous in certain ways. 

One person’s “three years of experience with .NET” might mean a few months of experience spread out over multiple years, whereas another person could have three years of intense, everyday work. And, we all know that years of experience don’t always have a direct correlation with skills. Sometimes, the more “junior” person is better, and these questions are designed to discover that.

Regardless of your feeling on the merits of these technical questions, many companies stand by them. If you’re doing a lot of interviews, it’s likely that you’ll encounter them and it’s best to be prepared.

Technical questions you’re likely to face will usually come in one of three forms: knowledge questions, coding/algorithm questions, and architecture questions. No level of experience makes you “immune” to any type of question, though it might affect the standards or expectations. In fact, many interviewers will ask the exact same types of questions to all candidates, regardless of their experience level. 

Knowledge questions generally have right or wrong answers. For example, an interviewer might ask you a question like, “What does the keyword sealed in C# do?” or “Is it possible to execute multiple ‘catch’ blocks?”

Obviously, the better you know the language, the better prepared you’ll be for knowledge questions. You can also refresh yourself prior to your interview by reviewing terminology and concepts from your preferred programming languages. 

Many popular interview questions can be found online on websites like CareerCup and Glassdoor, so those are good places to look for questions you might face. For each concept or keyword, make sure to think about where you might use them, what the relative pros / cons are, and what the alternatives (if any) are.

If you don’t know the answer offhand, all is not necessarily lost. You might be able to bring in your knowledge from other programming languages or deduce the answer some other way.

For example, if you don’t know immediately whether or not multiple catch blocks can be executed, you could think about how catch blocks work and what it would mean to be able to execute multiple catch blocks. 

Explain to the interviewer beforehand that you don’t know the answer but you’ll try to deduce it. In some cases, you might actually be able to demonstrate a better knowledge of the technologies by deducing the answer than by already knowing it.

Coding and algorithm questions are designed to test aptitude more so than pure knowledge. That is, they’re tests of your coding skills and problem solving skills. They’re supposed to make you think. This is good news actually; you don’t have to just know the answer. The interviewer wants to see how you solve the problem.

Coding and algorithm questions can vary substantially in difficulty, and can include questions like:

• Implement a program to check who, if anyone, has won a game of tic-tac-toe.
• Given an array of integers, return the number that it repeated the most.
• Design an algorithm to find the longest substring that is a palindrome in a string.
• Given a binary search tree whose “left” and “right” pointers are represented with “first” and “second,” write a program to convert this tree into a sorted linked list. This conversion should be done in place, with the linked list re-using the “first” and “second” pointers.

Some of these questions might test knowledge of data structures and algorithms, depending on your background and the company’s preferences.

To solve these questions, the following techniques work well:

Ask questions

Questions are sometimes more ambiguous than they appear. The interviewer might have forgotten some details, or you may have misheard some of the problem. Repeating the questions back and clarifying anything you’re confused about can prevent you from running down the wrong track.

Use an example

If you don’t know how to solve the problem at first, using an example can help you to brainstorm approaches. Be sure you come up with a realistic example though. For example, if you’re writing up an example to find the longest palindrome, you probably want to use a string with multiple palindromes.

Talk out loud

Your interviewer wants to know how you’re approaching the problem; that’s part of why he/she is asking you this question. Talking out loud will help show him/her that. It also has benefits for you though; it shows you’re either making progress or that you’re off track. Your interviewer can then get you back on track with some helpful hints.

Pseudocode

If it helps you, consider writing pseudocode prior to writing your actual code. This can be especially valuable in more complex code or in code that has lots of little details and minutia.

Write your code

You may not get a computer to code up your solutions on; rather, you will be expected to code on pen and paper or a whiteboard. Although your interviewer probably won’t mind too much if you forget something like a semicolon, you should strive to make your code as flawless as possible. Pseudocode is usually not sufficient (although it’s fine as an intermediary step). 

Test

When you finish writing code in the real world, do you just check it in to the source control system? Of course not. Likewise, in an interview, you shouldn’t think you’re done just because you’re, well, done. Interview code needs to be tested. No, you still won’t be given a computer, but you can run through your code by hand using some examples. 

When you find mistakes – and you probably will – don’t panic! Mistakes are okay; no reasonable interviewer expects you to just bang out flawless code, particularly when you don’t even have a computer. Just think through your bugs and carefully try to fix the solution.

On each question, you will be evaluated relative to other candidates on the same question. Think of this like being “graded on a curve.” The harder a question, the longer it will take to solve, the more bugs everyone will have and generally speaking everyone’s performance will be weaker on an absolute basis. Interviewers will therefore be a bit more lenient on all factors. You don’t have to be perfect! 

Architecture questions ask you to architect a system of some sort. This could be something like an email system or a system like tinyurl.com. 

In these questions, you should start off with understanding the constraints. Let’s suppose we are building an email system. What are we building this for? Are we building a massive email service like Gmail or Hotmail that needs to support millions of users?

Or are we building an email system from scratch for a small to medium sized company? What protocols will the mail system support? These are all good questions to discuss with your interviewer. 

Second, you should start with listing the components of the system. For this example, you’ll probably need some servers for incoming and outgoing mail, a database of some sort and possibly some servers or services to configure it. The email clients themselves might also be considered part of the system, particularly if it has a web frontend like Gmail or Hotmail. It might be useful to get up on the whiteboard and start drawing some pictures; go ahead! 

Third, you’ll need to describe how these components will work together. When and how does each component talk to the other? Do the incoming and outgoing servers talk to each other directly or does each read only from the database? 

Fourth, think about how to make the system better: faster, more robust, etc. How will you handle having a lot of data? What will happen if a server goes down? Is there anything you might want to cache in memory to make the system more optimal?

Depending on the question, you might get into the details of what technologies (which database, etc.) you might use. It would be wise to be prepared with an understanding of the pros and cons of different technologies.

Phew! That was a workout, right? Now that you’ve successfully navigated past HR and the senior developer, it’s time to move onto level 3 and go toe-to-toe with the next boss in the software development interview process: The Software Manager. 

You May Also Want to Read Previous Part : (Part 1)