Monday, August 24, 2015

Resources for Preparing for the Google Interview

Google interviews are the source of fable and mystery if you search the Web. A quick "Google" will return a myriad of pages documenting war stories, impossible brain teasers, inconsistent hiring methods, and too many rejection emails and phone calls.

I myself have interviewed with Google twice for a Software Engineer position and have not received an offer. So you're thinking - "he didnt get in. What qualifies him to write about getting into Google?";  in a word - nothing. This is just my humble collection of tips, artifacts, and experiences from my friends and peers who have made it into the Google Utopia, in hopes that it will help the next person get in.  "Dont be evil" right??

My Experience

First  Google Interview - 

I got a call from a recruiter and was super excited, little did I know the obsession to get in that would follow. 2 phone interviews came and went. Didn't hear from Google assumed they didn't care or weren't interested, so I moved on. No biggie.

I got a call from a recruiter saying "We have it here on record that you did well on the phone interviews last year, would you like to interview again?". OK fair enough there was a glitch in the Google process, no worries, lets do this again. 2 more phone interviews go by but this time I magically made it on-site. Life is good. Then the actual full day interview started. After a very long day of being asked various questions I am feeling pretty good. HR person calls tells me that 3 out of 5 gave good feedback but 2 gave really poor feedback so there would be no offer. He mentioned that I should apply back in a year so that I can sharpen up on my skills. Def a bruise to the ego but fair enough.

At this point I consistently ignored Google recruiters who emailed me cause I wasn't ready to go through the Google gauntlet just yet. I needed a break from that. Besides I didnt have a problem finding satisfying jobs in the interim. However Google still remained my elusive unicorn. 

Second Google Interview - After some time I decided to get back on the Google horse, so I emailed one of the few of them I had in my LinkedIn connections. I had no problem getting a phone interview. At this point I had studied almost a full month, knew CS fundamentals sufficiently well, and was prepared. Didnt get past phone interview. When HR recruiter calls tells me that "I didnt do bad or anything but we cant continue with the interview process." - color me confused. I figured I must have made a simple mistake and thats what caused me the interview. Alas this isn't the end of my quest - a few months and ill flirt with them again.

Now the good stuff:

I wont repeat alot of the stuff already out there, but rather collect and list the sites, links, and books that I have found helpful. 

Design Resources ( Design Patterns )

Programming Resources Sharpen your actual coding and math skills ) ( timed coding and algorithm skills ) - They say you might catch a recruiters eye if you solve a hard one.

Other fun/interesting links:

Tips I have come across:

  • Be on LinkedIn and update your resume as often as possible. If you are a software engineer this will surely raise the attention of big name companies like Google, Facebook, Yahoo, Twitter, Amazon, etc... and their recruiters will at least email you. 
  • Do mock interviews with SW engineer friends
  • Keep talking to the interviewer as you work - silence is not a good thing.
  • Reason out things that you dont understand. Even if it seems hard, your interviewer will nudge you in the right direction if you put up an effort.
  • Do not change the question - if they say your input is a linked list, dont change it to be an array to serve your purposes
  • Don't write psuedo code, they want a coding sample. So be as complete as possible
  • Unless you are the creator of  the language you are using, DO NOT tell them you are a 10 out of 10. There is a chance, although minor, that the person interviewing you wrote the language or had a part in it. 
  • Check for bound cases whenever writing code, 
  • When using recursion, remember the stop case.

Although the Google interviews may seem frustrating and tedious, try to enjoy it and learn from it. That's the reason I keep going back. I find that it serves as CS refresher and keeps me sharp. So its ok that you( I ) didn't get in the first or second etc.. time. Whats important is that like many other things in life, the satisfaction comes from the struggle to the accomplishment. Think about it, if Google were so easy to get into, would it be as exciting if you got in? Ok enough now go and smash algorithms in O(1/n).

If anyone has any other good tips or resources, please feel free to add them to the comments section and Ill add them to the list.

**UPDATE** - 8/24/2015

So my interview skills have improved tremendously. Now this is a tip to those of us that have been working for a while and have gotten a little lazy with our SW Engineering skills...

