SHARE

1. Xin Li, Software engineer at Google:

.
Working at Google is simultaneously easier than the interview, and also harder. The Google interview process focuses on your knowledge of Data structures, algorithms, ability to code, and system design.  The types of questions asked are pretty standard, and can be prepared for with some research, time and effort.  We no longer throw curve balls like asking questions about pennies in a blender.

Let’s suppose you are a college grad who made it through that gauntlet, and have started at Google.  You are probably starting as an L3.  At that level, you are responsible for a small part of a much larger project (e.g. The toolbar component of a table).  By the time the task is handed to you, it’s a very well defined problem with a readily available solution.  All that’s really needed from you is to convert it into code.   There’s a lot of hand holding available to you primarily through your mentor, your tech lead, and your team at large (don’t be afraid to ask “stupid questions”.  Those can prove to be some of the best questions).  At this stage in your career, the actual job is easier then the interview process.  At this level, I never had to use any of the fancy data structures I learned in college, or had to implement anything like a minimum covering set algorithm using dynamic programming techniques.

Fast forward some number of years, and a few levels.  You are now an L6 (Staff Software Engineer).  You are involved in the problem at a much earlier stage.  You are involved at the product definition stage, where you need to figure out what are the customer’s needs, and how those needs can be met by your product.  You need not only technical knowledge, but also deep domain and product expertise.  First you sit in a room with lots of product managers, and try to figure out what is the problem you are actually trying to solve.  Then once you have this problem defined, let’s move on to how to solve this problem.  Let’s say part of the problem is that your program is too slow (speed is a feature all its own). And the solution is to achieve a user perceived latency of  500ms or less.  How do you go about that?  Well, you may have a few approaches:

  1. Reorganize the structure of your data representation in the DB to enable faster lookup.
  2. Increase the number of threads and the amount of memory at the in memory caching layer.
  3. Create a better predictive fetching algorithm and prefetch the most likely dataset in the UI server, before the user requests it.
  4. Rework the actual UI code in the browser to create a flow that hides end to end latency.  For example, when the user is filling out some form, or reading through instructions, we can prefetch and pre-render the next step behind the scenes.

You may need to utilize some combination of these 4 approaches or maybe something completely different. And you have a deadline, because your product was pre-announced  at Google I/O.  And let’s say you are on the UI team, so you can do #4 using resources on your own team.  But that’s not enough, and you really need some combination of #4, #3, and maybe #2.  Well, #3 and #2 requires work from the API and backend teams, all of whom are resource constrained because they have their own projects and deadlines to meet.  So then, you need to setup meetings with them and discuss and work out some kind of agreement to divide up the work, after getting their sign off that your technical approach is sound.

Ok, so let’s say you get all of this done, and got sign off from all the stakeholders. Now it’s time to put all this into a coherent design doc, and present it at the design review, and get formal sign off from the teams at large. Once that’s done, draw up the milestone plans, and start assigning resources to actually do the implementation.

As you can see, at this level your job is lot more difficult than the interview process because:

  1. The problem you are trying to solve is nebulous without a clear path to victory.
  2. The solution cannot exist in a vacuum and must satisfy real world resource and timing constraints.
  3. You need more than hard technical skills (though these are still very much critical), you also need a lot of soft skills, such as the ability to drive consensus across multiple teams.”

2. John L. Miller, Former Staff Engineer at Google.

.“Working at Google is much harder than being interviewed at Google, at least for SWE roles. The same is true for Microsoft, Amazon, and Oracle in my experience.

One admission: I like being interviewed, and I have good interview skills, so I usually do well in interviews. This biases me against being intimidated by them.

Why is working at the company harder than the interview? Because  interview questions are calibrated to be solved or nearly solved in an hour or less, usually 20 minutes or less. So, you know there’s a solution, and that it will be relatively simple. And, the person asking you already knows a set of answers to the question, and will help if you ask nicely, e.g. by answering clarifying questions.

Work is a much different animal. Often you’re not sure whether what you’ve been asked to do / proposed to do is possible. You take it on faith it is, because the problems you haven’t been able to solve in the past are rare. But, along the way you may spend days, weeks, or months down the wrong path. Or have to fight politically for your solution. And of course deal with changing priorities at work. Even when you finish your work, nobody necessarily knows what the right answer is, so how do they evaluate how good a job you did? And how long it took you to do it?

Working is much harder than interviewing, at least at Google. It’s also much more fun and more rewarding.”

3. Jared Levy, 10 years at Google:

.
“In terms of success rates, interviewing at Google is more difficult that working there. For each person who receives a job offer, there’s at least one rejected candidate who would have had a successful Google career if hired. However, most Google employees successfully handle their work responsibilities.

Also, my Google interview was more stressful and tiring than almost any other day at Google, and most of my coworkers would probably say the same.

On the other hand, a Googler’s work tasks are more challenging than getting through the interview. The more capable you are, the more difficult the tasks you’re assigned. The best person on my team has a more difficult role than the weakest person on my team, even though they both passed the same hiring bar. Everyone is challenged when they first start at Google, since you need to learn so much before you can be productive.”

4. Lutz Enke, Strategy & Operations at Google

.
“Both the difficulty of the interview process and the job itself depend so much on the role and on you as a candidate/employee specifically. So this question is nearly impossible to answer.

I would say that the interview process probably is a more homogeneous challenge compared to the job. Because the idea is that interviewing should be a very fair process with the same hurdles for everyone.

If you receive great support from your team, are a good fit for the job, and you enjoy the way Google works (some people might not like large companies in general), then working at Google might come easier to you compared to the interview process.

Another approach at the question might be: “There’s more people failing in the interview process than in the first year of working. So obviously, interviewing is harder.” But that’s not 100% logical, as it just might be that the interview process creates a very good fit to the job, i.e. is the perfect pre-filter.”

This article has been adapted from the answers to this question on Quora. 

Comments

comments

NO COMMENTS

Comments are closed.