Interviewing for when the interviewing is expecting an array (sarcasm intended).

All kidding aside, unless I'm interviewing at an Elixir shop, I've learned that Elixir is a little too weird for interviewers who don't know Elixir very well.

Same things arrays are used for in all mainstream languages ie. index-based access.

You want tuples. They've got index-based access, and all your useful things in erlang:element/2, setelement/3, append_element/3, delete_element/2, insert_element/3.

With a big caveat that modifying tuples isn't great for performance unless the compiler or optimizer determine that mutating the tuple is acceptable rather than providing a mutated copy.

I understood tuples are only optimised for a handful of elements.

This is correct. If you want a true array experience you have to use atomics or a nif.

That's not answering the question. I've written many thousands of lines of elixir and never used index based access.

Good for you but why do all mainstream languages, including Clojure, have them?

Because they're built on mutable datatypes. Elixir (and Erlang, and some flavors of lisp) are not. Instead of fudging it to make it syntactically "look like" an array access, elixir makes you flip through the list to understand the cost of what you're doing.

Even clojure's is a cheat.

Then maybe that's a shortcoming of absolute immutability.

The only time I've hit this is when implementing algorithms that assume constant time access and modification (a lot of algorithms assume this, and can't be swapped for index based maps easily)

This occurred somewhat recently when implementing stable topological sort. I ended up swapping List out for a Vector (Aja is library I used). I received a 100x performance improvement from it.

That's really the only time I've truly hit a List performance roadblock in 7+ years of Elixir.