Mogę powiedzieć, że takie podejście byłoby bardzo odważne, a mówiąc odważnym, mam na myśli to w tym sensie, że bieganie do lasu, aby walczyć z niedźwiedziem bez broni i ochrony, byłoby odważne i przyniosłoby podobne rezultaty. / p>

Gdybyś poszedł na rozmowę kwalifikacyjną na stanowisko szefa kuchni, nie chciałbyś wejść do drzwi i powiedzieć im, że wszystko jest nie tak z ich menu, co w rzeczywistości byś robił. Byłoby lepiej, gdybyś mógł wskazać błędy w pracy KONKURENCJI.

To pokazuje, że możesz wykryć błędy, nie mówiąc nic złego o swoim przyszłym pracodawcy. Jeśli MUSISZ porozmawiać o ich wersji beta, wskaż, co zrobili dobrze i jak WIESZ, że zrobili to dobrze. Jeśli jesteś zmuszony do jakichkolwiek negatywów, zacznij w pozytywny sposób.

Cóż, zauważyłem, że gra jest bardzo płynna, a sztuczna inteligencja działa bardzo dobrze. Gdybym musiał wybrać coś do zmiany, mógłbym albo wybrać inny kolor dla nazw, albo kazać im zmienić kolor, jeśli przenoszą się do obszaru, w którym kolory pasują.

Zwróć uwagę, jak Nie powiedziałem, że to zły wybór, ale coś, co można by poprawić i JAK? Takie podejście chcesz zastosować podczas rozmowy kwalifikacyjnej.

Jeśli aplikujesz na rolę typu QA, wskazanie błędów w wersji beta ma duże znaczenie. Natychmiast demonstrujesz swoje wyczucie szczegółów i możesz pokazać swój styl zgłaszania błędów. Możesz pochwalić się tym, co uważasz za błędy w grze, ale przedstaw swoje uzasadnienia.

Jeśli jednak ubiegasz się o stanowisko programisty, zwolnij. Deweloperzy zawsze mają wyjątkowe błędy, do których jeszcze nie mieli dostępu. Jeśli zdarzy ci się nękać ankietera jednym z ich własnych wybitnych błędów (i robisz to bez wrażliwości), może to sprawić, że cię nienawidzą i możesz pożegnać się z pracą. Można przywołać błąd ankieterowi, którego to jest błąd, ale pamiętaj tylko, aby postępować lekko. Nie jest dobrze powiedzieć rozmówcy, że wykonał złą robotę, nawet jeśli przez przypadek.

EDYTUJ - Dodajemy więcej porad ....

Twórcy gier uwielbiają to robić, dodawanie pisanek i uroku do swojej gry. Na przykład w najnowszej grze Animal Crossing pirania ma domyślny cykl pływania wokół swojego zbiornika w akwarium. Jeśli jednak podejdziesz do szklanki, to trochę cię chrupi. Nie ma to żadnego znaczenia dla rozgrywki, ale można powiedzieć ludziom, którzy w to włożyli, zrobili to z miłością. Przejrzyj wersję demonstracyjną i spróbuj znaleźć takie rzeczy, które naprawdę lubisz w wersji demonstracyjnej, i przywołaj je zamiast błędów. Wciąż wykazuje inicjatywę i zainteresowanie produktem, ale bardziej prawdopodobne jest, że uzyskasz silną pozytywną reakcję ankietera, gdy będziesz omawiać rzeczy, które lubisz, zamiast rzeczy, które uważasz za złe.

Załóżmy, że wiedzą już o wszystkich znalezionych błędach.

Ich aplikacja jest w wersji beta. Mają testerów QA. Wiedzą o błędach i prawdopodobnie więcej, których nie znalazłeś. Nie powinni wykorzystywać rozmów z kandydatami do testowania własnej aplikacji i jest bardzo prawdopodobne, że tak nie jest.

Jeśli więc zdecydujesz się na zgłoszenie błędu, zrób to, mając to na uwadze. Pamiętaj, że mówisz im to, co już wiedzą, a oni zdecydowanie lepiej znają swoją aplikację niż Ty. Mówienie im staje się demonstracją własnej zdolności do dostrzegania szczegółów i możesz to zrobić, wskazując również dziury w innych aplikacjach, niezwiązanych z ich. Nie sugeruję zgłaszania błędów, chyba że o to poproszą.

Jeśli chcesz im powiedzieć o znalezionych błędach, skorzystaj z sugerowanego przez nich systemu rejestrowania błędów (zwykle w przypadku wersji beta, opublikują porady, co zrobić, jeśli znajdziesz błąd. Postępuj zgodnie z tym).

