The Android back button is broken

I explain why and offer some solutions on Google+.

I explain why releasing the Kindle Fire was a Mistake

Please comment over at the post on Google+.

The Reason Android is Laggy

I took a deep dive into the reasons Android is laggy over on Google+

https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS

X86 is doomed

My thoughts on AMD transitioning away from the the X86 market https://plus.google.com/100838276097451809262/posts/1K5RYkiTyTU

Why APM?

I’ve accepted an Associate Product Manager (APM) internship with Google this Summer. The Google APM program is a unique opportunity to be mentored by Google’s top executives and managers while directing one of Google’s products. Many tech industry leaders have come out of the program, including a personal hero of mine, Bret Taylor.  An APM internship is likely not as intense, but I’ll do everything in my power to get the most out of the experience.

My eagerness for the role comes as a surprise to many of my friends and colleagues. I’ve been a die-hard programmer for the last five years. Product management is foreign to me. So why the change?

Programming has become too comfortable. I’m confident that I can rise to the challenge of most programming projects. I no longer have the excitement and fear that comes with a new internship. Don’t get me wrong, I could still be a far better programmer and there are still many areas of computer science of which I’m painfully ignorant. It was very difficult to turn down some of the other offers I received.

But, the APM position fills me with a fresh sense of excitement and fear. I must bring a completely different skill set to the table to be a successful APM. Instead of writing code, I’ll be writing email and designing product specs. Instead of giving technical presentations, I’ll be pitching my product. Instead of a mentor or manager telling me what to focus on, I’ll be managing older and wiser SE’s with years of experience.

My time management, organization, and leadership skills will be pushed past their limit. I’ll probably fail. And that’s why I have to do it.

How to Land an Internship at a Top Tier Software Company

Want to work on the highest profile software projects in the world? Want to get paid more per hour for an internship than the average CS grad makes out of school? Want TechCrunch to call you a genius? Then read on to learn how to land a killer internship at companies like Google, Facebook, Amazon, Microsoft, or Apple. In the following paragraphs I will teach you how to land interviews and succeed at technical interviews. This is the guide I wish I had three years ago when I was starting out as a fresh-faced frosh.

My Credentials

I’m Software Engineering student at the University of Waterloo in my third year. In the past two years I’ve interned at a startup called Xtreme Labs, Amazon.com, and Google. At Amazon I worked in the exploding industry of cloud computing – creating the next generation of Amazon Web Services. I worked on Elastic Beanstalk. At Google I contributed to the upcoming Honeycomb release of Android. In addition to these internships I have interviewed with many startups and established companies like Facebook, Microsoft, Zynga, Bloomberg, Hulu, and Qualcomm.

I still have three more internships to go before I graduate. I expect to learn even more about the interview and internship process in that time, so this is not the definite guide to software engineering internships. Feedback, corrections, and suggestions are welcome.

How to Land Interviews

Scoring interviews with respected software companies is difficult, but with an impressive resume it is possible even in your early years. The key is standing out. Your grades don’t matter as much as your side projects. If you submit a tight resume that boasts that you build websites, work on a start-up, and run an active github account, you’re almost guaranteed an interview with any tech company (Exception: Microsoft, they only interview upper year students). Once you complete your first internship, interviews are easier to get because once you work for one big software company, the rest want you.

Don’t have any side projects or notable work that sets you apart? Unfortunately you might not get a top-tier interview in your first few years of school. But maybe you’ll get lucky, especially if you follow my resume do’s and don’t’s.

Do…

• List all side projects and open source contributions front and center.
• List Notable languages and technologies you know. Emphasizing that you know some of the cool, hip languages suggests that you’re a passionate and smart techie. Things like Haskell, Scala, Node.js, and NoSQL databases. Experience writing iPhone or Android apps shows you are self driven and have an entrepreneurial spirit.
• List notable skills, activities, and interests. They shows you have a life outside of computers, which many companies claim to look for. And Sometimes they will catch the eye of the reader or interviewer, which helps you form a personal connection.
• Cut out hackneyed phrases. For example, you don’t need to mention that you have “Excellent written and oral communication skills” or that you’re a “team player”. Those phrases are boring and the poor resume reader will hate you. Let your team projects and previous work experience implicitly illustrate your strong interpersonal skills.
• List your CS interests. Think scrum is the best thing since canned peaches? list it. Can’t get enough of path finding algorithms? Put that down. Convinced concurrency is going to revolutionize software? Mention it.

