Jak sprawdzić lub ocenić umiejętności debugowania danej osoby? [Zamknięte]

Jakie umiejętności determinują osobę, która jest w stanie z łatwością debugować kod? Jakiś czas temu mój przyjaciel przeprowadził wywiad ze stosunkowo dobrym programistą. Programista został zatrudniony. Potrafił pisać dobry kod, rozumieć ramy i wzorce projektowe. Brakowało mu tylko umiejętności debugowania. Nie mógł w ogóle debugować, a znalezienie problemów z jego kodem lub czyimś kodem było dla niego ogromnym bólem.

Od tego czasu zastanawiamy się, jak możemy ocenić lub oszacować umiejętności debugowania danej osoby.

Pierwsze pytanie brzmi: jakie umiejętności określają, czy dana osoba może skutecznie debugować oprogramowanie?

A po drugie: jak sprawdzić te umiejętności podczas rozmowy kwalifikacyjnej?

Jeśli pierwszą rzeczą, którą chce zrobić, jest spojrzenie na kod i przejście go przez debugger, osoba ta nie jest świetnym narzędziem do rozwiązywania problemów.

Jeśli nie masz jeszcze planu działania i zagłębiasz się w blind debuggera, jesteś w zasadzie Wielkanocnym Eggingiem. Dotyczy to KAŻDEGO rodzaju rozwiązywania problemów.

W wywiadzie osoba, która pyta o działanie systemu i pyta o historię systemu, byłaby kimś, kto mógłby być dobrym narzędziem do rozwiązywania problemów. Osoba, która myśli, że system jest pierwszy, a mechanicy drugi, może być dobrym narzędziem do rozwiązywania problemów.

Dotyczy to każdego złożonego systemu.

Argumentowałbym, że najlepszą miarą dobrego programisty w danym języku lub frameworku jest umiejętność krytycznej analizy złożonych problemów i dobra umiejętność debugowania w języku lub frameworku. Muszą być w stanie zademonstrować debugowanie na niskim poziomie, a także biegłość w debugowaniu na wysokim poziomie za pomocą popularnych narzędzi do debugowania.

Oznacza to stworzenie dla nich scenariusza, który demonstruje wysoką umiejętność debugowania narzędzi w wybranym IDE. Powinieneś szukać takich rzeczy jak:

• Uruchamianie piaskownicy aplikacji lub serwera w trybie debugowania lub budowanie aplikacji z symbolami debugowania

• Udostępnianie i demonstrowanie zdalnych portów debugowania lub debugowania aplikacji nieobsługującej piaskownicy, która została zbudowana z symboli (jeśli dotyczy języka)

• Strategiczne wykorzystanie punktów przerwania

• Niestandardowe właściwości punktów przerwania, wyrażenia warunkowe w punktach przerwania (jeśli dotyczy języka)

• Wykorzystanie wyrażeń lub zmiennych zegarków do monitorowania wartości zmiennych lub referencji

• Wykorzystanie wartości zmiennej ad-hoc lub manipulacji referencjami lub wskaźnikami w czasie rzeczywistym

• Wykazać zdolność do wchodzenia, wychodzenia i wychodzenia z przepływu aplikacji

• Krytyczna ocena stosu wywołań

• Debugowanie aplikacji wielowątkowych i ich zrozumienie.

Należy również zademonstrować inne strategie debugowania bez narzędzi, takie jak analiza dzienników i kodu źródłowego, a także możliwość wykonywania debugowania niskiego poziomu bez użycia IDE.

Powiedziałbym, że destylujesz błąd, który miałeś w swoim systemie, do czegoś, co można omówić w kontekście wywiadu. Odpal debugger i pozwól mu na to.

Zadaj mu takie pytania:

1. Jak poradzisz sobie z problemem?

2. Jaki jest jeden ze złożonych projektów i jak go osiągnąłeś?

3. Z jakich narzędzi debugowania korzystałeś?

4. Czy preferujesz niektóre narzędzia?

5. Podaj przykład własnego scenariusza i zapytaj go, jak sobie z tym poradzi?

6. Jak oceniasz swoją zdolność dostania się do kodu innej osoby?

