Wybitnie nie lubię podziału na junior/mid/senior, bo on w sumie nic nie oznacza, ale patrząc z punktu widzenia kogoś, kto szuka ludzi do pracy mam własną interpretację "poziomów" doświadczenia:
Junior - ktoś, kto ma wiedzę, suchą. Wie co to SOLID, zna język programowania, coś tam usłyszał jak należy pisać kod. Mało go jeszcze napisał, więc nie ma sensu pytać o przydatne w pracy rzeczy "jak coś zrobić", więc najczęściej odpytuje się go z głupot typu lista vs interface, albo daje jakiegoś hacker ranka do rozwiązania. W sumie to chyba najbardziej chce się zobaczyć, że chce się rozwijać w programowaniu, a wiedza jest tylko dowodem na to, że już jakoś tam w siebie zainwestował.
Mid - tutaj oczekuje się już kogoś, kto samodzielnie rozwiąże większość problemów w pracy. Nie wiadomo, czy te poprzednie 3 lata coś sensownego robił, miał się od kogo uczyć, więc trochę pytań na wstępie jest o głupoty, typu "klasa abstrakcyjna a interface", czasami trochę pytań o trudniejsze zagadnienia jakiegoś języka, ale powinien też sensownie być w stanie rozwiązywać problemy - ogarnąć jakiś kawałek kodu, rozbić funkcjonalność na klasy/funkcje, zaproponować rozwiązanie jakiegoś problemu, mieć swoje zdanie na tematy typu "czy lepiej pisać testy na poziomie klasy, czy na poziomie pakietu?". W skrócie wykazać się chociaż szczątkowym zrozumieniem tej wiedzy, której oczekuje się od juniora, na poziomie regułek.
Senior - tutaj jest najgorzej, bo nie ma sensu zadawać pytań o podstawy języka (co najwyżej, żeby odsiać ściemniaczy), a ważne są umiejętności, często pozatechniczne. W dodatku głęboka wiedza o jakimś zagadnieniu, albo nawet umiejętności miękkie mogą być wystarczającymi powodami do zatrudnienia. Jeżeli nie pamięta czym się różni jedna implementacja listy, od innej implementacji listy to trudno, bo w 99.9% przypadków, wybór nie ma żadnego praktycznego znaczenia.
Podsumowując - im dalej, tym trudniej, bo nie wiesz o co będą pytać, jak i czego właściwie oczekują.