Альтернативное название: Как пройти собеседование в компании
Вы когда-нибудь были на собеседовании, и интервьюер смотрит через стол и спрашивает: «У вас есть вопросы?», А вы просто смотрите в ответ и говорите: «ммм, я так не думаю». Если это случилось с вами, велика вероятность, что вы довольно однобоко оценили опыт собеседования.
Понятно, что вы как кандидат сосредоточены на одном результате: получении предложения о работе. Но не забывайте, что собеседование не одностороннее. Вы должны быть сосредоточены на собеседовании с компанией так же, как и на собеседовании с вами.
Но что вы должны их спросить?
Многие ищущие работу разработчики задавали мне этот вопрос. За последние 15 лет я проработал в 7 компаниях (считая 2 стажировки и 6 месяцев в стартапе) и провел собеседование еще в десятке. Я наконец решил записать все вопросы, которые задаю во время этих интервью, в надежде, что другие сочтут их полезными.
Боковое примечание: мы освещаем эту и многие другие темы в нашем еженедельном подкасте с советами для разработчиков Soft Skills Engineering. Подписывайся!
Моя цель - сделать это живым документом. Если у вас есть предложения, дайте мне знать через Twitter, и я учту их, чтобы всем было полезно.
С кем ты будешь разговаривать?
На собеседовании обычно встречаются три человека. В зависимости от размера компании это может быть один человек или несколько:
- Инженеры-программисты
- Технические менеджеры (технический руководитель, менеджер среднего звена, директор)
- Руководство компании (вице-президент, технический директор, генеральный директор, руководитель отдела)
У меня есть разные вопросы по каждому из этих персонажей, которые я перечислю ниже. Обратите внимание, что я иногда повторяю один и тот же вопрос нескольким людям, чтобы сравнить их ответы.
Это довольно длинная статья, и она предназначена больше для справки, чем для чтения. Если бы я проходил сегодня собеседование, я бы взял это с собой и (осторожно) упомянул бы об этом во время собеседования.
На большинство этих вопросов нет «правильного» или «неправильного» ответа. Они разработаны, чтобы помочь вам узнать о компании, ее культуре, процессах и организации. Они также служат началом разговора, что может быть весьма полезно во время собеседования, когда ваш мозг отключился.
Из вежливости я обычно говорю интервьюерам в начале собеседования, что хотел бы иметь время, чтобы задать вопросы. Это поможет им соответствующим образом спланировать. Обычно они позволяют мне задавать вопросы в конце собеседования, поэтому внимательно относитесь к расписанию собеседований и сообщайте им о ваших намерениях на раннем этапе. После каждого вопроса делайте паузу, чтобы спросить, можно ли вам продолжать задавать вопросы и сколько времени есть у интервьюеров.
Вопросы для инженеров-программистов
1. Как узнать, над чем работать каждый день?
Цель этого вопроса - выявить дисфункцию. Я хочу получить ответы от 2 или 3 инженеров. Если руководство компании говорит, что следует определенному процессу, но инженеры не говорят о процессе, это признак дисфункции. Если вы получаете разные ответы от разных инженеров, это еще один признак дисфункции.
В высококлассной команде я получаю последовательные ответы на этот вопрос. Каждый разработчик знает этот процесс, и этот процесс достаточно легкий, чтобы поддерживать инженеров, а не угнетать их.
Пример хорошего ответа (есть много других): «Мы проводим N-недельные спринты, в которых каждый инженер обязуется предоставить набор функций и исправлений ошибок. Каждый день мы сообщаем друг другу о ходе выполнения наших обязательств. У нас есть замечательный менеджер по продукту, который взаимодействует с клиентами, чтобы помочь нам расставить приоритеты в функциях и исправлениях ».
Пример плохого ответа (их много): «Я захожу в офис и смотрю, какие огни горит. В большинстве случаев меня прерывают чрезвычайные ситуации ».
Заметьте, я не упоминаю «Скрам» или какую-либо другую конкретную методологию. Меня гораздо меньше интересуют ярлыки, которые компания использует для своего процесса разработки, чем реальное повседневное «как все делается».
2. Что вы используете для контроля версий?
Хороший инструментарий - верный показатель хорошей команды. Если команда использует старую систему контроля версий, она, вероятно, использует кучу других устаревших инструментов. Более того, они, вероятно, не ценят повышение эффективности, которое может быть достигнуто за счет инвестиций в хорошие инструменты.
Хороший дополнительный вопрос - спросить о рабочих процессах. Вы пользуетесь ветками? Вы предпочитаете перебазирование или слияние (условия git)? Эти вопросы расскажут вам, насколько они хороши в выбранных ими инструментах, что многое расскажет об их уровне мастерства, что, в свою очередь, подскажет, чего ожидать, если вы возьметесь на работу. Например, станете ли вы «местным экспертом по git» или будете учиться у настоящего Линуса Торвальдса?
Этот вопрос может начать обсуждение инструментов в целом, что часто даст вам хорошее представление.
3. Что вам нравится в работе здесь?
Убедительный ответ: я получаю большое удовлетворение от своей работы.
Убедительный ответ: Нам очень нравится работать.
Серьезный ответ: мне нравится работать с действительно умными, дружелюбными сотрудниками.
Твердый ответ: руководство уважает инженерное дело.
Чем больше хороших ответов, тем лучше. Мне не нужно получать все вышеперечисленные ответы, чтобы дать высокую оценку компании. Имейте в виду, что некоторые люди от природы не «сытные», поэтому вы можете не получить здесь звездных отзывов, и это может быть нормально.
Но если я слышу следующие типы ответов и очень немногие из списка надежных ответов, я начинаю нервничать:
Слабый ответ: оно оплачивает счета.
Слабый ответ: мне не нужно очень много работать.
Слабый ответ: не требуется большого давления.
Слабый ответ: это неважно, если я сделаю большие ошибки.
Слабый ответ: (молчание)
Не думайте, что я придумываю эти ответы. Я действительно слышал это в реальных интервью.
Я не считаю себя автоматически плохой компанией, если слышу эти слабые ответы, но если это единственные ответы, я обычно ищу в другом месте.
4. Вы пишете модульные тесты?
Будьте осторожны, делая выводы о команде инженеров на основе их практики модульного тестирования. Если команда воодушевляется, когда я спрашиваю о модульном тестировании, это, как правило, хороший знак. Хотя, с другой стороны, если они не могут объяснить, почему они проводят модульное тестирование, или недостатки модульного тестирования, это может указывать на догму слепой овцы. Если они приводят плохие оправдания тому, почему они не пишут тесты, особенно такие отговорки, как «у нас нет времени», это плохой знак для меня.
Если инженеры говорят мне, что они пишут модульные тесты, и они могут сообщить мне метрики о своих тестах, например, сколько времени им требуется на выполнение, сколько тестов у них есть, и их покрытие кода, это довольно привлекательно для меня. Это говорит мне о том, что у них есть хорошие инструменты, и они знают, как ими пользоваться. С другой стороны, если они считают, что 100% покрытие кода гарантирует отсутствие ошибок в кодовой базе, я с подозрением отношусь к ним.
Я хочу знать заранее, буду ли я работать над большой, старой, непроверенной кодовой базой в этой компании. Это поможет мне управлять собственными ожиданиями и решить, хочу ли я этим заниматься.
Последующие вопросы:
- Вы предпочитаете модульные или интеграционные тесты?
- Есть ли у вас приемочные испытания?
- Какие рамки тестирования вы используете? Вам нравится это?
- Как долго выполняются ваши модульные тесты?
5. Есть ли у вас постоянная интеграция?
Лучшие команды разработчиков программного обеспечения, которых я знаю, используют такие инструменты, как Jenkins, Travis и Buildbot. Если в команде нет постоянной интеграции, я пытаюсь оценить, знакомы ли они с концепцией. Если нет, то, по моему опыту, это плохой знак. Наличие системы непрерывной интеграции означает, что команда, вероятно, верит в автоматизацию, что обычно является очень хорошим знаком по моему опыту.
Для некоторых команд это естественным образом приводит к дискуссии о непрерывной доставке, которая является родственной, но отличной от непрерывной интеграции концепцией. Если это позиция веб-разработчика, я ожидаю, что команда хотя бы слышала о CD, и сильные команды, как правило, воплощают ее в жизнь, по крайней мере частично.
Последующие вопросы:
- Когда CI сообщает о сбое, сколько времени требуется вашей команде, чтобы исправить это?
- Что вам нравится / не нравится в вашей системе CI?
- Как долго длится ваш CI-запуск? Вы делаете их быстрее?
6. Что вы измеряете?
Это открытый вопрос, призванный выяснить, приложила ли команда усилия для измерения своего программного обеспечения. Для команд веб-разработки ответы, как правило, сосредоточены на показателях производительности, таких как время отклика сервера, пропускная способность запросов, количество пользователей, скорость отклика на стороне клиента и т. Д. Но обсуждение может идти на такие вещи, как количество пользователей, говорящих на разных языках, поломка браузера. , процент попаданий / промахов в кеш и множество других тем. Если команда не потратила время на измерения, это может быть признаком того, что они не используют реальные данные для обоснования своих решений. Они могут быть преждевременными оптимизаторами. Я ценю команду, которая использует реальные измеренные данные для принятия решений, особенно в отношении производительности, но это применимо и ко многим другим вещам.
Если интервьюер знает ответы на многие из этих вопросов, это хороший знак того, что команда высококлассная. Если они понятия не имеют, зачем им вообще нужны какие-либо из этих измерений, это может быть отрицательным показателем.
Опять же, здесь применяется правило о догмах. Если команда, кажется, ухватилась за показатель, который не обязательно дает ценную, полезную информацию, и они не могут объяснить это к вашему удовлетворению, это может быть предупреждающим знаком.
Последующие вопросы:
- Каковы ваши самые важные показатели продукта?
- Какие системы измерения вы используете? (например, MixPanel, statsd и т. д.)
7. Как находить и исправлять ошибки?
В сильной команде обычно есть опытные тестировщики, а разработчики команды уделяют особое внимание качеству. У действительно сильной команды впечатляющая автоматизация тестирования. Некоторые команды слишком малы для специализированных тестировщиков или автоматизации тестирования, но это не обязательно означает, что они плохие. Когда я задаю этот вопрос, я пытаюсь понять их процесс. Их волосы всегда горят? Есть ли у них разумный процесс поиска и определения приоритетов ошибок? Они полагаются на то, что пользователи находят ошибки?
Последующие вопросы:
- Как вы расставляете приоритеты среди ошибок?
- Какой трекер ошибок вы используете? (и что ты в этом ненавидишь)
- Вы используете Excel для отслеживания ошибок? (Нееет!)
- Сколько ошибок в вашем трекере?
- Сколько времени нужно на исправление ошибок (мин. / Макс. / Тип.)?
8. Какие инструменты совместной работы вы используете?
По моему опыту, хорошо функционирующие команды используют множество инструментов для совместной работы. Они часто используют сервисы чата (Slack, IRC, HipChat, Jabber), сервисы проверки кода (Gerrit, GitHub, GitLab, Review Board) и, конечно же, почтенный, но показывающий свой возраст Email. Я ищу индикаторы того, что каждый разработчик знает, что делают другие разработчики. Я не ищу безумных уровней детализации, а больше для общего понимания. Также мне нравится видеть интеграцию с инструментами для совместной работы. Самый простой пример - автоматическое электронное письмо, отправляемое каждый раз, когда происходит сбой автоматической сборки. Другим примером для команд веб-разработчиков являются службы автоматической регистрации ошибок, которые уведомляют чат-комнату команды о возникновении серьезных ошибок или о том, что ключевые показатели превышают определенный порог.
9. Какие фреймворки вы используете?
Мое личное предпочтение фреймворкам двоякое:
- Я люблю современные вещи.
- Мне нравятся новинки.
Так что, если команда создает настольное приложение AIX в Motif, мне это, вероятно, не интересно. Но, может быть, да. Это сугубо личная тема, и вы должны подходить к ней с твердым пониманием своих предпочтений.
Независимо от ваших предпочтений фреймворка, важно понимать, почему команда выбрала свою фреймворк (ы). Они движимы хайпом? Меняют ли они рамки, например, нижнее белье? Их кодовая база усеяна шрапнелью от ежемесячного оттока? Они застряли на древней версии?
Что касается темы почему, мне нравится понимать, насколько свободно разработчики выбирают технологии. Обязает ли руководство выбор технологии? Обращается ли руководство к разработчикам? Чтобы разобраться в этих вопросах, я обычно спрашиваю: «Как вы пришли к использованию фреймворка X в своем проекте?». Если разработчики не знают ответа, это может быть плохим знаком или может означать, что они достаточно новички для компании, и их не было рядом, чтобы принять решение.
Мне нравится видеть, как команды вносят свой вклад в проекты с открытым исходным кодом, которые они используют. Это говорит мне о том, что они не только могут использовать открытый исходный код, но и достаточно опытны, чтобы вносить свой вклад в его разработку. Мне нравится работать с такими разработчиками. Даже лучше, если компания готова заплатить им за это. Это говорит мне, что компания понимает, что значит быть гражданином открытого исходного кода.
Если команда изобретает колесо вместо того, чтобы использовать доступные инструменты, чтобы помочь им создать свой продукт, я нервничаю. Из этого правила есть исключения. Например, когда Facebook работал над своей собственной структурой, я бы не стал возражать им (или стал бы).
10. Когда мы сможем соединиться?
Если вы хотите получить действительно четкое представление о том, каково работать с этой командой, попробуйте поработать с ними. Я никогда не делал этого лично, но у меня есть друг, у которого есть (вероятная история, верно). Думаю, это фантастическая идея. Если вы хотите узнать почти что-нибудь о команде, поработайте с ними полдня. Это может потребовать от вас подписания NDA. Если команда даже захочет рассмотреть эту идею, я думаю, это очень хороший знак.
Вам, вероятно, придется договориться об этом с кем-нибудь из руководства, поэтому этот вопрос больше предназначен для того, чтобы получить реакцию разработчиков. Они могут быть настолько потрясены идеей, что не стоит обсуждать ее с руководством.
11. Когда у вас следующий дедлайн?
(предоставлено Эван Фаррер)
Этот вопрос призван рассказать вам больше о процессе разработки, которому на самом деле следует компания. Этот вопрос сам по себе не очень информативен, но когда вы добавляете эти вопросы, все становится намного интереснее:
- Кто установил этот срок?
- Вы уложились в последний срок? Если нет, то почему?
Высококвалифицированные команды согласовывают и соблюдают сроки вместе. Сроки, которые назначаются произвольно, могут быть признаком дисфункции или, по крайней мере, того, что инженеры не сидят за столом при определении расписания.
12. Сколько времени нужно, чтобы настроить новую среду разработки?
(Материал предоставлен Эван Фаррер)
Этот вопрос помогает оценить, сколько усилий компания приложила к опыту разработчиков. Требуются ли часы, дни или недели, чтобы новые разработчики настроили свой компьютер и были готовы начать кодирование? Это автоматизировано или вручную? Это покажет вам, насколько команда опытна в «вспомогательных действиях», которые не имеют прямого отношения к написанию программного обеспечения, но помогают его поддерживать. Команда воспринимает это серьезно?
Некоторые компании гордятся тем, что процесс настройки разработчика настолько быстр, что новые разработчики могут запускать код в производство в первый же день. Это показывает, что компания очень серьезно относится к обеспечению беспрепятственного взаимодействия с разработчиками.
Вопросы для инженеров-менеджеров
1. Когда вы в последний раз писали код?
Мне нравятся менеджеры с сильным техническим образованием. Не обижайтесь на моих друзей-MBA, но я обнаружил, что менеджеры, которые мне действительно нравятся, - это те, кто делал то, что делаю я.
2. Как ты стал менеджером?
Мне нравятся менеджеры, которые решили стать менеджерами, потому что им это действительно нравится и они умеют это делать, а не вынуждены делать это. Мне также нравится, когда кажется, что менеджеры сосредоточены на обслуживании своей команды. Мои любимые менеджеры - это те, кто сосредоточен на улучшении жизни своей команды, а не на «управлении». Они видят себя помощником и защитником своей команды. У них есть отношение к служению, и они считают своей самой важной работой улучшение жизни членов своей команды.
3. Откуда ваши инженеры знают, над чем работать каждый день?
Поскольку я задаю инженерам тот же вопрос, мне нравится сравнивать ответы менеджера, чтобы увидеть, совпадают ли они. Если они не совпадают, это может означать дисфункцию. Худший вид дисфункции - это нераспознанная дисфункция. Я считаю, что задача менеджера - выявлять подобное несоответствие и исправлять его.
4. Какая сейчас самая большая проблема для вашей команды?
Обычно они отвечают, что нехватка персонала. Поскольку это распространенный и очевидный ответ (в конце концов, они нанимают), я хотел бы спросить об их второй по значимости проблеме. Я ищу красные флажки, такие как срыв графика, проблемы с качеством продукции и межличностные конфликты. Вы узнаете красные флажки, когда увидите их. У каждой команды есть проблемы, поэтому ответы, которые вы получите, будут зависеть от нескольких факторов:
- Осведомленность менеджера о проблемах
- Готовность менеджера быть честным с вами
- Серьезность проблем в команде
5. Как вы измеряете индивидуальную производительность?
У опытного менеджера будет хорошая техника для этого. Лучшие менеджеры будут тщательно собирать отзывы от всей команды при оценке работы отдельного члена команды. Плохой менеджер сделает звонок на основе собственных наблюдений, не посоветовавшись с командой.
6. Проводите ли вы официальные проверки эффективности?
Мне нравится работать с менеджерами, которые ценят обратную связь и помогают членам своей команды совершенствоваться. Отзывы о производительности могут быть болезненными или положительными. Основываясь на моих собственных наблюдениях, я думаю, что большинство людей считает их болезненными. По-настоящему великий менеджер будет знать об этом и примет меры, чтобы сделать обзоры производительности отличными, так что вы будете впечатлены и захотите работать на них.
Последующие вопросы:
- Не могли бы вы рассказать мне о случае, когда вы помогли кому-то улучшить их работу?
- Как вы тренируете людей во время этих обзоров?
7. Делаете ли вы ежегодное повышение зарплаты?
Мне нравится знать, что моя компенсация будет скорректирована в соответствии с моим вкладом в компанию, и что мы будем рассматривать ее официально не реже одного раза в год. Для компаний, где это применимо, я люблю спрашивать о собственном капитале. Вы дадите мне опционы на акции? Будете ли вы предлагать мне больше опционов на акции каждый год?
Некоторым инженерам неудобно задавать подобные финансовые вопросы. Не будет. Инженеры обычно тратят очень небольшой процент своего времени на размышления об этих темах, но менеджеры ведут эти разговоры все время. Эти вопросы не должны вызывать неудобства у менеджера:
- Как вы планируете прибавку к зарплате?
- Каков средний рост в вашей команде в прошлом году (в процентах)?
- Какого увеличения зарплаты я могу ожидать через год? В лучшем случае, в худшем?
Я не задаю эти вопросы в качестве подписанного кровью контракта или гарантии повышения зарплаты в будущем. Вместо этого я хочу понять, как работает компания. Придется ли мне изо всех сил просить о повышении или уже существует стандартный процесс?
8. Могу ли я получить на руки материалы с описанием преимуществ компании?
(Предоставлено Эван Фаррер)
Я полагаю, что большинство людей уже знают, чтобы задать этот вопрос, но для полноты картины об этом стоит упомянуть. Большинство компаний готовы предоставить вам пачку бумаги или веб-сайт с описанием преимуществ компании. Это важно знать, потому что часто это довольно большая часть вашего вознаграждения. Это может применяться только в США. Я не уверен, как льготы по медицинскому страхованию, предоставляемые компаниями, работают в других странах.
9. Сопоставляете ли вы сотрудников друг с другом?
(Предоставлено Мэтт Райан)
Некоторые компании определяют надбавки и бонусы (я не выдумываю), ранжируя каждого сотрудника в большом отсортированном списке, от лучшего к худшему, а затем вынуждая определенный процент сотрудников относить к «хорошим», «средним» и «плохим». »Подсписки.
Я никогда не встречал инженера, которому это нравилось бы. Это особенно характерно для крупных компаний. Это может повлиять на то, как вы взаимодействуете со своими сверстниками, потому что вы знаете, что однажды вам придется соревноваться с ними за деньги.
Когда я сталкиваюсь с этим, это не может сразу означать, что компания - ужасное место для работы. В таких компаниях часто есть небольшие очаги крутизны, скрытые от радаров ». Спросите интервьюеров, нравится ли им система. Некоторые менеджеры будут довольно откровенно заявлять о своей неприязни к системе, а некоторые даже расскажут вам о стратегиях, которые они используют для «игры» с системой на благо своей команды. Если вы найдете такого менеджера, вы можете упустить из виду систему ранжирования.
Также имейте в виду, что не все ненавидят эту систему. То, что я не встречал кого-то, кому это нравится, не означает, что их не существует.
Последующие вопросы:
- Вы действительно думаете, что X% ваших сотрудников «плохие»? Что это говорит о вашем процессе найма? (это смелый вопрос - действуйте осторожно)
- Применяете ли вы какую-то кривую для определения лучших исполнителей?
- Какие показатели вы используете для ранжирования сотрудников?
- Откуда вы знаете, что эти показатели собираются точно?
- Откуда вы знаете, что эти показатели на самом деле определяют лучших исполнителей?
Для получения дополнительной информации вот хороший анализ этого от Мэтта Райана.
10. Вы проводите регулярные командные ретроспективы?
(Предоставлено Aric Parkinson)
Если да, то на что они похожи? Как часто вы получаете отзывы от членов вашей команды? Когда вы в последний раз что-то меняли в том, как вы управляете своей командой, на основе полученных отзывов?
Эти вопросы дадут вам представление о том, насколько отзывчивым вы можете ожидать от руководства, и о том, вносит ли команда много обратной связи для руководства.
Если ретроспективы не проводятся, команде сложно выявить проблемы, не говоря уже о том, чтобы переключать механизмы, чтобы исправить их. И если менеджер не чувствует, что он получает обратную связь о том, как команда могла бы стать лучше, то он, вероятно, либо не слышит о проблемах команды, либо создает атмосферу, в которой люди не чувствуют себя в безопасности, чтобы говорить с ними. проблемы.
Вопросы для лидерства
Мне не всегда удается поговорить с высшим руководством компании, особенно с крупными компаниями, но когда я это делаю, я использую это как возможность оценить финансовую жизнеспособность компании. Я не очень квалифицирован для этого, но есть некоторые очевидные проблемы, которые я иногда могу обнаружить во время собеседования. Кроме того, мне нравится знать, что такое культура сверху вниз, потому что эта информация может сказать мне, как компания оценивает своих инженеров, как положительно, так и отрицательно.
1. Как вы финансируетесь?
Я пытаюсь разобраться в деньгах, стоящих за компанией. Если они финансируются венчурным капиталом, частным капиталом, публичными акциями или самофинансируются за счет доходов, я хочу знать это. Часто я могу довольно легко понять это до собеседования, но руководство компании часто добавляет идеи, которые я не могу найти через Google или CrunchBase.
2. Вы прибыльны?
Если выгодно - отлично! Если это не прибыльно, каковы ваши планы, чтобы стать прибыльным? У некоторых стартапов есть план на этот счет, в то время как другие ищут выход через поглощение или IPO.
Последующие темы:
- Исторический доход за последние несколько кварталов / лет. Он идет вверх?
- Риски для прибыльности, такие как конкуренция, неожиданные расходы и неожиданная нехватка доходов.
- Взлетно-посадочная полоса: как долго компания сможет работать, прежде чем привлечет дополнительный капитал.
3. Что вы думаете об аутсорсинге?
Я хочу знать, будет ли работа, на которую я претендую, в будущем будет отдана на аутсорсинг, или же эта работа может превратиться в должность по управлению внештатными инженерами.
Я говорю не только об офшорном аутсорсинге. Сюда входят и подрядчики.
4. Расскажите мне о культуре компании.
Это еще один вопрос, который я использую, чтобы согласовать точку зрения инженеров и точку зрения руководства. Я ищу несоответствия как признак дисфункции. Если руководство и инженерия находятся на одной странице, это указывает на хорошее общение сверху вниз. Я хочу знать, не поддерживает ли высшее руководство связи с находящимися в окопе сотрудниками. Я также хочу увидеть, есть ли у руководства твердое видение, о котором хорошо известно. Мои любимые компании, в которых я работаю, имеют сильное общее видение.
Некоторые компании очень серьезно относятся к культуре, и это может быть хорошо. По крайней мере, вам будет ясно, что компания ценит. Для других компаний вам придется разбираться в неявных, иногда невысказанных нюансах. Культура может иметь очень большое значение. Есть ли политическая борьба? Ценится профессионализм? Ценится ли честность? Оценивается ли сверхурочная работа?
5. Какие у вас есть гарантии того, что эта компания будет успешной?
Этим вопросом я ищу реальные доказательства, а не просто маркетинговую шумиху. Если высшее руководство дает мне реальные цифры, такие как выручка, размер рынка и капитализация, это хороший знак. Кроме того, если я смогу проверить эту информацию из других источников, это еще лучший знак. С другой стороны, цифры могут указывать на что-то очень плохое, например, на взлетно-посадочную полосу на один месяц без финансирования на горизонте.
6. Расскажите мне о вашей структуре отчетности.
Для меня лучший ответ на этот вопрос - простой. Если человек может нарисовать простую организационную диаграмму, объясняющую структуру отчетности, я удовлетворен. Лично я предпочитаю работать в небольших, быстрых компаниях с минимальными организационными и коммуникационными накладными расходами. Ваши предпочтения могут отличаться, и это нормально. Независимо от ваших предпочтений, этот вопрос предназначен для того, чтобы предоставить вам информацию, необходимую для принятия обоснованного решения о компании.
Заключение
Интервью двунаправленные. Убедитесь, что вы извлекли из опыта все необходимое, чтобы принять осознанное решение, если вам посчастливилось получить предложение. Удачи!
