[Aurornis]

> Ultimately I ended up with a bunch of highly paid employees who don’t know how to do anything but to “build and lead amazing teams.”

I've worked at a lot of startups. The worst of them were led by people who list things like "organization design" and "build and lead amazing teams" on their LinkedIn.

At the most dysfunctional company, the ex-FAANG CTO would take key job descriptions and add the requirement that they must have FAANG experience. This created a glass ceiling where the early employees, non of whom had FAANG backgrounds, were unable to be promoted. Instead, we got a lot of ex-FAANG VPs and Directors who didn't know how to function at a startup. They were told to lead teams of people who knew the business inside and out (because they built it!) yet they could barely function outside of a big company themselves. Every meeting would be a competition of stories about "At Microsoft we did this..." or "At Facebook we did that..." because playing the FAANG card was the only thing the CTO liked to hear.

The only non-FAANG person who thrived at that company was the single worst leader I've ever reported to. He is a LinkedIn influencer with his own newsletter where he talks about, among other things, his expertise in "Organizational Design". Yet the organization he designed was completely dysfunctional because he ignored how the business worked and instead hired arbitrary numbers of people according to some book he read. Half of the people at that company were 90% idle, while the other half were working 80 hour weeks because the "organizational design" person had strictly assigned responsibilities to arbitrary teams in a way that didn't account for how the business actually worked.

The next line from this post is exactly how he responded to every problem:

> Imagine you hire someone to scale an area and their solution is to divide that area into 5 sub areas and hire someone for each of them to figure it out, etc. that’s their solution.

He was never accountable for anything because he always had someone under him to blame.

[ethbr0]

I interviewed a guy the other day.

CS degree.

"I have a proven track record of building and leading amazing engineering teams."

"Okay. What's the difference between a character and a string?"

*crickets*

We all have our specialities, but jesus ¢@&#ing christ: if you're interviewing for an engineering role, of any sort, you should be able to answer basic questions.

[alex_lav]

I interviewed an ex-FAANG (developer) currently working as a software executive for a director role at a previous company. This person included 5 years-ish of Haskell experience on their resume. I don't know Haskell at all, but am aware of the language and its design principles, so I figured a lot of my technical questions would be pretty easy for him

Boy was I wrong. My first question was "Name the most common data structures you use day to day". He stayed silent for a bit and then said "What, do you want me to just list them?" I said yes. After some more silence he said he couldn't recall any. The fact that he said "list" was particularly ironic.

I kind of gave up on expecting used-to-be software developers to have retained a single bit of knowledge from their time as a dev after they've moved on to "leadership" or "management". I believe it's important for technical leadership to understand technical problems and their solutions in broad strokes, but it seems I'm mostly in the minority in the real world. That interview (and trying to hire for that role) really showed me how little engineering leaders remember about software.

[randomdata]

I write code every day and I still had to ponder your question for quite a while before I could think of a data structure I use regularly by name.

It is not exactly useful knowledge to keep top of mind. It is not like you need to look up how to use daily data structures. I had an easier time remembering the names of data structures I almost never use, or even have never used, as retaining their names actually has some usefulness.

In an interview situation, I expect I would also give up with stating I could not recall any to save the awkwardness of sitting there silent for half an hour racking my brain.

[Shaanie]

I'm sorry, but what? If you can't even remember what list/set/map whatever is called, how are you going to use them? We're not talking about exact syntax here, just what data structures you use...

[randomdata]

> If you can't even remember what list/set/map whatever is called, how are you going to use them?

Certainly not by dictating their names to my coworker. Why would I need to know their names? I suppose some languages require you to know their names in order to use built-in implementations, but lots of languages use other syntax – often void of natural language (e.g. [], {}, etc.) – to do the same.

I eventually got there, but it took awhile to remember. That's great if you have prioritized trivia to occupy your mind's space, but I have found no reason to.

[alex_lav]

> Why would I need to know their names?

Why would you need to _communicate about programming_? Because it's a core part of your job...

> That's great if you have prioritized trivia

Every interview question can be characterized as trivia if you squint hard enough.

[40yearoldman]

I think the part of the question that throws people is “most common”. It begins to sounds like a trick question, because it hat is the most common? Its going to very from code base to code base.

Maybe id the question was name 3 data structures, any 3 it might sit well.

But even so. The question did devolve into list of things somebody should know as a ex developer.

[alex_lav]

> I think the part of the question that throws people is “most common”. It begins to sounds like a trick question, because it hat is the most common? Its going to very from code base to code base

That’s pretty textbook overthinking for an interview. The point is that it varies from codebase to codebase. Tell me about what you normally use and I’ll ask questions.

> Maybe id the question was name 3 data structures, any 3 it might sit well.

Trying to get every human to agree on the wording for an extremely easy and general question isn’t a worthwhile use of time though.

> But even so. The question did devolve into list of things somebody should know as a ex developer.

Interesting use of “devolve”. An an interviewer for a technical role, am I not allowed to have a set of required skills? And is a basic understanding of common data structures not allowed to be in that set?

[fho]

That's interesting ... Might be my specific view on Haskell, but there is a lot of emphasis on using the right data structure for the right job. That's probably because due to Haskell being immutable you have to rethink which standard data structures you can reasonable use.

[euroderf]

"Why is this interview like a string?

Because it is terminated with A ZERO."

[t0mas88]

What role were you interviewing for? Sure anyone with a serious CS degree at some point knew the difference between a char and a string. But if you're hiring a VP or product in a larger org, it doesn't matter whether they remember because the people they'd be managing wouldn't even need to know.

[lumost]

