It’s a Trap! Technical Interviewing at a Startup
Getting a job offer from a startup can involve many factors such as cash burn rate, staffing needs, and fit within the culture of the company. One of these factors for engineers and developers is an assessment of technical aptitude and thinking ability in the form of a technical interview. This assessment can be critical in the interview process and may weigh significantly on the decision to make you an offer. Sure, exceptions to the norm always exist, but for the most part as an engineer interviewing for a job at a startup there’s going to be some form of test from a technical perspective.
After I graduated Startup Institute Boston (SIB) I interviewed at multiple startup companies in the Boston/Cambridge area before I happily accepted an offer at Backupify as an Operations Engineer. Before joining Backupify and doing SIB, I led college recruiting for my last employer. And because I’ve had some great adventures interviewing at startups, here’s my take on what I have learned.
Why Perform Technical Interviews?
Maybe you’ve networked your way in the front door for an interview and you may have a great resume and a fully stocked github to show off your body of work. Why shouldn’t a job offer be handed to you immediately after meeting you in person? Why do these technical interviews at all?
Here’s the bottom line: talking up your skills, having a great resume and maybe even producing a bunch of awesome applications previously is great. However, as a VP of Engineering trying to hire for a junior Ruby on Rails developer for example, its hard to gauge your level of knowledge and general problem solving / thought process without asking you to solve some sort of problem on the spot.
Solving problems on the spot provides insight into your skills and thinking as an engineer. After all, I got into engineering because I love to solve problems. This exercise is known as a “programming question” or “technical interview question.”
Now by asking you this programming question, a VP of Engineering is generally trying to find the answers to these questions:
- Does he/she have the practical ability to build something reasonably simple?
- Does he/she “get it?” Is it easy to communicate the task and does he/she understand it fully before starting?
- Does he/she ask appropriate questions? Does he/she avoid asking questions when it’s probably required?
- Can he/she find answers themselves on their own? Google, Stack Overflow, etc
- Do I (as the interviewer) like working with the interviewee in a pair programming environment, or in discussing their implementation?
- Does the resulting code reveal their style? Do they use a minimalist approach? Do they over engineer?
How to Tame the Beast
Typically, the interviewer is going to make you physically stand at a whiteboard with a marker and work through the problems. Be prepared for this. When you practice, its good to get experience standing up and working through the problem at hand. I don’t want you to end up like Eminem in the movie Eight Mile with the song “Lose Yourself” playing in the background…
“He opens his mouth, but the words won’t come out
He’s choking how, everybody’s joking now
The clock’s run out, time’s up over, blah!”
Before we dive into which types of programming questions you are likely to see, let’s cover the process you’ll need to solve them.
- Understand the problem - ASK QUESTIONS!!! Check your understanding by repeating back what you think you’re hearing: “If I understand correctly, you’re asking…” or “Is that like…?” Interviewers can give you more information or clarify something you may not understand.
- Define the algorithm with a block diagram or a list of steps and check it with the interviewer.
- Define use cases for the function to understand the code that must be written. Think of the corner conditions.
- Slowly, methodically start explaining and writing code. Start off by defining the function with a return type (void, bool, int, string, etc) and inputs needed.
- Remember it’s “pseudocode” so don’t get caught up on syntax. The more you talk, the easier it will be for the interviewer to understand your thoughts behind the code you’re writing and re-steer you/guide you if you’re slightly off
- Once code is written, run an example (test cases)
- Any bugs, find them before your interviewer does
Programming Interviews Exposed
At the Startup Institute, aspiring Developers are taught about Ruby on Rails, JavaScript frameworks and database design during the 8 week program. These topics are all very relevant to web-based startup companies and are essential skills needed to succeed.
So now, maybe if you know the skills needed at a startup you should be great during the interview, right? Well…. not so fast. In my experience interviewing, startups are going to test on programming questions that are for the most part “classical” examples rather than current technology. The focus is on the programming concepts rather than convention or specifics of a language.
Enter the Admiral
In order to handle these classical programming questions, you’re going to have to have a strong understanding of data structures. In my preparation for interviews, I used the book “Programming Interviews Exposed: Secrets to Landing Your Next Job” by John Mongan to help me re-familiarize myself with the key concepts which had previously been dormant in my brain since my days in college at Northeastern University.
Here’s the data structures to study and some commonly tested interview questions:
- Arrays
- Inserting numbers, finding duplicate numbers, sorting a database table
- Stacks
- Adding a value, removing a value, finding a value some positions away from the top
- Queues
- Adding a value, removing a value, finding a value some positions away from the top
- Linked Lists
- Insert or Delete a node at the front or back, finding a Node from the front or back (and using a stack or a queue to do it, hint hint)
- Binary Search Trees
- Insert, Delete or Find a node in the Tree
- Hash Tables
- Hash Maps
- Dictionary (key-value pairs, critical concept in Ruby on Rails development)
And now for an aside…
Admiral Ackbar was the foremost military commander of the Rebel Alliance who led major combat operations against the Galactic Empire in the 1983 Star Wars Trilogy film Return of the Jedi. Now we all know it ends happily ever after with the Death Star 2 being blown up by Luke and the gang, but while fighting the Empire’s fleet, he uttered the words that are now forever etched in internet meme history - “its a trap!”
So what can we learn from the Admiral’s situation? When it comes to programming questions (easily considered to be a product of the Dark Side), there’s a trap… here’s some of the common ones:
- Arrays - index an array at position 0 for the majority of programming languages. Make sure you explicitly say you’re indexing the first position at 0. Multi-dimensional indexing (think row, column) can also be a challenge. Also if you’re asked to sort a database table by a specific column there’s a pretty long list of questions you should be asking your interviewer such as what is the table definition? What are the data types of each column? How many records are there (solving for 10 entries is different than solving for 100,000,000)? Are there duplicates? Define the sort - unique or duplicates included? Etc, etc, etc until you have a clear understanding of the table. Just like that Michael Jackson song, don’t stop until you get enough… information.
- Linked Lists - the use of pointers in general is a trap. But more specifically, when provided with the HEAD node in a Linked List, is your function modifying the real HEAD or a local copy? Pass the HEAD node in by reference (“&” in C++ nomenclature) to avoid this one. Also when thinking about test cases for Linked Lists there’s always 2 - when the HEAD is null and when the HEAD is a real node. Don’t forget about the null condition, its a trap!
- Binary Search Tree - this structure has a root node, a left child node and right child node - each with a value. The catch here is that a Search Tree and a Binary Search Tree aren’t the same - the Binary variety can be nicely sorted with the right child’s value always being greater than or equal to the root value and the left child’s value always being less than or equal to the root. Its a trap, just ask the interviewer to be sure its a Binary Search Tree. Also, nodes without left or right child nodes just point to null… and yes, its a trap.
- Recursion - Maybe you love the concept, maybe you hate it but a problem on Binary Search Trees can easily segue into a discussion about using recursion or a function that calls itself, to modify the data structure. Recursion is an academic topic and often debated amongst software aficionados whether or not it’s useful in the real world (not covered in this post). But interviewers love to test on it so study up on it. Some of the classic recursion problems include:
- Adding/deleting nodes from a Binary Search Tree (and/or any other data structure modification)
- Fibonacci sequence
- Towers of Hanoi
- If the interviewer really wants to torture you… a Sudoku Puzzle Solver
- Algorithm Optimization (Big-O) - Optimization of an algorithm is a common follow up question after you’ve written a solution to a problem on a white board. It usually comes in the form of a question like:
- “How could we make it faster?”
- “How could we make it take up less memory?”
- “How could we optimize this algorithm?”
Big-O analysis measures the efficiency of an algorithm in terms of the time it takes for the algorithm to run as a function of the input size. For an example, I’ve been asked about Big-O after completing a simple array function that found a repeating number. Study up about Big-O and understand the O(n) and O(n^2) notations and always think about the best, worst, and average case for a function especially in searching arrays. A good follow up question for the interviewer is to ask if there’s a case they care about the most for optimization. That way if they say “the worst” you can think about which case takes the most amount of time depending on the input.
Say it with me… Its a trap! And yes, you’ve heard it a bunch of times by now. But preparing for these topics when they come up will give you a leg up on defeating the Dark Side of the interview.
Closing Thoughts
An interview is nerve wracking enough, so don’t make it harder for yourself by trying to fake your way through these problems. The fact is that programming interviews are easy to fail without preparation. So make sure you know the data structures mentioned above. There’s no shortcuts here.
After you’re comfortable with the syntax for the structures and the concept behind them, practice solving the problems using the process mentioned. Do yourself a favor and practice as much as you can before your interview, in addition to all the preparation work you’ll be doing (no one said finding a job was fun or easy right?). You’d be amazed at how much you can improve by solving a problem a day while riding on the T.
Now if you get stuck, and believe me it happens to everyone… stay calm, it’s not over! All was not lost in Return of the Jedi even when it was a trap. Go back to an example or maybe even try a different data structure (for example, maybe you used a stack when a queue would have been easier). Ask more questions to ensure that you understand the problem. Don’t give up.
The preparation will pay off, believe me I know from experience. The more times you’ve practiced solving a problem through the aforementioned process before the interview, the easier it will be live in front of a VP of Engineering when it counts.
Good luck in your pursuit of a career at a startup and forget The Alamo… remember the Admiral.
Vishal Sunak was in the Development track in SIB’s Fall 2012 class. Now he is the Operations Engineer at Backupify
