The interview process for the most part is normal given their structure. They need to split it up because they're spread out across different timezones.
You speak with 2 of the founders in a general and realistic fashion with respect to what you do and your experience.
However in addition to that there is a backend interview conducted as part of the main interviews where you will be presented with expectations that are not necessarily real world. As such when you encounter them they're impossible to handle unless you're prepared for them.
For example the expectation that you had to have previously developed a prominent "feature" in a previous role (they will choose which role from your resume). For anyone with any real experience after a while you've typically both:
Developed lots of features that you've given up considering any of them notable... and
You've been in roles where you've been the one that has to clean up and make functional the failed features written by others so you don't actually have any such examples to give. It makes the question unrealistic from a real world expectation. If you fall into any of those scenarios then you will be in trouble because the interviewer will visibly be disturbed that you cannot give him a "feature".
In addition in a more technical aspect of the backend c# interview component you will only be asked to identify "at a glance" what certain bug containing code will do when executed. One of them wouldn't even compile (or pass a linter) and the other 2 would be identifiable immediately upon first execution.
They are not examples of code that you would write so they are not real world scenarios.
In the c# component there is not one single real world scenario in the assessment.
When used as metrics to assess a candidate you need to ask yourself if you want to be assessed against metrics that you would never ever encounter in the real world and are selected specifically to induce failure? Will they do the same when it comes to performance reviews???
With respect to the SQL component you are also asked at a glance to identify what some poorly written queries will produce as output.
Once again they are not realistic of what a normal developer would write and again represents a non real world scenario.
