Ile pytań należy zadać jako stażysta? [Zamknięte]

Właśnie rozpocząłem staż i martwię się, że zadaję zbyt wiele pytań. Mój mentor zleca mi projekty i pomaga mi nauczyć się wszystkich technologii i metodologii firmy. Jednak jest tak wiele nowych materiałów do nauczenia się podczas realizacji tego projektu, że mam wiele pytań. Zasadniczo zadaję pytania za pośrednictwem wiadomości błyskawicznych lub wiadomości e-mail (są to podstawowe sposoby komunikacji dla mojej firmy).

Staram się uważać, aby nie zadawać zbyt wielu pytań: nie chcę wyglądać tak denerwująco, jak i głupio. Ile pytań należy zadać? Raz na godzinę? Więcej? Mniej? Pamiętaj, że mój mentor jest również programistą, który ma własne obowiązki.

Szanuj czas swojego mentora, przechowując listę pytań i zadając je partiami, w miarę możliwości. Nie przeszkadzaj mentorowi, dopóki dosłownie nie będziesz mógł zrobić postępu bez pomocy.

Wiele razy wiele się nauczysz, starając się znaleźć odpowiedź samemu, nawet w przypadkach, gdy twój mentor może cię czegoś nauczyć w 10 sekund. Na przykład, jeśli chcesz wiedzieć, gdzie coś jest w kodzie, możesz zapytać go (10 sekund) lub możesz spędzić cztery godziny studiując kod i próbując go samemu rozwiązać. Zaletą opcji „cztery godziny” jest to, że nauczysz się 200 nowych rzeczy na temat kodu, z których wszystkie pomogą ci później. Walka ze znalezieniem własnych odpowiedzi może być stratą czasu, ale może też być sposobem na poznanie dużej, skomplikowanej bazy kodu.

Nie trzeba dodawać, że jeśli jest to kwestia programistyczna, która nie dotyczy własnego kodu firmy, powinieneś spróbować rozwiązać to samodzielnie, korzystając z Internetu.

Jako senior, który widział juniorzy zadających wszelkiego rodzaju pytania, powiedziałbym, że nie jest to kwestia tego, jak często o to pytasz, ale o co pytasz .

Musisz to poczuć sam, ale ogólnie zasada jest taka: okaż swoje zainteresowanie i umiejętność samodzielnego myślenia i pracy .

Zadawanie ogólnych pytań w celu ustalenia kontekstu szczegółowego dochodzenia niskiego poziomu, które wykonujesz samodzielnie, jest w porządku .

Można zadawać pytania na temat wszystkiego, co nie jest kodem i nie jest udokumentowane - proces, kultura zespołu itp.

Cokolwiek robisz, pokaż, że przemyślałeś to i sam starałeś się zrozumieć lub rozwiązać problem.

Nie bój się jednak pytać! Możesz go użyć, aby wykazać zainteresowanie i głębsze myślenie , a także zaoszczędzić zespołowi bólu , nie przestrzegając ich praktyk lub podejmując niewłaściwe decyzje, które będą wymagały czasu, aby rozplątać się później.

Po prostu nie przekraczaj linii i poproś o kod dla siebie, za każdym razem powiedz dokładnie, co robić, wyjaśnij składnię i skopiuj dokumentację itd.

Myślę, że wiele odpowiedzi udzielonych do tej pory ma rację: nie bój się zadawać pytań (w końcu po to są staże), ale wyjaśnij, że sam próbowałeś znaleźć odpowiedź przed zapytaniem . Dla mnie wcale nie przeszkadzają pytania, ale mam na myśli pytania, w których jasne jest, że pytający pyta tylko dlatego, że wygodniej jest mu przeszkadzać komuś innemu. Jeśli próbujesz, możesz zadać proste pytanie, o ile nie zdarza się to zbyt często, ale nie jest w porządku nawet nie próbować samemu. Nawet w przypadku prostych pytań przygotuj zarówno uproszczoną skrzynkę, jak i krwawe szczegóły. Pomyśl SSCCE -Short, Self Contained, Correct/Compilable Example. Miałem kogoś, kto zatrzymał się i zaczął pytać o dynamiczny SQL, kiedy prawdziwe pytanie dotyczyło wydobywania danych z kodu wykonywanego przez SQL EXEC. To całkiem duża różnica.

