Что значит технические вопросы
Как правильно задавать технические вопросы?
Правильно заданные технические вопросы не только сокращают время ответа и поиска решения, но и способствуют самому факту ответа, а так же качеству решения. Да-да, вы не ослышались. И это касается не только бесплатных и общедоступных источников, таких как форумы. Это так же касается и служб поддержки коммерческих организаций. Разница между ними лишь в том, что последние обязаны предоставить хотя бы одно решение, даже если оно будет заключаться в полной переустановке «всего и вся».
Дело в том, что даже технические вопросы затрагивают различные аспекты психологии. Помните, вы общаетесь с людьми, а не ищите стандартным поиском фразу по документам. Грамотно составленный вопрос может привлечь внимание специалистов высокого уровня, а неграмотный наоборот оттолкнуть как можно дальше.
Попробуйте представить себе две ситуации.
Преамбула. Вы периодически просматриваете свои любимые форумы и иногда пытаетесь помочь с решением возникших проблем. Да и сами иногда задаете вопросы. Вы не профессионал, но и не новичок.
Ситуация первая. На форуме появился пост с названием «Возникла проблема! Срочно нужна помощь!». Вы заходите и читаете сообщение, из которого становится понятно, что проблема далеко не срочная, потому что есть обходной путь, пусть и требующий от пользователя кучи рутинных дел. Да и проблема возникла из-за банальной невнимательности пользователя, потому что пользователь даже не посчитал нужным прочесть небольшой абзац с предупреждением.
Однако, вы так же замечаете, что пользователь общается достаточно вежливо и при этом сознает свои ошибки, что само по себе говорит, что человек не просто задал вопрос, а приложил усилия к поиску решения. Из этого факта вы понимаете, что, скорее всего, ситуация произошла из-за возникшей спешки. И что срочность сообщения происходит из-за ограниченного количества времени.
Вы знаете два решения: долгое и рутинное, но не требующее от вас каких-либо усилий, и быстрое и эффективное, но требующее от вас поиска нужной утилиты среди вашей «свалке утилит в папке Разобрать».
Ситуация вторая. На форуме появился пост с названием «Ошибка в модуле X при выполнении операции Z. Что делать?». Вы заходите и читаете сообщение, в котором вся суть проблемы изложена достаточно понятно, хоть и текст составлен непривычными отрывками.
Тем не менее, как и в первой ситуации, вы так же знаете два ответа. Долгий и ничего не требующий. И быстрый, но требующий от вас усилий.
А теперь попробуйте честно ответить самим себе на простые вопросы. Будете ли вы отвечать на данные посты? Будете ли вы следить за темой? Если вы решитесь озвучить решение, то какое из двух? Решение вы озвучите полностью или же оставите некую определенность по типу «помнится где-то была какая-то утилита»?
Примечание: Конечно, в сообщении должно быть как грамотное корректное описание, так и правильная форма подачи. И суть описанных ситуаций не в том, что бы определить «что важнее», а в том, чтобы показать как увидят и воспримут заданные вопросы те люди, которые будут их читать.
Несколько шагов для получения качественного ответа на технических ресурсах
Соблюдая эти простые шаги, у вас будет гораздо больше шансов быстро получить качественное решение вашей проблемы.
Примечание: Конечно, эти шаги не являются панацеей. Если быть корректным, то это скорее набор самых базовых правил. И они ни в коей мере не смогут покрыть все аспекты. Но, даже этот список очень редко где соблюдаются. Плюс ко всему, постепенно используя эти шаги, вы найдете свои собственные, которые так же помогут вам быстро находить качественные решения и экономить время себе и другим людям.
Как проходить техническое собеседование?
Наши преподаватели поделились опытом прохождения технических интервью, в том числе с позиции работодателя. Раскрываем секреты, как себя проявить даже начинающему айтишнику, что делать, если не знаешь ответ на вопрос и многое другое.
Михаил Каморин
Senior Backend Developer в Skyeng, преподаватель курсов по PHP и его фреймворкам, Highload Architect.
Для middle и выше нет смысла заучивать формулировки и термины, важнее понимание.
Для джунов наоборот, понятно, что практического опыта ещё нет, и нужно хотя бы теоретически представлять себе происходящее.
Если не знаешь ответа, то стоит попытаться вывести его логически, но совсем пальцем в небо тыкать всё же не стоит, и лучше честно сказать, что не знаешь.
Если техспециалист на каждый правильный ответ задаёт вопрос всё сложнее, он не завалить хочет, а ищет «уровень незнания», и это нормально, если он его наконец находит. Другое дело, что потом это может быть использовано с целью сбить цену, но это уже не техспециалиста вопрос, его задача уровень оценить.
Вторичные навыки, смежные с компетенциями, необходимыми для вакансии, могут быть решающим фактором, но при условии прочих равных, а не сами по себе.
Чем выше позиция, тем важнее коммуникативные навыки, так как тем больше приходится общаться, обсуждать решения, планировать архитектуру и т.п.
Для джунов важнее всего иметь общее представление об используемом технологическом стеке (то есть большим плюсом является знание хотя бы в общих чертах о том, как устроен условный RabbitMQ) + решение алгоритмических задач. Также неплохо хотя бы формулировки из теории знать.
Для мидлов важно существование цельной картины. Очень часто приходят кандидаты, у которых SOLID отдельно, паттерны отдельно, например. Сразу видно, что на практике это либо вообще не применяется, либо применяется интуитивно, а теория подтянута за пару дней до собеседования.
То есть для мидлов полезно по последнему проекту посмотреть используемые паттерны, например, технологии и так далее.
Когда кандидат может привести практический пример использования какой-то теоретической вещи, это гораздо выигрышнее, чем знание формулировки.
Я часто спрашиваю вопросы типа «какой принцип в SOLID наименее нужный?» или «такой-то паттерн соответствует SOLID?» (у меня есть примеры на многие паттерны таких несоответствий). При этом если кандидат заранее такие вещи подготовит и расскажет в начальном вопросе про SOLID («что это такое?» или «когда стоит применять?»), это прямо жирный плюс
Ещё очень часто кандидаты сейчас пренебрегают знаниями по работе с БД. Везде ORM, наверное, половина кандидатов просто не знают, что там под капотом и как работает, так как никогда сырые запросы не делали. Стоит хотя бы в общих чертах посмотреть, что такое ACID, как реализуется. Как индексы и оптимизация запросов работает и т.п. Но это уже прямо конкретные вопросы под конкретную вакансию пошли.
Для middle+/senior важно ещё умение решать архитектурные вопросы. Знаю, что Яндексе есть даже специальная архитектурная секция интервью, прямо отдельный час.
Код на интервью сейчас редко спрашивают. Это довольно спорная затея, т.к. это стресс дополнительный + что-то серьёзное за время интервью покодить не получится.
Получается, что мы проверяем не то, что на самом деле нам нужно, и не в тех условиях, в которых это будет происходить на практике.
В алгоритмических задачах наоборот всегда говорю, что мне не нужен код, мне нужно описание алгоритма, его оценка, доказательство, что нельзя быстрее, например.
Сергей Голицын
Senior Software Engineer at Zillion Whales, преподаватель курса «Алгоритмы и структуры данных»
Смотрю на то, как кандидат думает, знает ли основы, прям основы. Мне хочется слушать, как рассуждает кандидат. Если, например, это алгоритмическая задачка, то хочу слышать рассуждения. Если это теория, то я могу задать вопрос близкий по теории и услышать, как кандидат будет выкручиваться и отвечать на него.
Все зависит от того, как кандидат отвечает. Если я вижу, что он отвечает по учебнику и говорит словами с известных всем сайтов, это явно говорит о том, что он готовился, и спрашивать его про это нет смысла. Лучше посмотреть, понимает ли он то, что говорит или просто заучил. Это может быть не прямой вопрос «Как работает хэш мапа?», а к примеру, как ее сломать или сломать особенным образом.
Я бы рекомендовал готовиться индивидуально к вакансии, т.к. у каждой компании свои требования к знаниям. И не пить много кофе перед интервью. Отдохнуть. Постараться расслабиться и получить удовольствие и вынести что-нибудь полезное с собеседования. Освежить знания.
Еще во время интервью смотрю, что у кандидата должны реально гореть глаза и он ооочень хочет попасть к нам. Так же у него должен быть реальный интерес к программированию, а не из-за денег. Это наверное для меня очень важный критерий при найме на любой уровень. Я ищу идейных ребят, для которых разработка — это хобби.
Действительно, очень многое зависит от компании и от должности, на которую претендует соискатель.
Если должность руководящая, как, например СТО, здесь многое, на мой взгляд, зависит от софт скиллов.
Главное на интервью — постараться быть самим собой и не пытаться прыгнуть выше головы, это заметно сразу же.
Ещё один совет: старайтесь не придумывать ответы на вопросы, на которые заранее не знаете ответ. Лучше пропустить вопрос. Конечно, сделать логический вывод — это плюс, но пытаться лукавить или гуглить параллельно выставит вас не в лучшем свете.
Олег А., team leader, преподаватель Java:
Процесс сильно зависит от компании. В крупных компаниях процесс выстроен четко: имеется анкета кандидата с большим количеством пунктов, и люди, которые проводят собеседование, туда вписывают свои оценки. Обычно оценивается так называемый «уровень сеньорити», который включает в себя: опыт, знание основ по основному стеку (язык программирования и встроенная библиотека) и знание проектирования софта (пресловутые шаблоны проектирования и SOLID встречаются практически везде), знание спец.инструментов, фреймворков и практик, умение работать в команде, лидерство и т.п.
Этап тех собеседования может быть и разделен: хард скилы отдельно, софт скилы отдельно, может быть совмещен, а может состоять из нескольких этапов — зависит от компании. В большинстве случаев нужно быть готовым писать код в режиме life-coding. Придется подтвердить свой опыт, ответив на связанные с ним вопросы. В итоге кандидат получает балл с оценкой уровня сеньорити. На ее основании формируется или нет оффер.
Сергей Терешин
технический pre-sale специалист по ИБ в ООО «Монт», преподаватель курса «Внедрение и работа в DevSecOps»
Я собеседовал обычно ИТ или ИБ специалистов. Обычно пытаюсь понять насколько человек в теме вопроса: от модели osi и маршрутизации до различных методик атак. Часто смотрю, как человек ведёт себя в ситуации неопределённости.
Из-за специфики направления я провожу тех. интервью в формате разговора. В информационной безопасности сложно спросить про код или написать что-то. В реальную сеть, естественно, доступ не дается. Я, как правило, прошу что-то нарисовать. Просто если ИТ\ИБ-шник как любой инженер в 3 фразе не сказал слово «схема» и не начал рисовать на бумаге, столе, в воздухе какие-то каракули, значит он сломался. Несите следующего 🙂
Игорь Звягин, старший frontend разработчик:
Я проходил собеседования в SberCloud, EPAM, Живосайт. Главное, правильно подать себя, навыки самопрезентации очень важны. Что я заметил, далеко не в каждой компании, даже в крупных, наседают на техническую часть. Можно честно сказать «я не знаю, я с этим не работал».
Что касается вопросов, в моей сфере обычно начинают с типов данных, как сравнивать объекты, как работает браузер, процессы как происходят, как работает React, просят написать простые функции.
И пожалуй, самое важное — нужно любить свою предметную область. Это значит, не только иметь достаточные знания, но и следить за развитием технологий, думать о перспективах. Вот это тоже стоит показать на собеседовании.
Всех желающих приглашаем на открытые demo-уроки:
1. «Архитектор онлайн-обучения перевернет твой взгляд на образование».
На вебинаре опишем позицию архитектора онлайн-обучения. Мечта и реальность: кто есть сейчас и почему возникает потребность в новых профессиях. Вы прикоснетесь к процессу зарождения новой профессии.
>> регистрация
2. «Цели обучения: как сделать так, чтобы обучение случилось?»
Первый шаг проектирования обучения — определение предполагаемых результатов у студентов. В педагогической теории существуют таксономии Блума, Марцано, Андерсен. Как их использовать? Сравним таксономии и выберем оттуда то, что помогает проектировать обучение. >> регистрация
Техническое собеседование: пять способов отпугнуть соискателя / пять способов взбесить интервьюера
Много боли изливается на страницы Сети по поводу неудачных собеседований. Кому-то не понравились вопросы интервьюеров, другого обидели насмешками, иных посудили по страничке вконтакте. Интервьюеры не отстают от соискателей и ругаются на то, как плохо нынче с кадрами, и какие глупые ответы дают неопытные программисты на их заковыристые технические вопросы.
К сожалению, универсальных правил прохождения и проведения собеседования нет и быть не может, потому что сотрудников подбирают не только по их техническим навыкам и личностным качествам, но и по совпадению с некоторым (зачастую неявным и очень субъективным) «профилем», который, по мнению интервьюеров, вписывается в их команду или компанию. Что же касается руководств из серии «как правильно проходить собеседования», то они обычно вызывают не меньше боли в комментариях, потому что очень субъективны и обязательно задевают чьи-нибудь болевые точки.
За свою профессиональную карьеру мне довелось побывать по обе стороны баррикад, хотя, пожалуй, проводить технические собеседования приходилось всё же немного больше, чем проходить их. Но за это время у меня накопилось некоторое количество «пунктиков», которые отпугивают меня во время технического интервью и сразу в моём сознании ставят крест на дальнейшей беседе. Об этом мне и хотелось рассказать — с позиций интервьюера и соискателя. Хочу сразу оговориться, что статья отражает мои личные субъективные впечатления и не претендует на «руководство по прохождению собеседований». С другой стороны, это не минутный всплеск ярости от неудавшегося интервью, а давно взвешенный набор тех критериев, которые, хотя и по негативному принципу, позволяют мне отсеять варианты, либо самому не отпугнуть потенциально подходящего соискателя.
А что на собеседованиях раздражает или напрягает вас? Поделитесь в комментариях.
Собеседование с позиции соискателя
Каждый раз при поиске работы программисту приходится проходить множество технических собеседований. Он ходит по офисам или разговаривает по скайпу, решает задачки или делает тестовые задания, отвечает на заковыристые технические вопросы, пытаясь продемонстрировать себя с лучшей стороны. Однако и сам он при этом оценивает людей, которые собеседуют и проверяют его, думая о том, что завтра ему потенциально с этими людьми придётся работать. И есть множество способов для технических интервьюеров отпугнуть соискателя от интересной должности. Я расскажу о том, что всегда отпугивало лично меня, и чего стараюсь не допустить я как интервьюер.
1. «Какое ещё техническое собеседование?»
Первое и главное, что всегда настораживало меня в техническом собеседовании — это его отсутствие. Бывает так, что вся беседа с техническими специалистами — потенциально будущими коллегами — строится на вопросах относительно профессионального опыта: где работал, какими проектами занимался, какую функцию в них выполнял. По технологиям или знаниям — вопросы уровня «какого цвета учебник». Знаете, что такое Message Broker? Отлично, мы вас берём!
Такой подход к проведению собеседования всегда резко настраивал меня против потенциального работодателя. Мне не задали ни одного вопроса, чтобы проверить, что я действительно знаю своё дело. Выглядит это так, будто собеседующие меня люди либо сами ничего не понимают в теме и ищут хоть одного человека, который понимает, либо просто отчаялись и готовы брать кого угодно. В любом случае, в коллективе, набранном подобным образом, мне едва ли захочется работать.
2. «Ну и чем вы там занимались в этом своём…»
Удивительно, как часто встречается пренебрежительное отношение к соискателям на технических собеседованиях. Да, возможно, вы суровый и опытный программист с кучей проектов за плечами, вас оторвали от чрезвычайно важной работы ради каких-то ненужных интервью с людьми, большая часть из которых, по вашему мнению, совершенно некомпетентна. Но не забывайте о том, что вы в этот момент представляете свою компанию и свою команду, и человек по вашему поведению обязательно составит оценку о климате в коллективе и о том, как к нему в этом коллективе будут относиться. Будьте вежливы и уважительны к соискателю, даже если вы с первых пяти минут поняли, что его и близко нельзя подпускать к вашему драгоценному коду.
3. «Что-то у вас имя/фамилия/отчество в резюме неправильно написано!»
Это совсем не технический, но, тем не менее, часто встречающийся косяк даже на технических интервью. У меня, к счастью, достаточно простое и распространённое имя, и таких проблем со мной не случалось. Однако я знаю, что существует удивительно много людей, которые свято уверены в том, что определённых имён и даже отчеств попросту не существует. Они будут вас убеждать, что правильно не «Данила», а «Даниил», или что имени «Алёна» нет, а есть только «Елена». Будут предлагать исправить и записать в своих документах «правильно». С такими грамотеями-доброхотами приходится часто иметь дело людям с редкими или необычными именами, и поверьте, это невероятно раздражает. Так вот, есть одно простое правило: нет таких имён, которых нет. Правильно писать так, как записано в паспорте. Проявите уважение к соискателю и не считайте его настолько глупым, что он не в состоянии переписать из паспорта в резюме собственное имя. Если даже подозреваете ошибку, это можно уточнить как-то более тактично.
4. «Сколько шариков для гольфа понадобится, чтобы помыть все круглые окна в школьном автобусе, уменьшенном до размеров пятицентовой монеты, во время эвакуации из Сан-Франциско, используя не более 3 взвешиваний?»
Ни одна статья про собеседования не будет полной без упоминания канализационных люков. Можете считать это моим персональным пунктиком, связанным с неумением быстро и под напряжением решать нестандартные задачи. Но я уверен, что брейн-тизеры на собеседованиях абсолютно бесполезны. Вернее, это отличный способ набрать полный отдел вундеркиндов с олимпиадой головного мозга, которые круглыми днями вместо работы будут перекидываться свеженькими брейн-тизерами. Реальный программист в естественной среде обитания, даже занимающийся очень крутыми и нестандартными задачами, всё равно редко кодит под напряжением, а большую часть дня сидит и в относительно спокойной обстановке неспешно думает над тем, как ему красиво распилить код по методам. «Мозговые мышцы» для решения хитрых задачек он не задействует в этом процессе ни разу.
5. «Неправильно. Дальше.»
Конечно, заниматься обучением приходящих на собеседование людей — это не задача интервьюера. Однако, если соискатель не смог ответить на вопрос, но всё же заинтересовался, то подсказать или хотя бы указать ему на правильное решение, прежде чем переходить к следующему вопросу — это вопрос профессиональной этики, демонстрация того, что здесь ему в случае чего помогут, научат, не бросят наедине с техническими проблемами. Скажите хотя бы пару слов, что ему погуглить, что почитать. Ведь интерес к правильному решению задачи — это само по себе положительное качество технического специалиста, и не стоит демотивировать такого человека пренебрежительным отношением к его ошибкам или неточностям.
Собеседование с позиции интервьюера
Каждый раз при открытии новой вакансии ведущему специалисту или начальнику отдела приходится проводить множество технических собеседований. На собеседования приходят люди с разным техническим опытом, уровнем подготовки, ожиданиями. Для проведения собеседований нужно продумывать план разговора, составлять список вопросов, а потом пытаться по ответам на эти вопросы понять, подходит человек на должность или нет. И вот иногда соискатели на собеседованиях говорят такие вещи, что становится сразу ясно — нет, ты с этим человеком работать вместе не сможешь. Вот некоторый набор ключевых фраз соискателей, которые настораживают лично меня.
1. «Какие-то у вас вопросы теоретические. Я не силён в теории, я закалён в практике! Давайте лучше тестовое!»
2. «Не ожидал здесь испанскую инквизицию! У вас прямо как на экзамене в институте. Обычно просто спрашивают, где работал, что делал»
Вы пришли на техническое собеседование. На техническом собеседовании вам будут задавать технические вопросы, чтобы проверить ваши технические навыки. Методику проверки и выбор вопросов оставьте на совести интервьюера — вопросы не всегда могут вам казаться адекватными, но интервьюер знает, какую именно информацию он хочет о вас получить, анализируя ваши ответы. Многие вопросы нужны не затем, чтобы проверить знания, а чтобы заставить вас порассуждать и посмотреть на ход ваших мыслей. Помните также, что не на все вопросы требуется идеально точный ответ, и если вы внятно ответите хотя бы на половину из того, о чём вас спросили, это уже произведёт хорошее впечатление.
3. «Мне и не нужно это знать, я специализируюсь на более высокоуровневых задачах!»
Не надо путать специализацию и незнание основ программирования. От разработчиков мобильных приложений я слышал подобные вещи про протоколы стека TCP/IP, от фронтэнд-программистов — в ответ на вопросы про алгоритмы сортировки и поиска. «Зачем мне это знать, всё есть в стандартной библиотеке, я работаю на более высоком уровне». В ответ на такие заявления я давно придумал пару небольших задачек с подло скрытой алгоритмикой — в надежде показать, что «наивное» решение, выданное от незнания алгоритмов, не выдерживает критики, и побудить хотя бы к самообразованию. Причём это не какие-то искусственно сконструированные задачи, а такие вещи, которые встречаются в разработке ежедневно. Любой код это алгоритм. Понимание основных алгоритмов и структур данных важно для любого программиста, а протоколы сети Интернет — это база, без знания которой невозможно грамотно написать хоть что-то, что выходит за пределы одного компьютера.
4. «А сами-то! / А покажите ваш код! / А вот я зашёл к вам на GitHub, а там такое. »
Меньше всего интервьюеру хочется взять человека на работу, а потом выслушивать от него критику своей кодобазы. Да, она, скорее всего, неидеальна. Да, технический долг есть везде и у всех. В любом коде найдётся что покритиковать. Но если вы действительно считаете себя настолько крутым, что видите очевидные проблемы в коде своих потенциальных работодателей — переведите это в конструктивный позитив: я знаю, как улучшить, у меня есть наработки на эту тему, я смогу принести вам пользу.
5. «Вы не правы!»
Всякое бывает, конечно, но мнение относительно неправоты интервьюера или сомнения в его компетентности лучше оставить при себе до окончания собеседования. Потом погуглите и разберётесь, кто из вас был прав. Техническое собеседование — это не место для дискуссий или самоутверждения, и вопросы здесь в первую очередь задают вам. Интервьюер не станет спрашивать о том, в чём сам не разбирается.
Как задавать технические вопросы: полное руководство
Перевод статьи «How to Ask Good Technical Questions – the Ultimate Guide».
Умение задавать технические вопросы так, чтобы почаще получать хорошие ответы, — важный навык, которым должен обладать каждый разработчик.
Бывает, вы бьетесь над какой-то ошибкой и не можете понять, почему ваша программа работает некорректно. Или, скажем, никак не можете разобраться в реализации какого-нибудь алгоритма.
В этих и многих других ситуациях вы, скорее всего, выйдете в Интернет и разместите вопрос на Stack Overflow, в каком-нибудь сообществе на Discord, в сабреддите, в группе Facebook или даже просто напишете сообщение с этим вопросом другу.
Следуя советам из этой статьи, вы научитесь так задавать вопросы, чтобы они были легкими для чтения и понимания. Это облегчит задачу каким-нибудь добрым людям, изъявившим желание помочь вам с вашими проблемами.
Предоставьте контекст
Первое, на что нужно обратить внимание, — это контекст. Он помогает людям лучше понять ваш вопрос. Благодаря предоставленному контексту люди узнают о конкретной ситуации, в которой проявилась ваша проблема, а также о деталях, от которых может зависеть ответ.
Разработчики — не ясновидящие, они не всегда могут угадать, какой язык программирования вы используете или с какой платформой у вас проблемы. И настройки вашей среды они тоже вряд ли угадают, просто прочитав несколько примеров кода.
Если вы хотите получить качественный ответ на свой вопрос, все эти детали имеют значение. Между тем, многие разработчики упорно игнорируют необходимость предоставить контекст.
Скажем, вы используете C++ 1999 и пытаетесь применить функцию, доступную только в C++ 2011. Если вы не напишете об этих подробностях, люди могут начать искать проблему совсем в других местах.
Пишите информативные заголовки
Обобщите свой вопрос в заголовке. На Stack Overflow, например, у каждого вопроса должен быть заголовок, отражающий основную мысль. Название должно быть относительно кратким изложением сути вопроса.
Конечно, не все детали могут поместиться в заголовок. Но нужно постараться добавить их достаточно, чтобы при беглом просмотре заголовков люди смогли определиться, способны ли они помочь вам с этой проблемой.
Это важно, потому что у людей обычно нет времени, чтобы открывать и вычитывать каждый вопрос (особенно, если в подробном изложении они занимают несколько страниц). Сжатый, информативный заголовок, предоставляющий достаточно информации для принятия решения, позволяет экономить время.
Например, можно написать: «Сложение float и int с использованием оператора + расценивается в C++ 11 как int», а не «Операторы C++ не работают». Первый вариант дает достаточно контекста о вашей проблеме.
Создайте минимальный воспроизводимый пример
Если ваш вопрос связан с кодом, всегда включайте минимальный воспроизводимый пример. Это может быть полный репозиторий GitHub, гист или даже всего пара строк кода.
Не нужно копировать весь проект или весь репозиторий, с которым работаете. Добавляйте только те части, которые понадобятся людям, захотевшим вам помочь.
Если указываете репозиторий целиком, обязательно напишите, где именно искать. Четко укажите, какие файлы затронуты, какие функции в этих файлах нарушены и т. д.
Пример должен быть полным, т. е. достаточным для объяснения проблемы. В нем должны быть все необходимые импорты, внешние модули и функции. В нем должно быть все, что нужно, чтобы другие люди могли понять этот код и обдумать его.
При этом добавленный код должен быть минимальным и не содержать ненужных фрагментов. Показывайте только тот код, который напрямую связан с вашей проблемой.
Пример также должен быть воспроизводимым. Если я не смогу воспроизвести проблему, с которой вы столкнулись, то и помочь вам не смогу. Контекст и здесь играет важную роль. Отсутствие достаточного контекста и примеров затрудняет поиск ответа на ваш вопрос.
Расскажите о любых ограничениях
Обязательно упомяните о существующих ограничениях. Без этого люди будут давать дельные советы, но для вас они будут неприменимы из-за определенных рамок, о которых вы знаете, а советчики — нет.
Допустим, вы не можете решить учебную задачу, в которой вам не разрешается использовать сложные структуры данных. Если вы об этом не напишете, люди могут предлагать решения, включающие и сложные структуры. В результате и вы не быстро получите подходящий ответ, и люди зря потратят время. А это огорчает добровольных помощников, из-за чего они могут полностью проигнорировать ваш вопрос.
Также стоит учесть, что иногда мы совершенно напрасно сами себе ставим какие-то ограничения. Поэтому полезно подробно объяснить, почему эти ограничения вообще существуют. Люди могут вас удивить!
Избегайте использования скриншотов кода
Если вы приложите к своему вопросу скриншоты кода, скорее всего, эти изображения сожмутся на сайте. Их станет трудно читать, а если кода много, — и вовсе невозможно.
Изображение низкого качества не позволяет разработчикам копировать ваш код, чтобы попробовать его самостоятельно. Чтобы вам помочь, людям придется набирать ваш код вручную.
Это отнимает много времени и, вероятно, оттолкнет желающих помочь вам.
Также имейте в виду, что изображения не так доступны, как текст. Возможно, тема вашей IDE будет недостаточно контрастной для качественного скриншота, и людям будет трудно читать код. Имейте в виду, что ваш вопрос должен быть максимально доступным как можно большему числу людей.
Если вам необходимо добавить примеры кода, текст — лучший способ сделать это. Текст позволит программам чтения с экрана фактически прочитать ваш вопрос вместо того, чтобы говорить что-то общее, например «изображение». Это также позволит другим разработчикам читать код, не выходя из собственной темы браузера (подумайте о темных и светлых темах Stack Overflow).
Есть много способов поделиться кодом. Для этого существуют специальные решения, такие как Codepen, JSBin, GitHub Gist, Codesandbox и Pastebin.
Вы также можете просто вставить код в вопрос в виде текста. На платформах вроде Stack Overflow и форумов freeCodeCamp такая опция поддерживается (у кода даже будет подсветка синтаксиса). Но некоторые онлайн-сообщества требуют применения особых решений для размещения кода, и вы должны следовать этим требованиям.
Расскажите, что вы уже пробовали
Составьте список того, что вы уже испробовали. Это поможет вам не показаться лентяем, который ничего не сделал сам. К тому же, возможно, ваша последняя попытка была в крошечном шаге от успеха. Если вы не напишете, что уже пробовали, людям придется начинать с самого начала.
Советчики, вероятно, будут предлагать способы решения, которые вы уже испытали. Это будет расстраивать не только вас, но и их, ведь это пустая трата времени.
Образцы данных должны быть небольшими
Часто для тестирования кода, который мы пытаемся запустить, нам нужны образцы данных. Это может быть ответ объекта JSON с сотнями ключей от какого-то сервера или SQL- таблица с десятками или даже сотнями столбцов.
В этом случае следует ограничить объем информации, которую вы предоставляете в качестве выборочных данных. Зачем включать десять столбцов, если проблема связана только с одним из них? Со слишком большим количеством информации будет сложно работать.
Постарайтесь ограничить объем вашего кода. Предоставьте упрощенный объект JSON с ограниченным количеством ключей или таблицу SQL только с теми столбцами, которые касаются вашей проблемы. Это облегчит отладку, да и людям будет понятнее, с чего начать.
Код должен быть отформатированным и документированным
Никто не захочет читать код, сбитый в одну строку, с непоследовательными отступами, несогласованными именами переменных или плохим стилем в целом. По возможности придерживайтесь популярных соглашений.
Имена переменных и функций должны указывать на то, для чего они нужны. Люди хотят понимать, что делает функция, просто прочитав ее имя. Они не хотят расшифровывать код перед его прочтением.
Если дать описательные имена совершенно невозможно, убедитесь, что у вас есть хорошая документация. Задокументируйте, что делают функции, для чего предназначены переменные и как вы собираетесь их использовать.
Попробуйте также использовать линтер. Линтеры — это инструменты, которые проверяют ваш код и дают подсказки о возможных улучшениях логики, нарушениях стиля и соглашений, а также в целом помогают с читабельностью кода.
В общем, нужно, чтобы ваш код выглядел не так:
Это очень помогает при чтении кода и отладке. Форматировать свой код нужно вообще всегда, независимо от того, публикуете вы его в Интернете или работаете над ним в одиночку. Поверьте, это полезно.
Для форматирования кода есть много инструментов, но в веб-разработке наиболее популярны Prettier и ESLint. Они поддерживают несколько языков и работают с несколькими редакторами, такими как Atom, Vim, VSCode, Visual Studio и другими.
Почти все IDE поставляются со встроенным инструментом форматирования и линтером. Поэтому, прежде чем обращаться к сторонним инструментам, присмотритесь к своей IDE.
Проверьте правописание
Иногда вопросы сложно расшифровать из-за слишком большого количества грамматических ошибок. Это затрудняет чтение и ограничивает количество людей, желающих вам помочь.
Такие платформы, как Stack Overflow, дают редакторам возможность улучшать вопросы, но вы не должны полагаться на это. На других платформах нет такой поддержки, поэтому обычно рекомендуется проверять грамматику ваших вопросов до и после их публикации.
Инструменты вроде Grammarly автоматически сканируют ваш текст и дают советы по улучшению грамматики или даже исправляют чисто грамматические ошибки. У Grammarly есть расширения для Firefox, Chrome, Safari и Edge. Попробуйте.
Отслеживайте судьбу своего вопроса
Одна из самых неприятных вещей для людей, отвечающих на вопросы в Интернете, — это отсутствие обратной связи.
Если вы задали вопрос и получили ответ, не улетучивайтесь моментально. Дайте людям, пытавшимся вам помочь, обратную связь. Расскажите им, что сработало, что не сработало и почему.
Часто вы можете остаться с частичным решением, но без обратной связи вы никогда не доберетесь до полного.
Иногда вас попросят предоставить дополнительную информацию. Возможно, вы забыли некоторые из наших советов или не предоставили достаточно подробностей. Приветствуйте фидбэк с улыбкой и отвечайте.
И помните: людям не платят за эти услуги. Они жертвуют своим временем и усилиями, чтобы помочь вам, поэтому цените это и работайте с ними, чтобы предоставить им как можно больше информации. В конце концов, это окупится.
Добавьте резюме
В целом, старайтесь, чтобы ваши вопросы были короткими. Чтение длинных вопросов занимает много времени, и из-за этого их часто игнорируют. Я не буду читать три страницы вопроса, заранее не зная, смогу ли вообще чем-то помочь.
Если ваш вопрос очень длинный, то помимо информативного заголовка добавьте еще и резюме в начале текста. Краткая версия вопроса даст людям возможность определиться, стоит ли читать вопрос целиком, смогут ли они помочь.
Все мы люди
Полученные ответы не всегда будут благожелательными и приветливыми. У людей есть своя жизнь, полная проблем. Если вы будете слишком давить на собеседников, они могут начать игнорировать вас или вообще удалят свои ответы. Уважайте частную жизнь людей и не загоняйте их в угол.