Z mojego doświadczenia wynika, że ​​często stwierdzenia problemów w wywiadach celowo pozostawiają nieokreślone szczegóły. Jedną z rzeczy, których szukamy, kiedy to robimy, jest to, jak reaguje kandydat. Dobre wyniki obejmują prośbę o wyjaśnienie lub przedstawienie założeń z góry; wydaje się, że słaby wynik nie bierze go pod uwagę.

Nie chcesz zadawać milionów pytań wyjaśniających zaraz za bramą; jak sugerujesz, może się to nie udać. Więc pierwszą rzeczą do zrobienia jest ustalenie priorytetów dla pytań. Zdecyduj, które pytania musisz zadać, a które możesz odrzucić (wyraźnie).

W twoim przypadku wygląda na to, że chcesz zapytać o kodowanie (to naprawdę ma znaczenie dla tego, jak podchodzisz problem): „Jak kodowany jest ciąg znaków, czy to powinno obsługiwać wszystkie kodowania?” (Zwróć uwagę, co tam zrobiłeś, oferując dokładniejsze rozwiązanie, ale dając im szansę na powiedzenie „nie, nie przejmuj się tym”).

Z drugiej strony zakres danych wejściowych może być czymś, co po prostu wyjaśniasz w drodze. „Sprawdzę tutaj puste dane wejściowe”, „Zakładam, że w tej chwili nie ma Unicode” itp. - niezależnie od twoich ograniczeń. W ten sposób demonstrujesz, że wiesz o tych obawach, a jeśli ankieterowi zależy na tym, zada dodatkowe pytania („ok, teraz musi też robić emoji; jak sobie z tym radzisz?”).

Prawdopodobnie upraszczasz lub odrzucasz także inne części problemu; to powinno być częścią tego. Na przykład, miałem kandydatów do obsługi błędów - złap wyjątek, a następnie powiedz „obsłuż to”, jeśli na przykład obsługa wyjątków nie jest celem problemu. Nikt nie oczekuje, że podczas wywiadu napiszesz kod produkcyjny na tablicy, ale oczekują , że zrozumiesz, jakie są ważne czynniki, które wpływają na sposób pisania tego kodu.

Te pytania mają na celu wyeliminowanie programistów, którzy nie potrafią programować. Właściwie nie musisz wdrażać idealnego rozwiązania, wystarczy pokazać, że znasz rozwiązanie problemu. Najpierw podaj prostą, prostą odpowiedź. Jeśli chcesz wziąć pod uwagę specjalne warunki, których nie określono w pytaniu, po prostu załóż taki, który Ci odpowiada, np.

Cóż, zakładając, że łańcuch pochodzi z kodowania X, to najpierw. ..

Najprawdopodobniej właśnie to chcą zobaczyć. To znaczy, jeśli przedstawiają problem jako prosty, prawdopodobnie oczekują prostej odpowiedzi.

A potem po udzieleniu prostej odpowiedzi możesz rozgałęzić się i porozmawiać o niektórych drugorzędnych obawach, które musiałbyś wziąć pod uwagę przemyślenia, aby mieć pewność, że masz idealne rozwiązanie. Mówienie o tych obawach pokazuje, że masz głęboką wiedzę techniczną jako bonus do zdania testu.

Poprowadź prostą odpowiedź, a następnie zapytaj o szczegóły.

Wygląda na to, że wiesz już, jak odwrócić prosty ciąg znaków, i zaczynasz się rozglądać na skrajnych przypadkach, w których ankieter chce po prostu zmierzyć twoje możliwości za pomocą kodowania.

Poprowadź wyjaśnienie, jak to zrobić bez żadnych problemów (zakładam, że masz już coś na myśli), następnie przejdź do problemów, które mogą się pojawić, i w jaki sposób rozwiązać każdy.

Ale to wszystko dotyczy tylko wywiadu. W rzeczywistym miejscu pracy są to szczegóły, które na pewno chcesz rozwinąć zanim znajdziesz odpowiedź. To nie jest pedantyczne podejście - za to ci płacą. Musisz znać te skrajne przypadki, które mogą powodować problemy.

