Почему 'тупых вопросов не бывает', но тебя всё равно посылают в гугл

Доводилось ли вам сталкиваться с фразами:
"Тупых вопросов не бывает"
"Задавай мне любые вопросы"

Но почему-то, когда обращаешься к таким людям — в лучшем случае тебя отправляют в гугл.

👋Почему так?

Чаще всего дело не в том, что люди злые.
Проблема обычно кроется в формулировках.

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

Со временем я пришел к следующим пунктам, которые хочу закрыть, когда что-то спрашиваю:
- Минимизировать количество уточняющих вопросов
- Показать что уже пытался разобраться
- Если информации нет - накидывал где я её собрал


📝 Общая структура следующая:

1. Приветствие + контекст
Ссылка на задачу, вспомогательные ссылки, логи — всё, что не заставит искать "а о чем вообще речь, где искать?"

2. Что я уже проверил и сделал
Показать, что попытался разобраться сам.

3. Что я наблюдаю
Скриншот (полный экран, а не обрезок) или запись экрана с шагами воспроизведения.

4. Ожидаемое vs реальное
Что должно быть vs что получилось.

💡 Лайфхак:
Перед тем, как писать вопрос - отойди на пять минут от задачи.

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


Пример из практики:

❌ Плохой вопрос (мой первый день работы):

"А что такое deadlock?"

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

Глядя на эту ситауцию сейчас я мог бы сделать следующее:
* Действительно погуглить
* Озвучить что нашел это, но не очень понятно почему это случилось (я сделал select * на базу)
* Уточнить насколько это норма в текущий момент времени и ситуации

✅ Улучшенный вопрос:

Привет

Я сделал запрос в базу database.test select * from user

Но у меня вылезла ошибка: ERROR: deadlock detected

Погуглив я увидел что это как-то связано с блокировкой таблиц. И не понял - это что-то сделал не так, или тут есть какая-то проблема с базой?

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

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

---

Если вообще тяжело\страшно спрашивать (особенно когда только пришел в фирму) задать вопрос в нейронку.

🤖 Воспользуйся этим промптом:

Я хочу спросить у коллеги: [вставь свой вопрос].

Помоги переформулировать вопрос так, чтобы коллега мог ответить сразу, без уточнений.

Проверь по чеклисту:
1. Какой контекст нужно добавить? (ссылки, номера задач, что уже проверил)
2. Что я наблюдаю vs что ожидаю увидеть если это необходимо?
3. Какую я хочу решить проблему?
4. Какую информацию я хочу получить?

Переформулируй мой вопрос по структуре:
- Контекст (что делал, где, зачем)
- Что уже проверил
- Что наблюдаю (с примерами кода/логов)
- Конкретный вопрос

Также подскажи:
- Что ещё стоит проверить самому перед тем, как задать вопрос?
- Какую информацию я возможно упускаю?

После этого собери недостающую информацию, и задай улучшенный вопрос.

Чем больше дашь контекста - тем проще добиться нужного ответа.

---

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


📣
Также мы обсуждали вопрос с коллегой (Миша, привет), он раскрыл вопрос с иной стороны.

💭
А какие у вас есть лайфхаки для формулировки вопросов?
С какими проблемами сталкивались?

Победил метод "сразу в бой" (50%)

Делюсь первым ресурсом overthewire, где можно попробовать его на практике

Начальная точка - уровень Bandit - серия мини-задач на отработку навыков linux-консоли

Формат простой - подключаешься по ssh к машине, ищешь пароль для перехода на следующий уровень, и так двигаешься дальше.
Здесь есть небольшие подсказки о том, какие из команд могут помочь в поиске пароля.
В отличие от sadservers, о котором писал раннее - этот ресурс совсем для новичков.
Но есть и продвинутые разделы с уклоном в пентест.

📕 Личный опыт
Сам его проходил несколько лет назад, и запомнилась история с файлами, у которых был нетипичный формат или пробелы.
Впоследствии мне это пригодилось на собеседовании, где тоже было похожее задание. За счет этого решил задачу быстро, потому что уже сталкивался с подобным.
Сервис хорошо развивает "чуйку" что где можно искать проблему, и какими наборами команд в моменте можешь воспользоваться.

🤹🏻‍♀️Что получишь:
* Понимание работы с нетипичными ситуациями (файлы с пробелами, скрытые символы, форматы файлов)
* Паттерны работы с основными командами linux
* Базовые навыки для админов, траблшутинга, и прохождения тестовых собеседований

—

⚡️Почему метод "сразу в бой" работает:
Здесь не ведут за руку, а скорее направляют чем можно воспользоваться.
У тебя есть цель - варианты решений перебираешь и ищешь сам.
Как в играх-песочницах - дается задача, инструменты, и зажигается азарт найти лучший способ.


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

—

Кому подойдет:
Начинающим системным администраторам, devops-инженерам, и тем, кто хочет попробовать тему пентеста

Рекомендую попробовать пройти первые 5 уровней.
Кто попробует - напишите в комментариях что понравилось, а что показалось сложным