Alternatively, you can use a library like Arrays which exposes purely functional arrays which have very good time- and memory-properties, especially for operations such as accessing random elements or modifying random elements.
Depending on the exact array implementation, these run in an amortized O(log10(n)) or O(log32(n)). The difference between this and ‘true’ O(1) is only noticeable at ridiculously large collection sizes (at which point the array will no longer fit in your cache, or possibly in all of your non-swap RAM, which will probably overshadow these differences anyway.)
Of course an implementation in a ‘close to the metal’ language will be even faster and even more predictable (like no GC pauses), but for most situations this difference in efficiency is not worth dwelling on too long, as it is much more likely that your app will be bottlenecked by other things (like e.g. reading from/to files or communicating with external services over a network)
And for programming exercises such as Leetcode, these approaches are most definitely more than fast enough 
.