Don’t…

• Describe the classes you take in school (unless they are noteworthy, i.e. taking a grad level course on compilers)
• Make the resume too long. Brevity is awesome. Cut out the chaff and emphasize the wheat.
• Be modest. A resume is no place to be humble. Describe all your projects and experience in the most impressive way possible. However, don’t lie. Even if you can fake it in the interview you’ll probably be out of your league in the job.
• Make your resume look like everybody else’s. This is absolutely crucial. Make your resume standout by using a different font and layout than your friends. However, never sacrifice readability for a novel layout.

For some examples of resumes, checkout mine or my friends Fravic Fernando [PDF] and Derek Thurn [PDF].

Get a Recommendation

There is a better way to get interviews. Get a recommendation. I was recommended to Google by a friend of mine. If you’re not socially awkward penguin, this is the best way to ensure you get an interview. Full time employees will practically beg you to let them recommend you because of the generous referral bonuses most companies handout. Even if you can’t get a full time to recommend you (because you don’t know any), an intern referral can be just as good.

The key to getting recommendations is effective networking. Network at school and work. Meet people at conferences and hackathons. Befriend the recruiters of major tech companies. Effective networking is outside the scope of this guide, but it’s essential to a lustrous tech career.

How to Ace Interviews

Software engineering interviews test you on your ability to think in highly stressful situations, communicate your ideas effectively, and win over the interviewer with your charm and intelligence. Typically interviewers do this by asking you to quickly and efficiently solve algorithm and data structure based software questions while clearly explaining your thought processes.

This is actually incredibly hard. This is how Google, Amazon, Facebook, and Microsoft can claim they only hire the best people, by failing most people at the interview stage. Many qualified candidates fail, but that’s on purpose. It’s better to have false negatives than false positives. See Joel Spolsky’s influential essay.

Many online guides to interviewing at Google perpetuate the misconception that interviewers ask logic questions, such as “You have a weight scale and eight rocks. One of the rocks is lighter than the rest. How do you find the light rock?” You will never be asked a question like this, so don’t waste time practicing them.

Another misconception, that unfortunately my own school perpetuates, is that you’ll be asked soft skill questions such as “When was a time you resolved a problem with a coworker?” I have never been asked a question like this by a top tier company. Typically the only kind of question you will be asked are algorithmic questions. Note: startups and stodgy, old companies like IBM and Sybase will ask you soft questions.

Startups want to know why you really want to work for them. They’re looking for extremely talented and motivated individuals. Chances are they are only hiring one or two interns, so there is no margin for error. Y-Combinator startups generally want to see your github account and value if you’re somehow involved in the startup community. Side note: if you go for startups, be prepared to get paid less and work harder, without any guarantee of equity. It’s not for the faint of heart, but it’s one hell of a way to learn.

The first step to mastering interviews is studying core computer science concepts. Every question you are asked in a technical interview will involve at least one of these concepts:

• Objected-oriented programming
• Single and two-dimensional arrays
• Single, double, and circularly linked lists
• String manipulation algorithms i.e reverse a string, find the longest palindrome
• Recursion
• Hash tables
• Stacks, queues, and heaps
• Trees
• Binary search
• Merge sort
• Quick sort
• Linear time sorts (Bucket sort, counting sort, radix sort)
• Depth and breadth first search
• Pointers
• Bitwise operations
• Algorithm solving approaches (divide and conquer, brute force, dynamic, etc)

Other more advanced concepts that are nice to know are design patterns, graph theory, and map reduce. I recommend picking up a copy of CLRS, it’s fun to read (if you ignore the proofs) and covers most of the bases. Additionally it will probably be the book for your algorithms class.

Programming Languages

Usually you can write code in any programming language, but I’d recommend at least knowing Java and C/C++ to cover cases where no choice is given. For example, Qualcomm will often require you to write C functions. Google, Facebook, Amazon, Microsoft and VMWare will typically let you choose the language of your choice within reason. Occasionally you will be asked questions about assembly code. A decent understanding of how to use the stack, set registers and jump in and out of functions is important.

