Hacker News Reader

Comment by qPM9l3XJrF | Hacker News Reader

What do you do instead?

It seems to me that having tough interview questions can allow a company to be less credentialist, because they know their questions are tough enough that anyone who solves them is qualified to work there. My resume doesn't necessarily make me look like a senior developer, but leetcode mediums are no trouble for me and with a little effort I think I could learn to solve hards quickly and reliably as well. So I've got a comparative advantage applying at a company that has that sort of interview.

View on HN

We ask questions similar to the work you'd actually do at Notion; see our interview guide here: https://www.notion.so/Guide-to-Engineering-Interviews-63876c....

Looking at a smattering of leetcode mediums, I don't understand how someone being able to return "the elements of a 2d matrix in spiral order" (https://leetcode.com/problems/spiral-matrix/) or use Kadane's algortith to solve "k-concatenation max sum" (https://leetcode.com/problems/k-concatenation-maximum-sum/) pertains to building multiplayer software as part of a team.

I say this as a happy Notion customer who spends a lot of time evangelising it within my own company: Notion is one of the most unpleasantly slow apps I have to use in my daily work, it has been the same way for years, and I can't help but think that a deeper appreciation of computer science fundamentals _might_ possibly help find better ways to fix that.

When I look at the performance of many pieces of software produced by FAANG companies and other big players known for basically bringing us the "leetcode interview meta" I really doubt the strongest connection can be made in that regard.

Haven't tried Notion yet, but is Notion really slower than Jira/Atlassian products?

Probably not that bad these days, although it depends on your content and workflow. I _enjoy_ Notion more, and for what it's worth I do actually trust Notion to give more a shit about it than Atlassian, but it's still the most common complaint I get from teams. Trello is certainly vastly snappier than both (as is a Google Spreadsheet, which is many users' go-to solution for any type of even vaguely structured data).

Hey, no gatekeeping! Leetcode bad!

I read the guide to engineering interviews you posted, but I am curious about the difference between your "Technical Screen" and leetcode type questions. Having to solve a problem while someone is watching and having to talk while you do it sounds similar to the FAANG style. Maybe I'm missing something?

From our guide:

> Please prepare a skeleton web application, using any web server framework you like, preferably a lightweight one, e.g. express (node), flask (python), sinatra (ruby).

> Have a tool to send payloads to your server and inspect responses, for example cURL or Postman. No front-end client is required other than cURL or Postman to send test requests. This will be a backend only exercise.

This is a far cry from leetcode stuff - these are real world tools and concepts many developers use every day. Yes, it is an interview with time pressure, talking, and problem solving. But, the tools and problem are much closer to web development than they are to a CS51 graph proof.

Hmm I don't see the quoted text in the guide. Maybe it's something different internally?

The page I see only says there's a 60min "language-agnostic coding exercise" and that you have to share your screen and talk through your thought process. That's why it felt similar to leetcode stuff.

LeetCode is a problem that took a famous computer scientist a month to write a paper about, but you have 30 minutes in a proprietary web app to either remember or re-invent it, and pass a test suite.

LeetCode-type interviews are about 60% a how-bad-do-you-want-this test, and 40% a barely-concealed IQ test.

I'm not even sure that's the wrong way for FAANG to do things, given how many people want to work there. I do know it's a damn bad idea for any place not offering FAANG-like comp, since at lower comp levels you're in competition with a ton of places that don't demand hours of grinding leetcode to prove you want the job bad enough.

I used to spend whole interview working on actual problems candidate will face on day-to-day. When hiring for back-end roles I had a few scripts I used to use to see how candidate does code review, or had an EC2 instance with specific problem simulated so candidate could look around and talk about what they see and how would they approach the problem at hand. I only gave algorithm problems to juniors who claimed they can code.

Reply on news.ycombinator.com