Скільки питань доцільно задати інтерну? [зачинено]

Отже, я тільки почав стажування, і я переживаю, що мені задають занадто багато питань. Мій наставник призначає мені проекти та допомагає мені вивчити всі технології та методології компанії. Однак мені так багато нового матеріалу, який я повинен вивчити, роблячи цей проект, що у мене виникає багато питань. Як правило, я задаю питання в режимі миттєвих повідомлень або електронної пошти (це основні способи комунікації для моєї компанії).

Я намагаюся бути обережним, щоб не задавати занадто багато питань: я не хочу виходити як роздратований або німий. Скільки питань доцільно задати? Раз на годину? Більше? Менше? Майте на увазі, мій наставник - це також колега-програміст, який має свої обов'язки.

Будьте з повагою до часу свого наставника, зберігаючи список питань і задаючи їх партіями, наскільки це можливо. Насправді не перебивайте свого наставника, поки ви буквально не зможете досягти прогресу вперед без допомоги.

Багато разів ви багато навчитесь, намагаючись знайти відповідь самостійно, навіть у випадках, коли ваш наставник може навчити вас чомусь за 10 секунд. Наприклад, якщо ви хочете дізнатися, де щось знаходиться в коді, ви можете запитати їх (10 секунд), або ви можете витратити чотири години на вивчення коду і намагаючись зрозуміти це самостійно. Перевага параметра "чотири години" полягає в тому, що ви насправді дізнаєтесь 200 нових речей про код, і все це допоможе вам згодом. Намагатися знайти власні відповіді може бути марною витратою часу, але це також може бути способом дізнатися велику складну базу коду.

Потрібно говорити, що це питання щодо програмування, яке не стосується власного власного коду вашої компанії, вам слід спробувати розібратися самостійно за допомогою Інтернету.

Як старший, який бачив юніорів, які задають усілякі запитання, я б сказав, що справа не в тому, як часто ви запитуєте, а в тому, що ви запитуєте .

Вам потрібно це відчути самостійно, але загалом правило таке: проявіть свій інтерес та вміння самостійно мислити та працювати .

Добре задавати загальні питання, щоб встановити контекст для низькорівневих детальних розслідувань, які ви робите самі.

Добре задавати питання про все, що не є кодом і не задокументоване - процес, культура команди тощо.

Що б ви не робили, покажіть, що ви подумали над цим і доклали зусиль, щоб зрозуміти чи вирішити проблему самостійно.

Не бійтеся запитати, хоча! Ви можете використовувати його, щоб проявити інтерес і глибше мислити , а також пощадити команду деякого болю , не дотримуючись їхньої практики або не приймаючи невідповідних рішень, які потребують часу, щоб пізніше розлучитись.

Просто не переступайте рядок і не вимагайте, щоб вони кодували для вас, підказували, що робити щоразу, пояснюйте синтаксис та копіюйте документацію тощо.

Я думаю, що багато відповідей, що даються досі, є правильними: це не бійтеся ставити запитання (адже саме для цього потрібні стажування), але дайте зрозуміти, що ви намагалися знайти відповідь, перш ніж запитувати . Я , наприклад, не заперечую питання на всіх, але я розуму питання , де ясно , що людина , що задає запитує тільки тому , що це більш зручно для них , щоб перервати кого - то іншого. Добре підійти до простого питання, якщо ви намагалися, доки це не трапляється занадто часто, але це не добре навіть не спробувати спочатку для себе. І навіть із простими запитаннями, будьте готові як спрощений випадок, так і деталі горілого. Подумайте, SSCCE -Short, Self Contained, Correct/Compilable Example. У мене хтось зупинився і почав розпитувати про динамічний SQL, коли справжнє питання стосувався вилучення даних з коду, виконаного через SQL EXEC. Це досить велика різниця.

Ще один момент, який слід врахувати: чи можна використовувати електронну пошту чи іншу не (або менш) нав'язливу форму спілкування для деяких своїх питань? Тоді ваш наставник може або відповісти електронною поштою, або (скоріше) зайти за ваш стіл, щоб обговорити речі, коли вони отримають можливість. Це також стосується вже наданих порад щодо "збору запитань", але мені особисто легше вирішувати одне запитання на повідомлення електронної пошти, ніж довгий перелік питань, які мають мало або нічого спільного між собою. разом в одне повідомлення. На одного часто можна відповісти через хвилину-дві, інший може дуже легко стати півгодинним часовим зворотом.

Я б не переймався над тим, щоб задати (занадто багато) питань. Хороший наставник привітно підкаже вам, коли настав час перестати просити і почати займатися. Зрештою, наставник був призначений наставництвом для вас, і це завдання зазвичай поставляється з бюджетом часу.

Я погоджуюсь, що це гарна ідея підготувати групу запитань і попросити наставника уваги обговорити їх усі за один раз. З іншого боку, також може бути дуже неприємно (особливо для початківців) спробувати зрозуміти, як працює робота годинами, коли просте запитання та відповідь буквально вирішать питання протягом декількох секунд.

Постарайтеся навчитися досвіду та розвивайте навичку «читати» свого наставника, щоб з’ясувати, коли є хороша можливість і як ви повинні донести своє бажання уваги. Розробка програмного забезпечення - це стільки ж, як взаємодія з людьми, так і з приводу того, як дивитися на вихідний код.

У відповідній ноті заохочення та ентузіазм працюють обома способами - від наставника до стажу та від інтерна до наставника.

