Część wywiadu ciągle mi się nie udaje, sugestie? [Zamknięte]


13

Mam więc kilka programów / witryn w moim portfolio. Zarabiają pieniądze, ale nie za dużo.

Postanowiłem więc zdobyć doświadczenie zawodowe, głównie aplikując na młodsze stanowiska programistyczne Java / PHP.

Problem polega na tym, że odpowiadam poprawnie na wszystkie pytania techniczne i planujemy zrobić „test” kodujący, ostatnią fazę wywiadu. Nigdy nie mogę się odprężyć i zastanowić nad tym, co kończy się testem bardzo powoli. LUB czasami po prostu uderzam w blok i bardzo trudno jest mi myśleć na własnych nogach.

Nie rozumiem tego, ponieważ inne rzeczy, które napisałem, rozwiązywały znacznie bardziej złożone problemy, podczas gdy „Test” jest tak naprawdę brutalnie prosty, jak pisanie i testowanie palindromu.

Innym razem dadzą mi test logiczny z przepływami do operacji matematycznych i znowu nie będę w stanie tego zrobić w czasie, który przydzielą.

Wiem, że potrafię pisać oprogramowanie / strony internetowe z możliwością sprzedaży, które mogą generować niewielkie przychody i znaleźć sposoby rozwiązania problemów, ale mam duże trudności z prostymi testami kodowania w wywiadach.

Jakieś sugestie?



Najwyraźniej sądzisz, że testy w rozmowie kwalifikacyjnej mogą być proste, ale wygląda na to, że nie jesteś sam w problemach z tymi
Jakiś programista koleś

2
Nie mogę się zgodzić z tym linkiem. Biorąc pod uwagę różnicę między dobrym deweloperem a złym, naprawdę chcesz zaryzykować znalezienie dobrych kandydatów niż zdobycie złych.
deadalnix

7
@deadalnix Nie zgadzam się z twoją niezgodą. :-) Widziałem wystarczająco dużo dobrych programistów, którzy źle przeprowadzili testy, a źli programiści zdali testy, które moim zdaniem nie są przydatne i często przynoszą efekt przeciwny do zamierzonego. IMO, wszystko, co robią, sprawia, że ​​ankieter / HR czuje się dobrze.
Brian Knoblauch,

2
@Boachim i wszyscy: jeśli przeczytasz pierwsze akapity tego linku, to tak naprawdę dobra rada, aby testy były odpowiednie i przydatne: nie oznacza to, że testy są bezużyteczne.
MarkJ

Odpowiedzi:


18

Uczęszczaj na wywiady. W końcu znajdziesz miejsce, w którym będziesz zadawać pytania bardziej dostosowane do twoich mocnych stron. Uzyskasz także lepszą i wygodniejszą rozmowę, która może tylko pomóc. Spójrz na to jak na grę, bo tak naprawdę jest. Graj dalej, a ostatecznie wygrasz.


2
Nie sądzę, że chodzi o wartość merytoryczną / treść pytań, a jedynie warunki odpowiedzi. Źle popełniłem błąd, bool isPalindrome(string)ponieważ miałem napisać go na papierze w terminie (15 minut?). Biorąc pod uwagę edytor tekstu i bez limitu czasu, uważam, że mógłbym to zrobić idealnie w ciągu minuty.
SF.

9
@SF: próbowałeś tego po wywiadzie? Jak długo Ci to zajęło?
kevin cline

2
Ćwicz także nad swoimi słabościami. W takim przypadku znajdź małe, podobne problemy i poświęć czas na ich rozwiązanie na papierze. Najpierw poćwicz, aby coś działało (nawet jeśli jest to złe), a następnie iteruj, wykonując odpowiednie czynności. W ten sposób możesz pokazać swój proces myślenia jako część wywiadu. Wygląda na to, że jest to największa umiejętność, której ci brakuje (w tej chwili), aby teraz uzyskać minimalną liczbę wyników, a następnie poprawić ją z czasem. Wiele firm lubi to :-)
Al Biglan,

Właśnie zobaczyłem to połączone z slashdot; nieco spokrewnione: infoworld.com/d/application-development/…
Kevin Hsu

Jeśli problem polega na tym, że nie można programować na papierze, to moim zdaniem prawdziwy problem. „isPalindrome” nie powinien wymagać żadnych niejasnych wywołań API ani funkcji językowych; powinieneś być w stanie stworzyć taki program, który można skompilować, bez żadnych korzyści inteligencji lub IDE.
Eoin Carroll

12

