My 2 cents on tech interviews in a non-holistic view - methodologies, outcome, candidate experience, and tips

I came across an article of a candidate’s experience with interviewing with Google. The impression I got from his words is that he’s got great experience and he will still feel happy and lucky to have interviewed with google even he got rejected eventually.

His experience sheds some light on the general positive recruiting experience by Google. I have seen similar testimonials before here and there. I myself echo to that from my experience. I then burst out thoughts around tech interviews, which is kinda an overdue topic I wanted to blog about. In addition, I have been on both sides of interviews and I have done decent amount of interviews on each side. I might as well put down a few points for whatever is worth.

Disclaimer: In the light of how things - all things - generally work, interview is a broad topic. Below is a brief (reads lazy) summary of what is on top of my mind on this subject. In particular, this is around tech interviews. More narrowly, it is around tech roles like SWE (Software Engineer), data engineers, data science, or similar roles that ask for coding.



Standardized interviews of algorithmic questions is trending.

Typically, it starts with a phone screening, one engineer shares an online coding screen with candidate, where a candidate is asked to write code. The candidate will be moved on to onsite if he/she/? did well, and onsite takes forms of in-person whiteboard coding, system design, and sometimes behaviorial. In principle, a full onsite takes a combo of these 3 types of interviews, and often weighed towards one particular type for different level and kind of hire needs. Pratically, a SWE interview, say an onsite of 5 rounds, can consist of 4 algorithmic problem solving rounds, 1 design round, or 1 behavior round. Depends on the target level, it may remove the design round for new grad, or replace some coding rounds with more design rounds to weigh heavier towards design ability assessment for more senior hires. Engineering manager or higher levels are not in scope of this discussion, the general principle probably applies. I have heard director level hire got asked coding question in his interview at a well-known tech giant, but briefly though.


There is a good number of tech companies following this methodology. Suprisingly, this is not just for new grads, I have seen people with more than 10 years of experience been put into same process of doing this kind of fundamentals related questions. The general motivation, I think and saw other people agree, is to enforce a consistent bar to ensure recruiting quality.

A few implications of no standardized interview process:

  1. Specific team has too much control, namely they get to decide what to ask and how they ask about it. Depends on the existing teams’ people quality, new hires quality can fluctuate greatly. In addition, bad people can sneak in here and there.

  2. Without an enforced standard hiring process, after a new executive gets on onboard, he/she/? can discretionarily bring onboard his previous connections without general consensus, which likely will make existing employees feel bad, which destroys the company’s engineering brand, which destroys the company.

  3. Interview is subjective. Without agreed process, given freedom, individual can get as creative as he/she/? can get, on assumption that interviewers are talented people, which is true in tech industry. Creative is good thing, but that good in judging people in hiring.

  4. It cause people lost faith in company’s engineering brand. Good expect company to only hiring good people, period.

The list can go on and on. Having the preset bar consistently met ensures general fairness in hiring.

statistically beneficial

The process consistently brings onboard good engineers to do the job - It is statistically true.

The process is not perfect. Using standardized whiteboarding has been long criticized for not being useful in accessing one’s real engineering ability. One example, a famous open source package manager (Homebrew) author once interviewed with Google, and got rejected since he could not revert a binary tree (binary search tree ? - I don’t quite recall the specifics) on whiteboard. While his open source package manager is widely used by Googlers. People argue that it is such an irony that the guy’s past history of great work on the project was no proof to his engineering ability, and ignored by Google, and his failure of doing a simple whiteboard coding disqualified his candidacy with Google.

The process does not promise to bring onboard all good engineers. There likely always be excellent outliers that does not fit in this model and got rejected as a result.

It is arguably not a perfect process holistically, but it is arguably a good process for the company.

Statistically, it works.


Given standardized interview process, a statistically good result will be achieved. That is to say, overall, companies will be able to hiring good people to do the work. It does not guarantee that it won’t miss any good talent, or some of the exteme talents. Probably, it will miss out. But the point is that companies’ intention is not to bruce forcefully find all good talents, and miss no single one. They just need a subset of them to do the work.

This kind of interview ends up explicitly asking people to prepare / brush up their CS foundementals before interview. In some sense, the interview also measures how hard a person want to join the company of interest.

candidate experience

My impression is that different companies have different strategies on tech recruiting and often drastically different interview process. That often comes down to different experience to each individual candidate.

