Część techniczna rozmowy kwalifikacyjnej przeważnie dotyczy bzdetów, z których skorzystałeś raz w życiu lub nigdy. Ja na takich rozmowach mówię wprost, że takie pytanie nic nie wnosi, bo dotyczy problemu oderwanego od rzeczywistości.
Na porządnej - moim zdaniem - rozmowie jesteś pytany o kilka prostych rzeczy, potem temat jest drążony, żeby pokazać dwie rzeczy: gdzie leży granica Twojej wiedzy oraz jak sobie radzisz, kiedy do tej granicy dojdziesz. Jeśli masz trochę doświadczenia w CV, to większość takiej dobrej rozmowy dotyczy tego, co i jak robiłeś, z jakimi technologiami miałeś do czynienia, jakie miałeś problemy i jak sobie z nimi poradziłeś. Nie oszukujmy się, w pracy masz google i niemal wszystkie techniczne problemy rozwiązujesz w pięć minut, a to co się liczy, to tworzenie kodu dobrze zaprojektowanego, przemyślanego i czytelnego; jeśli to umiesz, to co z tego, że nie wiesz jakie regułki składają się na akronim SOLID? Jeśli czegoś się nie umie, to trzeba to powiedzieć wprost i ewentualnie uzasadnić. Ja na rozmowach mówię wprost: jestem praktykiem, czasem nie wiem jak rozwija się dany skrót albo jak nazywa się dany wzorzec - tylko jakie to ma znaczenie w codziennej pracy jak rozwija się literka "L" z SOLID?
Kłamstwa wyjdą w trakcie pracy i nie przetrwasz okresu próbnego (chyba, że bardzo szybko się uczysz). Zresztą czy chciałbyś, żeby rekrutujący też kłamał (choć często to robią)?
Natomiast jeśli część techniczna to w większości pytania o rozwinięcia skrótów, definicje, rozwiązanie jakiegoś specyficznego zadania bez późniejszego omówienia go, to olej taką firmę. Absolutnie nie żałuj, jeśli rozmowa tego typu źle poszła, bo nikt nie ma w głowie wszystkich zagadnień dotyczących świata IT i każdego idzie zagiąć z jakiegoś tematu. Junior nie ma praktyki, natomiast powinien rozumieć co robi, stąd więcej pytań technicznych, żeby zweryfikować, że zna podstawy, ale nie znaczy to, że ma ogarniać każdy temat. Z kolei senior ma (a przynajmniej powinien, choć widuję oferty dla seniorów z trzyletnim doświadczeniem) dużo doświadczenia, powinien umieć je zaprezentować, opowiedzieć o problemach z którymi miał do czynienia i jak je rozwiązał lub dlaczego nie dał rady, a także nie powinien dać się zagiąć na większości pytań niskopoziomowych. Przy czym "nie dać zagiąć" niekoniecznie oznacza, że znasz odpowiedź. Przykład: jakich algorytmów używa GC w .net. Nie mam pojęcia. Dlaczego? Bo nie jest mi to do niczego potrzebne; jestem świadom, że jest GC, że trzeba sobie i jemu ułatwiać robotę (IDisposable/using), trzeba uważać na "gubienie" referencji i zasobów, że działa w pozornie losowych momentach, a tak w ogóle to czy rekrutujący zna odpowiedź na to pytanie, a jeśli tak, to czy kiedykolwiek taka wiedza przydała mu się do czegoś.