You ask trivia questions for a whole hour? That seems pretty gratuitous. I think most people would tire of that after about 15 minutes.

>"We also add a bonus question like "how many people can get into a train". Duration = 1h."

You ask Fermi questions? Between an hour of trivia questions and one "bonus" Fermi question your process sounds pretty horrible to me.

Interviewing candidates is a two way street. There are many candidates who would not want to work for a company that thought asking a candidate an hours worth of trivia questions and a bonus Fermi question was acceptable. For many this would be a red flag.

Can't speak for everyone, but I'd turn away and walked out the instant I hear this or similar BS (which is totally unrelated to "approaching new problems" or "stress management" in programming at least)

I can explain what everyone of them is, and why you'd want to use them. But I've never written any one of them and I'm not going to spend the time to memorize something I can look up in my CLR book or stackoverflow.

It's embarrassing that tech interviewing is still stuck in a 1990s mindset.

So you'll either have them built in to the language you'll be using, the company's using the wrong language, or you'll be tackling problems where they're not really needed.

I've never looked (at least, that hard) at the language; it was always a question of "is this the appropriate data structure for this task?". Linked-lists have somewhat peculiar time complexities, but occasionally those line up with what you need. (Usually a vector is also as good, time-complexity-wise, and wins out by being contiguous. But if you need O(1) removal…)

Also if you don't have a garbage collector you have to do reference counting, and if you want parallelism your reference counting has to be atomic, which when you're sharing a lot of linked list nodes, is another large penalty.

Such allocation is possible in languages such as C++/Rust/C as well. (Though to how much the standard library in each supports you may vary.)

My point was that at least I choose linked lists for the O(1) node insertion/removals in addition to maintaining a sequence of items, a trait pretty much unique to linked lists. It's a matter of whether or not the order notation beats out any additional allocation time and cache effects (Vec/std::vector/continuous-memory lists being more friendly towards cache)

> Also if you don't have a garbage collector you have to do reference counting, and if you want parallelism your reference counting has to be atomic, which when you're sharing a lot of linked list nodes, is another large penalty.

Neither Rust nor C++'s linked list implementations require ref counting, and neither have a GC. A node is essentially,

  struct LLNode<T> {
    LLNode *next;
    LLNode *prev;  // if doubly linked
    T item;
  }

In these languages you use them specifically because you can prepend without worrying about other things still holding a reference, even in other threads. In Rust you'd need Arc to do that.

Also yes you can use custom allocators in Rust/C++, but then you have to have everything have the same lifetime. With GC'd functional languages you don't because the GC will move them to the old generation if necessary.

I'm mainly talking about the empirical question of why Lisp/Haskell/OCaml use linked lists so much, but in other languages they're rare (e.g I see/use them less than heaps). In most cases where you want fast prepend you just append to a vector and just treat it as reversed or reverse it after.

I'm pretty sure my lifetime total is not much greater than 5.

Google Docs are horrible coding environments. In fact, anything besides the candidate's native editing environment makes for an obtuse and off-putting experience, all around. I mean, yeah, the candidate can suck it up and make it work if they felt they "had" to. But on balance it's just unnecessary mental gymnastics -- and completely avoidable source of awkwardness and all around unpleasantness in the interview experience.

And how would I use that, as an interviewer, in a phone screen, realistically?

(I don't believe that I could — reliably — get them into a Google Hangout, for example.)

(We used https://coderpad.io/ ; it was alright, and certainly better than Google Docs.)

Lastly...why are the engineers coming up with the hiring process anyway? Is this common in other professions?