After a first round with HR, a second call with an engineering director, then a coding interview.

I was receiving positive feedback during the implementation. All the code puzzles were solved in O(N); the only non-linear one was O(M+N). I did test the code and pseudocode after the interview, and it worked. The exercise itself was not that hard.

The person who interviewed me also asked random questions on UT, how to, and when to. Clearly, they were following a checklist. I'm not sure how prepared they were on the questions they were asking.

I made 4 of 6 steps of the exercise. The interviewer had to rush 20 minutes before the end of the one hour booked for the interview. I'm not sure if it was a strategy to get rid of me :), I'm confident I was going to complete the test.

It's fine not to pass an interview for any reason. When I asked HR for feedback, I unfortunately did not receive any reply with evidence. Interviews are a way to learn as well.

I do interview people frequently; the approach is different.

I did use C#.

Question: Validate a lineup.

A basic code puzzle. Straight implementation involved nested for loops. I achieved linear runtime execution by using dictionaries. Then, constant time operations inside the for loop, assignments, and key lookups during a single interaction.

Access in constant time within the dictionary to check for distinct key values.

Basic usage of LINQ to perform sum, groupBy, and distinct operations.

Generic, very high-level questions on Unit Testing, like "Do you think it makes sense to use them and when?"

Really, you cannot interview a senior developer and ask questions so poorly.

There was a question on the complexity of a LINQ command execution. I'm not sure about the point of that; it depends if the operation runs in memory or server-side. The time to generate the SQL command and execute it is another story. The volume of data to deal with is yet another story.