Python or Ruby are excellent choices for programming interviews because of their succinct and easy to follow syntax and powerful built-in features and the general familiarity in the software community. Knowing one of the “hip” languages can be useful. A friend of mine and his interviewer bonded over a shared love of Haskell, which secured him the job.

Practice, Practice, Practice

It’s vital that you are comfortable coding on paper or a white board. I was totally unprepared for the first time I was asked to code on paper. I was so nervous I botched a simple linked list reversal algorithm. Since then I’ve practiced coding on paper before every interview period at Waterloo. Get a bunch of friends together and ask each other questions you’ve heard in interviews or found online. It’s invaluable preparation.

Failure is not an Option… Usually

If you are asked a technical question in an interview and cannot provide reasonable answer in a reasonable amount of time you will fail. No exceptions. Most companies do two or more 45 minute interviews. In a 45 minute interview expect to answer two to three questions (occasionally one question if it’s very tough). If you only manage to get through the first question, you failed. If you don’t finish the second question in time, you fail. If you sit there quietly for too long you will fail. If you come up with an O(n log n) solution and don’t even realize there was a O(n) solution, you usually fail.

But… sometimes you get lucky. During an interview I came up with a O(log n + k) solution to a problem when the ideal solution was O(log n), but I explained that I implemented it my way for simplicity. After the interview I assumed I failed, but I still got an offer. This illustrates that it is critical to express yourself and your thought process clearly. if you can’t come up with fastest solution, at least explain that you’re aware that one exists and roughly how to implement it.

Hints

Sometimes you’ll need a nudge in the right direction to finish a question, and it’s acceptable to ask for a hint. For example, I was asked, “How can you implement a queue using only stacks and still achieve efficient dequeue() performance?” I started off by quickly describing the operations of queues and stacks, and then explaining the naive solution and how it would require O(n) time to dequeue an element. I was a bit stuck, so I asked for a tiny hint. My interviewer said, “what if you used two stacks?” “Eureka!”, I shouted and then coded up my implementation and described how it worked. Asking for that hint gave me enough time to answer the next question and move on in the interview process.

“Heard this one before”

One gray area of interviewing concerns what to do when you receive a question you’ve heard before. You can either lie and say you’ve never heard the question, or reveal that you know the solution. I’d recommend admitting you know the answer, because this establishes a bond of trust between you and the interviewer. Getting a job by lying isn’t the best way to start an internship.

This has only happened to me once. I stopped the interviewer mid question description and told him that I’d heard that one before, and I quickly described the solution. Instead of asking me a new question we just had a chat about life the company I was interviewing for. I got the offer.

Poker Face

The one aspect of interviews I hate and fear is the poker face. This is when the interviewer never lets on if you’re on the right track with a problem. He or she will simply frown at you, never revealing whether you’re making a complete idiot of yourself. You’ll finish writing code only to hear, “Are you sure that’s correct?” This is the most terrifying question an interviewer can ask you. Stay calm and carefully walk through your code and explain what it does. There is nothing else you can do. On occasion, post-interview, I realize I made a mistake or even misunderstood the question. It’s a terrible realization.

I’d estimate that about half of interviewers use the poker face technique. It is the stuff of nightmares.

Social Skills

Beyond pure skill at solving programming problems, social skills are critical to interviews. If you’re a socially awkward penguin and can’t imagine wowing an interviewer with your social skills I suggest reading How to Win Friends and Influence People by Dale Carnegie. It will teach you a great deal about how to get what you want and still make everybody happy in the process.

For example, in an interview I recognized my interviewer from a presentation he had given the year before. After introducing myself and shaking his hand, I mentioned how much I had enjoyed his presentation. This sparked a 15 minute discussion. When we actually began the programming questions, I only had time to answer one. I feared that I had failed, but to my astonishment, my interviewer brushed it off by saying we had wasted lots of time talking and not to worry about it. I later learned that the question I missed was a real doozy. That discussion might have gotten me the internship.

