Jak zdać rozmowę kwalifikacyjną HackerRank?

Wynik, który widzi rekruter, to nie tylko zdał albo nie zdał. Ocena HackerRank raportuje kilka rzeczy naraz, a wiedza o tym, które z nich zmieniają się niezależnie, wpływa na to, jak wykorzystujesz czas.

• Zaliczone przypadki testowe. Każde zadanie jest uruchamiane względem widocznych przypadków przykładowych i większego, ukrytego zestawu. To w ukrytym zestawie żyją puste dane wejściowe, pojedyncze elementy, duplikaty i maksymalne rozmiary. Większość utraconych punktów to przypadki brzegowe, a nie błędne algorytmy.
• Częściowe punkty. Ocenianie odbywa się zwykle na poziomie pojedynczego przypadku testowego, więc poprawne, ale wolne rozwiązanie zdobywa realne punkty. Niewysłane doskonałe rozwiązanie nie zdobywa żadnych.
• Limity czasu i pamięci. Tam, gdzie zadanie je ustala, nieefektywne rozwiązanie przekracza limit czasu na dużych ukrytych przypadkach, mimo że przechodzi każdy przykład.
• Raport nadzorcy. Zmiany kart, utrata fokusu, zdarzenia wklejania oraz, jeśli włączone, klatki z kamery są dołączane do Twojego zgłoszenia, aby rekruter mógł je przejrzeć.

To, co inne platformy rekrutacyjne testują etap po etapie, jest opisane w centrum platform rekrutacyjnych.

Znasz już algorytmy, a mimo to straciłeś punkty ostatnim razem, co sprawia wrażenie, że ćwiczenia poszły na marne. Ta sekcja opisuje część, która jest kwestią środowiska, a nie umiejętności. Większość możliwych do odzyskania punktów tkwi właśnie tam, a odzyskanie ich jest tanie.

• Ćwicz w edytorze HackerRank. To nie Twoje IDE. Nie ma autouzupełniania, na którym polegasz, nie ma debuggera, a Twoje skróty klawiszowe zniknęły. Zrób w nim kilka pełnych zadań przed właściwą próbą.
• Naucz się szablonu wejściowego (stub). Niektóre zadania dają gotową, sparsowaną sygnaturę funkcji, inne wymagają, żebyś sam czytał ze standardowego wejścia. Błędne odczytanie stubu to częsty sposób na oblanie każdego przypadku testowego mimo poprawnej logiki.
• Wybierz język, w którym najszybciej debugujesz, a nie ten, który wygląda najbardziej imponująco. Miarą jest przechodzenie testów.
• Najpierw napisz rozwiązanie brute force, wyślij je, potem optymalizuj. Zabezpieczenie częściowych punktów, zanim upłynie czas, to nawyk o najwyższej wartości.
• Przetestuj przypadki brzegowe ręcznie: puste dane wejściowe, jeden element, wszystkie identyczne, maksymalny rozmiar.

Weź pod uwagę backend engineera przygotowującego się do rozmowy kwalifikacyjnej dla zespołu platformowego. Rozwiązywał już wcześniej te podstawowe zadania, ale pierwszą część testu spędził na walce ze stubem parsowania danych wejściowych i wysłał jedno rozwiązanie zamiast trzech. Ograniczeniem nie była w żaden sposób jego wiedza o algorytmach.

CodePair to wspólny edytor z żywym człowiekiem na połączeniu, co czyni go rozmową z artefaktem kodu, a nie testem. Ocena to osąd człowieka, a cisza jest źle odbierana.

• Powtórz zadanie własnymi słowami i potwierdź ograniczenia, zanim cokolwiek napiszesz.
• Najpierw powiedz swoje podejście na głos, w tym to, które odrzuciłeś, i dlaczego. Osoby prowadzące rozmowę oceniają rozumowanie, a odrzucone podejście jest tego dowodem.
• Pisz, mówiąc jednocześnie. Długie odcinki ciszy to najczęstsza skarga, jaką osoby prowadzące rozmowy zgłaszają na temat tej rundy.
• Opowiadaj o swoich przypadkach testowych. Przejście przez przypadek brzegowy bez proszenia o to sygnalizuje tę samą staranność, którą ukryte testy mierzą w rundzie asynchronicznej.
• Pytaj, zanim zaczniesz optymalizować. Często osoba prowadząca rozmowę chce działającej wersji i dyskusji o złożoności, a nie wersji optymalnej.

Ćwiczenie tej narracji na głos jest właśnie po to, żeby służył tryb symulowanej rozmowy kwalifikacyjnej, ponieważ porażka jest tu werbalna, a nie algorytmiczna.

Bycie bezpośrednim w tej sprawie liczy się bardziej niż odpowiedź marketingowa.

• Nadzorowana ocena HackerRank jest poza zakresem. Nadzorca rejestruje zmiany kart, utratę fokusu, zdarzenia wklejania i klatki z kamery. Udostępnianie ekranu, nagrywanie ekranu, środowiska nadzorowane i komputery zarządzane przez firmę to przypadki, w których żaden asystent nie jest odpowiedni, a SubcueAI nie twierdzi inaczej.
• To przygotowanie jest tym, do czego pasuje. Wcześniejsze przeprowadzanie symulowanych rund, na głos, buduje nawyk narracji, który ocenia runda CodePair.
• Rozmowy behawioralne i o projektowaniu systemów wokół rundy programistycznej to zwykłe rozmowy kwalifikacyjne w zwykłym oprogramowaniu do spotkań, i to jest obszar, dla którego zbudowano SubcueAI.

To, co platforma może, a czego nie może zobaczyć, opisano bardziej szczegółowo w centrum wykrywalności.