W twoim konkretnym przypadku znajomość aplikacji byłaby pomocna, podobnie jak niektóre informacje wprowadzane przez użytkownika na temat oczekiwanego typu ciągów. Oba są przydatne w znalezieniu odpowiedzi, ale w każdym innym przypadku, jeśli użytkownik nie może udzielić ci konkretnej odpowiedzi, załóż najgorsze i planuj sobie z tym poradzić.

W rzeczywistym miejscu pracy, zwłaszcza w programowaniu, oczekuje się, że będziesz w stanie samodzielnie rozwiązywać te skrajne przypadki i dostosowywać się do nich. Nie zawsze będziesz mieć luksus, by usłyszeć, czego się spodziewać, ale w wywiadzie możesz poprowadzić, udzielając prostego wyjaśnienia, a następnie pokazać, że wiesz , czego się spodziewać. To pokazuje, że możesz wykonać natychmiastowe zadanie i że możesz zaplanować nieprzewidziane sytuacje (nawet dla tych, którzy w rzeczywistości nie rozumieją kodu).

O, maaaan, zabawne pytanie i byłem zajęty karmieniem wiewiórek.

Orzechy.

Zawsze udzielaj najprostszej odpowiedzi, jaką możesz. Pozwól, że rozszerzę tutaj o kilka centów.

W twoim przykładzie W scenariuszu, dałbyś funkcję programistyczną, która po odebraniu łańcucha zwraca odwrócony ciąg. Możesz „odrzucić” wszystkie problemy, które powodują, że piszesz więcej o jednym wywołaniu funkcji. W Javie możesz nawet odpowiedzieć na someString.reverse()¹.

W przypadku przykładu niezwiązanego z programowaniem, jeśli zostaniesz zapytany „opowiedz mi o sobie” , dałbyś odpowiedź, która zajmuje mniej więcej 1-2 minuty i nie obejmuje całej historii twojego życia, ale raczej najprostsze (naprawdę, najbardziej istotne ) historie, które namalują obraz tego, kim jesteś .

Zwykle ankieter używa pytania, aby odskoczyć do innego pytania lub poprosi Cię o nieco szersze omówienie obszarów, którymi jest zainteresowany. jest organiczny i pozwala im zbudować bardziej skomplikowane pytanie bez przerażania kandydata, zadając trudne pytanie od razu.

Nie chcesz zgadywać, gdzie przeprowadzający rozmowę kwalifikacyjną idzie - chyba że zostaniesz zatrudniony jako medium. Lepiej jest udzielić szerokiej odpowiedzi (przypadkowo także najprostszej odpowiedzi) i pozwolić im skupić się na niektórych obszarach do ekspansji. Pomaga to ankieterowi pozostać na miejscu i powstrzymuje Cię przed prowadzeniem wywiadu. Ankieterom nie podoba się, gdy kandydaci próbują prowadzić rozmowę kwalifikacyjną, choćby dlatego, że chcą mieć ustawione takie same pytania / odpowiedzi, aby sprawiedliwie ocenić wszystkich kandydatów.

~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. Ok, nie możesz tego napisać - jak zauważyli inni. Chciałbyś (alert nerd) new StringBuilder (someString) .reverse (). ToString (); ~ Ale dla mnie to było zbyt techniczne dla ogólnego forum profesjonalnego typu, takiego jak to. Więc wziąłem trochę swobody twórczej i skróciłem to. Ogólny punkt - podaj najprostszy - jest tym, co chcę przekazać.

Jaki jest dobry sposób radzenia sobie z takimi pytaniami?

Należy pamiętać, że ankieter prawie na pewno nie chce, abyś go uczył i nie Nie szukam rozwlekłej odpowiedzi, ale chce po prostu stosunkowo prostego i prostego rozwiązania pytania.