Confidence is king. Don’t constantly ask the interviewer if you’re doing it right. It makes you look weak. Act like you’re interviewing the company to see if they are good enough for you, as if it’s a forgone conclusion that the company would want you, and that you’re trying to decide between them and three others. Just like in dating, nobody wants to be around somebody needy. However, avoid arrogance. If the interviewer suggests something to you during a problem, by all means take their advice. Interviewers love it when you take their advice.

It’s OK to make jokes. Especially at a place like Waterloo, the interviewer will appreciate some humor after a day of boring interviews. It’s best to avoid self-deprecating humor. I once joked that I was terrible at recursion during an interview and despite answering all questions correctly I didn’t get an offer. Most importantly, never joke that the product of the company you are interviewing with is evil. Especially if that company is Sandvine. Apparently just because they make deep packet inspection technology doesn’t mean they told Comcast to use it. Learned that the hard way.

One area where social interaction can make or break the interview is the last five to ten minutes when the interviewer asks you if you have any questions. Start asking the interviewer what he or she does at the company, how long they’ve been there, and if they like it. You’ll have an interesting conversation that will make you stick out in the interviewer’s mind later. As a plus, you’ll learn a little bit about the culture and happiness of employees at that company.

Dress Code

Don’t wear a suit. Suits are overly formal for interviewing with hipster, west coast software companies. Plus, who wants to work for a company that expects a suit in an interview? Walk into the interview in jeans and a trendy t-shirt from threadless.com. For example, I showed up to an interview with Facebook wearing the three wolf moon shirt and my interviewer smiled, laughed and said that was the coolest thing he’d ever seen somebody wear to an interview.

Note due to reddit outrage: This advice only applies to laid back consumer products companies and startups. Dress formally for healthcare tech companies, banks, defense contractors and companies you aren’t sure about. When in doubt, go for business casual.

A rising tide lifts all Boats

Help your friends prepare for interviews. Do everything you can to get your friends good jobs. Recommend them for a position at your current internship. The more friends you have at good companies the more referrals you can get in the future. I have friends at every major tech company, which will help when it is time to apply for full time positions.

Even when you’re competing with your friends for the same job, help them out. Most top tier tech companies will hire as many interns as are qualified. Even if you’re friend does a better job in the interview than you, that likely has no bearing on the results of your interview. Plus, having friends with you on an internship is a blast. You can move across the country and live together. Last term I lived with six other Software Engineering students in Mountain View. It was epic.

Now go forth and prosper!

So there you have it. You should be now be prepared to succeed at applying and interviewing with top tier tech companies. It’s a lot of work, but it’s worth it. One final word of caution. I’m merely a know-it-all college student. Take everything I’ve said here with a giant grain of salt.

Thanks to reddit for suggesting various improvements.

Two weeks at Google

I’ve been a new Googler for the last two weeks (or Noogler as they like to call us).  I’m having a wonderful time and have already grown accustomed to tons of free food.  I’m very confused on the weekend when nobody gives me food  ><.

The engineering talent at Google tremendous and Google culture is intellectual, but fun.  I was surprised to find out that many of my favorite authors work for Google (such as Joshua Block and Scott Pilgrim) and have offices within a 3 minute walk from me.

However, I’m not as huge  a fan of Mountain View.  I’m living in a suburbia and it’s hard to get around without a car.  I wanted to go to a movie last night but we had no way of getting there except by taxi. Besides that, the weather has been gorgeous everyday.  No rain and blue skies throughout.  In fact I’m starting to miss the sound of rain.

Midterms argh

I’ve got a midterm tomorrow so instead of studying I’ve decided to post on my neglected blog. So without further ado:

I try to avoid taking a strong stance on programming languages because depending on one’s need there are plenty of acceptable languages for any project.
Java or C#? Whatever.
Python or Ruby? Meh.
Scala, Erlang or perhaps Haskell? *shrug*

However, the University of Waterloo, in its wisdom has decided that CS 246: Software Abstraction and Specification is to be taught in C++. C++ is the absolute last OO language that should be used to teach CS 246. We spent way too long learning about copy constructors, operator overloading, memory management, pointers, references, friend functions, and forward declarations instead of the proper principles of effective OOP. CS 246 should be about design patterns, agile development, UML, unit testing and the like. We are getting to that, but half the semester was wasted learning the intricacies of C++.