Możesz rozwiązać swoje wątpliwości, zadając pytania. Zawsze istnieje ryzyko, że może on być lub nie być dobry w niektórych umiejętnościach. Ale jeśli jest dobrym uczniem, to bardzo pomoże.

Jeśli chcesz sprawdzić, czy programista może debugować, podaj kod do naprawy. To samo podejście, jeśli chcesz sprawdzić, czy potrafią napisać kod. Daj im problem i poproś, aby napisali kod.

Teraz jestem zdezorientowany co do tego programisty, który nie ma problemów z pisaniem kodu, ale nie powiedzie się źle, gdy zostanie poproszony o debugowanie. Czy ta osoba odwołuje przykłady kodu lub po prostu trzyma się obszarów, które ma doświadczenie, takich jak czytanie i pisanie w bazie danych? Jeśli nie poprawią kodu za pierwszym razem, nie mogą go naprawić?

Może ta osoba po prostu nie lubi debugowania i nie stara się? Nie jestem w tym dobry, więc przestań mnie o to prosić - wyuczona bezradność.

Praca nad istniejącą bazą kodu wymaga przejrzenia kodu, dokumentacji i ewentualnie sporządzenia własnych notatek i desginów.

Wiem, że myślimy o debugowaniu jako naprawianiu kodu produkcyjnego, który zawiódł, ale muszę debugować kod podczas jego pisania. Albo ta osoba nie jest zbyt dobrym programistą, albo po prostu woli napisać nowy kod. Nie wszyscy.

W ten sam sposób, w jaki określasz czyjąś zdolność kodowania, zadawaj jej pytania dotyczące debugowania.

Zapytaj ich, w jaki sposób wykryliby błąd w danej sytuacji.

Zrób krok dalej i usiądź przed komputerem i obserwuj, jak debuguje problem.

Często podawałem kandydatom hipotetyczne sytuacje ... na przykład system produkcyjny przestał odpowiadać. Co robisz? Mogą odpowiedzieć „sprawdź dzienniki”, a ja mówię: „dzienniki nie pokazują niczego nienormalnego, z wyjątkiem tego, że od czasu pojawienia się problemu nic w nich nie jest napisane”. I tak dalej, aż jestem zadowolony, że oceniłem zdolność kandydatów do rozwiązywania problemów.

Zwykle ludzie o dobrych predyspozycjach mają również dobre umiejętności debugowania.

Podczas rozmowy (w zależności od stażu pracy) możesz przypisać im podobne zagadki, takie jak jakiś algorytm lub coś podobnego. To prosty sposób.

Jeśli możesz, możesz wydrukować kod z pracy, zapytaj osobę, czy coś tu jest nie tak, a jeśli tak, to jak to naprawić.

Nie bardzo wolę zadawać zaciemnione pytania podczas wywiadu, które zwykle koncentrują się na umiejętności czytania i poprawiania składni.

Podczas wywiadu poproś ich, aby powiedzieli ci o błędzie, który naprawili w przeszłości i krokach, które zastosowali podczas debugowania.

Niech powiedzą ci o tym, co zrobili w swojej ostatniej pracy, zadaniu domowym itp. I przez co przeszli, szukając problemu.

Podzielę się doświadczeniem wraz z perspektywą rekrutów na temat testu umiejętności kandydata w debugowaniu. Zdecydowałem się na wywiad, który miał trzy etapy. Drugi etap był „praktycznym przypadkiem”. W tym momencie nie wiedziałem więcej. Podczas gdy zostałem poinformowany, istnieje system, który przestał działać i nie wiedzą. Kilka błędów leży w tyle.

Został ustawiony jako zdalny pulpit do starego środowiska testowego. Prawdopodobnie do odłączonego lub izolowanego środowiska. Projekt obejmował kilka formularzy internetowych z niektórymi kontrolkami ASP.NET i powiązanym kodem pliku Code. Plik kodowy odnosi się do rodzaju warstwy biznesowej, dla której mam po prostu bibliotekę DLL, brak kodu źródłowego i opisy metod. Formularze internetowe wykonały funkcje CRUD, których można się spodziewać. Również mała funkcja wyszukiwania. Z kolei warstwa biznesowa rozmawiała z Views i SP na serwerze SQL.