Pracowałem w grach wideo przez kilka lat. Pamiętam, jak dostałem pierwszą kompilację, grałem w nią i od razu rozmawiałem z moim kierownikiem technicznym o niektórych rzeczach, które postrzegałem jako błędy. To nie była rozmowa wstępna; to był pierwszy tydzień mojej pracy. Mój trop był całkowicie otwarty na rozmowę, ale nie wszystko zostało zaakceptowane jako prawdziwy błąd.

Powiedziałbym, że 10 oddzielnych pozycji to zdecydowanie za dużo; nie spodziewaj się, że na wszystkich z nich wyjdziesz. Co najwyżej miej gotowe do omówienia 3 takie punkty.

Ale co ważniejsze, skup się na umiejętnościach, jakich oczekuje od Ciebie dana praca. Wykrywanie i zgłaszanie błędów może być tam głównym zajęciem lub nie. (Tam, gdzie byłem, był dedykowany dział Q / A, który przejął większą rolę w tej sprawie). Podstawowe umiejętności, które będziesz musiał wnieść do stołu jako inżynier, to umiejętność naprawiania błędów i opracowywania nowych funkcji. Jeśli masz przykłady kodu, który opracowałeś lub nad którym pracowałeś, lub pytania dotyczące kodowania zadane przez ankieterów, te będą o wiele ważniejsze.

Zapraszam do posiadania 3 takich elementów, aby ewentualnie okazać swoją uwagę i zainteresowanie w produkcie. Możesz spojrzeć, czy pojawi się to w wywiadzie półnaturalnie. Ale nie wymuszaj tego i skup się na bardziej priorytetowych kwestiach, takich jak umiejętności programistyczne.

Jeśli chcesz dostać pracę, powinieneś skupić się na tym, aby druga osoba czuła się świetnie, zatrudniając cię, więc samodzielne wychowywanie błędów jest stąpaniem po bardzo cienkim lodzie.

Jeśli zostaniesz zapytany, jak zestaw umiejętności pomóż temu zespołowi / grze / firmie, wtedy możesz o tym wspomnieć; ale nie nazywaj tego błędem lub oczywistym błędem projektowym. Przywołaj swoją zdolność do wykańczania rzeczy, które są obecnie w wersji alfa / beta i możliwość polerowania.

Powiedz na przykład:

Spostrzegłem kilka obszarów, w których polerowanie przydałoby się, np. „wstaw X tutaj”. Jeśli przywołasz czarne nazwy, przyznaj, że jest to drugorzędne.

Prawdopodobnie zostało to już zauważone i ma niski priorytet. Ponieważ nie ma to znaczenia dla podstawowej rozgrywki, prawdopodobnie zostanie to zrobione pod koniec projektu.

Najważniejszą rzeczą, którą powinieneś przekazać, jest to, że wierzysz w tę grę i możesz pomóc ją ulepszyć. Zaangażowanie to dobra rzecz u pracowników. Krytyczne myślenie to podstawowa umiejętność programisty. Wielu menedżerów nie jest programistami, więc bardzo skorzystasz na przekazywaniu swojej krytyki w bardziej pozytywny sposób.

Bardzo ważne jest również, aby dowiedzieć się, że niedokończone produkty to dokładnie to: Niedokończone. Nie krytykujesz ich za drobne szczegóły. Te drobne szczegóły zostaną (miejmy nadzieję) wyjaśnione.

Myślę, że to dobry pomysł. To zdecydowanie niekonwencjonalne podejście. Osobiście czekałbym, aż opisze firmę i jej obecny produkt.

Więc gdyby rozmowa wyglądała tak:

.... Osoba przeprowadzająca wywiad (I): „Czy zrobiłeś jakieś badania dotyczące naszej firmy lub tego, co robimy? ”

Ty:„ Tak, zauważyłem, że masz obecnie grę o nazwie X dostępną na Y. Pobrałem ją i wypróbowałem. ”

I: „O tak, co myślisz o tym produkcie?”

Ty: „Jest bardzo dobrze i mi się podoba. Jednak zauważyłem kilka błędów, szczególnie w obszar X, Y i Z. Gdybym był programistą, spróbowałbym zajrzeć do A, B, C i spróbowałby zrobić D, E i F. "

To mogłoby się udać. Myślę, że patrzą na Ciebie z punktu widzenia programisty / testera, a nie konsumenta pozostawiającego recenzję produktu. Ponieważ jesteś programistą, myślę, że znajomość błędów i tego, czym mogą być, jest dobrym podejściem. Jeśli jest to oprogramowanie typu open source, być może nawet wprowadzenie kodu może być dobrym bonusem.

Teraz tylko powiedzieć, że „naprawiłem część zepsutą” to zły pomysł. Jakiś czas temu przypominam sobie historię nastolatka, który był zainteresowany pracą w Apple. Więc to, co zrobił, zostało włamane do serwera i albo coś ściągnął, albo coś zmienił. Apple wcale nie był tym rozbawiony i wpadł w duże kłopoty, ale biorąc pod uwagę jego wiek, dostał przepustkę.

