After the initial recruiter call, I was required to complete a HackerRank task. The problem itself was easy, but the instructions were incomplete, forcing me to waste time reverse-engineering requirements based on failing test cases.

Next was the code pairing interview, which involved implementing an ICollection interface—straightforward in theory. However, the provided IDE lacked proper intellisense, making basic tasks more tedious than necessary. The example names were confusing, adding to the inefficiency.

I managed to pass 22-23 out of 25 test cases, but for the remaining failures, I couldn’t determine the issue. When I asked the interviewer for clarification, he outright refused, saying, “There are some hidden requirements, which I do not want to disclose.” That response was ridiculous. If the goal was to assess problem-solving skills, then the requirements should have been clear from the outset rather than being an arbitrary guessing game.

Even at the end, when I directly asked how to fix one of the failing methods, the response was, “We are out of time, and I would rather not disclose it.” That kind of approach makes no sense—interviews should not be "gotcha" exercises. If they wanted to test requirement gathering, that should have been a separate discussion rather than hiding key information in a coding task.

Another major issue was the choice of IDE. In real-world scenarios, we auto-generate interface methods and refine them, not manually type boilerplate code. Forcing candidates to work in a limited environment just slows things down unnecessarily.

To top it off, the interviewer had a thick accent that made communication difficult. I had to ask him to repeat himself multiple times, which further disrupted the process.

Overall, the experience was frustrating and felt poorly designed. If this is how they assess candidates, they are likely filtering out good engineers for all the wrong reasons.

Implementing a generic ICollection interface