Сколько вопросов подходит для стажера? [закрыто]

Итак, я только что начал стажировку и беспокоюсь, что задаю слишком много вопросов. Мой наставник назначает мне проекты и помогает мне изучить все технологии и методологии компании. Тем не менее, есть так много нового материала для изучения во время этого проекта, что у меня много вопросов. Обычно я задаю вопросы по мгновенным сообщениям или по электронной почте (это основные способы общения для моей компании).

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

С уважением относитесь к времени своего наставника, ведя список вопросов и задавая их по мере возможности. На самом деле не перебивайте своего наставника до тех пор, пока вы буквально не сможете продвигаться вперед без помощи

Много раз вы многому научитесь, пытаясь найти ответ самостоятельно, даже в тех случаях, когда ваш наставник может научить вас чему-то за 10 секунд. Например, если вы хотите узнать, где что-то находится в коде, вы можете спросить их (10 секунд), или вы можете потратить четыре часа на изучение кода и попытки выяснить его самостоятельно. Преимущество «четырехчасового» варианта в том, что вы на самом деле изучите 200 новых вещей о коде, и все это поможет вам позже. Борьба за то, чтобы найти свои ответы, может быть пустой тратой времени, но она также может стать способом изучения большой сложной кодовой базы.

Само собой разумеется, если это вопрос программирования, который не касается собственного фирменного кода вашей компании, вы должны попытаться выяснить это самостоятельно с помощью Интернета.

Будучи старшим, который видел юниоров, задающих всевозможные вопросы, я бы сказал, что дело не в том, как часто вы спрашиваете, а в том, что вы спрашиваете .

Вы должны почувствовать это сами, но, как правило, правило таково: проявляйте интерес и умение мыслить и работать самостоятельно .

Можно задавать общие вопросы, чтобы установить контекст для подробного расследования низкого уровня, которое вы делаете сами.

Можно задавать вопросы обо всем, что не написано в коде и не задокументировано - процесс, командная культура и т. Д.

Что бы вы ни делали, покажите, что вы обдумали это и приложили усилия, чтобы понять или решить проблему самостоятельно.

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

Только не переступайте черту и не просите их написать для вас код, точно сказать, что делать каждый раз, объяснять синтаксис и копировать документацию и так далее.

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

Еще один момент для рассмотрения: можете ли вы использовать электронную почту или какую-то другую (или менее) навязчивую форму общения для некоторых своих вопросов? Затем ваш наставник может либо ответить по электронной почте, либо (что более вероятно) зайти к вам за столом, чтобы обсудить вопросы, когда у них появится возможность. Это также относится к совету по «группированию вопросов», который я уже дал, но лично мне легче иметь дело с одним вопросом на одно сообщение электронной почты, чем с длинным списком вопросов, которые практически не связаны друг с другом. вместе в одном сообщении. На одного часто можно ответить через минуту или две, другой может очень легко стать полчаса.

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

Я согласен, что это хорошая идея, чтобы подготовить пакет вопросов и попросить внимание наставника, чтобы обсудить их все за один раз. С другой стороны, также может быть очень неприятно (особенно для начинающих) пытаться выяснить, как все работает часами, когда простой вопрос и ответ буквально решат проблему за считанные секунды.

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

На связанной ноте поощрение и энтузиазм работают в обоих направлениях, от наставника к стажеру и от стажера к наставнику.

Вероятно, это ситуация, через которую мы все прошли. Быть новым парнем, будь то стажер или постоянный работник, сложно. Это всегда связано с проблемой холодного старта, поскольку вы находитесь на новом месте, с новыми людьми, новыми технологиями, новыми методологиями. Я полностью понимаю беспокойство о том, что не знаю что-то и хочу узнать это идеально, так что вы скоро станете продуктивным.

Иметь вопросы совершенно естественно. И вы можете быть уверены, что ваши коллеги знают, что у вас есть и будут вопросы. Они тоже были на вашем месте в какой-то момент, верно? И поверьте мне, они должны были получить помощь откуда-то.

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

Старайтесь, учитесь, будьте любопытны и задавайте вопросы. Помните, все были на вашем месте, и все в конечном итоге выжили :)

Я думаю, что вы столкнетесь с различными типами вопросов.

Для моего ответа я сосредоточусь на том, что я считаю ПОЧЕМУ вопросы. Эти типы вопросов помогут вам понять, почему вас просят сделать что-то определенным образом. (напр., почему мы используем стандарт кодирования X?)

Я думаю, что было бы хорошо, если бы вы попросили своего наставника отводить какое-то время каждую неделю для изучения подобных вопросов. Одной из идей было бы выделить от 1 до 2 перерывов на кофе в неделю. Установив время для вопросов такого типа, вы показываете своему наставнику, что цените его время и хотите узнать, почему что-то делается определенным образом.

Пока ваш наставник знает, что вы сначала пытались найти ответ и пытались найти ответ на вопрос.

Совет, когда задавать вопрос, может быть, когда ваш наставник идет к кофеварке, тогда вы знаете, что прерываете его «поток».

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

Например, если вы пишете код, вы можете написать комментарий «todo» в этой части и продолжить писать остальную часть кода. Вы можете вернуться, чтобы заполнить задачу позже.

Затем, всякий раз, когда я встречаюсь со своим руководителем, я сразу же выгружаю все вопросы. К тому времени на некоторые вопросы я уже ответил сам! Некоторые вопросы также кажутся глупыми после того, как они были записаны на некоторое время, поэтому вы не должны их задавать.

Еще одна вещь, которую вы обязательно должны сделать, это просто поговорить об этом со своим наставником. На самом деле это первое, что я сделал. Я просто прямо спросил: «Я задаю слишком много вопросов?» Это дало мне прямую обратную связь, и я мог перестать беспокоиться о том, расслаблюсь ли или решу проблему.

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

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

Я думаю, Кейси, это не вопрос допроса ... дело в том, что ты стажер ... ты должен задавать вопросы. И лично я чувствую, что ставить вопросы всегда есть своя выгода. Даже если вы не пользуетесь Google в этом случае, ваш наставник должен сказать вам, что вы должны изучить это самостоятельно. Помните, что не расстраивайтесь и не ошеломляйтесь новой рабочей средой с огромной кодовой базой. Это просто время, которое вы должны дать и должны подвергать сомнению практически все, что вы хотите.

счастливого допроса :) :)

Вы знаете, если вы вежливы и веселы, вы можете спросить, спросить, спросить.

Но не задавайте те вопросы, которые звучат как пораженческие или подразумевают, что вы можете быть неадекватными,