Poza tym jest historia hydraulika bez pracy. Najwyraźniej jego ulica miała jakiś problem i wziął się na siebie, aby go naprawić. Właściwie rozerwał rurę z gazem ziemnym i został natychmiast zabity.

Teraz, w pionierskich czasach lat 80. i 90., kiedy wszystko było zupełnie nowe, wiele razy firmy zatrudniały hakerów lub osoby, które zepsuły ich produkty. Nie szukają kogoś, kto się trochę zmienił, ale raczej ludzi, którzy dobrze rozumieli podstawowy exploit i jak go używać. Nie sądzę, że takie podejście jest już dobre. Nie wydaje mi się, żeby ludzie w tamtych czasach chcieli zostać zatrudnieni w ten sposób, ale po prostu byli ciekawi lub nie zdawali sobie sprawy, że ich czyny wyrządzą tak wiele szkód.

Więc w sumie myślę, że „Naprawiłem zepsuty produkt” jest podejściem uczciwym, ale ryzykownym. Jest to ryzykowne, ponieważ próbujesz im zaimponować, naprawiając coś zepsutego i może to do pewnego stopnia spowodować zamieszanie, a nawet złość, w zależności od tego, jak to naprawisz. Najlepiej jest po prostu powiedzieć, że go pobrałeś i dać trochę informacji, a nie próbować go naprawić, robiąc coś złego, na przykład inżynierię wsteczną lub włamywanie się do ich rzeczy.

Większość pozostałych odpowiedzi jest zdecydowanie zbyt negatywna. To świetny pomysł, ale trzeba to zrobić właściwie. Łatwo byłoby się zorientować, że „jesteście bandą bozo i mógłbym wykonać lepszą robotę”, chcecie okazać empatię i zainteresowanie .

Więc mówisz coś w stylu „Pobrałem wersję demonstracyjną XYZ, jest super. Naprawdę podobało mi się jej używanie, szczególnie ABC. Doceniam to, że to wczesne dni i prawdopodobnie macie je w swoim systemie śledzenia błędów, ale zauważyłem (problem a) i (wydanie b). ” Najlepiej, aby nie były to rażąco oczywiste błędy lub problemy graficzne (często ostatnia rzecz do rozwiązania), ale coś, co pokazuje, że przetestowanie tego wszystkiego zajęło Ci trochę czasu i zainteresowania.

W większości zgadzam się ze wszystkimi innymi opiniami, że chcesz zostawić pozytywne odczucia z wywiadu, więc krytykowanie jest w najlepszym przypadku ryzykowne. Dodatkowo ankieter prawdopodobnie nie jest nawet odpowiednią osobą do dzielenia się takimi rzeczami, więc nie zadziałaby nawet, gdyby był na to otwarty.

ALE alternatywą, którą widzę, jest to, że jeśli w tej chwili proszą o opinię społeczności - co robią niektóre, ale nie wszystkie gry przedpremierowe ¹ - aby przesłać to, co zebrałeś, a podczas wywiadu spróbuj znaleźć miejsce, w którym od niechcenia Cię wspomnę zrobił to. W najlepszym przypadku ładna sytuacja przedstawia się i pozostawia dobre wrażenie, w najgorszym przypadku nie wspominasz o tym lub po prostu ich to nie obchodzi.

^{1 Powód mogą nie być w ogóle zainteresowani, ponieważ mają już zaległości w znanych problemach i zaczną zbierać opinie dopiero po osiągnięciu etapu RC.}

Najbliżej wspomnienia o problemach w wywiadzie jest podkreślenie, że grałeś w tę grę na tyle, aby przemyśleć ich decyzje projektowe. Może stamtąd mógłbyś lekko stąpać po rzeczach, które chciałbyś być inny. Te uwagi należy starannie opakować w pozytywną energię. Chcesz zakomunikować, że byłbyś podekscytowany, gdybyś dowiedział się od programistów, dlaczego coś zrobili, a nie, że czujesz się kwalifikowany do tego, by je odgadnąć.

Przywoływanie bezpośrednich błędów w wywiadzie to korporacyjne samobójstwo. Strzelaj, wychwytuj błędy, nawet dla starszych pracowników. Za każdym razem, gdy pracujesz z innymi ludźmi i poruszasz problem, powinieneś wziąć pod uwagę, że a) osoba, z którą rozmawiasz, już wie, b) próbowała znaleźć środki, aby rozwiązać problem, oraz c) oni ' ponownie wkurzony na kogoś, że tam jest problem. Jestem uważany za bardzo prostego strzelca i widziałem, jak ludzie oszaleli ze złości, kiedy skonfrontowałem ich z tym, co okazało się dobrze znanym problemem w ich oprogramowaniu. Nauczenie się, jak podchodzić do tych rozmów, to poważna umiejętność kariery.