Kolejnym kluczem jest zrozumienie kontekstu pytania. Jeśli stanowisko jest rolą programisty, to teoretyczne / matematyczne wyjaśnienie nie jest prawdopodobne, czego szuka ankieter. Bardziej prawdopodobne jest znalezienie praktycznego rozwiązania. Jeśli zamiast tego szukasz stanowiska badawczego, to odpowiednie mogą być bardziej teoretyczne odpowiedzi.

Podobnie jak w przypadku odpowiedzi na pytania na szkolnym egzaminie - spróbuj spojrzeć na to z punktu widzenia ankietera / nauczyciela. Podaj odpowiedź, którą Twoim zdaniem chce usłyszeć podczas rozmowy kwalifikacyjnej, a nie to, w co możesz wierzyć lub wiedzieć, że jest matematycznie / filozoficznie / teoretycznie możliwe i / lub poprawne.

Przede wszystkim udzielaj stosunkowo krótkich odpowiedzi. Wywiad nie powinien być zdominowany przez Twoją odpowiedź na jedno „zagadkowe” pytanie.

Jeśli tak działa twój umysł, czy nie byłbyś najszczęśliwszy w miejscu, które to docenia? Znalezienie pracy może zająć więcej czasu, ale jeśli to zrobisz, lepiej będzie, jeśli odpowiesz na pytania dokładnie tak, jak Twoim zdaniem należy na nie odpowiedzieć. Niektóre zawody wymagają tej umiejętności radzenia sobie ze złożonością, a inne nie. Jak myślisz, co by cię uszczęśliwiło?

Prowadziłbym, pytając, czy mogę założyć, cokolwiek myślisz, że biorą za pewnik, i początkowo unikałbym wyraźnego wspominania o tym, w jaki sposób założenie może być fałszywe.

W podanym przez Ciebie przykładzie być "Czy mogę założyć, że łańcuch jest prostym ASCII?"

Takie podejście ma kilka zalet

• Przenosi Cię do odpowiedzi na zadane pytanie tak szybko, jak czujesz się komfortowo idąc, nie zaniedbując potencjalnego „wpadki”
• To pokazuje, że zdajesz sobie sprawę z wagi weryfikacji swoich założeń
• Pokazuje, że jesteś świadomy reprezentacji tekstu poza ASCII
• Pozwala uniknąć postawienia ankietera na miejscu z jakąkolwiek alternatywną interpretacją, którą mógłbyś zidentyfikować

Zaproponowanie rozwiązania, które jest o wiele bardziej złożone, niż poszukiwane przez ankietera, nie spodobałoby się ankieterowi. Mnie też nie pasowałoby, gdybym był twoim menadżerem.

Przekształcenie czegoś prostego w coś złożonego, kiedy oczekuje się od ciebie zrobienia czegoś prostego, doprowadzi cię do śmierci. Nikt nie prosi cię o prowadzenie kursu odwracania strun. Dostarcz rozwiązanie, które masz dostarczyć Jeśli potrzebujesz wyjaśnień co do tego, czego oczekujesz, zapytaj - nie zgaduj. Jeśli masz zastrzeżenia lub zastrzeżenia, zgłoś je w osobnym komunikacie.

Przeczytaj o ankiecie. Czy są techniczni i cenią szczegóły, czy też zajmują się biznesem i chcą, aby postrzeganie było łatwe? Czy są tylko ankieterami i tylko przeglądają scenariusz? Jaka jest natura tej pozycji - czy jest to aplikacja sterująca lotem, czy tylko zwykłe wewnętrzne czyszczenie danych dla jednorazowego załadowania.

W rzeczywistości zdarzają się skrajne przypadki w produkcji. Możesz zaprojektować dla nich z góry lub sobie z tym poradzić, gdy to nastąpi. Zwykle jest to droższe, gdy to się stanie. W najlepszym przypadku użytkownik znajduje złe dane i poświęca czas na ich naprawienie. Co gorsza, nie znajdziesz złych danych, w wyniku czego firma popełnia kosztowny błąd.

Tak, użytkownicy mogą być sfrustrowani, gdy zadajesz właściwe pytania, ale mogą narazić się na bałagan, jeśli coś, o czym nie uważali w tym czasie za ważne, pojawi się jako problem z produkcją.

