The Art of the Technical Interview

I have a conjecture that I'd like to share regarding the technical interview process at software development companies:

A software engineer of average or higher skill can succeed at any technical interview.

Surely the terrifying stories of the interview gauntlets thrown down by the engineering giants (Google, Apple, Microsoft, Facebook, Electronic Arts, etc) may have discouraged many qualified developers. A large number of experienced programmers and passionate new grads with everything it takes to be great employees have fallen through the cracks of false negativity. The world's demand for software developers has grown tremendously as technology has empowered our lives and it is unfortunate that we are losing talent due to failed interviews.

I'd like to share some lessons I've learned along the way. These insights come from my experience since university both as a frequent interviewee at companies such as Electronic Arts, Google, Facebook, Twitter, Yahoo, Microsoft, Ubisoft, Mozilla, Qualcomm, and as an interviewer of maybe a dozen candidates. I've had bad interviews and good, I've interviewed candidates both strong and weak; I understand the process. The technical interview is an art and a science of its own. With the correct preparation, a competent developer can master the process, break through the interview barrier, and land her dream job.

Why do we fail?

The most probable reason for a qualified programmer failing a technical interview is inadequate preparation. There are numerous ways one can shoot themselves in either foot during the preparation phase leading up to an interview:

• Not relentlessly practicing problem solving
• Not reviewing computer science fundamentals (algorithms and data structures)
• Not communicating well
• Not studying systems design
• Not practicing writing and testing code by hand on a whiteboard
• Not doing mock interviews
• Not being intimately familiar with the programming languages you claim to know
• Not knowing the benchmark to which you will be evaluated
• Not having a game plan

Knowing the benchmark

While it is certainly possible to play a game without a plan, it is not as easy to win one. You need to know exactly what to expect from your interview in order to prepare yourself adequately. There are great resources available, a few essential ones are:

• Cracking the Coding Interview by Gayle Laakmann McDowell
• Algorithm Design by Kleinberg and Tardos
• MIT's OpenCourseWare Introduction to Algorithms videos and other course materials
• Steve Yegge's Get that Job at Google post
• Palantir's How to Rock a Systems Design Interview post

If you use them and follow the advice given, you will greatly improve your chances of succeeding in a technical interview. I'd like to offer a more specific strategy on how to prepare for your interview. One recommendation I have is that you give yourself a full week to prepare for a technical interview. Note that phone interviews for highly selective development companies are also technical interviews. If you interview with Google, be prepared to write code in a shared Google document as your interviewer talks to you on the phone. In fact you'll probably want to test your setup to make sure that you can type comfortably while talking on the phone.
You should partition your study time based on the priority of study topics:

