Q. Other insights from the studies you’ve already done?
A. On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.
Instead, what works well are structured behavioral interviews, where you have a consistent rubric for how you assess people, rather than having each interviewer just make stuff up.
Источник не лишен аналитики, в отличие от статьи на хабре просто утверждающей, что головоломки бесполезны и "позволяют чувствовать интервьюверу себя умнее".
DOO>P.S. А вот это отличное задание для менеджера продукта, между прочим: DOO>
DOO>Объясните что такое База Данных в трёх предложениях, так как это сделал бы ваш 8-летний племянник
DOO>Сам недавно пытался сформулировать буквально в трех предложениях простым языком (так как для высокого начальства), что за систему мы предлагаем создать, почему без нее плохо, а с ней хорошо и т.п.
+1
Там еще была задачка для разработчика ПО про "deadbeef", тоже не лишенная смысла. По ней можно анализировать как кандидат думает. В то же время важно правильно её задать.
Здравствуйте, Pzz, Вы писали:
Pzz>Мы сейчас спорим о терминах.
Pzz>Я называю процессом фактически используемые в организации нормы и практики, использующиеся для решения тех или иных проблем.
Неясна твоя позиция. Вот даём слово Листеру и Демарко
"Допустим, что у вас имеется абсолютно совершен-
ный процесс разработки программного обеспечения.
Устранит ли это всю неопределенность в нашем про-
екте? По сути, речь о том, является ли процесс раз-
работки программного обеспечения хотя бы одним
из главных источников неопределенности? "
Вопрос понятен ?
И далее Листер и Демарко дают наиболее важные факторы риска
1. Требования к системе, особенно взаимодействие системы с другими системами, людьми и тд.
2. Приоритеты
3. Среда, окружение
4. Сторонние зависимости — например, вендоры библиотек
5а. Контингет(фактически источник всех конфликтов), включая исполнителей и управленцев, а так же внутренняя политика конторы.
5б. Квалификация контингента == масштаб работ
..
N. Процесс
Идея понятна ? Итого, всего, по большому счет, 5 факторов — требования, приоритеты, среда, зависимости, контингент.
Pzz>Как бы то ни было, когда возникает проблема, люди что-то начинают делать. Одни организации заводят тикет в системе управления деятельностью, пропускают его через 100 этапов, после чего он сваливается на конкретного исполнителя, а потом проходит еще 100 этапов в обратную сторону, чтобы быть помеченным, как закрытый. В других организациях говорят Васе, и Вася после двух бессонный ночей и выпитого ведра кофе говорит, что все сделал. В любом случае, есть какая-то определенная последовательность действий, она и называется процессом. А эффективна она, или нет, это второй вопрос.
Правильно. И в любых вариантах для квадратного решения надо находить дискриминант. То есть, процесс ничего не решает, а всего лишь оформляет, посколько независимо от процесса надо считать дискриминант.
Pzz>У Яндекса принятый ими процесс определенно не совершенен, раз он допускает такие факапы, несмотря на титанические усилия (и ресурсы), потраченные на то, чтобы таких факапов не допустить.
Процесс вообще говоря не может сбороть такие проблемы. Те же приоритеты это уровнем ниже требований. А процессы это считай самое дно управления.
Здравствуйте, consign, Вы писали:
I>>Скажем, незачем чпокать гномиками того, кому предстоит заниматься рутиннейшим багфиксом годы напролёт.
C>Может и незачем, но ведь чпокали (может, и сейчас продолжают). Или придумали другие задачки, такие же релевантные.
Как ты замерил релевантность ? "Я не прошел в Яндекс -> гномики нерелевантны " ?
Здравствуйте, Ikemefula, Вы писали:
Pzz>>Я называю процессом фактически используемые в организации нормы и практики, использующиеся для решения тех или иных проблем.
I>Неясна твоя позиция.
Процесс не является серебряной пулей, и налаживание хорошего процесса не дает 100% гарантии успеха.
В то же время, хорошо налаженный процесс помогает работать, плохо налаженный — мешает. Поэтому налаживание процесса разработки стоит определенного количества потраченных усилий, но это не единственное, на что надо тратить усилия.
Процесс, который может быть выражен словами, проще "отлаживать". Если никто не может сформулировать, что происходит, то в случае неприятностей непонятно, что менять.
Определенные изъяны в процессе очевидным образом приводят к изъянам в результате. Скажем, если перенести сроки выпуска релиза чрезвычайно трудно, то продукт будет выходить сырой, но вовремя. А если слишком легко, то релизов вовсе не будет. Должен быть определенный баланс, на поиски которого уйдет какое-то количество времени и итераций.
В любом случае, какая-то упорядоченность должна быть, жить в полном хаосе невыносимо, но чрезмерная забюрократизированность процесса тоже очень мешает.
И да, разница между работоспособной компанией и не очень находится не в формальностях, а где-то в человеческих отношениях.
Здравствуйте, Pzz, Вы писали:
I>>Неясна твоя позиция.
Pzz>Процесс не является серебряной пулей, и налаживание хорошего процесса не дает 100% гарантии успеха.
Требования — это процесс ?
Окружение — это процесс ?
Контингент — это процесс ?
Масштаб задачи — это процесс ?
Зависимость от третьих сторон — это процесс ?
В обсуждаемом случае есть попадание в каждую из этих пяти строчек. Как то так
Pzz>И да, разница между работоспособной компанией и не очень находится не в формальностях, а где-то в человеческих отношениях.
Здравствуйте, Ikemefula, Вы писали:
I>Как ты замерил релевантность ? "Я не прошел в Яндекс -> гномики нерелевантны " ?
Фу, какая дешевая демагогия. Релевантность определяется очень просто — если вопросы не имеют прямого и непосредственного отношения к твоей непосредственной работе, то это собеседование — полная хрень.
Что касается Яндекса, то я сомневаюсь, что эта шарашкина контора сможет предложить достаточно, чтобы меня заинтересовать
Здравствуйте, Sharov, Вы писали:
Ops>>Да, надо попробовать. Он умеет выкачивать в кеш карты для нужного района? S>Не знаю, но вроде нет.
Умеет, но, ЕМНИП, в оффлайне навигатор не работает
Здравствуйте, Sharov, Вы писали:
S>А нафигатор эту карту подхватит?
Я последний раз этим пользовался пару лет назад. С тех пор мой сотовый провайдер сделал дата-роуминг в штатах разумным по цене, потому с тех пор мне оно было не нужно. Собственно, это не сложно проверить — отключи дата-соединение и попробуй "понавигироваться"
Здравствуйте, consign, Вы писали:
I>>Как ты замерил релевантность ? "Я не прошел в Яндекс -> гномики нерелевантны " ?
C>Фу, какая дешевая демагогия. Релевантность определяется очень просто — если вопросы не имеют прямого и непосредственного отношения к твоей непосредственной работе, то это собеседование — полная хрень.
Это заблуждение. Что бы проверить, можешь ли ты принимать решения или тебе это даётся с большим трудом, вобщем незачем спрашивать напрямую "можете ли вы принимать решения ?"
С другими скилами примерно так же. Вот воображение сильнее не у того, кто скажет "я креативен", а проявляется в целой куче особенностей мышления.
Кроме того, всегда нужно проверять вещи кроме самых насущных потребностей. Скажем, гномики те же очень четко детектят наличие определенных скилов. Проблема в том, что большинство вопрошающих делает "как в гугле", совершенно не думая о том, какую информацию дает решение-нерешение этой задачи и нужна ли им это задача.
Большинство контор в наборе гоняются за серебряной пулькой, эдакий тест "хорошести сотрудника". Если больше определенного порога, то надо брать, если нет, то не надо. Это и есть карго-культ. Проблема именно в этом подходе, а что именно будет в качестве теста, гномики, разговор за жизнь-опыт, реверс строки или "сложнеший баг", вообще не имеет значения. Результатом будет рандом вне зависимости от результатов теста.
Здравствуйте, vsb, Вы писали:
C>>Казалось бы, и при чем здесь сортировка гномиков? vsb>Это факап тестировщиков, менеджера проекта, девопсов, кого угодно, но уж точно не программистов.
А ничего, что у них релиз версия падает?
Когда финальные тесты уже подходили к концу, мы увидели, что последняя версия библиотеки пишет слишком много логов, и что-то заподозрили. Оказалось, что мы по ошибке снова взяли отладочную версию. Времени оставалось мало, но мы понадеялись на то, что релизная версия библиотеки не должна сильно отличаться от отладочной, и без глубокого тестирования попробовали собрать Навигатор с ней. Увы, приложение стало падать.
поэтому, гениальное решение:
Исправить ошибку было относительно легко, но времени на тестирование с новой версией не оставалось совсем, и мы решили откатиться на отладочную и запускаться с ней.
BFE>Когда финальные тесты уже подходили к концу, мы увидели, что последняя версия библиотеки пишет слишком много логов, и что-то заподозрили. Оказалось, что мы по ошибке снова взяли отладочную версию. Времени оставалось мало, но мы понадеялись на то, что релизная версия библиотеки не должна сильно отличаться от отладочной, и без глубокого тестирования попробовали собрать Навигатор с ней. Увы, приложение стало падать.
А можно задать вопрос в зал? Скажите, а зачем "отладочная версия" вообще существует, особенно в таком виде, в котором ее можно "взять", тем более, "по ошибке"?
Здравствуйте, Pzz, Вы писали:
Pzz>Всегда считал глупостью иметь отдельно отладочные и отдельно релизные билды. Фактически, весь цикл тестирования и отладки приходится проходить дважды.
Отладочные — для отладки. Тестировать надо только релизные. Отладочные программист вообще не должен никому отдавать.
Возьми да проверь.