I was constantly getting interviews from big Tech companies but ultimately didnt progress past that. I was always told that my data structures and algorithms skills were very solid, however I wont be going forward. After many many MANY interviews I made it onsite to a Google Interview. They HR person was gracious enough to give me a golden piece of advice. He said to me "The consensus was that you are a smart guy. He said everyone basically said that if you spent more time on the design/analysis, then your code will be alot cleaner to write" Boom goes the dynamite! I have been going about this all wrong. I spent way too much time on algorithms/data structures and not enough time on code cleanliness.

Working day to day as a SW engineer at a variety of companies, I tended to just come up with a general idea of what I wanted to do, start writing code, compile, run, fix bugs and repeat. Unfortunately this breeds bad habits especially when code quality is being scrutinized during a programming interview. And since I got that feedback maybe that's something that shouldn't be a norm in my day to day job either. However I do want to emphasize this, DONT EXPECT TO ALWAYS BE ABLE TO WRITE BUG FREE CODE - it just not human, nor is it realistic for anything than the most trivial of code blocks. So don't feel bad if you cant. The goal is to write relatively bug free code. Besides your interviewers probably cant write completely bug free code either.  Side note ( for high tech companies the probability that most engineers could get their job back if they re interviewed is 50% anyways - but I digress.)

I then spent quite a bit of time watching programming interviews on YouTube. I think this surprisingly helped me alot. Reading/Writing algorithms and such is great but watching a highlights reel on YouTube on good interviews was def the final nudge I needed. I would suggest YouTube as a major resource for getting the feel of good programming interviews.

But how do I spend so much time on analysis and design if I am being compared against my peers on the speed of which I answer the questions. Well it turns out while this is true, its not as dire or as cut throat as we make it in our minds. Interviewers wont ding you for taking you so long unless its really gross. Meaning if you take 30 mins to construct a For Loop, then maybe you need some more practice and/or more experience before interviewing. Otherwise generally they would rather see you take the time really nailing all the edge cases and write psuedo code before diving into the real code.

Therefore my humble guideline for a programming interview:

1. Ask all questions regarding the given problem

    • Ex. Integers vs Floats vs Doubles etc...
    • Ex. AlphaNumeric Strings vs AplhaNumeric + Spaces/Punctuation
    • Ex .InPlace or using Auxillary data structures
    • Ex. Memory vs Speed constraints
    • etc...

2. Write Psuedo Code
This is your opportunity to be messy in figuring things out. Make sure you tell the interviewer you will be writing psuedo code so they don't think that's how you write real code. Here  you should talk about everything you are thinking, whether it may sound dumb or not. They want to follow your thoughts, so its ok to say "hmm if I iterate over everything twice might work but wait that might not help so much"

Once you have a semi formed way of solving it. At a minimum do the following:

  • Check Input - Is input NULL, length == 0,etc...Does the input datatype match what they asked for?
  • Check Step by Step of the algorithm
    • Here literally write out step by step of the algorithm explicitly. You may find bugs yourself here which scores big points with the interviewer.
    • Recursion? Where is the stop condition?

  • Check Output, are you returning an index or a number or .... Make sure it matches the requirements of the function
  • Check Edge Cases,  Linked Lists? What happens with 0 nodes, 1 node, n nodes.  Search? What happens when element is not found.

3. Write Real Code
Once your interviewer feels confident your pseudo code is 90% there, they usually nudge you to start writing real code. This does not mean your pseudo code is actually complete. It just means its close enough.

I suggest to write code by translating line by line psuedo code to real code.This should make it alot more straight forward to write code vs fumbling around and modifying it like crazy which gives the impression of "sloppy code" which is programming interview death.

Once you have done that, now go back and again go line by line dissecting your code. This is the point at which you may discover that you need an extra variable to do a swap, need an extra condition in the for loop etc... Again here i suggest taking a break from writing real code but rather go back and modify your pseudo code to improve what you just found out. This shows the interviewer that when you get stuck you take a methodical way of resolving it vs just splashing around until you somehow get it to work. After all lots of interviewers often think how you would be to work with, so having a SW Engineer who just hacks it to work is scary especially when its a challenging problem with a deadline looming over them.