Це, мабуть, ситуація, через яку ми всі пережили. Бути новим хлопцем, будь то стажист чи штатний працівник, хитро. Це завжди пов'язане з проблемою «холодного старту», ​​оскільки ви знаходитесь на новому місці, з новими людьми, новими технологіями, новими методологіями. Я цілком розумію тривогу того, що чогось не знаю, і хочу довідатися це прекрасно, щоб ви незабаром стали продуктивними.

Поставити запитання цілком природно. І ви можете бути впевнені, що ваші колеги знають, що ви робите, і у вас будуть питання. Вони теж були у вашому становищі в якийсь момент, правда? І повірте, вони МАЄМО десь отримати допомогу.

Складна частина полягає в тому, що далеко не всі є доступними постійно, щоб відповісти на будь-яке з питань, які у вас можуть виникнути. Моя звичайна хитрість, переглядаючи код або документи, - це записувати речі, які не відразу зрозумілі, і організовувати кілька коротких зустрічей на день, щоб обговорити їх зі своїми старшими. Перш ніж задавати питання, завжди корисно зробити невелике «дослідження» щодо цього, постарайтеся отримати якомога більше інформації та підказки. Такі місця як StackOverflow - це золото. Ви навіть можете отримати точну відповідь, яку шукаєте. Ваші колеги оцінять ваші зусилля та з радістю допоможуть вам.

Намагайтеся наполегливо, навчайтеся наполегливо, будьте цікаві та задавайте питання. Пам'ятайте, всі були у вашому становищі, і всі врешті-решт вижили :)

Я думаю, ти зіткнешся з різними типами питань.

Для своєї відповіді я зупинюсь на тому, що вважаю ЧОМУ питаннями. Ці типи питань допомагають зрозуміти, чому вас просять зробити щось певним чином. (наприклад, чому ми використовуємо стандарт кодування X?)

Я думаю, було б добре, щоб ви попросили свого наставника щодня виділяти якийсь час, щоб переглядати подібні питання. Однією з ідей було б виділити 1 - 2 кава-перерви на тиждень. Маючи встановлений час для таких типів запитань, ви показуєте своєму наставнику, що ви цінуєте їх час і що хочете дізнатися, чому щось робиться певним чином.

Поки ви наставник знаєте, що ви спробували спочатку знайти відповідь і намагалися знайти відповідь на питання.

Порада, коли задавати питання, може бути, коли ваш наставник йде до кавоварки, тоді ви знаєте, що ви перебиваєте його "потік".

Я майже зараз у вашій точній ситуації. Мій керівник досить зайнятий, і я переконався, що мої перерви не дуже вітаються. У моєму випадку, я не знав багато використовуваних технологій. Отже, що я зробив, це щоразу, коли у мене виникає запитання, я його записую. Якщо мені потрібна відповідь, щоб продовжувати своє завдання, я деякий час роблю щось інше. Я прочитав деяку документацію для якоїсь іншої технології, яку знаю, що скоріше використаю. Якщо питання не є вирішальним для виконання завдання, над яким я повинен працювати, і я не можу продовжити без відповіді, я ставлю його в чергу.

Якщо це код, який ви пишете, наприклад, ви можете написати коментар "todo" у цій частині і продовжити писати решту коду. Ви можете повернутися, щоб заповнити тодо пізніше.

Потім, коли я зустрічаюся зі своїм керівником, я вивантажую всі питання одразу. До того часу деякі питання, на які я вже відповів сам! Деякі запитання також здаються німими після того, як їх записують на деякий час, тому ви їх не задаєте.

Ще одна річ, яку ви обов'язково повинні зробити, - це просто поговорити зі своїм наставником про це. Насправді це перше, що я зробив. Я просто прямо запитав "Чи я задаю занадто багато питань?" Це дало мені прямі відгуки, і я міг перестати турбуватися про те, якщо і розслабитись, чи вирішити проблему.

Примітка: вищезазначене дійсно стосується лише питань, які не стосуються технічних чи програмових програм. Я довго проводжу в Google / Stack Overflow, шукаючи технічні відповіді, і вам теж слід. Насправді, якщо ви не гуглите новою інформацією щодня, я майже сказав би, що ви недостатньо навчаєтесь :)

1. Не хвилюйтеся про те, що просите занадто багато. Неважливо, що ви не знаєте що-небудь, але вміння вивчати питання.
2. Подумайте і Google, перш ніж запитати.
3. Оскільки ви спілкуєтесь через чат та електронну пошту, спробуйте переконатися, що ваш наставник добре розуміє ваші запитання.
4. Після вирішення проблеми нотатки необхідні. Ми просто не можемо згадати все, що ми дізнаємось докладно.

Я думаю, що Кейсі не в тому, щоб допитуватись. Все в тому, що ви стажер. Ви, мабуть, задаєте питання. І особисто я відчуваю, що ставити під сумнів речі завжди має свою користь. Навіть якщо ви не є Google у цьому випадку, ваш наставник повинен сказати вам, що вам потрібно вивчити це самостійно. Слід пам’ятати, що не засмучуйтесь або не переймайте нове робоче середовище з величезною базою коду. Це просто час, який вам потрібно дати, і ви повинні дуже багато допитувати все, що ви хочете.

щасливий допит :) :)

Ви знаєте, якщо ви ввічливі і веселі, ви можете запитати, запитайте.

Але не задавайте тих питань, які звучать дефектистично або мають на увазі, що вони можуть бути недидактичними,