Kolejna kwestia do rozważenia: czy w przypadku niektórych pytań możesz użyć wiadomości e-mail lub innej, mniej lub bardziej ingerującej formy komunikacji? Następnie twój mentor może albo odpowiedzieć e-mailem, albo (bardziej prawdopodobne) przyjść do twojego biurka, aby przedyskutować różne rzeczy, kiedy tylko będzie to możliwe. Jest to również zgodne z już udzieloną poradą dotyczącą „zadawania pytań”, ale osobiście łatwiej mi jest poradzić sobie z jednym pytaniem na wiadomość e-mail, niż z długą listą pytań, które nie mają ze sobą nic wspólnego lub mają wiele wspólnego razem w jedną wiadomość. Na jedną można często odpowiedzieć w ciągu minuty lub dwóch, w drugiej bardzo łatwo można zmienić się w pół godziny.

Nie martwiłbym się zbytnio zadawaniem (zbyt wielu) pytań. Dobry mentor poinformuje cię w przyjazny sposób, kiedy nadejdzie czas, aby przestać pytać i zacząć ćwiczyć. W końcu mentor został przydzielony do mentorowania ciebie, a zadanie to zazwyczaj wiąże się z budżetem czasowym.

Zgadzam się, że dobrym pomysłem jest przygotowanie partii pytań i zwrócenie się do mentora o omówienie ich wszystkich za jednym razem. Z drugiej strony, może być również bardzo frustrujące (szczególnie dla początkujących), aby dowiedzieć się, jak to działa przez wiele godzin, gdy proste pytanie i odpowiedź dosłownie rozwiązałoby problem w ciągu kilku sekund.

Spróbuj uczyć się z doświadczenia i rozwinąć umiejętność „czytania” swojego mentora, aby dowiedzieć się, kiedy jest dobra okazja i jak należy komunikować chęć uwagi. Rozwój oprogramowania dotyczy zarówno interakcji z ludźmi, jak i wpatrywania się w kod źródłowy.

W powiązanej nucie zachęta i entuzjazm działają na dwa sposoby, od mentora do stażysty i od stażysty do mentora.

Jest to prawdopodobnie sytuacja, przez którą wszyscy przeszliśmy. Bycie nowym facetem, bez względu na to, czy jest to stażysta czy zwykły pracownik, jest trudne. Zawsze wiąże się to z problemem zimnego startu, ponieważ jesteś w nowym miejscu, z nowymi ludźmi, nowymi technologiami, nowymi metodologiami. Całkowicie rozumiem niepokój, że nie wiem czegoś i chcę go doskonale poznać, abyś wkrótce stał się produktywny.

Zadawanie pytań jest całkowicie naturalne. I możesz być pewien, że twoi koledzy wiedzą, że to robisz i będą mieli pytania. W pewnym momencie też byli na twojej pozycji, prawda? I wierzcie mi, MUSI skądś uzyskać pomoc.

Problem polega na tym, że nie wszyscy są dostępni przez cały czas, aby odpowiedzieć na dowolne pytania. Moją zwykłą sztuczką podczas przeglądania kodu lub dokumentów jest prowadzenie notatek o rzeczach, które nie są od razu jasne, i organizowanie kilku krótkich spotkań dziennie, aby omówić je z moimi seniorami. Przed zadaniem pytań zawsze dobrym pomysłem jest przeprowadzenie drobnych „badań” na ten temat, próba uzyskania jak największej liczby informacji i wskazówek. Strony takie jak StackOverflow są złote. Możesz nawet uzyskać dokładną odpowiedź, której szukasz. Twoi koledzy docenią wysiłek i chętniej Ci pomogą.

Staraj się, ucz się, bądź ciekawy i zadawaj pytania. Pamiętaj, że wszyscy byli na twojej pozycji i wszyscy w końcu przeżyli :)

Myślę, że napotkasz różne rodzaje pytań.

W odpowiedzi skupię się na tym, co uważam DLACZEGO pytania. Tego rodzaju pytania pomagają zrozumieć, dlaczego poproszono Cię o zrobienie czegoś w określony sposób. (np. Dlaczego używamy standardu kodowania X?)

