They already know your documentation style based on the portfolio. They are testing your grasp of language fundamentals and various features, and how you can use them to solve a simple and common problem.

Writing documentation headers in an interview setting should only happen if they explicitly state that you should write them, or after you ask the interviewer if you should be writing them.

They didn't look at the portfolio.

As someone administering these kind of questions regularly, the majority of interviewers are aware of the shortcomings. There's a kind of 'it's the worst form of interviewing except for all those other forms that have been tried' attitude prevailing. Every other method has problems that are usually worse than those associated with doing abstract problems like implementing a BST.

From what I've seen, interviewing is evolving and focusing gradually more on realistic, practically-oriented coding, and less on Leetcode-style questions, especially as people are learning to game those.

It's not relevant to the position, but 'coding on a whiteboard' is a legal sorting function that will reject a lot of truly awful candidates (You pretty much can't bullshit your way through it. You may end up being an awful hire for other reasons, like your personality, but that's another story.)

That it also rejects some good candidates is fine, there's always more candidates for FAANG jobs. (Few competitors pay FAANG salaries.)

That's fair but these companies also claim it is hard to find developers and more hb1's are needed. Hard to have it both ways.

I feel like there should be a course for passing these exams run by ex-FAANG employees. Perhaps a bootcamp.

1. There are plenty of websites which will let you grind away at FAANG interview questions. If you have a few weeks of time to waste on gaming this signal, you'll be coding self-balancing trees in your sleep... And have no issues with passing an interview for at least one of these firms. Depending on your current salary, this may be a much better ROI than your entire undergrad degree was.

2. Some of these firms occasionally host coaching sessions for referrals. Ask your friends if one is currently running.

3. "You don't need H1Bs, just lower your hiring bar" is a criticism that is a bit less applicable to firms with a high hiring bar, than to firms with a low hiring bar. If you are, in fact, talent-limited, an H1B will actually cost you more than a local worker. (Lawyers, immigration sponsorship, uncertainty in whether the visa will actually arrive, aren't cheap - and FAANG does not have a reputation for exploiting their H1B hires.)

> There are plenty of websites which will let you grind away at FAANG interview questions. If you have a few weeks of time to waste on gaming this signal, you'll be coding self-balancing trees in your sleep.

I'd like to practice this, any recommendations?

Leetcode, if you want to pay for UX.

If you don't want to pay, just get the list of former questions from the internet. [1]

Many of those questions may no longer be asked, but if you can ace them, you should have few problems with similar questions/variants thereof.

This is not a skillset that develops from doing your day job. You have to deliberately practice to get good at this.

[1] https://www.interviewcake.com/google-interview-questions

It's a game. You win, you get a job. It's worth spending a few weeks and just banging out BSTs every night until you're good at it. Engineers with years of industry experience tend to fall flat in these interviews because they haven't written BSTs in years and don't think they should have to in an interview. It's not about should, though, it's about whether you want the job. Change the system from the inside.

Thankfully in many regions we still have the choice not to go through hiring games.

I agree with you that in an ideal world there'd be a way for you to demonstrate your prowess without playing these games. However, in the real world, I want a job, I'm going to play? It's not like I don't solve hard engineering puzzles for fun on my own time anyways. Framing matters a lot!

Here's what I like about interviews:

(1) I get to talk about myself and how great I am without people rolling their eyes at me.

(2) I get to solve a fun puzzle with:

(2)(a) A defined answer.

(2)(b) That I never have to maintain.

(2)(c) With a potential financial windfall at the end.

Seriously though, in Europe the Algorithmic style interview is not the norm, by and large

Interesting, what's the process there like?

Plain old style interview, you get through HR, get a couple of interview rounds with people from different departments, discuss with them several subjects somehow related to work, positive and negative experiences across your career, what would you do if X happens,....

If you happen to do coding exercises at all, they are just basic tasks like implement a linked list data structure, count the number of words on a file and such.

Answer some trivia about the language you are supposed to use, e.g. when should you use a struct in C#.

Luckly only startups over here are somehow into SV hiring culture, which still leaves plenty of others with job offers available.

>You need to know the principle of a BST. Unless you're building a database working in a unique scenario, actually traversing it going to be done by some library.

Looks like you got stung by the confusion between binary tree and B-Tree (and B+Trees).

1. The b in btree isn't binary.

2. Databases use B+Trees.

3. binary trees are almost worthless.

> 3. binary trees are almost worthless.

Interval trees reduce to Binary Search Trees when the nodes can't overlap. Most markup DOMs (in browsers, WYSIWYG editors, etc.) are held as an Interval-tree ADT which is actually implemented by a BST.

Also, Red-Black trees specifically are used in many database clients to implement an in-memory write-back cache of a database table, as the combination of performance requirements for flushing batches of writes to the DB, and reading back arbitrary keys that were written to the cache, make these BSTs nearly optimal for this use-case.

But yes, DBMSes themselves don't tend to use BSTs for much. Maybe as a query-plan-AST term-rewriting-phase ADT.

>Interval trees reduce to Binary Search Trees when the nodes can't overlap.

Interval trees are degenerate R-Trees which can be implemented using GiST which is itself a btree.

>Also, Red-Black trees specifically are used in many database clients to implement an in-memory write-back cache of a database table, as the combination of performance requirements for flushing batches of writes to the DB, and reading back arbitrary keys that were written to the cache, make these BSTs nearly optimal for this use-case.

Got a source? I'd like to read up on this use case.

>But yes, DBMSes themselves don't tend to use BSTs for much. Maybe as a query-plan-AST term-rewriting-phase ADT.

Postgres' source does indeed have a red black tree in it:

https://doxygen.postgresql.org/structRBTree.html

I wonder if the merit of these exercises is from reading the candidate's reaction to meaningless and trivial tasks. If they take it with a smile, or better yet if they spent part of their free time studying it in detail, they will make a terrific cog in the machine...

To be honest, as a part of hiring procedure, it has its merits. In an ideal world, you want to ask the candidates a problem that is well defined, and applies the tools that they might have learned in their past. This is why algorithmic problems are common - a large pool of candidates have recently finished school, they have a lot of fundamental knowledge from their experience there (and nothing else), and asking these is a way to evaluate [ how well is this problem approached ] with [ tools they should have at their disposal]. It's more about can you understand what you have learnt and use it to solve a novel thing, and less about can you balance a binary tree given 100 integer inputs. It's largely devolved in a cat and mouse game now, with candidates spending a large part of their time poring over CLRS or on Leetcode, and companies asking increasingly difficult (and serving no purpose but testing how much time was spent on practising) whiteboard questions.

Where this falls down is when you're hiring someone who has 10 or 15 years of experience and has forgotten more about day-to-day product development than the freshers have learned about algorithms. So you're asking that guy questions that the freshers have fresh in their minds because it's all they know, and it's totally unsurprising that he fails because he hasn't ever used that knowledge in a work setting. You do need to tailor your interviews to the person's experience level. If you're hiring for experience, ask that person about process and about team forming and about mentoring and leadership. You don't have to be able to write a perfect algorithm as a senior, only to help your juniors over the hurdles keeping them from doing it themselves.

Part of it might also be a way around age discrimination, as those relatively fresh from school (and thus, younger - and likely will take a lower salary) likely are able to pass them faster than older potential hires.

That doesn't make much sense to me. If they don't want to hire older people to save money, can't they just offer lower salaries and let older people self-select themselves out of the job?

I suspect that the pre-employment drug screens are to test who washes their hands.