Time for a soap box rant.

I just found this in one of our projects. I've simplified the example to make it more anonymous.

When I see code like this it automatically means there is a lack of attention to enumerations and/or understanding of what they are.

One may argue that in a certain execution of code it's a minor performance hit and therefore insignificant. It's still a performance hit. Furthermore, it takes even less time to do it the right way than it does to do it the wrong way.

Every one of these lines will enumerate the list from the beginning to try and find that one element you're interested in. Big O notation, people.

Throw that crap into a dictionary or hashset or similarly applicable data structure with direct reads at the beginning of your logic so that it only gets enumerated ONCE when the data structure instance is created. Then access it however many times you want.

Soap box rant over.

Hmm. So have you ever argued in a job interview? Like really standing your ground? In a technical interview?

Today I had a live coding session with a company I'm interested in. The developer was giving me tasks to evolve the feature on and on.

Everything was TDD. Splendid!

However at one point I had to test if the outcome of the method call is random. What I did is basically:
```
Provider<String> provider = new SomeProvider("aaa", "bbb", "ccc", "ddd", "eee", "fff")

for(int i=0; i<100; i++) {
String str = provider.get();
map.put(str, incrementCount(str));
}
Set<Integer> occurences = new HashSet(map.values());
occurences.removeIf(o -> o.equals(occurences.get(0)));
assertFalse(occurences.empty());
```
and I called it good enough, since I cannot verify true randomness.
But the dev argued that this is not enough and I must verify whether the output is truly random or not, and the output (considering the provider only has a finite set of values to return) occurences are almost equal (i.e. the deviation from median is the median itself).

I argued this is not possible and it beats the core principle of randomness -- non-determinism. Since if you can reliably test whether the sequence is truly random you must have an algorithm which determines what value can or cannot be next in the sequence. Which means determinism. And that the (P)RNG is then flawed. The best you can do is to test whether randomness is "good enough" for your use case.

We were arguing and he eventually said "alright, let's call it a good enough solution, since we're short on time".

I wonder whether this will have adverse effect my evaluation . So have you ever argued with your interviewer? Did it turn out to the better or to the worse?

But more importantly, was I right? :D

Implement boolean as `HashSet<()>`

sat through a 2 hour lecture/live code on streams, still don't understand the structure well enough to modify an example to check for 4 sequential numbers in a HashSet.

Struggled whole day to remove duplicate objects from a list in java. Those objects (of a custom class) contain a unique id, the remaining properties can be identical across list items.
Wondered why hashset.add() always returns true and thus duplicates are still inserted.
Little did I forget about things like equals() and hashCode() 🤦

Some post 5 posts to achieve 2000 ++ while others post 2000 posts to achieve 5 ++, all fingers in an hashset

Having one year of experience in javascript and almost a year of experience in java. I am still not sure which one to use for interviews.

Would I able to handle questions on hashmap and hashset if I chose to work our data structures problem in javascript?.