Myślę, że dobrze by było, gdybyś poprosił swojego mentora, aby przeznaczył trochę czasu w każdym tygodniu na zadawanie tego rodzaju pytań. Jednym z pomysłów byłoby zarezerwowanie od 1 do 2 przerw kawowych tygodniowo. Ustalając czas na tego rodzaju pytania, pokazujesz swojemu mentorowi, że cenisz jego czas i że chcesz dowiedzieć się, dlaczego coś zostało zrobione w określony sposób.

Tak długo, jak mentor wie, że próbowałeś najpierw znaleźć odpowiedź i próbowałeś znaleźć odpowiedź na pytanie.

Wskazówka, kiedy zadać pytanie, może być, gdy twój mentor pójdzie do ekspresu do kawy, wtedy wiesz, że przeszkadzasz w jego „przepływie”.

Jestem w tej chwili dokładnie w twojej sytuacji. Mój przełożony jest dość zajęty i zauważyłem, że moje przerwy nie są mile widziane dość wcześnie. W moim przypadku jednak nie znałem wielu używanych technologii. Więc za każdym razem, gdy mam pytanie, zapisuję je. Jeśli potrzebuję odpowiedzi, aby kontynuować swoje zadanie, robię coś innego na jakiś czas. Przeczytałem dokumentację dotyczącą innej technologii, o której wiem, że wkrótce ją wykorzystam. Jeśli pytanie nie jest niezbędne do wykonania zadania, nad którym muszę pracować, i nie mogę kontynuować bez odpowiedzi, ustawiam je w kolejce.

Jeśli na przykład piszesz kod, możesz napisać komentarz „todo” w tej części i kontynuować pisanie reszty kodu. Możesz wrócić, aby wypełnić todo później.

Następnie, ilekroć spotykam się z moim przełożonym, rozładowuję wszystkie pytania na raz. Do tego czasu na niektóre pytania, na które sam już odpowiedziałem! Niektóre pytania wydają się również głupie po ich zapisaniu na jakiś czas, więc nie zadawaj ich.

Inną rzeczą, którą zdecydowanie powinieneś zrobić, to po prostu porozmawiać o tym ze swoim mentorem. W rzeczywistości to pierwsza rzecz, którą zrobiłem. Po prostu od razu zapytałem: „Zadaję zbyt wiele pytań?” Dało mi to bezpośrednią informację zwrotną i mogłem przestać się martwić, czy mogę się zrelaksować lub rozwiązać problem.

Uwaga: powyższe informacje dotyczą wyłącznie pytań niezwiązanych z kwestiami technicznymi lub programistycznymi. Sporo czasu spędzam w Google / Stack Overflow, szukając odpowiedzi technicznych i ty też powinieneś. W rzeczywistości, jeśli nie przeglądasz codziennie nowych informacji, prawie powiedziałbym, że nie uczysz się wystarczająco :)

1. Nie martw się o zbyt wiele pytań. Nie ważne, że nie wiesz, ale umiejętność studiowania spraw.
2. Pomyśl i Google, zanim zapytasz.
3. Ponieważ komunikujesz się za pomocą wiadomości błyskawicznych i poczty e-mail, postaraj się upewnić, że Twój mentor dobrze rozumie twoje pytania.
4. Po rozwiązaniu problemu konieczne są notatki. Po prostu nie pamiętamy wszystkiego, czego się szczegółowo uczymy.

Myślę, że Casey to nie jest kwestia przesłuchania. Chodzi o to, że jesteś stażystą. Powinieneś zadawać pytania. I osobiście uważam, że kwestionowanie rzeczy zawsze ma swoje zalety. Nawet jeśli nie korzystasz z Google w takim przypadku, twój mentor powinien powiedzieć ci, że musisz przestudiować to samodzielnie. Warto pamiętać, że nie denerwuj się ani nie przytłaczaj nowym środowiskiem pracy z ogromną bazą kodu. To tylko czas, który musisz dać i powinieneś zakwestionować prawie wszystko, czego chcesz.

miłego przesłuchania :) :)

Wiesz, jeśli jesteś uprzejmy i wesoły, możesz poprosić, spytaj.

Ale nie zadawaj pytań, które brzmią defetystycznie lub sugerują, że możesz być bezbożny,