To jest bardzo powszechne. Większość programistów jest w stanie skutecznie programować, gdy znajdują się w strefie komfortu. Na przykład mogę pracować tylko na Ubuntu, z vimem, jeśli nie mam tego obszaru roboczego, nie będę miał ochoty programować. Ja również wymagać , w pewnym stopniu Google na badania.

Jestem pewien, że opracowałeś strefę komfortu programowania. Polecam, przyzwyczajając się do środowiska, w którym ktoś stoi za tobą i czeka na uzupełnienie kodu. Najlepszym sposobem, aby się do tego przyzwyczaić, jest kontynuacja rozmowy kwalifikacyjnej.

Możesz myśleć, że nie ma to większego wpływu i może nie. Ale dla niektórych z nas, programowanie z muzyką lub bez, za pomocą IDE lub prostego edytora tekstu, za pomocą drewnianego krzesła lub siedzenia na kanapie, ciemnym pokoju lub jasnym pokoju ... to ogromna różnica w naszym rozwoju prędkość.

Uwaga: po otrzymaniu pracy zazwyczaj możesz stworzyć własną strefę komfortu w przestrzeni biurowej, którą ci dają.

EDYCJA : To pytanie przypomina mi sprzedawcę, który pyta, jak czuć się lepiej i lepiej dzwonić na zimno. Najlepszą odpowiedzią jest wykonywanie zimnych połączeń i refleksja nad każdym połączeniem. Po pewnym czasie sprzedawca poprawia swoje umiejętności i komfort. Wydaje mi się, że programista nie różni się, biorąc udział w rozmowach kwalifikacyjnych, ponieważ najważniejsze jest, aby sprzedać się ankieterowi


Kim jest Sopha? Piękna bliźniaczka Sophie?
u

@ Rick: niestety, jako ankieter, nie mogę po prostu uwierzyć komuś, że jest skutecznym programistą. Muszę zobaczyć, że faktycznie mogą programować. Ani zgłoszone doświadczenie, ani GPA, ani certyfikaty, ani próbki kodu nie mogą mi tego powiedzieć. Muszę zobaczyć, jak kandydaci wykonują programowanie.
kevin cline

@kevincline Zgadzam się, dlatego zalecam mu, aby nadal chodził na wywiady i czuł się swobodnie z ankieterami takimi jak ty.
Rick Rhodes,

6

To tylko moja sugestia, dlaczego nie spróbować zostać przedsiębiorcą. Może być wiele osób, które borykają się z podobnym problemem. Jeśli potrafisz pisać strony internetowe o niewielkich dochodach, to na pewno możesz na nich zarobić.


1
+1, a ducha przedsiębiorczości można postrzegać jako bardzo pozytywną cechę.
wałek klonowy

5

Zidentyfikowałeś już swój problem - rozwiązywanie problemów pod presją (np. Gdy ktoś cię obserwuje). Czy to dlatego, że brakuje ci pewności siebie, nie masz wystarczającego doświadczenia lub pękasz pod presją?

Udawanie się na wiele wywiadów w celu zdobycia doświadczenia i praktyki może być dobrym pomysłem, ale może również przynieść efekty przeciwne. Ciągłe niepowodzenia w wywiadach mogą jeszcze bardziej podważyć twoją pewność siebie, więc bądź ostrożny.

Sugeruję, abyś spróbował programowania równorzędnego, abyś mógł wygodnie rozwiązywać problemy, gdy ktoś cię obserwuje. Spróbuj także dowiedzieć się, co powstrzymuje cię przed byciem skutecznym pod presją (czy to stres związany z samym testowaniem, stres związany z pracą pod ścisłym nadzorem, stres związany z pracą w określonym czasie itp.).


1
Powinieneś także przejrzeć w Google niektóre z tych pytań testowych. Wydrukuj je w sposób, w jaki otrzymujesz je podczas wywiadu i rozwiąż je. Usiądź przy stole, a nie na komputerze. Musisz spróbować odtworzyć presję wywiadu.
Bill Leeper

3

Brzmi jak dusisz się pod presją. Ponieważ musisz wykonać przykłady czasowe w ramach procesu wywiadu, musisz nauczyć się, jak sobie z tym poradzić. To wszystko dotyczy radzenia sobie ze strachem, a nie umiejętności programowania.

Jedną z opcji byłoby przećwiczenie pisania przykładowych problemów i poświęcenie czasu sobie. Gdy dowiesz się, że możesz to zrobić w mniej niż dziesięć minut, możesz obawiać się mniejszego czasu.

Inną opcją byłoby wymyślenie techniki uspokojenia strachu i użycia jej do uwolnienia się od zadławienia. Nauka techniki medytacji może ci pomóc. Albo zapamiętaj litanię przeciwko strachowi (z Wydmy ). Naucz się sztuczki, aby zdjąć reakcję na strach.


