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.
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.
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.
I also ask the same question. Because of my current industry, usually with the caveat that they have to be able to get into some technical details without breaking NDA.
Some of my favorite other questions are:
1 - You're diving into one of our repos for the first time and you need to add X feature. Let's assume everything is perfect, what would you want to see in the repo and what are your first steps in learning the code?
2 - Tell me about your favorite bug? It doesn't have to be one you caused. And it doesn't have to be a super technical obscure bug. Just your favorite bug.
3 - What are some of your personal philosophies when it comes to programming. In other words: What are some of your opinionated takes. I understand, when working here you'll follow company policy. But what if you were the person who wrote the company policies.
All are great jumping off points for further discussion and open up a lot of followup questions. I find they're pretty hard to fake after the conversation goes on for more than a minute or so.
> You can tell pretty quickly how involved they were and if they were thinking through solutions vs just doing as told.
Yes, but which has more utility for you.
Do you tell people what you are indexing for? Its not a fair assessment if you don't tell which has more utility for you, or don't tell the recruiter how to help people prepare and just gaslight people with "there's no right/wrong answer, I just want to see how you think" if you actually want someone that does what they were told or someone that synthesized solutions. Many people have experience in both environments and have an answer for both environments.
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)
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.
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.
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.