Zepsuli niektóre części na różnych poziomach. Dostałem papier z objawami. „Can't search” „Pole„ region ”zniknęło po ostatniej aktualizacji” i tak dalej. Takie, jakie możesz otrzymać od swoich użytkowników.

Nie pamiętam wszystkich szczegółów, ale zmieniono nazwę przynajmniej pola tabeli, co doprowadziło do zepsutego SP, którego użyła funkcja wyszukiwania. Oznacza to brak błędów w VS i brak kodu źródłowego BL do śledzenia nazw pól. Parametr SELECT względem polecenia Sql został źle wpisany i spowodował nieprawidłowe działanie formularza internetowego. Pominięto także pole, które było brakującym polem w GridView (Autogeneratecolumns). Przycisk ASP.NET odnosi się do czegoś, co musi oznaczać zduplikowaną, ulepszoną metodę i „zapomniałem” wskazać przycisk nowej metodzie.

Także takie drobne rzeczy używające tytułu w tagu HTML, które na to nie pozwalają. Również przeciwny znacznik ALT został pominięty w kontrolce, która tego wymagała. Wystąpiły również błędy związane z nieprawidłowymi zamkniętymi tagami HTML, które jednak nie działały nieprawidłowo. Nie jestem pewien, czy wszystkie te błędy były czystym błędem projektu teatru, czy może takim samym projektem dla różnych rekrutacji. Nigdy nie pytałem Poziom trudności powinien oczywiście odpowiadać potrzebom rekruta.

Taki test powinien być prawdopodobnie sprawdzony (a nie wykonany), aby zobaczyć, po wywiadzie, jak przeprowadzono debugowanie. Dla mnie na tym etapie uznałem test za nieco niedorzeczny, ale to byłby również główny punkt. Jeśli tak było lub nie, warto mieć kandydata na właściwym miejscu.

* Myślę, że test został sprawdzony przez kandydatów / moje umiejętności do *
* Analizowania obcego systemu
* Używaj minimum informacji, aby znaleźć błędy i błędy
* W stresie czasowym i bez pomocy kogoś kod przyjmuje poprawki
* Różne poziomy wiedzy;
** sql db i procedury składowane,
** użycie dll w projekcie,
** technika asp.net,
** architektura warstwowa
** aspekt problemowy

Ale także bardziej oczywiste rzeczy, takie jak obsługa środowiska programistycznego, znalezienie i zrozumienie narzędzia Db Server Management. Z pewnością są kandydaci, którzy wyglądają naprawdę ładnie na papierze, ale w praktyce mogą utknąć na takich zadaniach.

Wybieram rzeczywisty napotkany problem, który dotyczy stanowiska i przedstawiam go kandydatowi tak, jak został mi przedstawiony. Oczywiście oferuję im ogólne tło i niewielką ilość odpowiedniej dokumentacji, takiej jak fragment kodu lub schemat.

Mówię im, że ich zadaniem jest rozwiązanie problemu, i oferuję odpowiedzieć na wszelkie pytania techniczne, które mają, i powiedzieć im o wynikach eksperymentów, które chcą przeprowadzić. Jeśli powiedzą: „Umieściłbym tutaj sondę zakresu”, naszkicuję im ślad tego, co mogą znaleźć. Jeśli chcą wstawić printfpętlę, powiem im, że nigdy nie wychodzi (!) Lub najpierw drukuje „7”, a następnie wielokrotnie „5”. Jeśli odejdą tak daleko od chwastów, że nie będę w stanie udzielić sensownych odpowiedzi, przyznam, że jesteśmy na złym torze i wracamy do czegoś innego. Jeśli utkną, zadam wiodące pytania lub dam wskazówki, dopóki nie będziemy mogli przejść dalej.

