Пункт про "почему вы хотите работать именно у нас?". Я вам открою маленькую тайну: если вы не MFANG - то кандидат СКОРЕЕ ВСЕГО не хочет работать ИМЕННО у вас. Скорее всего он просто проходит собеседования везде, где получил отклик, а свои предпочтения он сформирует уже по результатам этих собеседований. Вот вам список того, почему именно конкретному программисту нравится работать в той или иной компании:
0) Противоречия убеждениям. Если ваша контора специализируется на, скажем, азартных играх, а у меня личная неприязнь к этой сфере - я даже не соглашусь пойти к вам на собес.
1) Команда и корпоративные обычаи. Мне лично нравится, когда коллектив дружный, общительный, шутливо потстёбывающий, проводит вечера настолок по четвергам, а не "6 вечера - я домой", но при этом без духа "мы все - семья".
2) Логистика: удобно ли добираться до работы или обратно (особенно, если нет машины), сколько времени это занимает, есть ои поблизости торговый центр/магазин, где можно поесть/купить еды
3) Кодовая база. К сожалению, о ней можно узнать только попав к вам на работу, но тем не менее. С говнокодом не нравится работать никому. В то время как за работу, где ты - самый тупой и говнокодящий чел - ты будешь держаться до последнего. Потому что у тебя перед глазами материал, на котором можно учиться, плюс вокруг люди, у которых можно учиться или спрашивать.
4) Плюшки-бонусы. Всем нравятся скидки, вкусняшки в офисе и так далее. Но это не основной пункт. Например, на моей нынешней работе плюшек нет вообще. Есть два корпората в году: зимний тусич и летние байдарки. Плюс, две арендованные дорожки в бассейне два раза в неделю. Всё. Но я держусь за эту работу, потому что остальные пункты перевешивают недостаток отсутствия плюшек.
5) Деньги. Сюрприз-сюрприз, но все мы работаем за деньги и ради денег. Если вы предложите 180 тыщ, а другой предложит 250 тыщ - ну штош... Приму я оффер тех парней, а вы можете и дальше сидеть со своими ценностями, занижением вилки, паузами, ожиданием после начала собеса и своим комплексом "мы тут привечаем только избранных".
6) Какие задачи. Мне как бэкендеру нравится работать с данными, сторонними сервисами, интеграциями, а также поиском багов и исправлению их. Если моя основная работа будет заключаться в перекрашивании кнопок, починкой поехавшей разметки или написании конфиг-файлов - я сдохну от скуки.
ЗДЕСЬ СПИСОК ПРИОРИТЕТОВ ОКАНЧИВАЕТСЯ
8) Офигенность конкретно вашей компании
9) ваша миссия
Как видите, оба пунта, которые отвечают на вопрос "почему вы хотите работать именно у нас" - за пределами приоритетов.
----
Разогрев:
Если ко мне на видеособес опощлают более чем на 1 минуту - я напишу в личку. Если через минуту я не получу ответ типа "ой простите, забыл" - я уйду. Если на in place собес ко мне опоздают на 3 минуты - я уйду. Потому что даже если эйчар был на созвоне/совещании в жто время и не смог сказать руководству "всем сорян, но мне нужно бежать, у меня собес назначен через минуту" - у меня большие вопросы к эйчару и а организации бизнес- процессов и корпоративной культуре, если его после этого не отпустили. А если по факту причина заключается в сраной проверке - то имел я в виду эту контору. Боже упаси у них работать.
----
Про технические вопросы:
У меня два возражения.
Первое - вы должны разделить это на два собеса: корпоративно-духовно-прескрининговый и технический. Один человек не должен спрашивать и "чо вы к нам припёрлись", и "напишите пузырьковую сортировку". Как минимум потому что тут нужна экспертиза в разных областях.
Второе: технические вопросы должны быть основаны на требованиях проекта. Поэтому ваши советы типа "на мой взгляд, лучшие вопросы это ..." - это зашквар. Вот скажите мне, на кой чёрт у пэхэрэшника спрашивать про модель OSI? Он с ней не работает, он на неё не может никак повлиять. Он знать о ней не должен. На кой чёрт просить написать самопальный гербэдж коллектор, когда есть встроенный, который отлично работает, и вылизан сотней контрибуторов? Зачем просить отсортировать массив не встроенной функцией (которая работает максимально быстро), а самопальной? Спросите лучше что-то, что часто используется на вашем проекте - вам же с этим человеком потом работать!
----
Пункт про "спрашивает про переработки" в вашем исполнении я бы перевёл на человеческий как "если человек спрашивает про переработки, то это плохой кандидат, потому что его будет сложнее запрячь и ездить на нём" и посоветовал бы вам пересмотреть свою позицию.
Весь пункт про профильное образование - это какой-то булшит... Я как мидл пэхэпэшник самоучка с 4 годами стажа просто поделюсь следующим:
На первой работе спустя какое-то время я спросил: "а почему взяли именно меня, да еще и на максимальную зарплату по вилке джуна без опыта"?
Ответ: "ты оказался в разы сильнее, чем те, кто окончили вуз по специальности программирования. Чуваки даже не знали разницу между строгим и не строгим сравнением". В то время как у меня было ООП, обработка ошибок, валидация и т.д. и т.п. И это, на минуточку, в тестовом задании и техсобесе для джуна без опыта.
А автору статьи, который, по видимому, придерживается позиции, что профильное образование делает человека программистом, я хочу рассказать два момента:
1) в вузах образование на айтишника строится по следующему принципу: у тебя 11 разных математик, а каждый из языков программирования заеимает всего по полгода (тупо на пощупать), и сама программа строится по принципу (это, конечно, гиперболизируя, но всё же) "сегодня у нас лекция Знакомство с С++. Мы будем вводить и выводить текст в консоли. Домашнее задание: сами разберитесь, и сделайте калькулятор с графическим интерфейсом". Для понимания: С++ - максимально сложный язык, и до того, чтобы работать хотя бы с одним графическим движком типа OpenGL - надо идти и идти. А их там несколько. И есть разница. И в ней надо разобраться.
2) сейчас универы учат решать какие-то простые задачи типа написания калькулятора + лабораторки типа сделайте робота на платах ардуино, и чтобы он проехал из точки а в точку б. Там не учат ни тому, как решать поставленные задачи, ни декомпозиции, ни реальным кейсам. Люди с программерских институтов как правило не готовы к реальной работе в роли программистрв.
Лично я бы на вашем месте бОльший приоритет отдавал тем собеседуемым, кто сделал хоть один приличный (то есть не какая-то бесполезная пососная фигня чисто по фану) пет-проектом. Потому что человек поставил себе задачу автоматизировать что-то, декомпозировпл, искал в интернете способы решения того или иного аспекта, и имеет готовый продукт.
Вот читаю комментарии и офигеваю. Все вдруг резко накинулись с "грешно не знать про Х".
Я вот как мидл пэхэпэшник с несколькими годами стажа, включая сферу финансов, сферу образования и сферу е-комерса, ответственно заявляю:
Ноль раз в жизни мне потребовалось писать руками алгоритм сортировки (за исключением случаев, когда это делается ночером дома по фану или в образовательных целях). Умные старички со степенью математики уже давно изобрели прекрасные эффективные алгоритмы, а не менее одарённые программисты добавили их в нативную логику самого языка, и поэтому простейшая инструкция sort() отработает быстрее, чем рукописный алгоритм в 99.99% случаев.
Ноль раз в жизни мне потребовались структуры данных сложнее, чем массив или объект. Ясно-понятно, коллекции, композиции, все дела. Но деревья? Я до сих пор не встречался ни с одной задачей и ни с одним набором данных, которые потребовали бы подобную структуру. Возможно, если уходить в какой-то глубокий код, типа если вы пишете свой пхпстан или свой Doctrine\DBAL, но без этого - ни разу. И вообще: не важно, знает ли человек конкретную структуру: если он хороший разрпб, вы просто берёте его, он сталкивается с задачей, где ему надо работать с этой структурой, ...[прошло 30-60 минут] ..., ВУАЛЯ - он знает про такую структуру и умеет с ней работать. До нынешней работы я чот слышал про редис и кликхаус. Но исключительно "что это, и для чего это можно юзать". И меня взяли! А теперь я умею с ними работать.
Big O нотация: хватает одного/двух раз прочитать, чтобы понять что по чем, как делать льзя и нельзя, и это в целом полезно и крайне прельстиво для здоровья вас и вашего продукта. НО. Есть одно маленькое НО. Людей, которые называют это и знают об этом как "Big O Notation" горааааздо меньше, чем людей, которые называют это или знают об этом как "оценка сложности алгоритмов". И тут действительно вопрос больше смахивает на "мы хотим отсеять самоучек, и работать только с теми сливками сообщества, кто учился в MIT-е и шарит за высокое".
Прочие викторины: у меня было много собесов, и на одном из них меня так же задушили терминологией. В половине случаев с этого собеседования это оказывались механизмы языка, которые я знал и умеючи использовал по необходимости, но тупо не знал, как это называется. Потому что о большинстве вещей, открою вам тайну, мы узнаём либо в ответах стаковерфлоу, либо в чужом коде или коде коллег. Ну, сейчас еще всякие чаты гопоты добавились (на основе того же стака и открытых репо гита). Потом просто разбираемся, что это, и почему было сделано именно так. А как оно называется - никого не волнует.
Чем отличается алгоритм А от алгоритма Б: окей, я знаю разницу и принцип работы пузырька, бинарного поиска и может ещё пары. И хоть раньше я стеснялся в силу своей на тот момент джуновости, но в будущем я буду просто спрашивать: "а у вас была необходимость реализовывать руками и применять в проекте хоть один из них?". Более чем уверен, что ответ будет "Нет".
Вообще, как показала лично моя практика - чем больше на собесе вопросов аля "а знаешь ли ты Х" - тем херовее кодовая база у них на проекте.
В одной из компаний, где я работал, у меня на собесе спрашивали, что такое днс (при том, что я как джун-мидл не имел доступа к инфраструктуре и тем более её настройке или разворачиванию, да и днс они не юзали. На нынешней работе хотя бы ингрес-записи в кубике создаются...), а так же, вы будете смеяться, дефолтные порты mysql, ftp, ssh, http и https. Господи, меня даже попросили перечислить ВСЕ МАГИЧЕСКИЕ КОНСТАНТЫ ПЫХИ... (Моя личная позиция: если вам хоть одна из них понадобилась хоть где-то, кроме кастомных эксепшенов или Kernel-класса в методах `get(Root|Var|Whatever)Path()` для получения абсолютного пути - у меня вопросы к вашему коду). В результате - у них в коде методы по 300 строк, строки кода по 300+ символов без переноса, классы по 11к строк, год-обжекты, нарушение вообще всех принципов и паттернов, ноль тестов, а 60% команды даже не знали и/или не юзали xdebug, а дебажили dump-and-die... Самый мрак, который я там видел - `shell_exec('java -jar {300 символов аргументов}');`
Лично я на собесе может уделил бы какое-то время прощупыванию широты познаний собеседуемого, но в основном собес бы строился по сценарию:
Расскажи о самых, как ты считаешь, эксклюзивных своих познаниях в языке/фреймворке (так я бы узнал, до чего он дочитал/додебажился), и где и почему тебе это понадобилось.
У нас такая-то инфраструктура. Есть задача сделать вот это. Сейчас оно работает так и так. Как бы ты решал такую задачу
Интервьюируемый предлагает решение
Мы спрашиваем ещё одно, возможно усложняем задачу (правки, хых)
Он предлагает снова
В какой-то момент мы пользуемся ролью старшего и говорим, что нет, так мы делать не будем, а будем делать иначе (заведомо предлагая плохое решение). И здесь доп. баллы получит тот, кто возразит и аргументированно отстоит своё решение.
Ну а дальше смотрим, какое решение предложит чел, предусмотрел ли он возможные ошибки или эдж-кейсы и т.д. если это тестовое задание - написал ли он тесты на своё поделие, качество кода и т.д.
Если что-то может произойти - где-то когда-то оно обязательно произойдёт.
И мне кажется, вы не верно поняли основной месседж данной статьи. Он заключался не в "что считать", а "как считать".
А описанное мной когнитивное искажение заключается в том, что человек склонен любой рандом сводить до уровня монетки, где "либо повезёт, либо не повезёт", совершенно забывая о том, что удачным результатом он считает только один конкретный, а не удачным -- все остальные. И их как правило больше, чем один
Вы говорите о сложных системах, когда на результат влияет, будут ли вообще назначены штрафные, кто их будет кидать, какие у него навыки, насколько он сосредоточен, не болит ли у него спина, кто защищает и т.д. И сам бросок тут уже дело не самое первое.
А мы же тут говорим об абстракиях и о рандоме. Можно, конечно, задушнить, и начать разглагольствовать о том, что никакого рандома в Computer Science нет и в помине, и на самом деле у нас псевдо-рандом, а так же итемы в контейнерах имеют разные шансы дропа, но мы же говорим об абстрактных ситуациях...
Не все это знают, и не всех можно разубедить простым "это первая глава теории". Статья нацеленна на то, чтобы дать людям наглядный пример и аргумент для убеждения
Я свернул в сторону следующего: я хотел показать, почему ошибочно рассматривать следующий бросок в последовательности, учитывая контекст предыдущих результатов. Иначе говоря, когда человек вместо того, чтобы руководствоваться вероятностью одного броска начинает руководствоваться мыслью, что "не не может же мне так такого быть, что я 10 раз подряд не выбил страйк, и на одинадцатый тоже не выбью. Ведь вероятность не выбить одинадцать страйков подряд ещё меньше, чем 10 не страйков подряд"
Очень интересно стало, а не могли бы вы рассказать про математический всегда проигрыш?
А имел я в виду именно стратегию "ну если мне уже столько раз не повезло, то вот щас щас щас уж точно повезёт". То есть когда человек рассматривает не вероятность одного броска без контекста, а то, насколько невероятно не выбить ни одного страйка за двадцать бросков, и после этого на двадцать первый нова не выбить страйк, а потому вот вот мне повезёт, и я выбью страйк.
Спасибо за развёрнутый комментарий. Да, буквально все математики, которые развенчивают этот миф, всегда говорят о системе и её состоянии. Но это что-то на сложном. Я попытался сориентировать мою статью на тех, кому тяжело оперировать такими понятиями, или кто и вовсе не изучал математику на таком уровне, или изучал и забыл.
Вот весь этот раздел про казино - было весьма познавательно, сапсибо
Да, но не все изучали матстатистику, комбинаторику, теорию вероятностей и всё такое. Данная статья рассчитана скорее на такую аудиторию. И я попытался именно на примераз показать, что прошлое не имеет никакого эффекта на результат нового броска
В одной из итераций моих паролей у меня был плюс-минус один пароль на несколько сервисов. Скажем, для простоты, "%1$s %2$s %3$s %4$s", но %3$s заменялся на название сервиса. Типа twitter, vk, fb и тд.
В другой итерации моих паролей я начинал пароль с пробела. Потому что никто не юзает пробел в брутфорсе :D
Я полагаю, даже дети уже знают, что нельзя ставить паролем имена, даты, имейл, и штуки типа кверти, восьми единиц и 1..9. Остальное подбирается дольше трёх раз
Тогда его только Господь Бог остановит. Или смерть. Какой выбирать себе пароль -- дело пользователя. Захочет -- придумет себе пароль, как последняя моя регулярка со словарём спецсимволов. Такое хрен отгадаешь. Захочет -- "послал дед бабку к морю ловить рыбу", захочет -- кверти. Если кверти -- пользователь сам себе враг, и конкретный сайт тут не виноват.
Пункт про "почему вы хотите работать именно у нас?". Я вам открою маленькую тайну: если вы не MFANG - то кандидат СКОРЕЕ ВСЕГО не хочет работать ИМЕННО у вас. Скорее всего он просто проходит собеседования везде, где получил отклик, а свои предпочтения он сформирует уже по результатам этих собеседований. Вот вам список того, почему именно конкретному программисту нравится работать в той или иной компании:
0) Противоречия убеждениям. Если ваша контора специализируется на, скажем, азартных играх, а у меня личная неприязнь к этой сфере - я даже не соглашусь пойти к вам на собес.
1) Команда и корпоративные обычаи. Мне лично нравится, когда коллектив дружный, общительный, шутливо потстёбывающий, проводит вечера настолок по четвергам, а не "6 вечера - я домой", но при этом без духа "мы все - семья".
2) Логистика: удобно ли добираться до работы или обратно (особенно, если нет машины), сколько времени это занимает, есть ои поблизости торговый центр/магазин, где можно поесть/купить еды
3) Кодовая база. К сожалению, о ней можно узнать только попав к вам на работу, но тем не менее. С говнокодом не нравится работать никому. В то время как за работу, где ты - самый тупой и говнокодящий чел - ты будешь держаться до последнего. Потому что у тебя перед глазами материал, на котором можно учиться, плюс вокруг люди, у которых можно учиться или спрашивать.
4) Плюшки-бонусы. Всем нравятся скидки, вкусняшки в офисе и так далее. Но это не основной пункт. Например, на моей нынешней работе плюшек нет вообще. Есть два корпората в году: зимний тусич и летние байдарки. Плюс, две арендованные дорожки в бассейне два раза в неделю. Всё. Но я держусь за эту работу, потому что остальные пункты перевешивают недостаток отсутствия плюшек.
5) Деньги. Сюрприз-сюрприз, но все мы работаем за деньги и ради денег. Если вы предложите 180 тыщ, а другой предложит 250 тыщ - ну штош... Приму я оффер тех парней, а вы можете и дальше сидеть со своими ценностями, занижением вилки, паузами, ожиданием после начала собеса и своим комплексом "мы тут привечаем только избранных".
6) Какие задачи. Мне как бэкендеру нравится работать с данными, сторонними сервисами, интеграциями, а также поиском багов и исправлению их. Если моя основная работа будет заключаться в перекрашивании кнопок, починкой поехавшей разметки или написании конфиг-файлов - я сдохну от скуки.
ЗДЕСЬ СПИСОК ПРИОРИТЕТОВ ОКАНЧИВАЕТСЯ
8) Офигенность конкретно вашей компании
9) ваша миссия
Как видите, оба пунта, которые отвечают на вопрос "почему вы хотите работать именно у нас" - за пределами приоритетов.
----
Разогрев:
Если ко мне на видеособес опощлают более чем на 1 минуту - я напишу в личку. Если через минуту я не получу ответ типа "ой простите, забыл" - я уйду. Если на in place собес ко мне опоздают на 3 минуты - я уйду. Потому что даже если эйчар был на созвоне/совещании в жто время и не смог сказать руководству "всем сорян, но мне нужно бежать, у меня собес назначен через минуту" - у меня большие вопросы к эйчару и а организации бизнес- процессов и корпоративной культуре, если его после этого не отпустили. А если по факту причина заключается в сраной проверке - то имел я в виду эту контору. Боже упаси у них работать.
----
Про технические вопросы:
У меня два возражения.
Первое - вы должны разделить это на два собеса: корпоративно-духовно-прескрининговый и технический. Один человек не должен спрашивать и "чо вы к нам припёрлись", и "напишите пузырьковую сортировку". Как минимум потому что тут нужна экспертиза в разных областях.
Второе: технические вопросы должны быть основаны на требованиях проекта. Поэтому ваши советы типа "на мой взгляд, лучшие вопросы это ..." - это зашквар. Вот скажите мне, на кой чёрт у пэхэрэшника спрашивать про модель OSI? Он с ней не работает, он на неё не может никак повлиять. Он знать о ней не должен. На кой чёрт просить написать самопальный гербэдж коллектор, когда есть встроенный, который отлично работает, и вылизан сотней контрибуторов? Зачем просить отсортировать массив не встроенной функцией (которая работает максимально быстро), а самопальной? Спросите лучше что-то, что часто используется на вашем проекте - вам же с этим человеком потом работать!
----
Пункт про "спрашивает про переработки" в вашем исполнении я бы перевёл на человеческий как "если человек спрашивает про переработки, то это плохой кандидат, потому что его будет сложнее запрячь и ездить на нём" и посоветовал бы вам пересмотреть свою позицию.
Весь пункт про профильное образование - это какой-то булшит... Я как мидл пэхэпэшник самоучка с 4 годами стажа просто поделюсь следующим:
На первой работе спустя какое-то время я спросил: "а почему взяли именно меня, да еще и на максимальную зарплату по вилке джуна без опыта"?
Ответ: "ты оказался в разы сильнее, чем те, кто окончили вуз по специальности программирования. Чуваки даже не знали разницу между строгим и не строгим сравнением". В то время как у меня было ООП, обработка ошибок, валидация и т.д. и т.п. И это, на минуточку, в тестовом задании и техсобесе для джуна без опыта.
А автору статьи, который, по видимому, придерживается позиции, что профильное образование делает человека программистом, я хочу рассказать два момента:
1) в вузах образование на айтишника строится по следующему принципу: у тебя 11 разных математик, а каждый из языков программирования заеимает всего по полгода (тупо на пощупать), и сама программа строится по принципу (это, конечно, гиперболизируя, но всё же) "сегодня у нас лекция Знакомство с С++. Мы будем вводить и выводить текст в консоли. Домашнее задание: сами разберитесь, и сделайте калькулятор с графическим интерфейсом". Для понимания: С++ - максимально сложный язык, и до того, чтобы работать хотя бы с одним графическим движком типа OpenGL - надо идти и идти. А их там несколько. И есть разница. И в ней надо разобраться.
2) сейчас универы учат решать какие-то простые задачи типа написания калькулятора + лабораторки типа сделайте робота на платах ардуино, и чтобы он проехал из точки а в точку б. Там не учат ни тому, как решать поставленные задачи, ни декомпозиции, ни реальным кейсам. Люди с программерских институтов как правило не готовы к реальной работе в роли программистрв.
Лично я бы на вашем месте бОльший приоритет отдавал тем собеседуемым, кто сделал хоть один приличный (то есть не какая-то бесполезная пососная фигня чисто по фану) пет-проектом. Потому что человек поставил себе задачу автоматизировать что-то, декомпозировпл, искал в интернете способы решения того или иного аспекта, и имеет готовый продукт.
Вот читаю комментарии и офигеваю. Все вдруг резко накинулись с "грешно не знать про Х".
Я вот как мидл пэхэпэшник с несколькими годами стажа, включая сферу финансов, сферу образования и сферу е-комерса, ответственно заявляю:
Ноль раз в жизни мне потребовалось писать руками алгоритм сортировки (за исключением случаев, когда это делается ночером дома по фану или в образовательных целях). Умные старички со степенью математики уже давно изобрели прекрасные эффективные алгоритмы, а не менее одарённые программисты добавили их в нативную логику самого языка, и поэтому простейшая инструкция
sort()отработает быстрее, чем рукописный алгоритм в 99.99% случаев.Ноль раз в жизни мне потребовались структуры данных сложнее, чем массив или объект. Ясно-понятно, коллекции, композиции, все дела. Но деревья? Я до сих пор не встречался ни с одной задачей и ни с одним набором данных, которые потребовали бы подобную структуру. Возможно, если уходить в какой-то глубокий код, типа если вы пишете свой пхпстан или свой Doctrine\DBAL, но без этого - ни разу. И вообще: не важно, знает ли человек конкретную структуру: если он хороший разрпб, вы просто берёте его, он сталкивается с задачей, где ему надо работать с этой структурой, ...[прошло 30-60 минут] ..., ВУАЛЯ - он знает про такую структуру и умеет с ней работать. До нынешней работы я чот слышал про редис и кликхаус. Но исключительно "что это, и для чего это можно юзать". И меня взяли! А теперь я умею с ними работать.
Big O нотация: хватает одного/двух раз прочитать, чтобы понять что по чем, как делать льзя и нельзя, и это в целом полезно и крайне прельстиво для здоровья вас и вашего продукта. НО. Есть одно маленькое НО. Людей, которые называют это и знают об этом как "Big O Notation" горааааздо меньше, чем людей, которые называют это или знают об этом как "оценка сложности алгоритмов". И тут действительно вопрос больше смахивает на "мы хотим отсеять самоучек, и работать только с теми сливками сообщества, кто учился в MIT-е и шарит за высокое".
Прочие викторины: у меня было много собесов, и на одном из них меня так же задушили терминологией. В половине случаев с этого собеседования это оказывались механизмы языка, которые я знал и умеючи использовал по необходимости, но тупо не знал, как это называется. Потому что о большинстве вещей, открою вам тайну, мы узнаём либо в ответах стаковерфлоу, либо в чужом коде или коде коллег. Ну, сейчас еще всякие чаты гопоты добавились (на основе того же стака и открытых репо гита). Потом просто разбираемся, что это, и почему было сделано именно так. А как оно называется - никого не волнует.
Чем отличается алгоритм А от алгоритма Б: окей, я знаю разницу и принцип работы пузырька, бинарного поиска и может ещё пары. И хоть раньше я стеснялся в силу своей на тот момент джуновости, но в будущем я буду просто спрашивать: "а у вас была необходимость реализовывать руками и применять в проекте хоть один из них?". Более чем уверен, что ответ будет "Нет".
Вообще, как показала лично моя практика - чем больше на собесе вопросов аля "а знаешь ли ты Х" - тем херовее кодовая база у них на проекте.
В одной из компаний, где я работал, у меня на собесе спрашивали, что такое днс (при том, что я как джун-мидл не имел доступа к инфраструктуре и тем более её настройке или разворачиванию, да и днс они не юзали. На нынешней работе хотя бы ингрес-записи в кубике создаются...), а так же, вы будете смеяться, дефолтные порты mysql, ftp, ssh, http и https. Господи, меня даже попросили перечислить ВСЕ МАГИЧЕСКИЕ КОНСТАНТЫ ПЫХИ... (Моя личная позиция: если вам хоть одна из них понадобилась хоть где-то, кроме кастомных эксепшенов или Kernel-класса в методах `get(Root|Var|Whatever)Path()` для получения абсолютного пути - у меня вопросы к вашему коду). В результате - у них в коде методы по 300 строк, строки кода по 300+ символов без переноса, классы по 11к строк, год-обжекты, нарушение вообще всех принципов и паттернов, ноль тестов, а 60% команды даже не знали и/или не юзали xdebug, а дебажили dump-and-die... Самый мрак, который я там видел - `shell_exec('java -jar {300 символов аргументов}');`
Лично я на собесе может уделил бы какое-то время прощупыванию широты познаний собеседуемого, но в основном собес бы строился по сценарию:
Расскажи о самых, как ты считаешь, эксклюзивных своих познаниях в языке/фреймворке (так я бы узнал, до чего он дочитал/додебажился), и где и почему тебе это понадобилось.
У нас такая-то инфраструктура. Есть задача сделать вот это. Сейчас оно работает так и так. Как бы ты решал такую задачу
Интервьюируемый предлагает решение
Мы спрашиваем ещё одно, возможно усложняем задачу (правки, хых)
Он предлагает снова
В какой-то момент мы пользуемся ролью старшего и говорим, что нет, так мы делать не будем, а будем делать иначе (заведомо предлагая плохое решение). И здесь доп. баллы получит тот, кто возразит и аргументированно отстоит своё решение.
Ну а дальше смотрим, какое решение предложит чел, предусмотрел ли он возможные ошибки или эдж-кейсы и т.д. если это тестовое задание - написал ли он тесты на своё поделие, качество кода и т.д.
Если что-то может произойти - где-то когда-то оно обязательно произойдёт.
И мне кажется, вы не верно поняли основной месседж данной статьи. Он заключался не в "что считать", а "как считать".
А описанное мной когнитивное искажение заключается в том, что человек склонен любой рандом сводить до уровня монетки, где "либо повезёт, либо не повезёт", совершенно забывая о том, что удачным результатом он считает только один конкретный, а не удачным -- все остальные. И их как правило больше, чем один
Вы говорите о сложных системах, когда на результат влияет, будут ли вообще назначены штрафные, кто их будет кидать, какие у него навыки, насколько он сосредоточен, не болит ли у него спина, кто защищает и т.д. И сам бросок тут уже дело не самое первое.
А мы же тут говорим об абстракиях и о рандоме. Можно, конечно, задушнить, и начать разглагольствовать о том, что никакого рандома в Computer Science нет и в помине, и на самом деле у нас псевдо-рандом, а так же итемы в контейнерах имеют разные шансы дропа, но мы же говорим об абстрактных ситуациях...
Не все это знают, и не всех можно разубедить простым "это первая глава теории". Статья нацеленна на то, чтобы дать людям наглядный пример и аргумент для убеждения
Не только ограничен, но если сотрудник уличит вас применении математики - он должен позвать охрану, и вас выведут. Умным быть не разрешается
Я свернул в сторону следующего: я хотел показать, почему ошибочно рассматривать следующий бросок в последовательности, учитывая контекст предыдущих результатов. Иначе говоря, когда человек вместо того, чтобы руководствоваться вероятностью одного броска начинает руководствоваться мыслью, что "не не может же мне так такого быть, что я 10 раз подряд не выбил страйк, и на одинадцатый тоже не выбью. Ведь вероятность не выбить одинадцать страйков подряд ещё меньше, чем 10 не страйков подряд"
Очень интересно стало, а не могли бы вы рассказать про математический всегда проигрыш?
А имел я в виду именно стратегию "ну если мне уже столько раз не повезло, то вот щас щас щас уж точно повезёт". То есть когда человек рассматривает не вероятность одного броска без контекста, а то, насколько невероятно не выбить ни одного страйка за двадцать бросков, и после этого на двадцать первый нова не выбить страйк, а потому вот вот мне повезёт, и я выбью страйк.
На то это и теория вероятностей
Капец тут математики в чате... Я, в сторонке послушаю... О_О
Спасибо за развёрнутый комментарий. Да, буквально все математики, которые развенчивают этот миф, всегда говорят о системе и её состоянии. Но это что-то на сложном. Я попытался сориентировать мою статью на тех, кому тяжело оперировать такими понятиями, или кто и вовсе не изучал математику на таком уровне, или изучал и забыл.
Вот весь этот раздел про казино - было весьма познавательно, сапсибо
Да, но не все изучали матстатистику, комбинаторику, теорию вероятностей и всё такое. Данная статья рассчитана скорее на такую аудиторию. И я попытался именно на примераз показать, что прошлое не имеет никакого эффекта на результат нового броска
Совершенно забыл добавить это предложение, спасибо
В одной из итераций моих паролей у меня был плюс-минус один пароль на несколько сервисов. Скажем, для простоты, "%1$s %2$s %3$s %4$s", но %3$s заменялся на название сервиса. Типа twitter, vk, fb и тд.
В другой итерации моих паролей я начинал пароль с пробела. Потому что никто не юзает пробел в брутфорсе :D
:D
пасиб
Я полагаю, даже дети уже знают, что нельзя ставить паролем имена, даты, имейл, и штуки типа кверти, восьми единиц и 1..9. Остальное подбирается дольше трёх раз
От утекшей базы мы как бэкендеры можем озаботиться только защитой системы и, господи, в который раз: кто вообще хранит пароль не в виде хэша?
Тогда его только Господь Бог остановит. Или смерть. Какой выбирать себе пароль -- дело пользователя. Захочет -- придумет себе пароль, как последняя моя регулярка со словарём спецсимволов. Такое хрен отгадаешь. Захочет -- "послал дед бабку к морю ловить рыбу", захочет -- кверти. Если кверти -- пользователь сам себе враг, и конкретный сайт тут не виноват.