Let me start saying I always had the best treatment by Alicia, Javier and Eduardo at every stage of the interview. My experience wasn't the best for other reasons. I believe I hadn't been told (if so I hadn't understood it) that the technical interview would include live coding and solving code challenges on the spot. I had been told it consisted in a code review of a repo I had been given access to in GitLab. The code to review had many topics of discussion explicitly mentioned in the README, giving you the idea that it will be what you discuss in the technical interview. It was a basic server with tons of repetitive code, var/let/const arbitrarily, bad practices, no DB... The topics involved reestructuring (DDD), DB implementation, SOLID, testing... Many topics to be discussed and that would easily evaluate one's capacity to work in the backend. But at the time of the interview (1h) this was only the first 5-10 minutes. The rest was abstract/logic/how-would-you live coding problems, unrelated to the previous code. I am particularly against these practices when they are not oriented towards everyday tasks one might find. Live coding logic problems (everyday more and more solvable through any AI for instance) or theoretical questions of 'how would you' with that hybrid of code it but don't code it... makes me nervous cause of the evaluation context and blocks me internally. This is probably my process, although I have put this in common with peers and it might not be my problem only. That being said, let's remember I was given quite some time to review some code. What if those live coding questions were referring to the code that the candidate has had the time to familiarize with? And not something on the spot? It is way more realistic, practical and I believe reliable. I believe that part of the process was really tricky and this is why I blocked and wasn't able to perform, thus perhaps wasting what could have been a very nice match...