Hacker News new | ask | show | jobs
by repsilat 2786 days ago
> There is really not much that is unique to Google's interviews

Having just gone through 10 days of on-site interviews (including two at Google), there are some things that are peculiar Google's process:

- No talk about software engineering,

- No talk about software design,

- No talk about project management, working on a team, culture of any kind, caring about customers etc etc...,

- No debugging,

- No using unfamiliar APIs, no reading documentation,

- No actually running any code.

In particular, Google was the only place I didn't actually test and run my code. It was the only place where I was given the option of doing all of my work on the whiteboard, too.

At least one time I had convinced my interviewer I had a working solution and then realised it didn't work and had to convince them of that...
3 comments
vonmoltke 2786 days ago
> It was the only place where I was given the option of doing all of my work on the whiteboard, too.

I just interviewed at Facebook, and I was only given the option of doing all my work on a whiteboard. I hate that medium for writing code (or any dense text, really).

link
repsilat 2786 days ago
Hmm. I programmed on my own laptop (and ran the code) at Instacart, Apple, Airbnb, Dropbox, Stripe, Cruise, Flexport and Benchling. Late September/October this year.

At Google I wasn't allowed to bring my laptop, but they let me "program" in a text editor with syntax highlighting and automatic indentation. Most of the interviewers hadn't seen that before though.

link
ma2rten 2786 days ago
I interviewed at Facebook, Snapchat, Apple, Pinterest, LinkedIn and startups. The coding interviews were exactly the same. This was less than 3 years ago.
link
joshuamorton 2786 days ago
The first two depend on the level you are interviewing for. If you're going for senior positions, you will have system design interviews.

The others, ehh, practically every interview I've conducted has had some debugging when people encounter issues in the code they wrote. Sure you're not spelunking logs or stack traces, but reasoning about what causes an issue on a smaller scale is still useful signal.

link