My background
I'm a senior software engineer at Waymo, and previously worked at Google. I've conducted around 150 technical interviews and been part of a couple hiring committees.
Who can this probably help
People who want to work as software engineers at FAANG companies (or companies with similar interviews), and want to get more feedback than a leetcode/Hackerrank will give. For example, how many questions to ask the interviewer? How to talk about your background? What exactly is the hiring bar for a recent college grad? And other things that are otherwise hard to learn about.
I expect this to be most helpful for folks early in their career (or pre-career!), but I'm happy to give a mock interview for anyone.
Also more generally, if you want to practice interviews but find real interviews stressful, I’m friendly!
Contact me
Email: dantweinand@gmail.com
Title: EA FAANG mock interview
Body: Hey, could we set up a mock software interview?
Anything else you write is a bonus. We'll figure out a compatible time over email.
[edit: I sometimes get asked if these are still ongoing. I hereby commit to updating this page if I stop doing these.
I've also had someone offer to share some interviewing.io interviews that they have built up, so if you are interested feel free to ask about that and I'll get you in touch with them.
After having done a dozen or so of these practice interviews, there are also some common themes that come up pretty frequently. These are:
1) It's important to be familiar with the major datastructures in the programming language you intend to interview in. Big-O cheatsheet has a good summary of the operations that various structures support efficiently. The most important structures for interviews are IMO: arrays, linked lists (for stacks/queues), hash maps, balanced binary search trees, heaps, and tries.
2) It's good to feel comfortable with the syntax of the language and basic implementation. Leetcode/Neetcode/Hackerrank are great for this. Project Euler is excellent for more algorithmically heavy problems, although I would recommend against going beyond the 100 most solved problems (unless you love number theory).
3) Ask the interviewer clarifying questions and for examples of terms. It's really helpful to be on the same page and prevent accidentally going off on a different problem.]
I forgot to mention in the body, but I should thank Yonatan for putting a draft of this together and encouraging me to post it. Thanks! I've been meaning to do this for a while.
If there's too much demand for this, I'd also be willing to do these.
When I was interviewing at big tech companies, it helped that I had 3 roommates who worked for Google. In general it seems like EAs who want to work for big tech but don't have existing connections to it are disadvantaged. That seems suboptimal. I'm glad you made this post.
Thanks! Current volume is reasonable but I will totally forward some your way if I get overwhelmed.
Interested in answering these questions?
While not directly related, this post gives an opportunity to ask question that are interesting and might benefit others:
How would an aligned EA working on something approximately EA, recruit and judge other SWE EAs for a software role?
What have you found surprising about recruiting or building a team for a small project?
One reason I'm asking is that I’m assuming the answers might be different than normal, because there might be differences/advantages in having an EA recruit an EA.
(On the other hand, there's probably reasons and examples that are evidence against this).
As someone who has recently been in the AI Safety org interview circuit, about 50% of interviews were traditional Leetcode style algorithmic/coding puzzle and 50% were more practical. This seems pretty typical compared to industry.
The EA orgs I interviewed with were very candid about their approach, and I was much less surprised by the style of interview I got than I was surprised when interviewing in industry. Anthropic, Ought, and CEA all very explicitly lay out what their interviews look like publicly. My experience was that the interviews matched the public description very well.
My priors:
Thanks for the answers, this makes a lot of sense.
Can you be specific about #1? For example, what format of programming tests would you prefer to give to a generalist engineer?
By the way, do you mean something special or "hands on" for ML programming or design questions?
For ML programming, it seems bad to rely on ML or design questions in the sense of a verbal question and answer? I think actually designing/choosing ML scientific knowledge is a tiny part of the job, so I think many ML knowledge questions would be unnatural (rewarding memorization of standard ML books/selecting for "enthusiasts" who read up on recent libraries, and blow out strong talent who solved a lot of hard real world problems).
Yeah I personally find it very hard to do ML interviews for that reason. So far I'm doing a mix of theory/conceptual questions and practical ML coding questions. It helps if the conceptual questions include some unusual setups, or ask about unusal tweaks.