3

Jestem zaskoczony, że nikt jeszcze o to nie pytał, ale jak podchodzisz do zadań programistycznych ?

Jeśli po prostu wskakujesz do kodu, istnieje szansa, że ​​się zgubisz i popełnisz proste błędy i wpadniesz w błąd. Zrób to krok po kroku:

  1. Zbierz wymagania : o co dokładnie pyta Twój ankieter. Upewnij się, że przed kodowaniem jest zero pytań w powietrzu. Na przykład w przypadku odwiecznego pytania „isPalindrome” zadaj takie rzeczy, jak „a jeśli ciąg ma znaki specjalne?” lub „czy ciągi nieparzystej długości, takie jak„ ada ”, liczą się jako palindromy?”. Ci muszą umieć wyjaśnić wymagania przed projektowaniu algorytmu.
  2. Zaprojektuj swój algorytm : Podziel go na logiczne sekcje, jeśli ma to sens. Porozmawiaj o tym ... Może napisz jakiś pseudokod, jeśli piszesz na tablicy. Przeprowadź swojego ankietera przez swoje kroki. Spróbuj uruchomić go z kilkoma różnymi danymi wejściowymi (poprawnymi i nieprawidłowymi), aby uzyskać pożądane wyniki.
  3. Teraz zacznij kodować : w tym momencie powinieneś być bardzo pewny tego, co zamierzasz napisać. Zasadniczo powinieneś po prostu wykonywać ruchy w jakimkolwiek języku, który znasz. W tym momencie tak naprawdę nie ma znaczenia, czy wystąpią błędy składniowe, ponieważ ankieterzy, którzy są groszem warti, wybaczą tym podczas sesji tablicy (jeśli dostaniesz komputer / IDE do rozwiązania problemu, to inna historia).

Naprawdę, podczas rozwiązywania problemów z kodowaniem, ankieter nie szuka aż tak dobrego kodu. Chodzi bardziej o to, jak poradzisz sobie z danym problemem. Nurkowanie bezpośrednio w kodzie to zła rzecz, kropka.

Przekonasz się również, że kiedy mówisz o problemie (zbieranie wymagań i projektowanie), poczujesz się trochę wygodniej i rzadziej popełniasz głupie błędy podczas kodowania.


3

Projekt Euler

Wydaje mi się, że nie zdajesz testu fizzbuz . Umysł odrętwiający proste algorytmy, które zasadniczo nie służą żadnemu praktycznemu celowi, z wyjątkiem określenia, czy rozumiesz podstawowe pojęcia programowania.

Odśwież swoje podstawy

Polecam odświeżyć swoje podstawy.

http://projecteuler.net/

Zarejestruj się i zacznij ćwiczyć, a przekonasz się o tych przykładach, aby lepiej zrozumieć podstawowe koncepcje programowania. Myślę, że znajdziesz tam pytanie palindromowe wraz z sekwencjami Fibonacciego i innymi pojęciami matematycznymi (brzmi znajomo).


2

Poproś o informacje zwrotne podczas wywiadu lub po nim. Co im się podobało Co im się nie podobało? Możesz być zaskoczony odpowiedziami.

Różni ludzie oczywiście szukają różnych rzeczy, ale sposób, w jaki próbujesz rozwiązać problem, jest zwykle ważniejszy niż napisanie w 100% poprawnego rozwiązania. Możesz martwić się o wszystkie złe rzeczy.

Najlepszym sposobem na poprawienie czegokolwiek jest ćwiczenie. Spróbuj zapisać listę krótkich problemów. Następnie dla każdego elementu na liście napisz mały program, który rozwiąże problem. Zacznij od bardzo łatwych problemów, takich jak FizzBuzz , i stopniowo zwiększaj poziom trudności. Czy potrafisz rozwiązać problemy, które widziałeś w poprzednich wywiadach? Znajdź największy podciąg, który łączy dwa ciągi? Oblicz pierwszą faktoryzację n !?

Chodzi o to, aby nie nauczyć się rozwiązania każdego napotkanego problemu, ale poćwiczyć szybkie pisanie małych programów, a także dowiedzieć się, gdzie są twoje słabe punkty, abyś mógł poprawić. Wiele problemów można łatwo rozwiązać za pomocą odpowiedniej struktury danych, ale w innym przypadku jest to trudne, więc upewnij się, że masz solidne podstawy w strukturach danych.


2