Chcę zobaczyć uporządkowane procesy myślowe, determinację, aby znaleźć rozwiązanie, dobrze przemyślane pytania i eksperymenty, a najlepiej udaną identyfikację problemu. Czasami wybieram problemy, które są zbyt skomplikowane, aby ktoś mógł w pełni debugować podczas godzinnego wywiadu, a na koniec udzielam im prawdziwej odpowiedzi. W tym momencie szukam reakcji, która pokazałaby, że byli zaangażowani w problem i doświadczyli tej chwili „aha” i satysfakcji z dotarcia do przyczyny. Najlepsi kandydaci w tym momencie spontanicznie zadadzą pytania uzupełniające, próbując powiązać swoją mentalną mapę problemu z tym, co naprawdę się działo.

Usiądź przy komputerze z kilkoma prostymi symbolami binarnymi (z debugowaniem), które segfagują z odwołaniem do wskaźnika zerowego lub takim + kodem źródłowym + gdb i sprawdź, czy mogą znaleźć przyczynę awarii?

Jeśli masz kandydatów na wstępne testy kodu, poproś ich o zmodyfikowanie kodu podczas rozmowy, aby rozwiązać błąd lub dodać nową funkcję lub jeszcze lepiej oba. Jeśli specyfikacje testu kodu są dość niejasne, ułatwiłoby to tworzenie przypadków testowych z „błędami” w tym czasie.

Znalezienie „błędu” w małym fragmencie kodu jest bardzo sztuczną sytuacją. Przypuszczam, że może to być pomocne w taki sam sposób, jak puzzle i łamigłówki.

Bardziej kompleksowe podejście zadawałoby pytania behawioralne dotyczące tego, jak kandydat przeprowadził debugowanie w przeszłości, powołując się na określone incydenty, a następnie odpowiadając na pytania.

Ktoś, kto jest dobry w rozwiązywaniu problemów, będzie mógł mówić o czymś więcej niż tylko o narzędziach do debugowania w IDE. A co z ... narzędziami do zgłaszania błędów, interakcją użytkownika końcowego, odtwarzaniem błędu, analizą pliku dziennika, weryfikacją?

Debugowanie wymaga WIĘCEJ WIĘCEJ niż śledzenie bloku kodu i każda ocena czyichś umiejętności w debugowaniu powinna to odzwierciedlać.

Daj komuś niesamowity kod, który Twoja firma produkuje. Poproś ich o wprowadzenie subtelnego błędu. Zapytaj ich, dlaczego wybrali ten. Zapytaj ich, jak poszliby znaleźć i naprawić.

Punkt bonusowy, jeśli znajdą błąd w oryginalnym kodzie.

Podwój punkt bonusowy, jeśli mogą naprawić błąd w oryginalnym kodzie.

Zwykle proszę ludzi, aby opisali mi najtrudniejszy błąd, jaki kiedykolwiek mieli do wyśledzenia i naprawienia oraz co zrobili, aby go znaleźć i naprawić. Wiem również, że jeśli najtrudniejszy błąd był czymś, czego można oczekiwać od początkującego, to prawdopodobnie nie są dobrym narzędziem do rozwiązywania problemów (chyba że jest to wywiad dla początkujących). Jeśli jest to naprawdę trudne i opisują swój proces myślowy, próbując go wyśledzić, to mogę się dowiedzieć, jaki jest jego poziom umiejętności. Zawsze zadziwia mnie sama liczba osób, które wyglądają jak „jeleń w świetle reflektorów” i nie potrafią wymyślić żadnego przykładu, co zrobiły, co było skomplikowane. Cóż, przepraszam, że ktoś, kto pozostawia trudne problemy komuś innemu do naprawienia, nie jest kimś, kogo interesuję się czymś innym niż zwykłym szkolnym,

Zadałbym kilka technologicznych pytań agnostycznych, takich jak:

• Przeprowadź mnie przez wszystkie kroki, które podejmujesz, aby zidentyfikować przyczynę źródłową i naprawić błąd
• Jak użyjesz stosu połączeń podczas debugowania aplikacji obsługującej wiele wątków

Działa to naprawdę dobrze, szczególnie w wywiadach telefonicznych, ponieważ wystarczy, że dana osoba udzieli Ci przekonującej odpowiedzi, która pokaże, jak naprawdę działa podczas rozwiązywania problemu.