[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.

[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.

[ethbr0]

Customer-facing implementation engineer, more or less.

[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.

[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)

[F-W-M]

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

[faangiq]

Why not ask him what a bit is?

This is a low IQ question.