4. Optimize The Code
Once you have a working version the interviewer seems to like. Take some time to actually optimize your code. Do you need that extra loop, extra variable, maybe a reference is better to use vs a pointer. This demonstrates not only do you care about solving the problem but you care about the elegance of the actual code itself. Most interviewers will copy your code same if its a phone interview to show others. So make sure you do a good job of making a final draft.

With these steps you'd be surprised how smoothly you get through a phone interview. Give it a shot.

Now back to my story:

After my last Google onsite interview, I was told I had very strong analytical skills and a solid grasp of Data Structures and Algorithms. They also did mention that they couldnt give me an offer because I jumped too quickly into code rather then hashing out a good design before I started coding. So even though I didnt get the offer, the feedback they gave me was worth its weight in gold. I took some time to really nail my weak points. Last week I had a technical phone interview with Facebook. I already accepted a job offer from a different company so I was using this interview as a practice of what I was practicing on my own. Surprisingly I solved 2 programming questions within the time with time to spare - usually one question and I don't finish within the time.  So I do feel very confident that there will be a follow up and if not then ya know what it's all good. I am learning more and more how to hone my craft, so that satisfying to me. Its not always about the destination its about the journey.

Yes - I am annoyingly optimistic about this. I figure I will keep interviewing even if it takes 100 times and many many small incremental steps, I want to get to the point of actually conquering the Technical Programming Interviews from the big Tech Companies.

Friday, March 27, 2015

Trying Meteor Part 2

So initially I was saying how unstable and immature Meteor is. I do retract that statement, the more I play with it the more comfortable I am becoming with it and find it to be quite fluid to work with. I am still not sure about its scalability since I have been using it for relatively easy projects, so I leave it to others who have used it more extensively and at a greater scale to comment about it.

Here is what I do find compelling about it now that I am a bit more familiar with it.

  • Meteor can function on any machine since you can install the JS VM on any machine. This is equivalent to most interpreted languages. This allows easy portability for you application. So no need to set up LAMP on every system you want to run it on.

Saturday, December 13, 2014

Meteor Tips

On my journey to learning Meteor, I am learning a bunch of gotchas on the way. I figured I'd document them here in hopes that others will augment and correct what I have written. Ill add to this as I learn more:.

  • Large Collections: It is critical to make sure you only publish what you need. If you're browser is hanging when your page is loaded, it is because Meteor is sending tons and tons of data to your browser. If you have GBs in your MongoDB then guess what, it is sending GBs. The best and recommend approach is to publish only the data you want on the server side, then subscribe to only the data you want on the client side. In this way you are sending only what you want and dramatically improving your load rate.

Wednesday, December 10, 2014

Trying Meteor


I was told about Meteor about a month ago and was told it was the next big thing,so it intrigued me. I figured I'd read up on it and try it out for myself. On most of the forums many were touting it as the framework to rule them all - "its so easy and intuitive"....blah blah. Ok Im curious lets give it a hurl. Besides if it could make things easier for me when developing a prototype or when developing a web project, then why not give it a shot. The more tools you have in your tool belt the greater variety of things you can build.

In the past I have used PHP, Ruby on Rails, and Django. I have mostly used Django for my side projects and even prototypes I built at work. I wanted to see what the difference was with Meteor.

DISCLAIMER: I don't claim to be a certified expert on Meteor nor Django but rather these are my humble opinions based on what I have learned and played with. I leave it open to readers to correct me where I am wrong.

