From Intel to Google (2)

From Intel to Google

From Intel to Google, from hardware engineering to software engineering, many aspects of my work have changed. Some of these changes I still haven't fully adjusted to. Below, I've listed a few of the biggest differences. This might be helpful for those considering working in the Bay Area or making the switch from hardware to software.

Interviews become easier (?)

For me, preparing for hardware engineering interviews is extremely challenging because the scope of the questions is broad and unpredictable, varying significantly across different fields. When I first graduated and interviewed for Intel's research department, I had to prepare for solid-state physics and semiconductor device physics. Later, when I interviewed with the photolithography team, I needed to study optical physics. Then, for the memory team, I had to focus on probability, statistics, and memory-related knowledge. Finally, during the pandemic, when I interviewed for Apple's display team, I had to prepare for signal and system as well as display-related knowledge.

Preparing for these interviews isn’t like studying for an exam with access to question banks. Instead, it involves revisiting college and graduate textbooks. However, given the vast amount of material, it’s impossible to go through every page or practice questions as if preparing for a final exam. The best I could do was focus on key concepts and ensure my understanding was solid.

In fact, during my time at Intel, we understood how challenging the questions could be for the candidates. In our team, the interview process involved giving candidates a take-home assignment. They were required to complete it within an hour and then send the answers back.

As an interviewer, preparing for hardware interviews is also quite challenging. We can't ask questions that are too trivial or confidential to the job, so we often have to turn to college and graduate-level textbooks for inspiration. However, given the vast range of topics, it’s not feasible to create questions as complex as final exam problems. Instead, we focus on broader concepts and design questions that test understanding.

Looking back, interviewers and candidates really share a similar fate—both are revisiting their textbooks, trying to find questions that are challenging but not overly so, just right to test core concepts while being answerable within the allotted time.

Software interviews are a completely different story—much easier (at least in my view)! Especially at big companies like Meta and Google, the questions almost always come from websites like LeetCode. Regardless of whether your résumé highlights expertise in React, Java, or SQL, the questions often boil down to coding problems like finding the shortest path for a car traveling from point A to point B. Specific domain knowledge is rarely tested. Whether relying solely on question banks is good or bad could easily be the subject of its own article.

Take, for example, the famous case of software guru Max Howell, who developed the widely used package manager "Homebrew." In 2015, he failed Google's interview because he didn’t know what a binary tree was—a concept every computer science student is expected to know—and was rejected. Frustrated, Max tweeted: "Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off."

Two years later, he admitted he had acted a bit impulsively and clarified that he majored in chemistry, not computer science, so he wasn’t familiar with binary trees. However, he still argued that Google should have hired him because he excels at software development. This incident became widely known and sparked heated debates online about whether algorithms and data structures should be tested, even if they’re rarely used on the job.

Nearly a decade later, interview practices have hardly changed, suggesting that the "traditionalists" have won. The reasons for this are likely twofold. First, if algorithms and data structures aren’t tested, there doesn’t seem to be a more universally fair way to evaluate candidates. Second, proponents argue that while these topics might not be directly relevant to daily work, they assess a candidate's logical thinking and, to some extent, predict the quality of code they’ll write in the future.

As an interviewer, creating software interview questions is much easier than preparing hardware ones. Candidates have platforms like LeetCode to practice, and interviewers have access to the company's internal question banks to select from. For example, Google has an interview question system with hundreds of pre-written questions, complete with detailed explanations and guidance on techniques—such as how to provide appropriate hints when a candidate gets stuck to help them work through the problem.

If a question is leaked by a candidate, it can be reported in the system, and that question will no longer be used in future interviews. As a result, Google interviewers don’t need to come up with new questions—they just select them from the system and ensure that other interviewers haven’t chosen similar ones. I believe other large software companies likely follow similar practices.

By the way, Google's interview questions are created by volunteers within the company. At Google, many small software tools, utilities, or tasks don’t have dedicated teams to manage them, so they rely on volunteers to maintain or contribute. To encourage volunteering, promote learning and teamwork, and ensure that such efforts are taken seriously, Google introduced a program called the "20% Project."

Under the "20% Project," volunteers working on these initiatives must dedicate 20% of their working hours to the volunteer activity, provided their manager approves. Many of Google's interview questions were created as part of this "20%" initiative.