Don’t get me wrong, a strong background in C++ is an asset for any programmer, but it’s just a terrible teaching language. Not to mention it’s not portable. For the last homework project, we had to implement the game of Euchre. The specification provided was incomplete, so the only way to determine the correct output was by copying logic and output from the provided reference implementation. Not a bid deal. Except…

The only provided binary was compiled for 64 bit Linux. Turns out my Ubuntu VM is 32 bit. Crap. I was forced to SSH into the slow Waterloo machines to test the code (I’m too lazy to install another VM). If only the provided code was Java byte code, a Python .pyc file, or even Microsoft Intermediate Language (yes, MIL is portable thanks to Mono).

TL;DR: I finally understand why CS departments don’t teach CS using C++ anymore (except Waterloo, that is).

JQuery and YUI

Recently I’ve had the pleasure of developing a web app using a combination of jQuery and YUI on the front end.  These two frameworks take strikingly different approaches to JavaScript development.  YUI is massive, verbose, and feels like using a mildly over-engineered Java library.  JQuery code tends to be much smaller and functional.  I imagine jQuery is much closer to what the creators of JavaScript originally had in mind.  The ease of navigating the DOM in jQuery needs to be seen to be believed:

<script>
     //selects the first li element from the first ul under
     //the navigation element in the following HTML
     $("#navigation ul:first li:first"); //the entire JQuery code
</script>
<div id="navigation">
<ul>
   <li>foo</li>
   <li>bar</li>
   <li>Ackbar</li>
   <li>Bob Barker</li>
</ul>
<!--- subnav --->
<ul>
    <li>Some other useless list item</li>
    <li>Jeff Bain should use JQuery</li>
</ul>
</div>

However, YUI does have one advantage. The YUI GUI widgets are extremely powerful and exceed in breadth and depth the widgets of jQuery-UI. For example, jQuery has no equivalent of the YUI DataTable. Recently I was tasked with scrapping the data in a HTML <table> from a live website.  There was lots of superflious rows in the table, so I used jQuery’s AJAX API’s to download the table and remove all the irrelevent information. Once complete, I passed off the formatted <table> data to a YUI DataSource, which generated a beautiful, sortable, and resizable YUI DataTable on the fly.

Without jQuery, it would have been agany using YUI’s verbose and limited selectors.  Without YUI, I would have had to either create my own datasheet class or trust that a bug free and costumizable jQuery plugin existed.  jQuery and YUI are an awesome combination and cover just about anything you’d want to do on the web.

Disclaimer: I used YUI 2.8.  It’s entirely possible that YUI 3.0 is better, however it’s missing most of YUI 2′s nice widgets – defeating the point.

Concurrency versus Distributed Systems

Up until recently I was a bit fuzzy on the difference between concurrency and distributed systems.  It was not until I was studying Facebook Chat, Erlang, Scala, Go, and the new python web server Tornado that it finally clicked.  Concurrency simply implies that two or more pieces of code are executing at the same time.  Distributed system are running concurrently on many different machines.

The difference is a critical when planning how to scale a system.  With simple concurrency, you can only scale a program vertically- by adding faster or more cores, installing more ram, etc.  However, a properly abstracted distributed system can be scaled horizontally – adding in more machines or nodes to the system easily by simply modifying a config file.

Scala and Erlang and Google’s new language Go share a model of concurrency based on message passing.  However, only one of these languages, Erlang, natively supports distributed systems using its message passing system.  Erlang’s native and transparent support of distributed computing is one of the reasons Facebook chose to use it for Facebook Chat. Other languages like Scala and Python require cumbersome third party libraries to support distributed computing.  Scala’s lack of native support for distributed computing is particularly interesting given that it’s concurrency model is directly based on Erlang.

So I could learn Erlang, or try to learn distributed programming in Python. It has tons of third party options for distributed programming, but as yet I don’t know which is the best.

Thoughts? Am I an idiot?

PS: Thanks to my six readers Jeff, Thor, Karan, Eric,  Rachel, and Dad for reading!

EDIT:

And Jamie (Nice blog dude! (Omegle Voyeur is hilarious))