For those who are unfamiliar with Meteor, it is a web framework that resides on top of Node.js. Everything is completely written in Javascript to be run on Google JavaScript Engine V8. As JS is typically run on the client side/browser  Node.js uses the JS Engine so that it can be used as a standard interpreted language such as Python,Perl etc... except in JavaScript of course.. There are a couple reasons that this framework has gained such popularity:

  • Real Time Updates: With the explosion of Big Data and the Analytics, there is a real need to have the most up to date information at the user's fingertips asap so that they could make the most informed decision based on the data. That's where Meteor excels above other frameworks. It allows you to use the notion of Publications and Subscriptions to allow a template on a web page update automatically. So you publish a data set ( Collection ), the client side code subscribes to this collection and so there is a callback to the page whenever the Collection changes. No need for messy AJAX calls, this is included in the standard Meteor install out of the box. Pretty cool the first time you create a collection and watch it change before your eyes. Oh the power you wield!
  • Event Loop: A general design pattern that is used for high performance is that of an Event Loop. Typically with IO, often time code cannot be executed because it is waiting on IO to complete. Perhaps its reading from a Hard Disk, Sensor,  or controlling an actuator. With Syncrhonous calls code is blocked until the IO is completed. This does not neeccsarrily waste CPU time as the CPU will swap out the process when its waiting for IO, but rather it means no other code in the calling code can be executed until the IO is complete and returns. For a more complete description of the event loop based on Node.js see Understanding the node.js event loop .  So now you can provide a callback function to your IO calls, continue executing your code, then have it perform an action when its complete without having to worry about it. This is a huge benefit when dealing with highly used web applications. It scales well as code isn't left hanging for a variety of things.
  • Code Caching: A good portion your code will be cached onto the client side, such that incremental changes are communicated minimally rather then having to download all of your JS, CSS, HTML,Images,etc.. every time. This results in a faster loading and generally a better user experience. 

So these are at least 3 of very compelling bullet points for using Meteor. I jumped right in and am reading a book about it. I built the demo app they walk you though in the tutorial off the main site. I am feeling good. Then I started trying add a bit more complexity to the app, I found the following to be downers.

  • Only Supports MongoDB: I think MongoDB is a good DB, but what if I want to use MySQL( which is still the predominant DB out there), Hive, or Cassandra. Nope out of luck. Some whispers of it being on the list for the next release.
  • NPM: Now I know many people love the Node Package Manager and I did like it initially but I found it a bit annoying that a variety of basic functionality that other frameworks offer out of the box have to be installed via NPM. For example, you need to install Iron:Router. I imagine 95% people would use this, unless you are designing a single page. Rather then a complete set of base libraries to get your initial project done, it requires grabbing a variety of JS libraries from a host of options. I found this to be a bit annoying. Seemed hacky to me.
  • Callbacks Callback Callbacks: It seems to get a majority of communication between the server side and the client side, require a callback. Additionally nested functions in callbacks in nested functions in callbacks easily build up. Sure this is alleviated by creating variables for callback functions and making sure to use a good coding style, but this doesn't change that you need to pass in a callback. You are just masking it with nice readable variable names and style to be able to follow it.
  • Codebase seems immature: Now while I think it has incredible potential and its an exceptional code base, I think there is a lot of gaps to it, that the more mature frameworks  I think it needs a couple more revisions before I'd consider using it in a real  product and not just a prototype or small side project.
  • Good for front-end developers: Based that its JS based, it has a natural feel to those that have been using JQuery/JS all along. If you are more a backend sw developer, I'd recommend learning Node.js first to get comfortable with JS and the system libraries Node.js provides. Not saying its crazy hard but rather an adjustment.
  • Not a large community: When looking for answers there are some responses via StackOverflow but in general knowledge and expertise about it seem a bit thin. Not saying you can find an answer to your question, you can, but itll take a bit of googling and using the right keywords.
  • Easier thing become hard, Hard things become easier: As eluded to before things that should be easy or intuitive in other languages become a bit convoluted in Meteor. Want to unzip a file in Python use the unzip library. Want to unzip in Meteor, download the right zip library submitted.  Now id like to say that this last one is probably because I don't know how to use it fluidly just yet

So yeah that's my experience. A cool new language. Does it have potential undoubtedly - YES. Is it awesome sauce right now? Definitely not. Its a framework ill keep my eye upon, but it wouldnt surprise me if someone built a competing framework addressing the gaps it has, that more mature languages typically have.

Monday, January 21, 2013

Startup Stagnance

As I read through the typical startup websites such as Tech Crunch, MSNBC Future Tech, KickStartr, etc.. I am finding the the majority of startups are doing the exact same thing. They are doing some sort of social networking, picture manipulation app, microblogging etc... While some are doing some relatively cool things, it seems its flooding an already saturated market. Even the resurgence of MySpace with the help of Justin Timberlake looks like a long shot. The more I read, the more these startups all sound the same with little or no novelty.