Poćwicz i znajdź kogoś, kto pomoże ci przejść przez podstawy, jak się przez to przejść. Może to wymagać kilku prób, ale może być zaskakujące, co zostanie odkryte, jeśli możesz uzyskać informacje zwrotne i poćwiczyć na ten temat. Miałem rekrutera, który przeprowadził mnie przez proces rozwiązywania problemu z tablicą, która wydaje się podobna do twojego problemu tutaj.

Nie sugeruję zapamiętywania odpowiedzi w takim stopniu, w jakim zawiera plan tego, co robić, gdy pojawia się taki problem i jak go omówić. Jak to wygląda? Czy widziałeś podobne problemy? Co mogą przynieść niektóre proste podejścia w zakresie algorytmu? Przynajmniej taka jest moja propozycja dla ciebie.


2

Deweloperzy oprogramowania często marnieją, gdy są proszeni o poddanie się testowi kodowania lub napisanie małego fragmentu kodu podczas wywiadu. Jak ktoś już wspomniał, dzieje się tak dlatego, że większość z nas może kodować tylko wtedy, gdy znajdujemy się w „strefie komfortu” i siedzenie w małym pokoju, otoczonym 2-5 ankieterami, nie zapewnia większego komfortu.

Odpowiedź jest trzykrotna:

  • ćwiczyć i ćwiczyć więcej. spróbuj przez miesiąc zrobić 30-40 minut programowania za pomocą papieru i długopisu, a będziesz zaskoczony, jak łatwo by to było. Podczas ćwiczeń - wypróbuj zadania programistyczne, których oczekujesz od sesji kodowania wywiadu - np. Zaimplementuj singleton, odwróć ciąg znaków itp. Jeszcze łatwiej jest „odczytać fragment niepotrzebnego kodu i znaleźć coś złego „- spróbuj wydrukować i analizować te wydruki przez dwa tygodnie, a znacznie poprawisz tę umiejętność.

  • naucz się kontrolować swój strach. jeśli uważasz, że test jest zbyt trudny i możesz go ukończyć tylko 20% - zrób to 20%, nie martw się o resztę. Może się zdarzyć, że test jest nieuzasadniony za długi jak na ten czas (np. Faceci podczas wywiadu powinni dać ci 20 minut na jego ukończenie, ale muszą zakończyć rozmowę w ciągu 5 minut z powodu pewnego wybuchu produkcji itp.) . Możliwe jest również, że innym kandydatom udało się tylko ukończyć test 10%, więc po ukończeniu 20% nadal będziesz wyprzedzać innych kandydatów.

  • Pisząc kod podczas rozmowy kwalifikacyjnej - nie zawracaj sobie głowy tym, aby był idealny w pierwszym przejściu. po prostu zaimplementuj „szczęśliwą ścieżkę, czyli pierwszy najczęściej występujący scenariusz”, a później zajmuj się obsługą błędów. jeśli kończy Ci się czas - po prostu dodaj krótką notatkę na dole opisu arkusza - co byś zrobił, aby poprawić kod, gdybyś miał więcej czasu.

[muszę uruchomić, zmodyfikuję / poprawię moją odpowiedź później]


1

Jak już wiele osób powiedziało, ćwiczę to jedna z najważniejszych rzeczy. Jeśli już zrobiłeś podobny problem, będziesz w stanie szybko znaleźć rozwiązanie.

Jeśli masz problemy z samodzielnym rozwiązywaniem problemów, skorzystaj z wyszukiwarki Google, aby znaleźć odpowiedzi na pytania dotyczące rozmowy kwalifikacyjnej w Twoim języku lub wybranym języku.

Możesz także odebrać książki przeznaczone do nauczania kursów CS niższego poziomu. Większość tych książek jest wypełniona niewielkimi zadaniami programistycznymi i można je szybko wykonać w domu. Można je wykorzystać do ćwiczeń.


0

Jestem też bardzo zły na testach i zawsze tak było. Przez całe życie nie mogłem zrozumieć, dlaczego dano mi lekcje programowania, żeby wziąć ołówek i papier. Nigdy nie byłem w tym dobry. Jednak to, co zrobiłem, wyjaśniło ankieterom, że miałem ten problem i wiedziałem o nim. Udało mi się również przeprowadzić wywiad z firmami, które nie dały mi głupich testów.

Moją sugestią jest poinformowanie firmy przed udaniem się na rozmowę, że nie zrobisz tego z takimi testami, jednak zamiast tego jesteś zadowolony z X. (Wymyśl alternatywę, która ma sens, a czujesz się komfortowo.) Dla siebie zaproponowałem, że wyślę im kod i pewnego razu zasugerowałem, że dadzą mi prosty program do pisania, a ja przyniosę go ze sobą wywiad za 3 dni.

W zależności od tego, gdzie szukasz pracy, może to dla ciebie działać lub nie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.