• 60% whiteboard problem solving, coding, and testing
• 20% studying theory through algorithm design books, online course materials, and web resources
• 15% studying systems design and practicing solving system design problems
• 5% studying the programming languages that may be required by the interview (e.g. C, C++, C#, Java, Python)

Of course your actual time distribution will vary depending on what you know about the companies interview process. If you are preparing for an interview at a gaming company such as Blizzard, Ubisoft, or Electronic Arts, your time may better be spent studying game engine architecture, C++, computer graphics, and mathematics for game developers. Wherever you are interviewing, make sure you do your research and learn what you need to prepare for. Ask your HR contact for as much information as they will divulge to help you plan your preparation. Practice doesn't make perfect. Perfect practice makes perfect. It's hard to pass an exam if you've studied all the wrong things. Your job is to figure out what the right things are and to put all your time into studying for them.
You need to try to get the exact metrics by which you are being evaluated. When a company gives interviews, usually they have a formal process through which interviewers give feedback. Usually it consists of giving a score say from 1 to 5 for certain evaluation criteria. For example, Google might use the following:

• Analytical ability
• Understanding of computer science
• Coding skills
• Communication / personality

You need to know where you have to score points to win the game. Analytical ability includes raw intelligence and your ability to understand problems and come up with efficient algorithms. The understanding of CS relates to your comprehension of data structures, asymptotic complexity, time and space tradeoffs, etc. Coding skills relates to your ability to translate your algorithm to clean code that will be reusable and easy to understand by coworkers.

Communication

Communication is one of the most important points of evaluation for an interview. Interviewers are evaluating whether or not they want to work with you so it is critical that you behave like someone they'd enjoy working with. Explaining exactly what you are thinking when you are trying to solve a problem is very important. You are being evaluated not on your ability to solve the problem but on your thought process and your approach to problem solving. You should never stare in silence at the whiteboard, the floor, your interviewer, the clock, the door, or the window (depending on your preferred escape route). Even if you are stuck, talk through your dilemma or your brainstorming process. Be methodical and follow a logical approach to solving the problem. Not only does this make the interview more interactive, this will also give your interviewer a chance to point you in the right direction. Sometimes all it takes is a single tip from the interviewer to get you on the right path to the correct solution. However if you aren't speaking your mind, they may not have the opportunity to help you. Help them help you. After you've figured out your algorithm, talk through the coding. You may be making a mistake in the implementation and the last thing you want is to write tons of code on the board then have to erase it all because you missed a key implementation detail. You also don't want the room to go silent as you write away furiously for 10 minutes and then finally reveal your solution to the world. In your preparation, talk out loud while solving problems on the whiteboard. Treat it like you have an omnipresent interviewer. You want excellent communication to be second nature to you. It will also prepare you for the realities of 2-5 back to back interviews where you have to be talking. Your mouth will get dry --make sure you have water, and you may get tired standing and writing for so long. Be ready for it. An interviewer will notice when you communicate very well. It will make them want to work with you. It will make them more likely to stand up for you when the company decides your fate.

Mastering the whiteboard

Figure 1: Whiteboard layout


When you write code in an editor or an IDE, you have numerous tools to improve your productivity. Those same tools are your enemy when preparing for a technical interview. Besides just trying to memorize problem solutions, practicing solving problems in an IDE with syntax checking, auto-completion, a compiler, and a debugger is one of the worst things you can do. You won't have such training wheels during the interview. You need to be ready for the whiteboard. If you don't have one, go somewhere that does and practice solving problems there or head to your local office supply store and buy one for $40. The cost can easily be justified as an investment since it will help lead you to your awesome new higher paying job. Now that you have a whiteboard, make use of it. Get a large list of interview problems (Cracking the Coding Interview has 150 of them, Elements of Programming Interviews has 300), pick some and start working them out on the board. Here is a winning approach:

• Ask your interviewer questions to clarify the problem (in preparation you'll have to make assumptions)
• Write important details on the right side of the board (inputs, output, requirements, and constraints)
• Begin by drawing diagrams and writing test cases on the board while talking through the problem
• Talk through different approaches to the problem writing down any important insights you have that may help you
• Once you've figured out the algorithm, write pseudo code (make sure to state that real code will follow) to clarify your thoughts
• Discuss the time and space complexity to make sure that this solution is adequate
• Begin writing code on the top left edge of the board (always check validity of inputs and edge cases)
• Once you've completed writing code, immediately (before being prompted) start running through the code with your test cases
• When you are confident the solution works, let the interviewer know

If you practice solving lots of problems like this, it will be second nature to you and when it comes time to perform for the interview you will be very comfortable and confident. When you are practicing on your board, still talk through everything and make sure you are aware of your lapses in communication so that you know to correct it for the next time. It is hard to break bad habits. If you always solve problems in silence, you may have a hard time speaking up during the interview.
Whiteboard space management and partitioning can be very useful. I like to divide the whiteboard in half —keeping problem details, algorithm notes, diagrams, test cases, and pseudocode on the right side (see Figure 1). The left side is reserved for code. Start at the top left corner and don't write too big or you risk running out of space. It is best to not have to worry about erasing the board or writing code in a tiny font at the bottom edge of the board. In practice, you'll become used to this format and it will benefit you in the interview. It is important to not erase all the stuff you wrote down before coding on the right side because you will want to refer to it. It is easy to forget details after you've come up with the algorithm in your head. Writing important information down will help you remember and will prevent you from needing to ask the interviewer to repeat something from the problem definition. Also an interviewer who sees you fill the whiteboard in such a structured and methodical way will likely be impressed with your problem solving ability. In the time leading up to the interview you'll want to be very intimate with your whiteboard; take the time to think about how you can use it to your advantage.

The Secret to Success

The preceding quote from David Gelb's 2011 documentary Jiro Dreams of Sushi expresses the Japanese concept of shokunin kishitsu: the craftsman’s spirit. Matt Linderman of 37signals wrote a post describing the idea. I believe that the software professional should take pride in her work, continuously investing in learning and working towards perfecting her craft. The key to this is to be passionate about your job. If the only reason you want to work for a technology company is for the money then perhaps you shouldn't make it through the interview process. Great companies want great people who love what they do and will bring passion, creativity, and innovation to the workplace. You won't truly be successful in life until they don't have to pay you a dime to do what you do. Because you are a shokunin and you don't really care about the money. Well maybe you do, but only enough so that you don't have to care about it.
I hope you aren't overwhelmed by all the information and all the work involved with preparing for the interview process at a highly selective company. You should treat this with the importance it deserves. An interview is the gateway to that dream job that will change your life. I hope that this knowledge will empower and motivate someone to learn from their failures and put forward 100% in preparation for their next interview. Your interviews may be done within a day but they cannot control how much you practice, study, and prepare. Given sufficient time for preparation, a sound game plan, and hard work; success is just a day away. Good luck.

Goodbye Blogger

I'll no longer be posting to this blogger. I haven't blogged in a while but if I do it will be at: https://medium.com/@pierrebear so feel free to follow me there.

Android Meetup Talk: Tips for Better Android Development

I gave a talk at a Toronto Android meetup earlier today. The turnout was great and I am glad that everyone enjoyed the content. I hope that it will help guide Android developers down the right path. Here is the abstract from the talk:

The goal of this talk is to help bridge the gap between amateur, intermediate, and advanced Android developers. Pierre will provide his tips for more professional, productive, and effective Android development while sharing common mistakes that new and even experienced Android developers make. This talk will be more of a general discussion about software development in the context of Android than a hands on tutorial on how to solve specific programming problems. Pierre hopes to illuminate the path to becoming a highly valuable Android developer and a software craftsman.

I promised I would post my slides and notes so here are the slides and the notes ready for your consumption.

Thanks to everyone that came out and I hope that this information will be useful as well for those who did not make it.

Installing IdeaVim on Android Studio Preview

Update: This post is no longer relevant. IdeaVim shows up in the Android Studio plugin repository and can be installed as expected.

The announcement of Android Studio at Google I/O 2013 marked the rise of IntelliJ Idea as the new standard for Android development. Being a long time Idea user, I'm glad to see Google moving away from Eclipse and Idea stepping into the lime light. The "What's New in Developer Tools" session from yesterday was essentially an introduction to Idea featuring the CTO of JetBrains and an Android Tools engineer touting the new screen layout preview skins, the resource string hints, and the like. This is a good talk for Eclipse users who want to upgrade to Android Studio, however it was quite tedious for seasoned Idea users.

I was excited about switching from my normal Idea environment to this new Android Studio and loaded up my Android project to find that the IdeaVim plugin no longer showed up in the Plugins repositories. This could be a deal breaker for me. The advantages of Android Studio are easily offset by the loss of productivity I'd suffer if I couldn't use IdeaVim. I'm sure support will be added eventually but that doesn't help me now.

Turns out that a manual installation of IdeaVim works. Here are the steps:

• Download IdeaVim plugin from JetBrains Plugins
• Extract and copy Vim.xml to $HOME/Library/Preferences/AndroidStudioPreview/keymap/ to get the Vim keymap
• Open the Plugins dialog in Android Studio and select "Install plugins from disk..." Locate your extracted IdeaVim.jar and load the plugin.
• Restart Android Studio and the plugin should be activated

It seems that I have IdeaVim working correctly. I haven't spent too much time in Android Studio to know if there are any issues with IdeaVim. I'll keep everyone posted.

Curing Depression at Random Hacks of Kindness Toronto

In his 2011 OSCON Data talk, Google's Steve Yegge argued that good hearted programmers will take interest in solving the harder, more impactful, world problems at the end of their careers.

"As you gain wealth, if you're not a total mercenary, you start getting interested in charity and helping people who are needy and you start getting interested in politics, and all these kind of hard problems. And a lot of them, interestingly, are data mining problems."

Yegge challenges programmers to start getting involved now rather than later in their career. He believes that if we spent less time trying to scale FarmVille and more working on the world's hardest problems, we might actually have a good chance of solving them. Yegge actually quits his job at Google at the end of the talk so that he can focus full time on solving these problems.

The other, more notable, instance of this turn to philanthropy is by Bill Gates in his late career. The Bill & Melinda Gates Foundation was established in 2000, followed by Gates stepping down as CEO to begin full time work at his charity. The foundation has since had a major influence on global health, global development, and education.

Random Hacks of Kindness (RHoK) challenges developers to use technology for social good and to work on hard problems that benefit mankind. RHoK organizes hackathons where volunteers sign up to work on a prototype solution to a specific problem.

"RHoK Global June 2012, the 6th Random Hacks of Kindness hackathon, came to a close this weekend, with technologists, designers, experts and activists coming together in 25 cities in 14 different countries to “hack for humanity.” Over 900 people participated worldwide, with the largest event in Nairobi, Kenya at 130 people. 

During an intense 36 hours, these 900 hackers for humanity came together in 132 different teams to address 124 unique problems and they built 138 solution." RHoK Blog

This was my first time attending RHoK and it was a great experience. The Center for Social Innovation, in downtown Toronto, hosted 40+ volunteers working on 8 different problems ranging from using technology to prevent pregnancy related deaths in developing countries, to georeferencing and organizing imagery from the International Space Station.

My team worked on curing depression through better data collection and analysis. 1datapoint was founded by Jonathan Polak, a former sufferer of mental health issues, with the idea that one datapoint is not enough to make a proper diagnosis.

 

"300 million prescriptions for anti-depressants every year. Suicide is 2nd highest cause of death for under 25 age group. Most diagnoses made with just one visit to doctor."

 

After much discussion about the scope of the problem, the requirements, the possibilities, and the design, we got to work building an Android application for quick, easy and unobtrusive collection of mental health data points. We focused on getting the user in and out as fast as possible; making for a pleasant user experience. We succeeded in prototyping a beautiful, simple and intuitive application that could potentially provide doctors with the crucial background data they've been lacking in their analysis in the past.

Our graphic designers came up with this clean and pleasant design for the home page:

We developed a novel data collection user interface that allows the collection of two data points from a single touch. As the focus is on measuring the delta and not quantifying levels of mental states, we were able to make the graph minimal:

I also was inspired to come up with a minimal UI for time selection that allows setting the time in 2-3 touches:

We decided to have two self-explanatory buttons at the bottom of all data collection pages to reduce the cognitive burden of the user who may be unsure what the back or home button will do to their data. Each page has these that allow for a quick exit. This was one of the many hot topic discussions we had over the weekend on designing a user interface for an anxious person.

Overall, it was a valuable experience both from a philanthropic and from a professional development standpoint. The mix of people at the event was very broad: there were students, professional developers, designers, entrepreneurs, etc. A lot of great demos came out of the weekend and it was wonderful to be in such a dynamic, exciting and creative environment where people were working out the goodness of their hearts rather than for a paycheck. I plan to do more hacking for humanity in the future and will take up Yegge's challenge to start learning about the math, physics, bioinformatics, data mining, and all the other tools that will be essential for using the skills that we have been blessed with as developers to begin developing a better world.

A Simple Facebook Cover Photo Hack

For those of you who haven't entirely abandoned Facebook for the uprising Google+, you'll likely have noticed that Facebook has once again made a significant change to the Profile page. The Facebook Timeline is the product of Facebook's new focus on UI design. Love it or hate it, it's here to stay.

One of the most beloved changes has been the addition of a large "cover" photo to the profile page. Facebook tells us to: "Fill this wide, open space with a unique image that represents you best. It's the first thing people see when they visit your timeline." Indeed, the cover photo and the profile picture provide a great opportunity for one to show off their creativity. See "Facebook Timeline Cover: 40 creative examples" for some interesting cover hacks.

A simple Facebook cover photo hack is to use the profile picture as a transparent window into the cover photo. LifeHacker recently posted an article describing how to do exactly this with Photoshop or Gimp. Inspired by this post, I decided to make a simple HTML page to preview this kind of cover photo. Below you will find the source code to this test page:

To test out your cover photo, you would modify the img tag (.background img) to point to your large cover photo. The cover photo is 850x315px, but you'll need a larger image than that to show through to the profile picture. Using the Chrome Dev Tools, Firebug, or a similar CSS/DOM debugger you can adjust the dimensions and position of the cover image to your desired position. 

Now you still would need to fire up your image editor to crop out your profile picture, which needs to be 180x180, and your cover photo which should be 850x315px. This will require keeping track of the offsets and the dimensions you've been testing with. It makes for a simple tool for seeing what kind of cool cover/profile combinations you can come up with. You can test out your profile picture by enabling the commented out profile img tag and seeing if it worked out the way you desired.

You could now, in theory, do some simple crops with your default system image editor and avoid using the heavyweight Gimp or Photoshop. However, I've found it to be tricky to get Facebook to do exactly what you'd expect with your uploaded photos. I had to do a few uploads of profile pictures before I got the satisfactory alignment which completed my Facebook cover photo hack.

Bad Android Typography: A Tale of Text Justification

"From all these expe­ri­ences the most impor­tant thing I have learned is that leg­i­bil­ity and beauty stand close together and that type design, in its restraint, should be only felt but not per­ceived by the reader." —Adrian Frutiger

When speaking of typography, one must consider a multitude of variables that go into the art of arranging type to display language. There is the selection of the typeface, the point size, the line length, the line spacing, the spacing between groups of letters and the space between pairs of letters. The end goal is of course legibility, however a good designer will seek a visually aesthetic expression of the language through typography. There is an emotive response that follows the sight of visually pleasing typography, it encourages the consumption of the content. Magazines, newspapers and books all have a rich history in beautiful typography.

Figure 1: Bembo text

The Web, being the new canvas for textual content, has been slowly following the lead of its dead tree predecessors. The implementation of the W3C's Web Open Font Format (WOFF) among all modern desktop browsers gives designers limitless possibility for beautiful text design on the web. Where the Web trails behind is in text justification. Full text justification on the Web is known to be flawed (See Batchelder: Bad Web Typography). Text that is fully justified on the Web may lead to terribly inconsistent word spacing that is very noticeable to the reader.

      I stand here today humbled by the task before us, grateful for the trust you have bestowed, mindful of the sacrifices borne by our ancestors. I thank President Bush for his service to our nation, as well as the generosity and cooperation he has shown throughout this transition.
       Forty-four Americans have now taken the presidential oath. The words have been spoken during rising tides of prosperity and the still waters of peace. Yet, every so often the oath is taken amidst gathering clouds and raging storms. At these moments, America has carried on not simply because of the skill or vision of those in high office, but because We the People have remained faithful to the ideals of our forbearers, and true to our founding documents.

The text above is fully justified with a left and right margin of 200px. Observe the spacing of words on each line and notice the inconsistency. Text justification involves aligning to the left and the right, stretching word spaces to obtain the most uniform amount of per word spacing. When the words are too "loose" it makes for a visually displeasing effect. Hyphenation is used in typography to reduce the looseness of lines. However, browsers don't hyphenate fully justified text. There have been efforts to hyphenate text using Javascript. A script called Hyphenator.js was developed to automatically hyphenate text and is available on Google Code.

On Android, using the standard TextView widget, the problem is worse. The TextView, which is a View used to display text, does not support full justification at all. This means if you wanted to make a reader application similar to the Amazon Kindle app using a TextView, you'd get text that looked like this:

Figure 2: Android TextView left aligned text

The jagged right side of the text is quite unpleasant and there is much wasted space where more text could fit in the viewport. There is a fairly simple way to get full text justification on Android; it requires using a WebView. A WebView essentially is like embedding a chrome-less browser into your Android application. This means you get all the benefits of laying out text on the Web, as well as the aforementioned deficiency.

                  

       Figure 3: WebView with fully justified text   Figure 4: WebView with fully justified text and hyphenation 

The image on the left shows how mobile WebKit (the rendering engine which powers the WebView) lays out the fully justified text. The second image shows the layout hyphenated by the Hyphenator.js script. The use of two hyphens greatly improved the spacing for lines like "seen grasshoppers and" and "ladybugs. My uncle Bob". The hyphenated WebView text, while superior to the default TextView and the standard fully justified Web text, still has its flaws. The Amazon Kindle Android app does a better job of laying out the excerpt of Roger Ebert's "Life Itself: A Memoir". 

Figure 5: Amazon Kindle Android Application

The Kindle app does use hyphenation although it is not shown above. It clearly has a much more uniform spacing of the words though some lines are still suspect. For example: "me. Hal Holmes has a red" stands out.  The difference in the WebView layout and the Kindle layout may be attributed to the difference in font type and size, margin size, line spacing etc. The WebView examples use Helvetica and I am not sure which font is being used by the Kindle app. It is also unclear whether or not the Amazon Android app is using its own layout algorithm or is using a WebView with a hyphenation JavaScript. 

So it seems that the problem with full justification on the Web plagues Android because developers must use a WebView to achieve it unless they are brave enough to roll their own text justification algorithm. In case you are interested, try solving this problem from Kleinberg's Algorithm Design concerning "pretty printing" of text: 

But unless you are passioned by Markov Chains or Dynamic Programming, you'll probably stick to a WebView with text-align: justify. 

[Update] I've just discovered that the new CSS3 Text W3C working draft describes support for hyphenation within the browser: http://www.w3.org/TR/css3-text/#hyphenation. In fact, it's been rolled out in the latest WebKit browsers and in Firefox. I haven't tested it out yet but the usage is fairly standard:

p {
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    hyphens: auto;
}

It's great to see typography on the Web moving forward.