I believe startups would have an edge if they addressed the real world issues that bother people or at a minimum tried something different or address a real need. Yes while networking is important there are already so many avenues to handle that. Off the top of my head, I believe that if startups were to concentrate in the following areas, they could really capitalize on creating emerging technology:

  • HealthCare - 
    • Organizing systems for healthcare professionals and patients to use. Organizing information can be overwhelming for hospitals.
    • Having access to all of your medical records on demand
    • Stream Lined  Prescription Process
  • Home Automation:
    • Many people are trying their hands in home automation. It would be great to have a single platform to rule them all or some kind of standardization for each to adhere to.
    • Have an affordable and practical way my home can be merged into a smart home, OR setting the ground work for new homes to become smart homes. 
    • Also using techniques to reduce energy consumption/bills at home
  • Education:
    • Similar to paperwork at hospitals and medical institutions, educational institutions can also face the same organizational problem with paperwork.
Where do you see a big need for innovation? Where should startups concentrate on?

Saturday, December 8, 2012

Tips for Staying Sane in a Startup

I have been a part of a few startups and startup attempts and this is what I have learned along the way to not lose your mind. This is what I find to help in my humble opinion.

In general it all rests on the premise that a startup is "A Marathon, not a Sprint"

1. Moderation- We all hear about overnight Tech Startups that make it to fame and glory overnight. However that is more of the exception than the rule. Most startups will have to work long and hard to get something that's even remotely presentable to investors. In this case, its important to not lose enthusiasm for the project you are working nor burn out.Whether you are working full time or part time at this startup, make sure if you have other things that occupy your time, fiends, hobbies, a social life, etc... This will relieve stress, keep you grounded, and will refresh you to be able to keep on going. Dont obsess about the startup only, you will in fact stop caring, be depressed, etc....

2. Ups and Downs - Being in a startup is an emotional rollercoaster - one day you have an idea that you think is the best thing since the wheel, the next day the idea sounds silly and trivial and your best developer has just quit. Oh no! Its important to remember that this will happen often so be prepared for the unexpected. But never freak out.  I learned that it comes with the territory and the romance of a startup. Its important to be limber and to adapt. If your lead developer has quit, redefine your scope, figure out why he/she quit, and hire someone else. I believe it builds character. Whatever you do , don't lose heart! Who said anything that was worth it was easy. If startups were easy, then everyone would have their own startup and become the next Mark Zuckerberg. Perseverance means more than talent here.

3. Be Realistic - If you are working full time at your money making job and have other responsibilities such as family and other commitments, be realistic about how much time you can commit. I made this mistake,  however in my case, I tried to fit in volunteering, graduate course, work full time, exercise time commitment, and also a social life. I was able to keep this going for about 2 months before I just snapped one weekend and I didn't want to do anything. Consider this a time management and priority self exercise. Lesson I learned, do only a few things to do them great and give myself room to breathe vs trying to do everything and  do them half-assed and burn out. Ultimately I kept myself to doing my job (obviously), gym, social life, and the startup work.

4.Remember the Goal - Often times it will seem like there is no end in sight. You have been working at this in your spare time for a while now, cancelling on social events, friends, other hobbies, etc... In this situation its easy to lose interest and say "nothing is coming of this", especially when you see Instagram built and sold in 6 months for a billion dollars yet your startup has been going on for years and no tangible results have come from it. Don't lose heart!  Those types of occurrences are exceptions and certainly not the norm. Remember the objective you had when joining or starting this startup. An analogy to this is in school/college when you were studied for an exam it was sometimes difficult and long winded and just plain ol boring. You didnt think you were getting the material or that other students have easily mastered this while you struggled. But what usually happens?  You take the exam, do much better then you expected, and feel (hopefully) a feeling of achievement and accomplishment. Startups are no different - they are a testament to your perseverance. Consider a startup a test of your willingness to forego instant gratification for a better reward and accomplishment later on. I definitely believe its worth it.

Thursday, November 29, 2012

Short Circuit

So lately I have been getting more and more interested in doing more and more DIY projects. I have been so deep in the pure software world for a while i am looking to get into the physical computing domain a bit more.

For anyone that has similar interests, here are some sites that I find helpful:

How to Build a Robot Tutorial - Society of Robots
Arduino - HomePage

Still kind of brain storming what I want to make as my first project. Probably a small simple robot to do the basics, like vacuum my floor.

Give me some inspiration - what cool DIY electronics have you built?