Interviewing a 7yr experienced c++ guy, started with an ice breaker.
Me: when would you use std::list and when would you prefer to use std::vector
Candidate: vector for sequential elements and list for sequential but sorted elements
Me: why list for sorted elements? I didn’t say anything about sorting
Candidate: you’re rude

Real telephonic interview

Candidate dodged a bullet there

Could someone explain it? I don't get it.

Surya. In IT recruiters are not all powerful and candidates shouldn’t have to accept rudeness. I wish this were the case in other fields.
In any case, why are you surprised he responded to you with the same tone you used with him?

As a hand on technical manager, I have a different viewpoint from the rest in here...

It might have been the right answer, but there is value in pressing a candidate slightly - without doing it in a rude tone.

Developers are often competent, but rarely learn quite important concepts like design principles. Too often I have worked with a developer who thinks they know best, if ore advice, even ignore what I ask them to do entirely, and they don't know the fundamentals like even how to write a test, even why they need to write tests. "But it works so it's fine".

That wouldn't be a problem but their reaction to any kind of constructive criticism is always to fight back.

If you're a developer with a lead it's your job to disagree when necessary, but do what you're asked to do. If your lead is incompetent change jobs.

An interviewee reacting like this sends alarm bells that they're going to be a pain in the arse. I don't want to work until midnight because they didn't fucking listen.

Unless you have good reason to believe the lead knows fuck all eg they don't know how to write a test, understand nothing about FP Vs OOP, have never heard of design patterns, haven't heard of DDD, and lie about their ability. Sadly that happens a lot too.

His answer doesn't make any sense to me. A list has nothing to do with sorting, and you can obviously sort contents of a vector as well.

IMO, the right answer should have been to use vector by default and normally avoid lists.

With a large list length, any benefit in insert / delete is more than offset by cache thrashing upon traversal so that the block copy operations of a vector will still be faster.

@Fast-Nop Agree that his answer didn't make sense.
I am not 100% about the std implementation, but I think of vectors as arrays - where the memory is allocated continuously for elements. A list would just have pointers to elements that can be allocated freely. So I would say if you want quick access you'd use vector, but if you expect to have a lot of data, then trying to allocate it continuously might be a bad idea. Classic memory-runtime tradeoff.

@NickyBones I wouldn't quite agree to this because the memory is only continuous in terms of virtual address space, not in terms of physical memory layout, and the MMU translates between them two. With a 64 bit virtual address space, memory fragmentation has become a non-issue.

At least unless we're talking microcontrollers without MMU, i.e. embedded systems, where dynamic memory allocation after initialisation should better be avoided in all forms, vector and list alike. Memory fragmentation is one the the reasons, unpredictable allocator latency another one.

@inawhile Ask the other way around: why not vector for larger element count, given that even insert / delete is faster with vector on contemporary CPUs - which removes the only thing a list ever had going for it?

I could only imagine the fringe case with a lot of insertions / deletions in a short list that has huge individual elements.

@Fast-Nop I've been working directly with hardware memory addresses for most of my programming life. Virtual memory is a privilege :)

@inawhile Btw., what do you mean by "wider number of elements"? Not just "many elements"?

Also, the question might be a trick question, or the interviewer holds a different view on the traversal cost of lists. In a good interview, that would be OK as long as the candidate can present valid technical arguments. In a bad interview, the candidate would dodge a bullet.

@NickyBones In my first company, they made an embedded system with no MMU and tons of dynamic memory allocations because that would cut down the BOM a little (less RAM needed). I had warned against that, but they ignored me because I was just a junior dev.

They ended up with a 24 hour auto-reboot to get that thing stable because it would hang in some "out of memory" error state after a week at most.