> However, reversing a string is not a commonly useful operation.

But not for an interview :)

If you ask me to reverse a string at interview, you're going to get my opinion about at least:

* Why a string isn't (shouldn't be treated as) really just a sequence of characters (even if yes, internally it's probably some structure like a vector of bytes, or 16-bit unsigned integers, or whatever) and so "reversing" it is probably nonsense.

* Dangers that fall out of that, starting with: Oops my reverse function actually produces invalid trash because that's not how text works.

* Bad interview code exercises. Do you actually reverse strings here? No? Then why are you wasting my time?

The first two are good discussions. I used to have an interview problem that was framed around money computations and I always appreciated it when interviewees considered the challenges with doing floating point math for money.

I also don't really expect "reverse a string" to be on any interview except the "have you ever coded before in your life" phone screen.

The last one, frankly, makes you come across as a jerk. If somebody spends their interview time telling me I am an idiot or mean or foolish for choosing a particular interview question, that's not going to go well. People who show up to a design review with a shallow understanding of the problem and assume that the other people are just stupid for not doing it a certain way are terrible to work with. Assuming that the other person has a reason for doing something is a better starting point.

I think you can do this stuff in a respectful way. I've been in and around a lot of hiring situations where no one knew what they were doing, and were also aware they didn't know what they were doing. If your candidates start showing up saying "this is... not exactly what people do" that's actually really helpful.

For example, I'm fully against whiteboarding now. I'm pretty good at it, but I think it's irrelevant and ableist (lots of people have anxiety issues and so on). When companies ask me to take a live test, I decline respectfully, talk about all this, and offer alternatives (pairing, take home assignments, review of past work, references). If this doesn't fly, well it wasn't meant to be, and it's better we both found out early on.

I think I'm pretty against whiteboarding code, but I do feel like there's value in having someone sketch an architecture diagram or something, since that is pretty relevant to most software engineering jobs.

Like sure, you're usually going to start the design review with a prepared document that everyone's looked at in advance, but if it becomes contentious, you need people to be able to quickly pitch their alternatives and hash out the various tradeoffs in a synchronous way (eg, not running off and making a whole new slide deck for each stage of iteration).

Oh, yeah I guess I've been using "whiteboarding" to mean "live code test"--which these days are done on like CodeSignal or whatever. I guess for teams that do architecture stuff w/ an actual whiteboard then like, yeah that skill seems relevant.

And I 100% think that both parties getting a feel for how work is done is very important, so I think like letting interviewees have a look at some code reviews, maybe sit in on a retro, do a pair exercise or whatever, this stuff makes sense. And I like your point about "if things become contentious": a lot of teams can fall apart in these moments, and they're kind of a test of the maturity of the participants and the strength of the culture.

If given a question about reversing a string, it lets you ask the interviewer questions like:

* Do you want to do it in-place or as a copy?

* Is it an ASCII or Unicode string? If using Unicode, I assume you want to reverse on grapheme cluster boundaries?

Asking these questions let you as a candidate demonstrate your knowledge.

If the candidate doesn't ask these questions, the interviewer can ask follow up questions like.

* What is the time/space complexity of the algorithm? (Easy answer!)

* How does this work with UTF strings?

I don't particularly like the question, but have been in interviews where this exact question was used. From the discussion with the candidate it did very quickly weed out inexperienced developers. I was amazed at how many people applied for roles and had no knowledge of these concepts.

> Do you actually reverse strings here?

We've also tried doing more in-depth code exercises, which are more applicable to our business domain. That didn't work much better, and required upfront work from the candidate, which isn't always fair on them.

Anyways - happily not involved in the recruiting process any more.

"Welcome to Reversr. We provide string reversal as a service!"

LOL. I mean, if it existed Reversr is potentially a really interesting business, like they presumably have some very sophisticated language analysis stuff and they've got a bunch of different reverses they can do, for example maybe there are cases where (020) 6543 2109 should be reversed as 9012 3456 (020) notice the parentheses swapped there to still make sense. Or they can reverse "black cat named Noir" to "white cat named Blanc" or a whole bunch of interesting work.

But, I'm guessing Reversr don't want me to write some awful slice swapping algorithm that disrespects their hard won knowledge about human writing systems.

This would be a great answer in my book, it shows advanced knowledge and the willingness to voice and objectively justify your opinion. I would openly say so, but insist on the coding just to see you pop a vein.

A good programmer knows to call out the bullshit task, but also do it anyway when needs must.

So reverse a list/slice of anything else then?

Sure, reversing slices of say integers makes lots of sense, people definitely use that. I don't remember enough Go to know how tricky that is - presumably it is not a built-in feature?

Rust's slices have reverse() but the implementation is a little hairier than you might expect: https://doc.rust-lang.org/src/core/slice/mod.rs.html#625 explains why, it wants to persuade LLVM that the things we're swapping are definitely different things, so it cuts the slice in half (if there's an odd middle element no matter, it needn't move anywhere by definition) and swaps between halves, so that LLVM can see OK, this necessarily is two different things, no aliasing is possible.

I can't think an interviewer is expecting you to show that unless you're interviewing for a job working on optimisations in the compiler or something.

I'm really curious why LLVM can't figure out that a[i:j] and a[j:k] are disjoint without help. Is something about the use of Range making it opaque?

Mmm, I don't recognise your notation, are a[i:j] and a[j:k] really disjoint?

Isn't a[j] in both of these slices?

In all programming languages I know of using this syntax the upper bound is exclusive.

It's inclusive in R, Julia, Matlab, Fortran and presumably most languages use 1-based indices by default.

Fair I guess - of those I only used Fortran and not in an environment which supported the colon syntax. (Once you've chosen the wrong way to address array elements of course you'll end up with the wrong way to denote bounds, to take the contrapositive of the classic Djikstra note.)

But in this thread we're talking about Go - and the syntax is also used in Python and Ruby and with the same semantics `..` in Rust - and above all else the notation was clear from my question when I explicitly said those sets were disjoint - and that question is the much more interesting thing, I think?

If i==j==k then they’re not disjoint.

Then they're both zero length and a zero-length set is disjoint from all other sets.

Anyone want to explain why Rust needs to explicitly de-alias this yet? What a useless digression...

Why LLVM needs this explaining? Probably somewhere an optimiser could inspect something and it doesn't.

Rust cuts the slice in half and swaps between the halves, so probably LLVM doesn't convince itself that if you did those swaps directly they aren't ever aliased, but once there are two slices which can't overlap it can see it's fine.

Can you elaborate so that I may regurgitate your response in an interview? Thanks :)

You wouldn't be allowed to use it in an interview anyway, so its absence a feature.

I'm rather confused by this. Do you all not ever have a need to reverse strings? I find it somewhat common in my work. Maybe its because I work with text data for NLP models?