I have heard, and quote:

  1. “Amazon hiring is chaotic; Your life will be miserable; You will overwork; But their stocks have hugh growth”

  2. “Facebook pays more; They move fast; They promote faster; FB is catching up Google”

  3. “I want to work for Google; Google is great; Growth maybe slow”

For each individual company, in the past few years, I have seen they update their hiring specifics from time to time. Thereforce, one time quotes like above may not reflect what their hiring experience is really like. But in general, the overall interviewing experience rarely change much, and is quite persistent form what I can see.

IMO, each individual interview affects the overall candidate experience. How interviewers apprach candidates, how candidates feel they are treated by the interviewers, how kind is interviewers, how organized is the process, is the interviewer cool ? …


My experience tells me that you will likely succeed in those interviews if you:

Technical competence

(Coding part)

  • You are VERY familiar with CS fundamentals - well-known algorithms, frequently used data structures.
  • Close to bug-free coding ability on shared online coding platform & whiteboard.

To achieve those, I have seen different people approach it differently. Some praticed solving a lot - I mean a lot - of those algorithmic problems. Some other comes with phD background, and are very good at them in general, and they simply pratice small amount of such problems for keep their “hot hands”. I have also seen people spend thousands of dollars to take those 3rd party algorithm classes designed specifically for tech interviews.

(Design part)

  • Speak what you know - Preferably, you can drive the process, persuade people with solid points, bring a consensus on to the table.

Design often comes with various depths. Those who have worked in their field for a long time naturally and easily can nail this part. Candidates with less experience, at least from what I have seen, are less likely to be asked same questions. Interviewer/companies can easily fail you if they want to. Typically, when you are interviewing for the position that is appropriate per your experience, appropriate problems are used to assess all candidates in the pipeline. I don’t believe all companies follow this though, which is likely true, especially in start-ups where processes can get messy sometimes.


(During interview)

  • You don’t need to please interviewers. Preferably, you stand your ground and proactively clarify it when there is a miscommunication.
  • You know what you are talking about. Preferably, you are assertive and persuasive.
  • You can comfortablely make a point. Preferably, you are articulate when you get across your point.
  • You are not wordy. Preferably, you talk just right amount of time during each interaction, no more, no less, just right amount.
  • You don’t have to be humorous. But, if you can crack a joke, pls do so. Subconsciously, people favor and want to work with those that they like.
  • You are not an asshole. Preferably, you don’t argue everytime over everything just to prove yourself. Ideally, you are emmpathetic, you listen carefully for what others have to say, and recognize the fact that you don’t know sth when that is true.
  • You communicate. Preferably, you drive the process, you ASK before jumping in.
  • You reconcile. There are very likely heated debate and argument moments in interview and real life work, you can tell when you are crossing the line and making others uncomfortable by over arguing over a small point that is not worth it. Preferably, you are good at resolving an expected conflict.
  • Depends on the level where you are at, it is good that you demonstarte that you are trustworthy. A defined task can be given to and delivered by you. Further, an ambiguous problem can be given to you and you drive the process to understand the problem, make specs clear to the known requirements and collect good requirements for that is not scoped but necessary to solve the problem. Further, others find it instrumental to talk to you, respect you naturally, and generally agree that you are a personal they can learn from and want to work with.


Interview at as many places as you can. Likely, you will fail quite a few of them when you are new to such interviews. After each interview, you can feel you subtly have a more mature view of interview process, and you can gradually identify where you did well and where not. You learn from them. You eventually get extremely good at those interviews and land offers from all over the places.

Resources that maybe useful

There are a lot of resources online available. Many companies often send out their compiled preparation materials. Below is a list of resources that I have used and found helpful.

Algorithm coding

  • - You can filter problems by companies, problem type, data structures. Downside is that you need to pay for some of the features and problems. To give a sense my preparation - by the time I was interviewing with FB & Google, I finished ~600 problems overall (shamelessly posting my profile page here
  • - I mainly take references from this site. Be critical & cautious when you consume the content on this site, I find some content misleading. But overall, it has a lot of good and helpful code snippets.


  • Google it ? - There are a ton of materials and popular design questions online.

In addition, there is a famous book called sth like “crack the technical interview”. I heard many people mentioned it and there is good amount of good mentions online as well. It might also be worth checking out. But I have not read any bit of that book.

Good luck.

comments powered by Disqus