It’s quite possible to avoid learning this. A trivial way is to do all of your coding in python, and then never do anything more advanced than a todo MVC app. Do this for 3 years then get promoted to management and stop coding.

When money was cheap, delivery didn’t matter for a while.

[squeaky-clean]

I've interviewed and approved people for hiring who probably did not know the actual difference between a char and a string. And they've done more than a TODO MVP. They were great employees. For python dev work you really don't need to know about that, since it doesn't have a dedicated char type. They could probably answer questions about Django and RabbitMQ that OP couldn't.

But I'm assuming OP is hiring for a lower-level language role where that knowledge is necessary. I've interviewed people with similar levels of incompetence. Again for that Django role, people who did not know the difference between GET and POST. I'm amazed they made it past the first phone screen with our hiring manager. And I'm curious how bad the people who did not pass the phone screen were.

[alex_lav]

> It’s quite possible to avoid learning this.

Could it be inferred? It feels kind of self explanatory...

[ethbr0]

Customer-facing implementation engineer, more or less.

[ionwake]

I find people who judge others on how they answer a tech question to be sus highly judgemental and often wrong about their hunches

But I could be wrong

[ethbr0]

That's why I try to ask open-ended questions. Get to a solution. Might not be my solution, but at least get me there.

How do you run candidate interviews?

[ionwake]

I dont interview, I just hire based on their portfolio, and increment their work load as results come in.

[zo1]

Maybe this is a reverse fizz-buzz filtering test. I.e. they want to self-select themselves out of positions that require them knowing such basics.

Either that or they're completely incompetent. Likewise it takes a special kind of stupid to think they could wing it.

[matrix_overload]

In their defence, many companies advertise various "leadership positions", but once you get to an interview stage, you see they are looking for another JavaScript monkey in the team, and the whole leadership thing is a pie in the sky in lieu of a competitive salary.

[yieldcrv]

The bytes it takes up and how it can be cast? What answer would you be looking for

[somestag]

Presumably something like "a string is a sequence of characters" would be a good first answer, though it might prompt some follow-up questions.

I love how questions like this suddenly become more complicated when you have a deeper understanding of the internals. Your first instinct of an answer might not be 100% correct. If I were asked this question unexpectedly, I'd probably trip over myself a few times as I thought through it out loud.

[ethbr0]

My high water mark was the basics... and then the candidate drawing an analogy between char as primitive and char-array-based-strings as object oriented classes that offered additional functionality on top of chars.

[janstice]

That sounds like someone who will make a four-page fizzbuzz solution, which was at one stage a highlight for us.

What I try to get candidates to do in interviews is find the project they are most proud of, and get them to talk about it at a technical level - the constraints, challenges & solutions. That’s much harder to fake than pretty much anything else, and works at any technical level. My theory is that if they can communicate technical things in enough detail, and show that they have sufficient depth in at least one area they should be able to move sideways into our stack and context.

[ethbr0]

I've also had good luck asking about a project they were on that went off the rails and what they'd do differently next time around.

You can tell pretty quickly how involved they were and if they were thinking through solutions vs just doing as told.

[ultrasaurus]

Not the OP but I'd expect the desired answer to be some kind of semi-technical discussion that shows they understand the fundamentals even if they've forgotten all the details and can have a healthy conversation, not that they know the answer.

Possible good indicators: "I haven't written C code in a decades, but one is a byte, one is a structure" "I'd be in over my head with Unicode but.." "What are you looking to solve?"

Bad indicators: Hostility. Authoritative wrong answers.

(For a director of Product role once, I was asked the difference between REST and SOAP -- not because he cared that I knew the answer, but because he wanted to see how I could work with an engineer who was focusing on the wrong problem)

[yieldcrv]

“Lets ask neurodivergent people stupid questions for stupid reasons”

[F-W-M]

"Strings are sequences of characters" or sth. like that.

[ethbr0]

It's a grab bag, tell-me-something-interesting icebreaker question. I'm looking for some evidence of the fact that you can differentiate the two in some meaningful way.

Not intended to be a gotcha question! Just a quick test of basic CS knowledge to get the candidate comfortable.

[yieldcrv]

> Just a quick test of basic CS knowledge to get the candidate comfortable.

did it work for that purpose?

[ethbr0]

Not this time!

But for every candidate that could answer, I think so.

[yieldcrv]

oh ok, I tend to overthink irrelevant questions in interviews

[ineedasername]

There’s nothing irrelevant about measuring someone’s technical understanding of the very basics at the same time that you gauge their ability to have a conversation about the domain.

[faangiq]

Why not ask him what a bit is?

This is a low IQ question.

[CapricornNoble]

This makes for frustrating reading, coming from an industry where "Organizational Design" can have extremely serious consequences: the military.

A brief case study: Russia's invasion of Ukraine. The argument has been made (and I agree) that much of their early failures stem from not understanding/implementing Unified Command. They didn't have a Joint Task Force Commander who was responsible for the entire Area of Operations. They didn't have an Air Component Commander subordinate to the JTF to ensure all air operations achieved synergy with, and were in support of, the ground scheme of maneuver.

Most field-grade officers who have planned and/or executed a major multi-service or multi-national training exercise are familiar with Command Relationship org charts and understand WHY they are important (if that stuff isn't clear, responsibilities get fuzzy when edge cases arise, and then in the resulting confusion/friction....people die). It's also just as important to understand how much of that "big DoD" cruft you can peel away when you are doing small, localized training with a developing nation with....austere practices, shall we say.

So I could see adding "Organizational Design" to my LinkedIn....unknowingly putting myself in the same bucket as "hot-air no-nothing ex-FAANG managers". And then no one cares what digital signal processing stuff I could do for them as an IC... :(