Szoruję i wczytuję dane w ramach mojej pracy i jest to o wiele bardziej złożone, niż większość ludzi przyznaje. Te dwa słowa to nie to samo „nie mogę” i „nie mogę” to nie to samo. Nie mają nawet tych samych podwójnych cudzysłowów. Użytkownicy nie rozumieją, że to, co kopiujesz z programu Word, niekoniecznie jest tym, co wpisałeś. Powiedziano mi, żebym załadował dane, o których wiedziałem, że chcą je przeszukać. Powiedziałem im, że musimy normalizować, a oni powiedzieli, że nie potrzebujemy wierności. Z pewnością kluczowy klient nie mógł wyszukać inteligentnej oferty i poszedł balistycznie. Teraz mogę z góry zadawać właściwe pytania. Chodzi o to, że możesz zadawać pytania, na które są gotowi, tylko w sposób, który ma dla nich znaczenie. Ostrzeż ich o tym, co może się nie udać, tak aby kiedy coś się stało, pamiętają, że próbował mnie ostrzec.

Wiele firm poszukuje programistów zorientowanych na szczegóły. Musisz zadać pytanie w taktowny sposób. Jeśli nie nagradzają szczegółów, to nie jest to dobre rozwiązanie dla Ciebie. Rozmawiasz z nimi tak samo, jak oni z tobą.

A jeśli chodzi o wisiorek? Zadawaj pytania, używając terminów, które ankieter rozumie i powiedz im, dlaczego. Jeśli nie wiedzą, jakie jest kodowanie lub ascii, zapytaj ich, czy to tylko klawisze na klawiaturze.

W pokerze mają takie powiedzenie, że zawsze podbijaj nutsa (najwyższa możliwa ręka). Mogą dokładnie szukać programisty analnego i dać im szansę to zobaczyć. Raz przewracają oczami, a potem się wycofują.

Pierwsze pytanie, które powinieneś sobie zadać podczas rozmowy kwalifikacyjnej, dotyczy tego, kto przeprowadza z Tobą rozmowę. Jaka jest ich rola? W zależności od roli, jaką pełnią w firmie, ich doświadczenie będzie się różnić, od wysoce technicznych, przez kierownicze, po wspieranie rówieśników, itp. ... Ponieważ doświadczenia będą się różnić, tak samo będą z oczekiwaniami.

Jaka jest ich rola, pomoże ci zrozumieć, jakie jest prawdziwe pytanie.

Przykłady tego, o czym mówię:

Dla kierownika technicznego , który na co dzień odgrywa mniejszą rolę w programowaniu, mogą pytać jesteś pytaniem, ponieważ chcą zobaczyć, jak rozwiązujesz problemy. Być może napotkali problem podczas zarządzania innym programistą i byli bardzo sfrustrowani szczegółową odpowiedzią. Nawet jeśli pytanie jest wysoce techniczne, możliwe, że po prostu sprawdzili je w Internecie. Często oczekują, że będziesz w stanie uzyskać wyniki, zamiast bez końca programować się w dziurze. Chociaż mają wiedzę branżową, ich głównym zainteresowaniem jest realizacja projektu. Oczywiście będziesz chciał być zwięzły i szybko uzyskać odpowiedź, ale wyjaśnij, że rzeczywista sytuacja może wymagać szczegółów, których nie można złamać.

* AKTUALIZACJA Znaczenie terminu „kierownik techniczny” może się różnić w zależności od branży / firmy. Ale tutaj odnoszę się do wyżej wymienionego zastosowania.

W przypadku programisty , który będzie Twoim rówieśnikiem, możesz zwykle założyć, że testuje Cię pod kątem znajomości domeny. Oczywiście widziałem również skrajność, w której ankietowany był proszony o rozwiązanie problemu za pomocą sortowania przez scalanie, kiedy istniały tysiące dobrze napisanych bibliotek w języku programowania, z którym pracowaliśmy. Umiejętność rozwiązania tego problemu w żaden sposób nie wykazała kompetencji na stanowiskach pracy. Było to raczej bardziej skomplikowane wyzwanie: „Czy jesteś wystarczająco dobry? Nie chcę spędzać całego czasu na opiece nad dzieckiem”. W takim przypadku rozsądnie byłoby, nawet jeśli przyjmujesz założenia, aby odpowiedzieć na swoje pytanie, przywołać wszystkie zastrzeżenia, aby pokazać im, że jesteś bystry i doświadczony.

Przeczytałem dyskusję na thedailywtf. Jeśli chcesz to zrobić poprawnie z ciągami znaków Unicode, jest to niezwykle trudne i prawdopodobnie niemożliwe. Z drugiej strony, nigdy nie widziałem nikogo, kto chciałby odwrócić strunę w prawdziwym życiu.

Więc ogłosiłbym, że pokażę kod, który odwraca kolejność punktów kodowych Unicode w ciągu (dając ankieterowi szansę spytania o coś innego), wyjaśnię, dlaczego odwrócenie kolejności wygranych bajtów ' być akceptowalnym i pisz jasny i wydajny kod, który robi to, co powinien.

Następnie powiedziałbym „jeśli chcesz, mogę Ci powiedzieć, jakie są problemy z tym kodem”. Po przeczytaniu dyskusji pojawiła się nieskończona liczba problemów, od całkiem rozsądnych po absolutnie ezoteryczne do niemożliwych do rozwiązania. Słyszałem też, że są ankieterzy, którzy powiedzą „jest błąd w Twoim kodzie, czy możesz go znaleźć”, więc masz na to odpowiedź :-)

W wielu sytuacjach programistycznych, gdy pytasz o wyjaśnienia, osoba proszona o wyjaśnienia tak naprawdę nie ma pojęcia. Więc jeśli zamiast pytać o specyfikację, której nie mają, napiszesz specyfikację i zapytasz „czy ta specyfikacja jest dla Ciebie akceptowalna”, jest to o wiele bardziej pomocne.

Jeśli zostaniesz poproszony o kod do skopiowania pliku, możesz zapytać, co powinieneś zrobić w przypadku wszystkich możliwych błędów. Zamiast tego możesz wymyślić plan, co zrobić, i zapytać „oto, co sugeruję, co powinno być zrobione, gdy są problemy, czy wszystko w porządku”. Myślę, że to idzie o wiele lepiej niż niekończące się prośby o wyjaśnienia. Oznacza to również, że najprawdopodobniej twoje sugestie zostaną zaakceptowane lub zastąpione czymś lepszym, a nie czymś, co twój szef wymyślił na miejscu, ponieważ go o to poprosiłeś.

Myślę, że powinieneś poprosić o wyjaśnienie. Wywiad nigdy nie jest miejscem, w którym można „zgadywać, co myśli ankieter”.

Jeśli chcą prostego rozwiązania, to:

  myReverseStringFunction ("banana") {print "ananab";}  

Można to postrzegać jako: geniusz, prostoduszny lub sprytny.

Osobiście wolałbym zatrudniać ludzi, którzy są zdolni do robienia skomplikowanych rzeczy i współpracować z nimi, aby to złagodzić, niż ludzi, którzy nie mają umysłowej mocy i nie wiedzą, jak uczynić ich mądrzejszymi.

EDYCJA: Zwykle w pytaniach o kodowanie wywiadów nie oczekuje się pisania kodu, który w pełni się kompiluje, ma pełne pokrycie testów jednostkowych, obsługuje błędy, sprawdza poprawność danych wprowadzonych przez użytkownika, jest zbyt wydajny, skaluje, wygląda elokwentnie, pięknie itp. Zawsze możesz zapytać. Dobry ankieter poinformowałby Cię, czego się oczekuje.

EDYCJA 2: Może powinniśmy przestać zadawać pytania programistyczne podczas rozmów kwalifikacyjnych i po prostu spojrzeć na wpisy kandydata na Githubie.