Его поддержали многочисленные коллеги:
Эта тема, которая периодически поднимается на разных площадках, как нельзя кстати легла на мой собственный опыт: на этой неделе и паре прошлых я прошёл несколько технических интервью в компаниях, и вопрос о том, как готовиться, является сейчас самым важным для меня.
Не секрет, довольно часто интервьюеры спрашивают т.н. Основы языка (в моём случае, это JavaScript), которые в том числе включают в себя алгоритмы. И тут любой нормальный (вокруг этого определения возможна дискуссия, но я настаиваю именно на нормальности, без кавычек) инженер сталкивается с двумя трудностями. Только сначала маленькое пояснение к «нормальности»: обычный разработчик обязан использовать в коммерческой разработке передовые технические решения, принятые в его области. Например, лучшие алгоритмы. Однако обязан ли рядовой, нормальный программист помнить конкретные реализации лучших алгоритмов в коде, это вопрос.
Итак, две трудности:
1) Зачастую на интервью перед тобой лист бумаги и карандаш. Либо доска и маркер. В реальной разработке мы пользуемся многочисленными инструментами, снимающими некоторые рутинные задачи: например, выполняющими автодополнение кода. И поэтому, к тому же учитывая несколько стрессовую обстановку на собеседовании, с лёту написать правильный, синтаксически верный код не всегда удаётся.
2) Вторая трудность является следствием фундаментальной особенности цифровой эры. Поясню на маленьком примере.
Последние пару лет я изучаю китайский язык. Основная трудность в изучении китайского — запомнить написание слов, выраженных иероглифами. В отличие от европейских, привычных нам алфавитных языков, в китайском, даже если ты хорошо помнишь произношение слова, это вряд ли поможет тебе вспомнить его точное написание. Делу помогают современные электронные помощники — приложения для телефона, вводя в которые фонетическую запись слова на латинице (пхинь инь), можно быстро получить искомые иероглифы.
Периодически я думаю, как люди обходились раньше. Ведь в лучшем случае нужно было каждый раз лезть в толстый словарь, чтобы подсмотреть правильное написание искомого слова. Это предъявляло совершенно другие требования к способности запоминать иероглифы, времени на их повторение при изучении и так далее.
Короче, если говорить грубо, часть функций нашего мозга невольно выносится во внешние интерфейсы. Нет, не сама память, но, скажем так, хэш-таблица к ней, по которой мы можем быстро восстановить все те многочисленные знания, которые получаем во всё убыстряющемся потоке профессиональной жизни.
Ровно о же самое можно сказать и о знаниях в программировании. Положа руку на сердце, каждый может признаться: он рано или поздно подзабывает какие-то вещи, принятые относить к Основам. Например, любой хороший курс по JavaScript включает себя понятие ООП, раскрытие темы наследования, создания «классов» и так далее. Однако в современных проектах, особенно основанных на фреймворках, программист напрямую использует ООП-парадигмы в написании своего кода не так часто. Не так часто, как спрашивают ООП на интервью при приёме на работу (а его любят спрашивать практически всегда). Естественно, возникают коллизии между тем, что есть на самом деле, и тем, что ты, как тебе кажется, твёрдо запомнил (и успешно забыл).
Другими словами, успешно работающий программист, который знает где и как быстро восстановить знания по текущей теме, выдающий каждый день код и даже способный на решение весьма нетривильных задач (например, придумать RoR), на интервью вдруг с треском проваливается, мыча что-то не очень внятное, глядя на, казалось бы, «детскую» задачу. Тогда вопрос — а что на самом деле определяет такое интервью?
По этой теме у буржуев, кстати, есть исследования. Например, вот это.
Вывод: «там не всё так однозначно». Конечно же, любой нормальный наниматель в первую очередь желает видеть перед собой человека, знающего элементарные вещи. Поскольку вся наша культура является прежде всего письменной культурой, наниматель в праве требовать, чтобы свои знания кандидат мог изложить на бумаге. Однако с программированием (и, вероятно, с некоторыми другими областями напряжённого умственного труда) всё очевиднее простой факт: человек уже не в состоянии воспроизвести все свои знания без специальных ключиков, подсказок. Скорее на интервью было бы продуктивнее предлагать соискателю решать ту или иную практическую задачу, интегрально оценивая его способности и умения находить решение, а не только вспоминать отдельные куски кода.
По материалам статьи, русский перевод частично здесь.
Комментарии (714)
avost
04.03.2017 02:04-3даже способный на решение весьма нетривильных задач (например, придумать RoR), на интервью вдруг с треском проваливается, мыча что-то не очень внятное, глядя на, казалось бы, «детскую» задачу
Я в это не верю, а DHH, мне кажется, просто троллит тупых, но очень самонадеянных "программистов на рельсах".
LexS007
04.03.2017 05:19+3Специалист умеет пользоваться всеми доступными инструментами для решения задачи. Что плохого в поиске описания алгоритма? Все же знать нереально. Ну на счет пузырка он, скорее всего, просто преувеличил)
avost
04.03.2017 09:15+3Вот я и говорю, что троллит. Это и по форме "признания" заметно. В поиске описания алгоритма нет проблем, если бы, к примеру, меня, поразил тяжёлый приступ амнезии и я забыл суть алгоритма пузырька, я бы в первую очередь попросил интервьюера мне его напомнить. Это абсолютно нормально. Но в статье DHH пишет, что он якобы подглядывает детали реализации, код. Полагаю, что в таком случае "программист" (не заигрывающий с публикой DHH), не способный по описанию алгоритма написать реализацию пузырька, не способен написать практически ничего. Ну, то есть то, что он будет способен написать не будет представлять коммерческого интереса. И зачем кому-то такой "работник". Это как лётчик, который умеет летать аж на вертолёте, но только по прямой. А чтобы поворачивать ему нужно каждый раз гуглить.
shir
04.03.2017 11:01-1Ну вот если мне вдруг понадобится реализовать алгоритм сортировки пузырьком (не понятно правда зачем, т.к. есть и более эффективные алгоритмы) я тоже в гугл полезу конкретную реализацию смотреть на конкретном языке. Да, я помню основной принцип. Но конкретную реализацию я буду как минимум час-два писать, чтоб все красиво было. А нагуглить это можно минут за пять. И может быть сделано красивее и эффективнее чем я бы сам написал в итоге. Если случится вдруг такое что я буду в бункере без интернета с таблетками бессмертия (чтоб было не ограниченное время), то я смогу написать реализацию не хуже, а может и лучше. Но пока мы живем в реальном мире где время стоит дорого быстрее будет погуглить.
В качестве примера можно провести аналогию с машиной. Я могу сам поменять резину на колесах машины, но я поеду в специализированный сервис, потому что там это сделают быстрее и качественнее.
avost
04.03.2017 13:55+1если мне вдруг понадобится реализовать алгоритм сортировки пузырьком (не понятно правда зачем, т.к. есть и более эффективные алгоритмы) я тоже в гугл полезу конкретную реализацию смотреть на конкретном языке. Да, я помню основной принцип. Но конкретную реализацию я буду как минимум час-два писать
Это означает, что если вы на такой тривиальный код тратите два часа, то на чуть более сложный будете тратить времени ещё больше. Так бывает. Возможно, вам поэтому дают совсем банальные задачки, либо вашего работодателя по какой-то причине устраивает такая неэффективность вашего труда.
Но пока мы живем в реальном мире где время стоит дорого быстрее будет погуглить.
Ну, мир не устроен из совсем примитивных задачек. Я, как правило, работаю над задачами, реализация которых сильно сложнее "пузырька" и кода для которых ещё нет в гугле (по правде говоря, не понимаю зачем работать над такими задачами — они ж уже решены). Ну, а такие простые пишутся вообще не включая голову. Я пузырёк первый (и последний) раз писал приблизительно 23 года назад, не вижу проблемы написать его реализацию минут за пять. Красивую. Там чтобы некрасивую написать специально думать надо.
В качестве примера можно провести аналогию с машиной. Я могу сам поменять резину на колесах машины, но я поеду в специализированный сервис, потому что там это сделают быстрее и качественнее.
Это так если вы способны только на примитивные действия в рамках рода деятельности. Задача смены колёс не входит в задачу вождения машины. Задача реализации алгоритмов напрямую входит в область деятельности программиста. Особенно таких примитивных. Более качественную аналогию я привёл. Вы способны водить машину. Но только по прямой. Если надо повернуть, то вы вызываете эвакуатор, он вас грузит, разворачивает в нужном направлении, выгружает, вы едите до следующего поворота.
shir
04.03.2017 14:10+1Это означает, что если вы на такой тривиальный код тратите два часа, то на чуть более сложный будете тратить времени ещё больше.
А вы вот сами попробуйте написать. Ну и скринкаст запишите в качестве подтверждения. Я посмотрю за сколько вы напишите. С нуля. Ничего заранее не продумывая. На месте вспоминая как это пишется. Включая отладку, рефакторинг и оптимизацию. Сильно сомневаюсь что быстрее уложитесь.
Возможно, вам поэтому дают совсем банальные задачки, либо вашего работодателя по какой-то причине устраивает такая неэффективность вашего труда.
А откуда вы знаете какие задачи мне дают и какая моя эффективность? Не надо делать предположений на пустом месте. ;)
Ну, мир не устроен из совсем примитивных задачек. Я, как правило, работаю над задачами, реализация которых сильно сложнее "пузырька" и кода для которых ещё нет в гугле (по правде говоря, не понимаю зачем работать над такими задачами — они ж уже решены).
Ну вот может тогда стоит тратить время на разработку этих алгоритмов, а не тех что уже давно сотни раз разработаны и оптимизрованы? Как бы об этом и речь.
Задача реализации алгоритмов напрямую входит в область деятельности программиста.
Программисты тоже разные бывают. Есть прикладные программисты, а есть те кто разрабатывают библиотеки. Для первого важно знать библиотеку из которой он может взять функцию сортировки, для второго важно знать наилучший способ сортировки и уметь его реализовывать с закрытыми глазами.
VolCh
04.03.2017 14:23Включая отладку, рефакторинг и оптимизацию.
Крайне редко это требуют на собеседованиях. В худшем (для соискателя) случае попросят отладить, если валится и даёт на простейших данных неверный результат, а если на каких-то граничных случаях валится или даёт неправильный результат, то скорее спросят как будет фиксить, как будешь рефакторить и оптимизировать, а не требовать продакшен код.
shir
04.03.2017 14:30Ну я в своем комментарии говорил не о собеседованиях (как и оригинальный топик), а об обычной работе. И вот в обычной работе ну вот совсем не нужно это знание (зависит конечно от специализации). И речь о том что если вдруг возникла такая задача, то вместо того чтоб тратить время пытаясь вспомнить и идеально реализовать этот алгоритм, проще погуглить.
avost
04.03.2017 16:16+2А вы вот сами попробуйте написать. Ну и скринкаст запишите в качестве подтверждения. Я посмотрю за сколько вы напишите. С нуля. Ничего заранее не продумывая. На месте вспоминая как это пишется. Включая отладку, рефакторинг и оптимизацию. Сильно сомневаюсь что быстрее уложитесь.
Гм. 23 года не брал я в руки шашек…
for (int i=0; i<a.length; ++i)
for (int j=0; j<a.length-i-1; ++j)
if (a[j] > a[j+1]) swap(a[j], a[j+1] );
Две минуты на планшете.
Рефакторинг? Оптимизация? Для реализации баблсорта? Отказать.
Ну вот может тогда стоит тратить время на разработку этих алгоритмов, а не тех что уже давно сотни раз разработаны и оптимизрованы? Как бы об этом и речь.
Вр4мя тратить н4 надо. Мы говорим о проверке способности кандидата реализовать простейший алгоритм на три строчки. Если кандидата вгоняет в ступор вложенный цикл с условием, то достаточно очевидно, что более сложные алгоритмы ему и вовсе давать на реализацию бессмысленно. Не бывает так, чтобы человек, не умеющий делать простые вещи умел при этом делать более сложные.
А откуда вы знаете какие задачи мне дают и какая моя эффективность? Не надо делать предположений на пустом месте. ;)
Почему на пустом? Я исходил из вашей же оценки этой задачи.
Программисты тоже разные бывают. Есть прикладные программисты
По-вашему, прикладные программисты это те, которые копипастят уже решённые задачи? По-моему, это и не программисты вовсе.
Есть прикладные программисты, а есть те кто разрабатывают библиотеки. Для первого важно знать библиотеку из которой он может взять функцию сортировки
Какая библиотека, о чём вы? Если для человека отклонение от линейного алгоритма (а он ведь тоже, ужаснитесь — алгоритм! Хоть и линейный) представляет непосильную задачу, то это не прикладной программист, а никакой программист. Водитель, который может ехать только прямо.
для второго важно знать наилучший способ сортировки и уметь его реализовывать с закрытыми глазами.
Ну, давайте вам прикладную задачку подкину — вам надо много раз быстро сортировать массивы из трёх чисел. Или, даже, из четырёх. Какой фреймворк станете разворачивать? Какой эсимейт на решение этой мегапроблемы?
shir
04.03.2017 16:37-1Вы меня не понимаете и говорите совсем о других вещах о которых я писал. Приводите примеры не подходящий тому что я описывал. Не вижу смысла продолжать дальше спор. Какой-то спор глухого со слепым.
avost
04.03.2017 19:52+2Приводите примеры не подходящий тому что я описывал
Переведите это на русский.
говорите совсем о других вещах о которых я писал
Как это о других? Вы же сами просили:
А вы вот сами попробуйте написать
Не ваши слова, не? Ну, вы тогда кошку, что ли, накажите, которая за вас это написала. Чтобы хоть какой-то повод был от собственных слов отказаться. А то вот так прямо, на ровном месте… Это сильно… Посильнее фауста гёте. На таких раскладах и правда бессмысленно о чём-то разговаривать.
shir
04.03.2017 20:35-3Как это о других? Вы же сами просили:
А вы вот сами попробуйте написать
Ну давайте уж полностью приведем цитату что я просил:
А вы вот сами попробуйте написать. Ну и скринкаст запишите в качестве подтверждения. Я посмотрю за сколько вы напишите. С нуля. Ничего заранее не продумывая. На месте вспоминая как это пишется. Включая отладку, рефакторинг и оптимизацию. Сильно сомневаюсь что быстрее уложитесь.
Тем не менее ваш коментарий был на 2 часа позже моего. Поэтому я не знаю сколько вы реально затратили времени. И вы уверены что ваш алгоритм оптимален? (я не утверждаю что не оптимален, но и не уверен что оптимален). А как оптимален по времени или по используемой памяти? И на каком языке? Вроде бы СИ. А если надо, скажем на питоне? Я вот, например, питон не знаю. Мне уже как циклы делать надо будет гуглить.
Но в целом вы почему то не соглашаетесь со мной, хотя говорите о том же что и я только другими словами. Поэтому считаю что спор бесполезен.
avost
04.03.2017 22:40+4Тем не менее ваш коментарий был на 2 часа позже моего. Поэтому я не знаю сколько вы реально затратили времени
Ну, разумеется, все два часа обдумывал эти три строчки. Рефакторил. А сначала провёл сам с собой стендап-митинг и плэннинг-покер. А в конце ретроспекцию.
И вы уверены что ваш алгоритм оптимален?
Задачи алгоритмизации не стояло. Стояла задача реализации заранее заданного алгоритма. Реализация оптимальна, если можно применить это определение к этой реализации. Сам алгоритм можно улучшать, оставаясь в рамках алгоритма, но делать это следует только в очень редких случаях, когда входные данные отвечают определённым условиям. В общем случае — это бессмысленно. Любому программисту (то есть не специалисту по копи-н-пэйст) это понятно.
И на каком языке? Вроде бы СИ
На любом удобном. Нет, это сиподобный псевдокод.
А если надо, скажем на питоне? Я вот, например, питон не знаю.
Не знаете питона и идёте устраиваться на работу питонистом? Такое бывает, но в этом случае надо заранее известить об этом интервьюера и тогда он не станет требовать от вас писать именно на питоне.
хотя говорите о том же что и я только другими словами.
Разве? Я утверждаю, что работа программиста заключается в реализации алгоритмов. Вы утверждаете, что якобы есть какие-то "прикладные программисты", которые не занимаются реализацией алгоритмов (а чего они тогда делают?).
qw1
04.03.2017 22:43+5Поэтому я не знаю сколько вы реально затратили времени. И вы уверены что ваш алгоритм оптимален?
Как-то даже весело со стороны это наблюдать.
— А это точно пузырёк?
— А вы уверены, что он оптимален по времени?
— А по памяти?
Причём кода-то — 3 строчки ))))khim
04.03.2017 23:03+2Слушайте, это люди из мира где дописать несколько пробелов — это задача, достойная отдельной библиотеки! Причём весьма и весьма нетривиальной, с кучей оптимизаций (я не издеваюсь — посмотрите на код). А вы говорите — пузырёк.
maxpsyhos
05.03.2017 07:03+1А вы уверены, что в «нормальном» мире, например в том же С++ или Java в стандартной библиотеке эта функция не работает похожим образом? И вся разница в том, что в одном языке это встроено, а в другом приходится писать всё самим.
Idot
05.03.2017 09:04-1Писать сами — это ещё куда ни шло и терпимо.
Гораздо хуже когда для этой функции используют десятки не совместимых библиотек. Вплоть до того, что после выхода новой версии библиотеки или компилятора проект вообще перестаёт компилироваться.
am-amotion-city
06.03.2017 14:25В «нормальном» мире автор этой «библиотеки» не может изъять ее репозитория, чтобы проучить упоровшихся владельцев репозитория, и остановить работу ста тысяч проектов (или сколько там, не помню точно) на неопределенное время.
Вы что, профессиональные новости вообще не читаете, только желтуху типа хабра?
zagayevskiy
06.03.2017 14:16+1Вы упоролись? Это сортировка пузырьком. Алгоритм такой, общепринятый. У него квадратичная сложность и константная память, это общеизвестно (а кому неизвестно, могут посчитать самостоятельно из описания). Какая оптимальность, о чём вы вообще?
alexback
05.03.2017 11:12Во внешнем цикле
for (int i=0; i<a.length; ++i), последний проход вроде как лишний, достаточно for (int i=0; i<a.length-1; ++i).avost
05.03.2017 13:01+1Верно! С другой стороны это "нулевой проход" — внутренний цикл не выполнится. На общую квадратичную сложность алгоритма это не повлияет ;)
vadim_shb
06.03.2017 09:56Насколько я понимаю, пузырек имеет смысл применять только если исходный массив «почти отсортирован». И проверка на отсортированность (чтобы впустую не гонять циклы) не помешает. Ну то есть для собеседования — вопросов нет, а вот в реальном мире все же лучше погуглить.
avost
06.03.2017 17:37Насколько я понимаю, пузырек имеет смысл применять только если исходный массив «почти отсортирован».
Неправильно понимаете.
а вот в реальном мире все же лучше погуглить
Да не надо тут гуглить, ситуация же простейшая. Если даже это нужно гуглить, то это говорит лишь о профнепригодности человека.
Вы, к примеру, тест не прошли сразу по двум критериям:
- Не поняли техзадание (оно состояло в реализации алгоритма, а не в анализе его применимости)
- Провалили анализ этого простейшего алгоритма (возможно, это было бы следующим вопросом :).
ЗЫ. "пузырёк" может быть применён в реальном мире. Навскидку пара вариантов — сортировка коротких массивов из трёх, возможно, четырёх элементов (помимо самостоятельной задачи, это можно использовать для сортировки коротких "хвостов" в том же qsort'е). Только циклы желательно развернуть, если уж до такой оптимизации дело дошло. Ещё вариант, когда у нас есть "эн пополам" параллельных синхронных(!) процессов. Например, "сортировщик", реализованный в железе. Чтобы более-менее эффективно применять пузырёк к "почти отсортированным" массивам надо его изрядно модифицировать — сделать двунаправленным и отсекать начальные отсортированные последовательности в каждом из направлений.
DistortNeo
06.03.2017 21:15ЗЫ. "пузырёк" может быть применён в реальном мире. Навскидку пара вариантов — сортировка коротких массивов из трёх, возможно, четырёх элементов (помимо самостоятельной задачи, это можно использовать для сортировки коротких "хвостов" в том же qsort'е).
В .NET сортировка вставками (тот же пузырёк), судя по документации, используется до массивов длиной до 16 элементов при вызове Array.Sort.
Кстати, для массивов фиксированного размера я бы вообще использовал сортировочную сеть.
0xd34df00d
06.03.2017 22:21+1Не поняли техзадание (оно состояло в реализации алгоритма, а не в анализе его применимости)
Во-первых, я понятия не имею, техзадание это, вопрос с заковыкой или психологический тест, и что именно интервьювер ожидает от меня услышать, поэтому моё дело — выдать как можно больше информации.
Во-вторых, я не на должность стучателя по клавиатуре собеседуюсь. Если я вижу заведомую лажу, то мой профессиональный долг на неё указать.
vadim_shb
07.03.2017 01:28Какой еще тест? Я к вам на собеседование еще не приходил ;).
Мне так лениво быть занудой, ну да побуду немного…
<Зануда_mode>
Вы почему-то хотите подмять условия под себя и выглядеть д'Артаньяном… Ну ок, развлекйтесь. Вы например постоянно пытаетесь свести исходную задачу shir к задаче на собеседовании, хотя он четко дал понять, что речь идет о промышленном коде. Если вам в промышленном коде не приходится заниматься анализом алгоритмов, то я рад за вас. Наверное.
Лично я когда встала задача «написать сортировку пузырьком в промышленном коде», не могу абстрагироваться от контекста и тупо фигачить пузырек. Даже если эту задачу поставил мне истинный Гасконец-архитектор со всеми регалиями. Я предполагаю, что какие-то доводы на реализацию этого пузырька (которым многие здесь присутствующие не пользовались десятки лет) были. Единственный посыл, который я знаю — «почти отсортированный массив». Вы, кстати описали один такой — массив из 3-4 элементов. А если из 7 то уже бутылочное горлышко? А если 50? А если из 300 млн, состоящих из блоков по 3 числа, причем блоки уже отсортированны, и только числа внутри блоков нет? Пузырек перестает быть эффективным? Нужно просто не забыть остановить его через 2 прогона. Или досортировать массив строк уже отсортированный по префиксам?
Я к чему веду — контекст имеет значение. Ни я ни вы не знаем какой контекст был в голове у shir, когда он говорил про два часа, но вы вместо того чтобы задать вопрос сделали выводы. Я тоже не представляю, чем там 2 часа можно заниматься, но это профессионально по-вашему? Если контекст был таким — каким вы его себе видете — ваши выводы адекватны. А если нет — то ваша категоричность неадекватна. И вот тогда прогуглить под конкретный контекст — один из способов сэкономить время. Может в итоге и не пузырек вовсе был нужен?
Точно так же вы поступили, когда не удосужились выяснить моего определения «почти отсортированного массива» :). Бросились делать выводы и обвинять в некомпетентности. Зато шпага сверкает.
</Зануда_mode>
На второй такой пост занудства меня вряд ли хватит — времени жалко, так что можете воспользоваться этим, и смело обвинять меня в чем вашей душе угодно. Я наверняка некомпетентен и профнепригоден в огромном количестве областей :).vadim_shb
07.03.2017 01:39Хотя конечно предположение что вы писали 3 строчки 2 часа тоже за гранью адекватности.
avost
07.03.2017 04:09-1Какой еще тест? Я к вам на собеседование еще не приходил ;).
А какая разница, если ваши рассуждения лежат либо за пределами темы дискуссии, либо просто неверны.
Вы например постоянно пытаетесь свести исходную задачу shir к задаче на собеседовании, хотя он четко дал понять, что речь идет о промышленном коде.
Ну, вообще-то, если бы вы внимательно посмотрели, то исходная задача — моя :). А если ещё внимательнее, то и не моя и даже не топик-стартера, а DHH. А если ещё вни… Впрочем, ладно. Это как раз shir пытался её свести к какой-то другой, но так и не пояснил к какой. К "какой-то, которая требует гугления, рефакторинга и занимает два часа" ;).
Единственный посыл, который я знаю — «почти отсортированный массив». Вы, кстати описали один такой — массив из 3-4 элементов.
Он не почти отсортированый, он просто короткий.
А если из 7 то уже бутылочное горлышко? А если 50?
Ну, тут надо анализировать альтернативы и более точно считать операции, чтобы определить есть ли решения у уравнения вроде А n^2 = В n * log_2 n, при n>1. Если я ничего не напутал.
А если из 300 млн, состоящих из блоков по 3 числа, причем блоки уже отсортированны, и только числа внутри блоков нет? Пузырек перестает быть эффективным?
Пытаетесь подогнать задачу под ответ? Да, разумеется, оригинальный "трёхстрочный" пузырёк будет иметь здесь всё те же сложность "триста миллионов в квадрате". Модифицированный отработает быстрее. И если бы вы внимательно прочли, то обнаружили бы, что я даже уже расписал способ модификации.
Точно так же вы поступили, когда не удосужились выяснить моего определения «почти отсортированного массива» :).
А это не очень важно. Мой способ подходит и для вашего случая тоже, несмотря на то, что я думал о другом.
Хотя конечно предположение что вы писали 3 строчки 2 часа тоже за гранью адекватности.
Я не могу писать чаще, чем раз в час :). А почему написал не через час, а через два — не помню уже. Хотел через час.
qw1
06.03.2017 20:24Увы, это не совсем так. Если «лёгкий» элемент стоит не на своём месте, он за первый проход займет своё место. Но если «тяжёлый» элемент не на месте, нужно столько проходов, сколько пузырьков должны его обогнать. То есть, эвристика «почти отсортированности» требует уточнения, которое делает её сложно применимой.
khim
06.03.2017 20:45Нужно утюжить массив туда-обратно, чтобы было хорошо. Но реальный удел пузырька — массивы в 3-5 элементов. Можно CHECK в программе поставить, чтобы она сообщала когда их будет больше 10.
am-amotion-city
04.03.2017 09:16+4Весь приличный код в рельсах написан внезапно не Ханссоном. DHH придумал, как можно продать хомячкам мощь, которую заложил в язык Матц. Сам Матц, при этом, сортировку пузырьком напишет влет.
В этом и разница между хорошими антрепренерами (DHH) и высококлассными спецами (Валим, например). Гонщик из DHH неплохой, это да.
При этом, замечу, рельсы крайне негативно повлияли на средний уровень программиста в вебе.
i360u
04.03.2017 12:51+11Хороший опытный программист, скорее всего, имеет какую-то свою наработанную специализацию, и она, скорее всего, не из области алгоритмов из учебника. Формальный подход дает формальный результат и победители олимпиад по программированию в боевых условиях часто сильно проигрывают практикам.
tyomitch
05.03.2017 02:10+2победители олимпиад по программированию в боевых условиях часто сильно проигрывают практикам
На самом деле нет: черты характера, позволившие человеку стать победителем олимпиад по программированию (усидчивость, хорошая память, внимание к мелочам и т.п.), могут при достаточной мотивации сделать из него и отличного промышленного программиста. Знаю много людей, которые совмещают и те и другие навыки; хотя прямой связи между этими навыками действительно нет.i360u
05.03.2017 10:26+1Дело не в чертах характера, а натаскивании "нейросети" из собственной черепной коробки на определенный круг задач. Вот тут-то и выясняется, что для олимпиад и практики — эти задачи весьма непохожи (что для многих — контринтуитивно, говорят-то, вроде, об одном и том-же, о программировании). А так — да, и боксер может стать хорошим программистом при достаточном рвении. Но это совсем не значит, что его боксерские навыки ему помогут. Аналогичный пример — вундеркинды: мало кто из них добивается чего-то заметного в жизни, это общеизвестный факт.
tyomitch
05.03.2017 11:18Я как раз про то, что навыки разные, но методики «натаскивания нейросети» на тот и на другой круг задач — похожи между собой, и непохожи на методики тренировки боксёра.
i360u
05.03.2017 17:55Они далеко не так похожи, как нам кажется, если мы будем смотреть на вопрос формально. В это все дело.
daiver19
05.03.2017 14:42+2Я понимаю, что людям, не добившимся чего-то приятно полить грязью людей добившихся этого. Много денег — несчастен в семье, красавица — значит тупая, спортсмен — тупой, хорошо учится — ботаник итд. Из этой же серии и ваше утверждение.
В рельности все неоднозначно, конечно, и случаи разные бывают. Но в основном «олимпиадники» работают в фэйсбуках с гуглами и зачастую успешно. Просто потому, что это обычно умные и способные люди.i360u
05.03.2017 17:46У Вас богатая фантазия, но, боюсь, она увела Вас далеко от реальности. Мое утверждение никак не связано с поливанием кого-то грязью и принижением чьих-то заслуг. Также Вы понятия не имеете о моих достижениях. Я говорю только о том, что навыки для решения разных специфичных задач — требуются разные. Мой опыт указывает на это со всей очевидностью.
daiver19
05.03.2017 18:11Ничего не знаю о ваших достижениях. Просто (осознанно или нет) вы использовали стандартную фразу, которая звучит ровно так же, как и примеры, которые я привел. Еще и выдумали каких-то «практиков». Ту же самую формулировку вы продемонстрировали и в отношение вундеркиндов (еще и с применением классического демагогического приема про «общеизвестный факт»).
Пример с корреляцией весьма забавный. Во-первых, все мы знаем, что correlation does not imply causation. Во-вторых, как бы там ни было, но пройти собеседование в Гугл определенно легче олимпиаднику.
i360u
05.03.2017 18:29Ок, практиков — я выдумал. И написал какую-то "стандартную фразу", которая, почему-то (для меня это загадка), звучит так-же как то, что Вы нафантазировали. На этом и разойдемся.
i360u
05.03.2017 17:49
VMichael
05.03.2017 17:57По вашей ссылке обсуждение вылилось в такой же холивар между «обычными программистами» и «программистами которые не считают за программистов тех, кто не пишет сортировки по лучшим алгоритмам и не применяет высшую математику». :)
i360u
05.03.2017 18:00Да, и это вполне предсказуемая реакция аудитории. Но это не отменяет посыла самой статьи.
moborb
04.03.2017 05:42+8Умею писать алгоритмы на листе так как учился в такие времена и таких местах что даже олимпиада по программированию проходила на листочках с карандашем )) Первые свои программы на С++ писал в тетрадке
kuftachev
04.03.2017 14:20+4На одной странице код на C++, а на следующей — его откомпилированная версия под целевую платформу на Assembly )))).
P.S. Это просто абстрактная шутка не касающаяся конкретных людей, так как есть разные условию и лучше делать как есть возможность на данный момент, идя к своей цели.
Blast
04.03.2017 22:58+1Шутки шутками, но в школьные годы было дело, писал «вирус» на асме, транслировал его по таблицам опкодов из учебника, потом переводил в альт-коды, чтоб можно было набрать с бумажки на машине, где даже до командной строки нужно было добираться с бубном и постоянно оглядываясь. И всё это из желания подгадить «плохому» администратору местного игрового клуба :) До применения, правда, дело так и не дошло, да и вряд ли бы оно вообще запустилось, но вспомнить приятно. Сейчас ох как не хватает того упорства и целеустремлённости.
Res1dent
04.03.2017 22:58Времена эти еще не ушли. Сейчас школьные олимпиады, да даже ЕГЭ — проходят с написанием кода на листочке.
SDSWanderer
04.03.2017 07:19+2Даже примерно не помню ни одного алгоритма сортировки, если попросят написать без гугла — изобрету парочку. В работе мне оно как веб разработчику не нужно совершенно. Я не хочу сказать что мне это вообще не интересно, просто когда-то сдал и забыл за ненадобностью, так же как и многое другое, даже гораздо более близкое к реальной разработке. Вот например синтаксис SQL иногда приходится гуглить, так как обычно все решает ORM, и забывается он на ура. Никогда таких вещей не стесняюсь, на собеседовании если заставляют писать SQL на бумажке обычно вообще отказываюсь, и ничего, еще ни разу из за этого не получил отказ.
quantum
04.03.2017 11:37Зря вы так с sql
SDSWanderer
04.03.2017 17:51Аргументы?
edogs
04.03.2017 19:46+3Ну, это просто значит что понятие «архитектура БД» для Вас мало что значит.
ORM решения универсальны, но не оптимальны, годятся только для проектов где производительность (по каким-то причинам) не важна вообще. Таких много, таких большинство, но все же это далеко не 100%.
«Грязный костыль» sql запросов проложенный в обход ORM может ускорить загрузку веб-сайта в 10 раз легко и так же потребление ресурсов снизить, что уж тут говорить о чисто интегрированном sql решении в веб-сайт, вместо ORM.SDSWanderer
04.03.2017 21:36+2Ну, это просто значит что понятие «архитектура БД» для Вас мало что значит.
Ничего себе вывод. А как это получилось из того что я плохо помню синтаксис SQL? Я уж молчу что понятие «архитектура БД» включает в себя не только реляционные БД.
ORM решения универсальны, но не оптимальны, годятся только для проектов где производительность (по каким-то причинам) не важна вообще.
От 90% запросов в обычном проекте (где производительность вообще-то важна) будут одинаковыми по производительности (да и вообще различия будут чисто синтаксические) если их писать руками или с помощью ORM. Для остальных я знаю чего мне нужно добиться и пишу SQL если приходится. Вот тут то и приходится гуглить. И кстати, не считаю что это «Грязный костыль», даже в кавычках (при условии что не нарушена инкапсуляция итд).
edogs
05.03.2017 18:36А как это получилось из того что я плохо помню синтаксис SQL?
В основном это получилось из «все решает ORM»:) Ни в коем случае не настаиваем на правоте.
Вот что Вы скажете человеку высказавшему мысль что «в автомобиле все решает газ и тормоз»? Не, ну так-то конечно решает, но заподозрить такого человека в глубинном знании устройства авто и принципов контраварийного вождения трудно.
DistortNeo
04.03.2017 21:42Проблема заключается в соотношении стоимости разработки к стоимости использования и поддержки продукта. Обычно покупка десятикратного количества серверов обходится дешевле.
qw1
04.03.2017 22:46+1Бывает, что ORM генерит запрос, которому SQL-сервер подбирает неоптимальный план. И тогда каждое открытие страницы — 10 секунд (фуллскан таблицы на 5 млн. записей). И никакими серверами это не заткнёшь, хоть 100 серверов поставь.
Нужно переписывать код, а чтобы понять, какие хинты дать ORM, надо спуститься на уровень SQL.
edogs
05.03.2017 18:48+1Проблема заключается в соотношении стоимости разработки к стоимости использования и поддержки продукта. Обычно покупка десятикратного количества серверов обходится дешевле.
Последнее время все больше наблюдаем отход от этого, несмотря на рост мощностей серверов.
Когда проект только начинается, разница между 1000 за сервер и 10000 за 10 серверов выливается в 9 тысяч за сервер в месяц, это мало того что не такая уж маленькая сумма, но и может являться гранью между рентабельностью и не рентабельностью.
Кроме того, есть нюанс по разработке. Один сервер достаточно легко масштабируется до 3 (просто разбросом базы, веб-морды и кода на разные сервера), но дальнейшее масштабирование подразумевает наличие хорошего архитектурного решения позволяющего распределять нагрузку на 10 серверов.
Вынос в облако не всегда решает, т.к. это все же обычно дороже плюс не все и всегда туда можно вынести в принципе.
igrishaev
04.03.2017 07:23Автор, вы выдаете желаемое за действительное. Все твиты кроме первого говорят о технических деталях, а не об алгоритмах (длина строки, SQL). И мне кажется, что 4 твита — не слишком большая выборка для столь громкого заголовка, он звучит как "все программисты в мире". Алгоритмы знать нужно, хотя бы понимать смысл работы. И готовиться к собеседованию тоже нужно.
alexey-m-ukolov
04.03.2017 08:47+3Там далеко не четыре твита. Вот небольшая подборка — https://twitter.com/i/moments/836232961037058050
igrishaev
04.03.2017 10:37+3Они все тоже про технические детали. Не знаю метод или класс. А топик-стартер лучше бы потратил пять минут на википедию. Тем более, он знаковая фигура в мире рельс, и теперь еще больше джуниоров начнут говорить, что алгоритмы не нужны.
Nakosika
04.03.2017 10:55+2а нафига они нужны? Я за 20 лет только в геймдеве алгоритмы писал. И нет, такие алгоритмы не учат в вузах. Сейчас если тебе нужен алгоритм ты просто берешь либу. Или гугл в помощь. Имхо, Пытаться все знать заранее — это какая-то болезнь, которую развивают в учебных учреждениях.
VolCh
04.03.2017 12:14+1Работа чистого программиста заключается в основном в переводе алгоритмов в код. Мы пишем алгоритмы в строго формализованном виде и по сути ничего другого и не делаем.
Nakosika
13.03.2017 16:21Что за чистые программисты в вакууме вместе с квадратным конем? И раз вы выделяете чистых программистов то где-то наверное есть и грязные? И кто такие «вы» и что за алгоритмы пишете в строго формализованном виде (судя по всему вам компы не завезли чтобы проверять теорию на практике)?
ЗЫ Знаю что толсто, просто на веселье пробило. Понедельник, все такие серьезные.VolCh
13.03.2017 16:37:) Грязные ещё алгоритмы и придумывают, а строго формализованный вид алгоритма — синтаксически корректная программа на каком-то ЯП,
Symphel
04.03.2017 14:21А что вы понимаете под «писать»? Если разрабатывать, то, конечно, не каждому приходится. А вот использовать существующие — да почти постояно, что-нибудь типа рекурсивного обхода дерева очень часто встречается.
И даже если используешь готовые алгоритмы из фремворка, знать эти алгоритмы крайне желательно, чтобы, как минимум, оценить границы применимости, сложность и т. д.
sbnur
04.03.2017 08:18+1Основная утомляющая трудность работ программиста — это набор кода.
Я учился во времена, когда программы писались на листе и сдавались для запуска на перфорацию.
Поэтому навыками рукописной работы с кодом овладел еще в вузе (кстати в одном интервью мне удалось написать корректно сортировку пузырьком, хотя я просто его помнил, так как имел опыт преподования программирования для студентов).
Но значимо ли это умение для оценки программиста на работу?
Думаю нет.
Все-таки любое интервью является стрессовой ситуацией, что не способствует сосредоточенности, необходимой для корректного написания кода, тем более, что наличие сред разработки предупреждает многочисленные описки, что снижает уровень навыков внутреннего синтаксического контроля.
Мне кажется, что в ходе интервью необходим рассказ о предыдущих выполненных проектах
И при необходимости лучше дать тестовое задание и обсудить его результаты при собеседовании
Scf
04.03.2017 09:06Имхо, как-то дико хвастаться пробелами в школьных знаниях. Во всяком случае, мне в 90х в обычной школе далеко в тундре рассказывали про деревья, двоичный поиск, сортировку пузырьком и вставками.
Со специфичными вопросами по языкам/фреймворкам всё немного не так — ответы на них показывают опыт работы с конкретным языком/фичами. Если кандидат рассказывает о своей сложной базе на рельсах, он не может не помнить синтаксис миграций. Если кандидат не знает, как найти длину строки в питоне, то питон точно не его основной язык.
К примеру, заезженный вопрос по джаве "какие есть методы у класса Object". Интервьювер ожидает не заучивание явадока, а список методов, которые кандидат использовал настолько интенсивно, что они намертво застряли у него в памяти.
Skerrigan
04.03.2017 09:19-2вопрос по джаве «какие есть методы у класса Object»
Прочитал, подумал про себя, с ужасом понял, что не помню ни одного.
4 года подряд опыта разработки софта на java… когда пишу код, мой мозг при этом не участвует… пишут какие-то гномикиzagayevskiy
06.03.2017 14:32+2Мда? Ни разу не использовали toString()? Не знаете, что для того, чтобы положить объект своего класса в HashMap, надо консистентно реализовать equals() и hashCode()? Ну это из простого, без всяких wait()/notify() и прочих clone() (привет, Cloneable!)
У меня для вас плохие новости.Skerrigan
06.03.2017 15:54-1Вот опять же — пока вы не сказали об этом, я и не помнил.
Правда про объект — делаю несколько иначе.
Я обычно такой ерундой себе голову просто не забиваю. Мой кэш памяти не слишком большой, в жизни есть более важные вещи. А когда сажусь решать конкретную задачу, то быстро понимаю где прочитать документацию и оперативно подгрузить данные в мозг. Когда код написан — данные из памяти мгновенно стираются. Помогает вне офиса не думать о работе. И на сон положительно влияет.
А так, и наследование, и инъекции, и ORM (что по xml, что по аннотациям), собственноручный парсер JSON (еще до появления этой либы), сокеты и т.д.
А вот на такие мелочевки в памяти ни места, ни приоритетов.zagayevskiy
06.03.2017 16:34+2Ну так вам вопрос задали, нужно как-то взять себя в руки и вспомнить, блин. Потому что если вы не знаете про equals/hashCode, то никакой гугл вам не поможет, пока баге в проде не полезут.
Skerrigan
07.03.2017 04:13-1положить объект своего класса в HashMap,
Правда про объект — делаю несколько иначе.
Еще раз повторюсь, что работа с объектом у меня проблемы не вызывает — есть отличная библиотека, что позволяет работать безопасно. Я использую ее.
*Безусловно, понимаю, что это «не спортивно». Но скажем так, современные технологии и приемы проникают в нашу жизнь постоянно. Если завтра нас отключат от гугла, то и это не будет лично для меня проблемой — предложений на работу у меня хватает со всего северного полушария. Если гугл исчезнет совсем, то опять же эти знания не будут иметь ровно никакой ценности — будет важней навык выживания в постъядерном мире.
**Ваша жизнь — она ваша, а моя остается моей. Вам я никак не запрещаю помнить нативные реализации, считаете что это для вас весьма важно — никаких проблем :)
Однако для меня это ценности никакой не имеет. Вот правильно сделать архитектуру, чтобы спустя пару-тройку лет команда не поимела кучу боли — это в моей шкале более ценно.zagayevskiy
07.03.2017 11:53Окей, но тогда не жалуйтесь в интернетах, что не смогли пройти интервью, "потому что у меня спросили какие-то нативные реализации базовых фич языка, которые я не обязан помнить, потому что волшебная библиотека делает всё за меня".
Skerrigan
07.03.2017 12:52А не надо это воспринимать как жалобу. Такой цели не было.
Читаете вы явно плохо — у меня нет проблем с трудоустройством.
Мой первоначальный пост был вообще о другом: что я удивился отсутствию в памяти этих данных. Все остальное приплели вы на пустом месте.
Neikist
04.03.2017 09:47+4мне в 90х в обычной школе далеко в тундре рассказывали про деревья, двоичный поиск, сортировку пузырьком и вставками.
Повезло вам, нас в 2000х учили пользоваться паинтом, браузером, включать компьютер и т.п., ну и в конце вершиной было написание программы решения квадратных уравнений на qbasic
strannik_k
04.03.2017 09:48+3вопрос по джаве «какие есть методы у класса Object»
Мне подобный вопрос задали по C#. На тот момент было 5 лет опыта работы на C#.
Завис на какое время. Кое-как вспомнил парочку. Никогда не приходилось об этом задумываться, не глядя при этом в IDE.
Считаю подобные вопросы не правильными. Высокий шанс нанять того, кто вчера это просто зазубрил, но не пользовался. Эффективней показать список методов класса Object и попросить рассказать, что они делают.
sshikov
04.03.2017 10:04>К примеру, заезженный вопрос по джаве «какие есть методы у класса Object». Интервьювер ожидает не заучивание явадока, а список методов, которые кандидат использовал настолько интенсивно, что они намертво застряли у него в памяти.
Хм. Ну не знаю. Когда я это спрашиваю — я ожидаю совсем не этого. Хотя бы потому, что никогда сам не использовал «настолько интенсивно» именно их. Это сильно зависит от задач.
И кстати, по той же причине — никогда не понимаю, когда меня о них спрашивают, что именно человек ждет получить. Слишком о разном можно рассказывать.
shir
04.03.2017 11:11+3Если кандидат рассказывает о своей сложной базе на рельсах, он не может не помнить синтаксис миграций.
Семль лет (или уже восемь?) разработки на рельсах. За плечами десяток разных проектов. И нет, я не помню синтаксис миграций. Что-то там генерируется… Ну да, как колонку описать помню. Помню как индекс описать. Хотя как удалить индекс уже приходится подглядывать, помню только что синтаксис немного отличается от создания. Как сделать реверсивную миграцию уже не получается запомнить. Что-то там
revers.... А вот как описать таблицу с нуля уже точно не помню. Вы не поверите, но после работы с некоторыми проектами где база редко меняется, я забываю как генерировать миграции :)
eXtReeM
04.03.2017 09:25+5Друг вчера собеседовался в Яндекс. Дали несколько задач и и листок бумаги с ручкой. Все бы ничего, но даже исправления они восприняли как ошибку (sic!). Молчу про само собой разумеющуюся необходимость компиляции написанного кода.
Lailore
04.03.2017 12:35+1Это правда? Не ожидал от яндекса такого, может и из-за ткого подхода они не обогнали гугл в свое время, хотя появились раньше.
kmu1990
04.03.2017 13:10+2Проходил собеседование в Яндекс, у меня было совсем не так. Писал либо на доске, либо каком-то колаборативном редакторе. К ошибкам относились адекватно, я бы даже сказал слишком мягко. За то, что какие-то детали стандартной бибиотеки я не помнил, по рукам не били, помидорами в меня не бросались (например, я часто в C++ erase называю, почему-то, remove).
ef_end_y
04.03.2017 19:14Я собеседовался в Яндекс тоже с листиком и ручкой. При этом никто не обращал внимание на ошибки, которые в бою будут подсвечиваться ИДЕ, например. Смотрели на «ход моих мыслей». Была даже относительно сложная задача, на которую я сказал так: честно говоря, у меня пока нет идей в плане алгоритма, боюсь что это займет много времени и вы будете долго ждать пока я буду пытаться что-то придумать. Они отвечают: мы знаем что эта задача сложная, мы будем подсказывать, нам важно понять как ты мыслишь) В общем, меня приняли и даже сказали, что им понравилось как я себя показал
zagayevskiy
06.03.2017 14:36Интересно, а как именно он понял, что это считали ошибкой? Попытался исправить у него вырвали ручку и указали на дверь?
eXtReeM
07.03.2017 01:58Не так утрировано, но четко сказали, что при исправлении решение задачи не засчитывается.
Imbecile
04.03.2017 09:25+7Как по мне, ООП не нужно знать. Его нужно чувствовать, что ли. Ты никогда не сделаешь публичным поле, чувствуя инкапсуляцию, или не сделаешь switch на пять позиций, когда есть ощущение как обойтись наследованием. И это не столько про алгоритмы, сколько про парадигму.
А алгоритмы — да, stackoverflow и вперёд. Не вижу никакого смысла держать это в голове.
Labunsky
04.03.2017 17:20не сделаешь switch на пять позиций, когда есть ощущение как обойтись наследованием
Подвис на этой фразе минут на пять. Можно пояснить, как связан switch и наследование? А то ночь без сна провести боюсьLailore
04.03.2017 17:44+1switch Type
case Type.Type1
DoSomthing(1)
break
case Type.Type2
DoNothing(2)
break;
case Type.Type3
Cool(5)
DoSomthing(1)
brear;
default:
Standart(8)
break;
Что то такое, и так в каждом из методов.
Imbecile
04.03.2017 20:33Первое, что на ум пришло.
Если вижу что-то типа такого
class MathOperation { double Execute(double op1, double op2, string operation) { switch (opearation) { case "+": return op1 + op2; case "-": return op1 - op2; // etc... } } }
то сразу хочется сделать что-то такое
class AddOperation : MathOperation { override double Execute(double op1, double op2, string operation) { return op1 + op2; } }kmu1990
04.03.2017 20:49Тогда получается, что operation какой-то лишний немного, кажется чуть удачнее это сделать так (прошу прощения за не C#, это ведь C# был?):
class BinOp(object): impl = {'+': lambda x, y : x + y, '-': lambda x, y: x - y, ...} def execute(self, x, y, op): return BinOp.impl[op](x, y)Imbecile
05.03.2017 02:15Я не пытался рассказывать про конкретное решение конкретной задачи. Я просто пытался показать пример, когда моё чутьё подсказывает: «Ау, чувак, схерали у тебя тут не наследники, а большое количество переключений вариантов»?
kmu1990
05.03.2017 07:52Ну так и я пытался вам показать, что пример-то для наследования не очень удачный (как вы можете видеть, мое решение не очень-то далеко ушло от switch-а).
DrNefario
04.03.2017 22:59Допустим, нам нужно написать программу для вывода различных геометрических фигур на экран. Сейчас у нас есть геометрические фигуры Cube, Sphere. Пусть, все они наследуются от интерфейса Figure. (полиморфизма ради).
Какие вопросы однозначно придут (должны однозначно прийти) нам в голову перед написанием данного приложения?
1.Отличается ли написание кода для вывода различных фигур?
Однозначно, да! Вы не сможете вывести идентичным алгоритмом треугольник и квадрат, поскольку количество вершин уже говорит само за себя. Следовательно, для вывода каждой из этих фигур нужно будет написать разный код.
2. Будут ли добавляться новые фигуры для вывода?
Если «нет» сейчас, то не факт, что потом заказчику не придет в голову начать развивать свой продукт. И тут новые программисты придут и будутплеватьсяудивляться тому, почему ваша программа не соответсвует принципу «закрытость для изменений, открытость для расширений» (Б.Мейер). И как итог, им придется немало потрудиться… Но уж если вы 100% уверены, что такого не произойдет, то ладно, ладно…
После ответа на вышестоящие вопросы, в худшем случае мы придем к выводу, что программа должна поддерживать отрисовку каждой фигуры отдельно и обладать способностью внедрения новых фигур.
Для воплощения есть два принципиально разных подхода: Структурный или ООП-шный. Дабы не рассусоливать здесь столько, сколько бы хватило на целую статью я приведу примеры каждого в коде:
Структурный:
public class FigureShower{ public void render(Figure figure){ switch(figure.index){ case 0: //Cube ... case 1: //Sphere ... case n: //Arbitary chosen figure ... } } }
ООП-шный:
public interface Displayable { public void render(); } public class Cube implements Displayable { public void render(){ //instruction for cube rendering } } public class Sphere implements Displayable { public void render(){ //instruction for sphere rendering } } ... public class NFigure implements Displayable { public void render(){ //instruction for n-figure rendering } }
Можете воскликнуть: да тут то особой разницы по величине кода да и нет! И вы будете правы. Но есть пару моментом на которые стоит обратить внимание.
1.Если программист пользователь захочет сделать фигуру выводимой, то в первом «структурном» случае ему самому вспомнить, что прога не работает, потому что он забыл добавить в switch новые инструкции. В ООП-ном компилятор сам напомнит реализовать функцию.
2. Читается ООП-шное творение куда приятнее. Ну это, конечно, больше дело вкуса…
За большей информацией обращайтесь к Роберту Мартину и его творению «Чистый код»VolCh
06.03.2017 10:17+1Однозначно, да! Вы не сможете вывести идентичным алгоритмом треугольник и квадрат, поскольку количество вершин уже говорит само за себя. Следовательно, для вывода каждой из этих фигур нужно будет написать разный код.
Смогу. Обычный алгоритм рисования произвольного многоугольника, заданного упорядоченной коллекцией координат вершин с выделением функции рисования отрезка и передачи ей пар вершин в цикле с возможным выделением функции рисования точки. В принципе любую задачу вывода планиметрических фигур или проекций стереометрических можно свести к функции рисования точки, вызываемой из цикла, получающего коллекцию точек для входа. Для разных типов фигур, для разных типов их задания функции получения коллекций точек будут разные, но это стандартные задачи решения геометрических задач численными методами.
symbix
04.03.2017 23:05+1Насчет ООП — подобный вопрос позволяет легко выяснить уровень кандидата.
Джуниор начнет рассказывать про синтаксис языка, ключевые слова class, extends и implements, ну и вспомнит заученную мантру инкпслц-нслдвн-плмрфзм. Сеньор или хороший миддл расскажет про принципы SOLID и подобные вещи, причем не заученное из учебников, а свой опыт.
VolCh
06.03.2017 10:19Вот, кстати, да. Не каждый миддл слышал про SOLID.
Neikist
06.03.2017 10:35Ну, хотя бы слышать должны наверно процентов 90, если не больше. На хабре частенько упоминается в каментах, да и например в «Совершенный код» Макконела упоминается, пусть и не в виде аббревиатуры вроде, а просто пунктами по тексту книги. Выходит принципы довольно известные, раз даже я, пишущий на 1с, которая ни разу не ооп, про них слышал.
VolCh
06.03.2017 11:00Хабр не каждый миддл читает :) Реально люди даже с десятком лет опыта могут про SOLID не знать, ограничиваясь документацией к языку/феймворкам, причем справочной её частью. Ну или слышали абреввиатуру, но содержания не знают. С другой стороны в беседе может оказаться, что сами принципы знают и используют, просто не знают, что это имеет собственно название, за эти десять лет сами пришли к тому, что у класса должна быть единственная ответственность и т. д.
OtshelnikFm
04.03.2017 10:09-3Реже копипастить надо, и тогда будет запоминаться лучше.
rodial
04.03.2017 14:22Нам рассказывали про сортировку пузырьком в институте, даже спрашивали на зачёте.
Но после 5 лет разработки я сходу не вспомню алгоритма.
Почему? Да потому что ни разу за это время она мне не пригодилась, всегда использовал методы/функции языка, и в большинстве случаев они были эффективнее.
Если вдруг мне понадобится написать оптимальную сортировку для набора данных я в первую очередь проанализирую эти данные и постараюсь выбрать наибелее подходящий алгоритм и 99% что это будет НЕ метод пузька.
Так что не считаю что все должны его помнить, врочем то же самое относится и к большинству других алгоритмов.
То, что подобное спрашивают на собеседованиях можно сравнить со случаем если бы вам не продали газету с объявлениями если вы не отгадали часть кроссворда. С очень большой долей вероятности эти знания вам не понадобятся в чтении объявлений (работе).
В тех собеседованиях что я учавствовал было 4 типа проверки знаний:
1) Беседа о реализованных проектах, применённых технологиях, трудностях.
2) Вопросы об основах работы (сеть, протоколы, ОС, браузер).
3) Тестовое задание. При этом алгорим рассказывали сразу, спрашивали как собираешься делать, иногда рассказывали о фейлах других собеседующихся и смотрели на реакцию.
4) Реализация алгоритма/задачки на месте. Опять же алгоритм рассказывали сразу, если была необходимость. Смотрели как реализуешь, просили проговаривать мысли вслух.
Эти подходы были отдельно либо вместе на одном собеседовании.
Именно их считаю правильными.avost
04.03.2017 23:40+2Но после 5 лет разработки я сходу не вспомню алгоритма
Так задача и не стоит в придумывании или вспоминании этого алгоритма. Никому (ну, кроме гугла и яндекса) не интересно помните вы его или нет. Задача стоит в проверке вашей способности реализовать заданный алгоритм. Пузырёк здесь выбран исключительно потому, что он настолько прост, что его трудно забыть. Но если вы с молотилки упали и страдаете ретроградной амнезией, то нет ничего страшного, если вы попросите напомнить суть этого алгоритма.
Stasgar
07.03.2017 15:54Ну пузырек можно сказать, даже ни разу не изучая ни единого алгоритма сортировки — напишет любой человек. Он слишком очевиден и «в лоб» так сказать. Сравним по сложности с поиском max/min эл-та в массиве, путем банального перебора с записью в переменную.
symbix
04.03.2017 23:12+1Надо не запоминать, а понимать.
Я не собираюсь забивать себе голову всякой ерундой, которая мне нужна раз в три года. Ну или в случае алгоритма сортировки пузырьком — не понадобится никогда.
То же самое касается нечасто используемых функций/методов стандартных библиотек. Зачем мне это помнить, если IDE подскажет?
Впрочем, пузырек или merge sort я легко воспроизведу — суть понятна из названий. А вот quicksort я хрен вспомню просто так. В общих чертах что-то припоминаю, не более того. Но мне это никогда не понадобится, потому что уже есть эффективные стандартные реализации.
DistortNeo
04.03.2017 23:44Вот, написал за 5 минут:
void qsort(T *arr, int left, int right) { if (left >= right) return; int l = left, r = right; T pivot = arr[(left + right) / 2]; while (left < right) { while (arr[l] < pivot) l++; while (arr[r] > pivot) r--; if (l < r) swap(arr[l++], arr[r--]); } qsort(arr, left, r); qsort(arr, l, right); }
Помню только потому, что раньше (в 90-е) он не являлся стандартным алгоритмом, и его постоянно приходилось писать.
Сейчас, понятное дело, только IDE, только библиотеки.
symbix
05.03.2017 00:39В 90-е я был школьником, на найденной дискетке с турбо-бейсиком (это где-то 93-й год был, или 94-й) была реализация quicksort без рекурсии. Не то, чтобы я знал и про рекурсивную тогда, но разобрался.
А щас вот нифига не помню, ну, то есть, теперь-то вспомнил :)
wataru
05.03.2017 01:09И тут сразу 2 ошибки: Первое — цикл while у вас по left/right, а внутри меняються l и r.
Второе — может быть случай, когда задается массив из двух чисел, то один из указателей не будет сдвинут и в рекурсивном вызове вы с теми же параметрами вызовитесь и будет бесконечная рекурсия.
Это хороший пример — вызубрить эту реализацию сложно, можно знак перепутать легко. Но если понимать, что тут происходит, да еще и с подсказкой интервьювера, эту ошибку очень просто отловить.
DistortNeo
05.03.2017 01:20И тут сразу 2 ошибки: Первое — цикл while у вас по left/right, а внутри меняються l и r.
Верно. У меня сначала не было
lиr, я изменял значенияleftиright, но потом я вспомнил, что старые значенияleftиrightнужно сохранить, и ввёл две новые переменные, забыв исправить условие.
Второе — может быть случай, когда задается массив из двух чисел, то один из указателей не будет сдвинут и в рекурсивном вызове вы с теми же параметрами вызовитесь и будет бесконечная рекурсия.
Да, вместо
l < rнужно использоватьl <= r. Один раз накалывался.
Впрочем, если в начале функции делать проверку на длину массива и при длине меньше 8 вызывать простую сортировку, то эта ошибка бы не вылезла.
symbix
05.03.2017 02:03О, а я, кстати, не заметил про left/l и right/r. :) По общей картинке алгоритм вспомнил и не обратил внимания — в голове "прочитал" там именно l и r.
Думаю, если человек это пишет не молча, а рассуждая вслух, то понятно, что не вызубрил.
Кстати, вопрос именования, если назвать не left/right, а, скажем, low/high, ошибка сразу очевиднее. Вот на эту тему можно было бы и побеседовать.
OtshelnikFm
05.03.2017 10:52Понимать надо. Согласен.
Но всё надо «пропускать через руки». Простое понимание, от того что вы прочитали и скопипастили — не поможет. Эффективней для запоминания — это набрать руками. Возможно выше я не совсем точно определил границы — не только алгоритмы, но и функции и методы — все нужно набирать руками, а не копипастить.symbix
06.03.2017 00:08А, вы про это. Честно говоря, не припоминаю ситуаций, когда я что-то копипастил.
Разве что когда была необходимость выполнить функции сисадмина и настроить какой-нибудь там exim или named, в детали которого я погружаться не желаю и хочу чтобы просто все заработало.
А с программированием — ну не знаю, не помню таких случаев. Гуглишь-то какие-то детали и идею, а реализацию все равно писать самому под свои условия и свою архитектуру. Единственный, наверное, случай, это когда изучаю что-то совсем для себя новое, читаю какой-нибудь онлайн-туториал — тогда могу скопипастить пример и уже его править, чтобы разобраться, как это повлияет. Да и то сейчас для такого чаще есть возможность склонировать гит-репозиторий.
norlin
04.03.2017 10:32Те несколько раз, когда я собеседовал людей по Javascript, спрашивал лишь самые базовые вещи — приведение типов, hoisting и замыкания – всё на базе подготовленых мной примеров кода, не требуя никаких формальных определений.
vdshat
04.03.2017 10:41+4Основное на интервью — выяснить может ли человек мыслить и в каком направлении. Прежде всего ты выбираешь члена команды. Смотришь впишется или нет, а то бывали настолько с оригинальным мышлением кандидаты, что понять не сразу удавалось, что он имеет ввиду.
Гуглокодеров видно сразу и не по незнанию алгоритмов, а по неумению подходить к решению задачи. Я предлагаю что-то нестандартное для человека, например, спроектировать описание комнаты или описать процесс забивания гвоздя в стену. Умиляют ответы типа я же не строитель. Т.е абстрактное мышление отсутствует как область. Но кодеров, например, раньше готовило ПТУ, а если у вас высшее образование, то и должны уметь больше. И не писать на листочке, а проверяю способность излагать свои мысли.
Но знание алгоритмов тоже мало что показывает. Например, большинство олимпиадников, которые знают кучу алгоритмов, в жизни слабо ориентируются, т.к. она нелогичная. Опять же прогресс не стоит на месте и скорей всего есть более совершенная реализация и как инженеру вам лучше ее использовать. Но ориентироваться быстро в предметной области нужно обязательно
lookid
04.03.2017 10:44+4Давать задания дольше, чем на 1 час — нельзя, так как личное время важно.
Просить написать код на листочке — нельзя, т.к. на работе пишут не на листочке.
Спрашивать какое-то API — нельзя, так как оно может меняться и зубрить не имеет смысла.
Спрашивать Кнута-Кормена — нельзя, так как выветрилось из головы еще на 2 курсе.
Спрашивать ООП нельзя — так как для компилятора это не играет никакой роли.
Спрашивать Design Patterns нельзя — так как кроме синглтона, фабрики, обзервера, команды и адаптера не используется.
Надо было начинать твиты с фразы "Привет, я программист и я не умею программировать. Просто повезло, что железо мощное и оперативки много. Поэтому мой код работает и зарабатывает".am-amotion-city
04.03.2017 10:56Привет, я программист и я не умею программировать. Просто повезло, что железо мощное и оперативки много. Поэтому мой код работает и зарабатывает.
Так это как раз легко пойдет эпиграфом к биографии DHH :)
Удивительно в последнее время: как только адекватный комментарий — так у его автора карма -?. Тенденция.
Suvitruf
04.03.2017 11:33Спрашивать ООП нельзя — так как для компилятора это не играет никакой роли
Зато для других разработчиков в команде играет.
Спрашивать какое-то API — нельзя, так как оно может меняться и зубрить не имеет смысла.
Если проект пилится на конкретной версии, то почему нет? Как вы и сами сказали, от версии к версии многое меняется, посему знать различия довольно полезно.
edogs
04.03.2017 11:04+3Твиты скорее о том, что какие-то вещи могут выпадать.
А статья пробует преподносить это как то, что «знаю английский со словарем» для переводчика нормально, а ответ программиста на собеседовании «если мне надо знать как цикл пишется я посмотрю, а если мне понадобятся паттерны ооп я их за пять минут найду».
Но если нанимается переводчик, от него ожидается работа по переводу, а если программер, то работа по программированию… если бы нужен специалист по гуглению знаний — такого бы и наняли.
При чем если это выливается в то, что программер 70% времени гуглит как что-то написать — это еще можно терпеть.
Хуже когда наступает этап, когда у программера всплывает необходимость разобраться в чужом коде. Потому что если нагуглить «алгоритм пузырьков» с целью его реализации еще можно, то вот увидев «алгоритм пузырьков» программер не сможет нагуглить что это и будет неделю втыкать и пытаться разобраться спрашивая на форумах.
Именно отсюда появляются люди, которые не могут понимать чужой код и кончается это старым известным «да этот код говно лучше написать новый». Конечно лучше блин, если ты в старый воткнуть не можешь, что тебе еще говорить?
p.s.: И да, создателям языков и людям с 30 летним стажем все эти вещи разумеется знать уже не надо, т.к. они не рядовые программеры и это уже далеко от них, задачи сделать подобное они спускают вниз, а не выполняют сами. Но если ты не руководитель проекта с подчиненными 100 программистами, то утешать себя способностью нагуглить функцию длины строки это бред.Lailore
04.03.2017 12:15Когда переводчик переводит приложение, а не транслирует речь в реал тайм, то нет ничего плохого смотреть в словарь. А вы сравниваете именно это. Много вы программируете в «реалтайм»?
VolCh
04.03.2017 12:20Собственно обычно берут на работу человека, чтобы он программировал в "реалтайме". Если нужен "батч", то берут подрядчика на аутсорс, перекладывая на него ответственность за организацию работы "реалтайм".
Lailore
04.03.2017 12:24Вы не понимаете «реалтайма». Или понимаете, но тогда у вас случайно не возникает классической проблемы «ПОЧЕМУ ЭТОТ СЕМ НЕ ПРОГРАММИРУЕТ?!»?
Кстати, у вас не возникает вопроса, почему книга «Идеальный код» вообще не об алгоритмах?VolCh
04.03.2017 12:40Я понимаю "реалтайм программирование" как реализацию предоставленных алгоритмов в коде за разумное время без дополнительных исследований. Если человеку для написания цикла или инициализации массива в языке, который он позиционирует как свой основной, нужно лезть в "словарь", то вряд ли мне захочется с ним работать.
Потому что она именно о "реалтайм" программировании. О том как идеально реализовать уже решенную алгоритмически задачу без поминутного заглядывания в "словарь", чтобы решив выделить метод не лезть в спеку языка смотреть, а как вообще методы в целевом языке декларируются.
Lailore
04.03.2017 13:14Мы тут не про циклы и массивы. Мы тут про сортировки массива, поиск подстроки в строке и т.п., и да есть уже написанные, и да они почти 100% лучше что ты сможешь написать сам за нормальное время, и да, они оттестированы лучше.
VolCh
04.03.2017 13:30Обычно всё это в стандартной библиотеки языка. Никто не запрещает её использовать обычно. Равно как де-юре не стандартные, но очень популярные. А вот тратить время на исследование вопроса есть ли готовая библиотека для задачи, сколько их, какая из них лучше для проекта подходит и т. п. уже выходит за рамки "реалтайм" программирования, если своя наивная реализация, которую потом можно будет оптимизировать или заменить на стороннюю, пишется за полчаса. Тем более, что, как правило, вопрос о включении стороннего кода в проект это не ответственность отдельного разработчика и даже не команды разработчиков и(или) её лидера. Как минимум ещё юристы должны дать добро, что предполагаемый сценарий использования не нарушает лицензии и прочих прав третьих лиц, возможно бухгалтера на баланс поставить и т. п.
Lailore
04.03.2017 13:45Вы работаете на «потогонке»? Ваш реал тайм это конвеер. Я бы не хотел работать в таком месте. Свой пул потоков тоже можно написать за пол часа, свой ди контейнер и т.п.
VolCh
04.03.2017 14:08Нет, не конвейер точно. Но если мне говорят (или я кому-то говорю), что надо какую-то получасовую фичу взять и сделать "вчера", то это значит что времени на гугление нет, надо брать и делать, чтоб работало. Потом можно заниматься исследованиями, поисками более красивых/быстрых/меньших решений, но сейчас надо брать и делать способом, не требующем исследований.
Это не запрет на использование стороннего кода и просмотр документации, можно использовать уже используемый, можно вводить хорошо знакомый, можно смотреть в документацию, но нельзя тратить время на исследования если наивная самостоятельная реализация не занимает много времени, а оценка времени на исследования значительно больше. Никто не скажет слова против, если на просьбу оценить сроки скажешь "дайте минутку, я погуглю, может есть готовое и простое в использовании решение и сделаю на его базе за 15 минут, а если нет, то за полчаса сделаю сам", но если через минуту скажешь "вроде нашел что-то похоже, но надо полчаса на то, чтобы разобраться подходит или нет технически, да лицензия не входит в список одобренных юристами", то скажут "пиши сам",
Lailore
04.03.2017 14:23+4фичу взять и сделать «вчера». Если такое говорит начальник(давно это было), то я отвечал, что пусть приходит вчера, и все будет. )
kmu1990
04.03.2017 13:22+1Вы про эту книгу: Идеальный код Орам Э., Уилсон Г.? Книга, конечно, не целиком об алгоритмах, но алгоритмам там посвящено какое-то место. То, что инженеру кроме алгоритмов приходится иметь дело еще с кучей других вещей, не аргумент в пользу того, что алгоритмы на каком-то уровне он знать не должен, а наличие книги, которая не посвящена алгоритмам целиком вряд ли показатель хоть чего-то.
Lailore
04.03.2017 13:47Я о том, что зубрежка алгоритмов ничего в преспективе не даст. Давайте не лгать друг другу, мы с вами не математики, что бы на коленке за пол часа смочь написать крутой способ сортировки.
kmu1990
04.03.2017 14:05+1Зубрить не нужно, нужно понимать идеи (divide-and-conquer, dp, two pointers, основные шаги простых алгоритмов, например, merge двух отсортированных списков и, соответственно, merge sort, partition и, соответственно, quick sort, как работает heap и, соответственно, heap sort и т. д.).
Касательно «не математики», то я был на защите магистерской работы одного теоретика, он придумал алгоритм для какой-то задачи, который улучшал предыдущие известные алгоритмы. Так вот на защите его спросили, а сравнивал ли он реализацию своего алгоритма с другими, на что он ответил, что он не силен в реализации, так что алогритм он придумал, но реализовывать его не стал. Т. е. математики, очевидно, тоже не всегда могут реализовывать свои алгоритмы. Вопрос, а кто же тогда будет реализовывать эти алгоритмы?
Ну и как факт, за пол часа я вполне могу реализовать Heap Sort, Merge Sort или Quick Sort. Не то чтобы это требовалось мне часто, но если вы понимаете алгоритм, то не понятно какие проблемы могут быть с тем, что бы его закодить. Код для Heap Sort может быть довольно массивным, но как не суметь реализовать простой Merge Sort, я не очень понимаю.Lailore
04.03.2017 14:20Реализовывать будут заинтересованные в это люди, тогда когда это и есть бизнес задача. Например Кармак, когда писал свой движок читал и тырил алгоритмы и идеи у все что только можно, и это хорошо.
kmu1990
04.03.2017 14:30+2Т. е. вы думаете, что инженер, который не может справиться с классической, хорошо изученной задачей, у которой есть простое решение, вдруг магическим образом справится с более сложной задачей, когда она станет бизнес требованием? Я очень сильно в этом сомневаюсь.
Не каждый кандидат приходящий в компанию на собеседование — Кармак. И оценивать кандидатов так, как-будто все они «как Кармак» — смешно и не дальновидно. Более того, то, что вы можете найти решение каких-то задач в Интернет, не значит, что вы сможете найти там адекватное решение любой задачи, т. е. не значит, что вы не должны уметь решать задачи самостоятельно.
Элементарно, чтобы оценить найденное на просторах Интернет решение вы уже должны обладать каким-то уровнем понимания, чтобы проверить его корректность и чтобы оценить его эффективность.
VMichael
04.03.2017 14:30Зубрить не нужно, нужно понимать идеи (divide-and-conquer, dp, two pointers, основные шаги простых алгоритмов, например, merge двух отсортированных списков и, соответственно, merge sort, partition и, соответственно, quick sort, как работает heap и, соответственно, heap sort и т. д.).
А зачем, ели таких задач нет в реальной работе?
Зачем тратить время на абстрактные понятия?
По моему опыту набора людей. Люди, которые все это знают, также как и люди, любящие решать некие «головоломковые, не стандартные» задачки, не работают гарантированно производительнее других людей. Все выясняется потом в процессе работы.greendimka
04.03.2017 14:35Да, люди, которые знают мало, работают с тем же темпом, что и те, которые знают много. Знания, они, в среднем, слабо влияют на скорость нажатия клавиш.
Но всё упирается в проект. Если нужна посадочная страница, которая поживёт месяц, то вполне сгодится мало знающий. Если же это серьёзный проект, то малое количество знаний выливается в крупное количество бабла при масштабировании проекта.VolCh
04.03.2017 14:39С посадочной не всё просто. Если средний пользователь из-за низких знаний разработчика не дожидается загрузки страницы и закрывает её, то очень много бабла на продвижение может оказаться потраченным впустую.
greendimka
04.03.2017 14:49Согласен на все 100%. Посадочная — это всего лишь утрированный пример того, как разнятся проекты. Но вы правильно подметили — даже для посадочной отсутствие каких-то знаний выливается в убыток.
VMichael
04.03.2017 14:45Так я про это и говорю.
Я считаю не нужно грузить человека на собеседованиях понятиями, которые ему в работе не нужны.
Вы же знаете, какой работой предполагаете занять кандидата.
Если он будет писать свою СУБД и реализовывать в ней сортировку, спрашивайте про сортировки.
А если человеку для сортировки данных нужно знать ORDER BY, то так его и спрашивайте. :)greendimka
04.03.2017 14:58Согласен. Просто ваш комментарий прозвучал так, будто те, кто знает больше и подходит к работе с любовью — чем-то хуже, не стоит с ними связываться. Как то так.
botyaslonim
04.03.2017 15:00На серьёзных проектах существует архитектор: человек заведомо большего кругозора и уровня знаний, чем разработчик. Также существует промежуточные релизы, совещания, тесты на обеих сторонах и т.д.
Как человек, работавший и над маленькими, и над большими проектам, могу сказать, что маленькие не взлетают чаще именно из-за концентрации рисков на 1 человеке. В то время как большой проект — это система, её завалить сложнее.greendimka
04.03.2017 15:15+3В России существует Путин, а в подъездах всё равно грязно :) Сколько раз я видел, как компании заменяли своих архитекторов или тимлидов, думая что вот новый то сейчас всё разрулит. И при этом набирали самых дешевых индийских программистов. И вот, значит, архитектор всё обдумывает, архитектуру строит, отказоустойчивость закладывает… А какой-нибудь Рахул или Радж: утечка памяти тут, утечка память там… закрыть дескриптор файла? Не, моя такое не слысала. Короче, вы поняли…
guai
05.03.2017 03:24почему это «заведомо»?
у разных людей вполне могут быть не пересекающиеся области компетенции, тем и ценны
если ваш лид считает, что лучше всех разбирается во всем — то он… чудак
самое главное умение лида должно состоять в том, чтобы сильные стороны членов своей команды выпятить, а слабые скомпенсировать
kmu1990
04.03.2017 14:44+11. То что таких задач нет в вашей практике не значит, что их нет ни у кого. Если вы нашли способ оценивать людей на собеседовании, который для вас работает — ок. Но это не значит, что спрашивать простые алгоритмические задачи на собеседованиях для других — это плохо или не правильно.
2. Перед собеседованиями в одну не безизвестную компанию, где спрашивают простые алгоритмические задачи, меня специально предупреждали, что главное не решение, а мысленный процесс. Т. е. то, что они оценивают — это как вы ищите решение задачи. И, в этом смысле, алгоритмические задачи ничем не хуже любых других.
3. Сортировка и алгоритмы сортировки — не абстракные понятия. Идеи используемые в различных алгоритмах, конечно, абстрактны, но конкретных примеров их применения вполне достаточно. Так что, не смотря на абстрактность понятий, польза от них вполне конкретна.VMichael
04.03.2017 14:51Я и не говорил, что таких задач нет ни у кого.
Я говорил, что:Я считаю не нужно грузить человека на собеседованиях понятиями, которые ему в работе будут не нужны.
.
И из текущей работы можно надергать вопросов для собеседования.
Вообще, поговорить «по душам», для меня лично, конечно, приносит больше пользы всех прочих.
Вопросы, да, помогают разговориться.
Вообще в программировании часто не как у людей.
Вот берут плотника. И спрашивают его про деревообработку.
Берут водителя. Он должен водить машину.
Маляр — красить.
А вот программиста начинают пытать вещами, которые ему в работе в данной конкретной организации будут не нужны, но зато они типа «помогают определить, как мыслит кандидат».kmu1990
04.03.2017 14:59+1Если инженер не может нормально разрабатывать решение проблемы, с которой он раньше не сталкивался, то какой от него толк? Собственно, это и пытаются оценить, и я не вижу ничего плохого в попытке оценить «как мыслит кандидат». В конечном итоге любая инжеренерия — это интеллектуальная работа, мысленный процесс.
VMichael
04.03.2017 15:04А он будет решать такие проблемы в реальности?
В ближайшие n — лет?
Или будет клепать странички однотипные?
Или ваять отчеты для ЦБ?
Для разных задач, разные люди, разные вопросы на собеседовании.
Как разные инструменты.
Пытаюсь продвинуть такую мысль.kmu1990
04.03.2017 15:13Еще раз, я до вас пытаюсь донести мысль, что алгоритмические вопросы на собеседовании оценивают не как кандидат может решать какую-то конкретную задачу, знает ли он какой-то конкретный алгоритм или структуру данных, и уж тем более не знание интерфейса очередной нелепой библиотеки для построения отчетов. Проверяется, как он может искать решение задачи, для которой решения не известно. Проверяется как он может думать, как он может оценивать, может ли обоснованно принимать решения.
Среди моих утверждений не было:
1. только алгоритмические вопросы и никакие другие;
2. алгоритмическиме вопросы работают для всех;
Среди моих утверждений было:
1. нет ничего плохого в попытке оценить мысленный процесс;
2. нет ничего плохого в использовании алгоритмических вопросов для оценки мысленного процесса;
3. алгоритмические задачи встречаются в реальной жизни;
4. инженер — интеллектуальная работа, т. е. он должен уметь искать решение задач.
VolCh
04.03.2017 15:39Если надо брать человека для клепания страничек на базе какого-то фреймворка/CMS, то я буду гонять его по ним.
Если надо брать человека для реализации в коде алгоритмов, придуманных бизнесом/аналитиками/мною, то посмотрю как он реализует хорошо известный алгоритм типа пузырька (если вдруг не знает или забыл, то дам описание), просто чтобы не пугать его реальными алгоритмами оперирующими терминами предметной области, зачастую имеющимися и в разработке, но отличающимися значениями типа "операция" и "транзакция"
Если надо брать человека для придумывания и последующей реализации эффективных алгоритмов для решения задач бизнеса, то будут задачи соответствующие типа в 23:59:59 у пула сущностей в сотни тысяч должно быть одно значение атрибута, при запросе к веб-морде начиная с 00:00:00 должно быть другое, в зависимости от состояния на 23:59:59, а к 2:00:00 новые состояния должны лежать в базе с учетом изменений прошедших за это время, а на расчёт нужно порядка 8 часов.
VMichael
04.03.2017 16:26Отличный подход, здравый смысл (в моем понимании) совершенно с ним согласен.
edogs
04.03.2017 19:29Когда переводчик переводит приложение, а не транслирует речь в реал тайм, то нет ничего плохого смотреть в словарь.
Есть. Две важнейших вещи
1) Это время. Переводчика нанимают на 40 рабочих часов в неделю что бы он 40 рабочих часов в неделю переводил. А не 10 часов переводил, а 30 часов гуглил переводы, имея по факту эффективность в 25% и 75% времени занимаясь не работой, а самообразованием.
2) Это качество. Если переводчику нужно смотреть в словарь, это значит он не понимает ни нюансов перевода этого слова, ни уместных способов применения этих слов, ни контекста, ничего — потому что словарь всего этого не дает. Перевод это нечто большее чем проставление тупого соответствия слов одного языка словам другого.
В случае с программингом (как и с любой другой профой) играют роль те же факторы.
Видите ли, именно поэтому компании предпочитают нанимать специалистов, да еще и с опытом, а не новичков вообще ничего не знающих (но несомненно умеющих нагуглить как перевести с урду на латынь). Все промежуточные варианты это по сути рыба второй свежести.
Какие-то узкоспециальные вещи можно не знать, какие-то могут выпасть из памяти, но это должно быть редчайшим исключением, а не предметом для гордости с аргументом наизготовку «если что нагуглить», потому что нагуглить может кто угодно, но профессионализм тогда в чем?michael_vostrikov
04.03.2017 19:42В том, чтобы уметь это применить. Знания в голове это тоже своего рода гугл, только встроенный.
edogs
04.03.2017 19:50Нельзя качественно и быстро применять то, с чем незнаком.
А если это у Вас в гугле вместо головы, то Вы с этим незнакомы.michael_vostrikov
04.03.2017 20:03А вот прочитаю, и буду знаком. После прочтения ведь оно появится в голове. Естественно, это не с каждой задачей работает, есть такие, с которыми даже с гуглом надо не один час разбираться. Но и встречаются они реже, чем простые.
edogs
04.03.2017 20:18+1Не-а.
Вопрос риторический. И чем Вы тогда лучше любого дворника? Он тоже прочитает и будет знаком, у него тоже появится это в голове.
В свое время знаковой строкой в резюме было «легко обучаем», это означало что работник не фига не знает и надеется на авось, на то что его обучат, на то что пронесет. Сейчас это звучит как «знаю английский со словарем» и «нагуглю если что».
Это эпик фэил, и самая трагедия тут в том, что человек считающий что «он все нагуглит, а значит он и есть профессионал в переводе» искренне убежден в своей правоте.
90% выпускников вузов носители теории «если что нагуглю я крут» с прицелом на зарплату «овер 3к в месяц» так и остаются за бортом пару лет, пока в голове что-то не проясняется.
Погуглите на эту тему, будете знакомы:)michael_vostrikov
04.03.2017 20:29И чем Вы тогда лучше любого дворника? Он тоже прочитает и будет знаком, у него тоже появится это в голове.
Тем, что умею это применять.
и самая трагедия тут в том, что человек считающий что "он все нагуглит"
Считать так тоже неправильно. Поэтому я и написал, что задачи бывают разные.
edogs
04.03.2017 21:12Тем, что умею это применять.
Не прочитав? Уже умеете? Это сильно:)michael_vostrikov
05.03.2017 08:10Диалог был такой:
— А вот прочитаю, и буду знаком.
— И чем Вы тогда лучше любого дворника? Он тоже прочитает и будет знаком.
— Тем, что умею это применять.Где вы увидели, что "не прочитав"?
edogs
05.03.2017 18:51Перечитайте внимательнее.
В последней фразы Вы утверждаете что умеете это применять, хотя из первой фразы прямо следует что Вы еще не прочитали.michael_vostrikov
05.03.2017 22:35Последняя фраза подразумевает действия после прочтения, потому что нельзя применять то, чего еще нет. В общем-то весь этот тред подразумевает знания, уже полученные из гугла. А первая и вторая подразумевают условное наклонение, а не изъявительное. Поэтому третья это действие после выполнения условий.
И чем Вы тогда лучше любого дворника? Он тоже [может прочитать] и будет знаком, у него тоже появится это в голове.
Тем, что умею [потом] это [которое появилось] применять.
ClearAirTurbulence
04.03.2017 22:31+2Вот я переводчик. Могу без словаря. Ввиду того, что изучал с детства, словарный запас у меня неплохой — например, вот тут у меня результат стабильно top 5%.
При этом, если перевод не устный, я постоянно пользуюсь словарем, если исходник, кончено, не quick brown fox, а что-то посерьезнее.
Хороший плиточник сможет положить плитку без лазерного уровня, но зачем, если с ним быстрее и лучше?edogs
05.03.2017 19:03+1А при чем тут лазерный уровень? Лазерный уровень это компьютер на котором Вы можете набирать перевод, вместо того что бы выбивать перевод на скале.
В терминах плиточников это будет по другому — Вы пригласили бригаду класть плитку и вот они приезжают в количестве 5 человек и оппа… достают ноуты, один гуглит какую плитку лучше купить, другой какой раствор лучше купить, третий как его лучше класть, четвертый напоминаем им что есть еще яндекс и бинг.
Эдакая бригада плиточников-хипстеров :)
Ваш пример непонятен, т.к. непонятно что для Вас не «brown fox» и что собственно означают top 5% в топ тесте (мы не переводчики и особо не задумываясь в топ 10% попали, при этом сделав несколько ошибок).
Antelle
06.03.2017 01:09Оффтопик: почему вы всегда пишете "мы" и говорите о себе во множественном числе?
VMichael
04.03.2017 13:58+1Конечно лучше блин, если ты в старый воткнуть не можешь, что тебе еще говорить?
У меня лично и у нас, в команде, были такие случаи неоднократно, когда мы переписывали старый код полностью, потому, что воткнуться в его работу, для того, чтобы корректно внести доработку, было очень затратно.
Поэтому не могу согласится с этой фразой.edogs
04.03.2017 19:35+1Зависит конечно от ситуации, но если речь не о г-но проекте из трех страничек, то это крайне редко хорошая мысль.
байка про мальчикаРодился мальчик, а у него вместо пупка гайка. Приходит он к бабке
поветухе и говорит: Слышь бабуль вот все дети как дети, а у меня гайка
вместо пупка. Что делать?
Это длинная история.
Пойдешь за тридевять земель в тридевятое царство, будешь идти тридцать
три года три дня и три месяца. Сносишь трое железных сопогов, сломаешь
трое железных посохов. Придешь туда, увидишь дуб на дубе будет ларец в
ларце будет заяц в зайце будет утка в утке будет яйцо и в яйце найдешь
то, что тебе надо.
Ну и пошел мальчик за тридевять земель в тридевятое царство, шел
тридцать три года три дня и три месяца. Сносил трое железных сапогов,
сломал трое железных посохов. Пришел туда, дуб завалил, ларец сломал
зайца убил, утку убил яйцо ломает а там гаичный ключ внутри.
Он гайку на пупке откручивает, у него жопа отваливается.
Мораль: Не ищи на жопу приключений.michael_vostrikov
04.03.2017 19:42Потому что интерфейс.
edogs
04.03.2017 19:52Нет, нет, это по хипстерски, в оригинале ответ звучит «потому что гладиолус»
michael_vostrikov
04.03.2017 20:06Переформулирую. Можно убрать старый код, не разбираясь в нем, и написать новый, если знать, что он получает на вход и возвращает на выходе.
edogs
04.03.2017 20:11Нельзя. Мальчик уже пытался и чем это кончилось? Чуть детальнее ответили ниже в комменте для VMichael
michael_vostrikov
04.03.2017 21:04Ваш мальчик это абстрактная придуманная байка. А в проектах работает вполне реальный код. У которого есть вход, выход, и побочные эффекты.
Пример. У вас есть функция генерации отчетаGenerateReportByLocations, и там что-то типа такого:
string sql = "DECLARE @TransportReturnOrdersID varchar(10), @ReceivingOn datetime, @sourceLocationName varchar(255), @OldsourceLocationName varchar(255), @targetLocationName varchar(255), @ItemName varchar(100), @OldItemName varchar(100), @EstimatedQuantity int, @ActualQuantity int, @Variance int, "; sql += "@SubTotalEstimatedQuantity int, @SubTotalActualQuantity int, @SubTotalVariance int, @TotalEstimatedQuantity int, @TotalActualQuantity int, @TotalVariance int "; ...
По ТЗ, готовому отчету, и входным параметрам функции можно написать ее заново, не разбираясь в этой куче кода.edogs
04.03.2017 21:15+1У которого есть вход, выход, и побочные эффекты
И вот их-то Вы никогда не предугадаете.
Даже если предположить что вход и выход и контекст 100% полно и корректно описаны, что бывает только в сказках.
По ТЗ, готовому отчету, и входным параметрам функции можно написать ее заново, не разбираясь в этой куче кода.
Ее писать не надо, она уже есть.
А написать Вы можете только аналог, аналог будет работать аналогично. Но не так же. Например, в нем может не оказаться гаечки и жопа таки отвалится:)VMichael
04.03.2017 21:25+1Уже писал ниже, повторюсь.
Не должна жопа быть связана с гаечкой.
И это приходится переделывать.
Без знания, каким таким образом связалась жопа с гаечкой.
Пупок должен быть и жопа должна работать должным образом, без ненужных связей с гаечкой.
Вот это и делается, что бы все работало как надо.
Пойдет такая аналогия?
P\S Полностью переделать процедуру возвращающую данные — это вообще рутинная операция при оптимизации работы.edogs
04.03.2017 21:26Уже писал ниже, повторюсь.
Уже опровергли ниже, повторяться не будем, можете прочитать там:)
Полностью переделать процедуру возвращающую данные — это вообще рутинная операция при оптимизации работы
При условии что Вы понимаете что, как, в каком контексте и почему делает эта процедура. А как мы с Вами выше уже решили — Вы этого не понимаете, потому что Вам слишком сложно разбираться с этим.
michael_vostrikov
05.03.2017 08:24И вот их-то Вы никогда не предугадаете.
Их не надо предугадывать. Если в алгоритме нет ни одного insert или там присвоений глобальным переменным, то не важно, что там происходит локально. Если есть, можно поискать по названиям.
В любом случае их надо убирать. Если есть тесты, то проблемы нет. Запустили тесты, проверили, что и где отвалилось. Если нет, то можно основное проверить руками. В крайнем случае ошибка все равно себя проявит рано или поздно. А если не проявит, то и значит и неважно.
Не раз делал рефакторинг полным переписыванием на основе интерфейса/описания/целей. Никакой проблемы нет. А если код настолько критичный, и при этом такого качества, что его трогать нельзя, то проблема явно не со способом рефакторинга.
Ее писать не надо, она уже есть.
Есть функция, которая работает неправильно. Либо из-за ошибки, либо из-за изменившихся требований. Иначе бы никто в нее не полез.
отвалится
Ну если у вас в коде от каждого изменения что-то отваливается, значит у вас плохой код.
tyomitch
05.03.2017 11:30+1Их не надо предугадывать. Если в алгоритме нет ни одного insert или там присвоений глобальным переменным, то не важно, что там происходит локально. Если есть, можно поискать по названиям.
Если в алгоритме вызывается другая функция, внутри которой третья, и т.д. на десять уровней вложенности, и десятая функция при каких-то определённых условиях меняет значения глобальных переменных — то очень долго вы будете искать такой побочный эффект поиском по коду.
(Например, программисту может показаться, что уprintfнет побочных эффектов; но на самом деле она в случае ошибки изменяетerrno, и раз в сто лет это может внести в код трудновыявимый баг.)michael_vostrikov
05.03.2017 14:39то очень долго вы будете искать такой побочный эффект поиском по коду
Я и при разборе непонятного кода буду долго искать такой побочный эффект. Не лазить же на 10 уровней вложенности в каждую функцию. Так что здесь нет разницы.
Тут есть небольшая путаница. "Что делает код" имеет разное значение в зависимости от контекста. В одном случае это цель/результат — зачем он это делает. В другом средство — какие действия он делает. Если я знаю цель, но не понимаю средства, я могу просто взять другие средства — полностью переписать код. Если я не знаю цель, то просто переписать конечно не получится.
knekrasov
05.03.2017 13:33+1На эту тему есть отличная статья Джоэла Спольски
Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.
VMichael
04.03.2017 19:57Потому, что бывают очень работящие программисты, которые делают горы кода для достижения цели.
И зная, что на входе, а что нужно получить на выходе, бывает (редко конечно) проще реализовать заново все.
Вот, статья, например: https://habrahabr.ru/post/321644/
Человек, вероятно гениально и остроумно решил вопрос, фильтрации данных по полю, который может и решать то не стоило.
Бывает, не так редко, что вместо того, что бы использовать ключ, выводят набор неких правил, что бы определить строку.
Да разное бывает.
Не говорю, что бы это было прямо таки правило, но бывает, бывает, как никогда не говори никогда, знаете ли.
P\S: Пример с мальчиком не убедил. Переделывать или разбираться со старым кодом, ради того, что бы «отвернуть гайку», у меня не было столько свободного времени, обычно очередь задач висела над головой.edogs
04.03.2017 20:10И зная, что на входе, а что нужно получить на выходе, бывает
Проблема в том, что такого не бывает:)
Точнее бывает, но только если код простой, изолированный, узкоспециализированный, документированные и… (фанфары) в таком случае в нем разобраться проблемы нет.
Пример с мальчиком не убедил. Переделывать или разбираться со старым кодом, ради того, что бы «отвернуть гайку», у меня не было столько свободного времени, обычно очередь задач висела над головой.
Мальчик не понимал что делает старый код (гайка) и пытался избавиться от него (отвинтить гайку) вероятно заменив на что-то свое (разумеется гениальное), что привело к потере жопы (ибо есть правило — работает, не трогай).
У Вас правда столько времени, что бы разбираться с проблемами вызванными отключением старого кода? Или с проблемами вызванными отличием старого кода от нового в каких-то нюансах?VMichael
04.03.2017 20:48Мальчик не понимал что делает старый код (гайка) и пытался избавиться от него (отвинтить гайку) вероятно заменив на что-то свое (разумеется гениальное), что привело к потере жопы (ибо есть правило — работает, не трогай).
Да не должно быть в пупке гайки. И мальчик это понимал. В его контрукции, оказалось что гайку прилепили, что бы очко не отваливалось. Это плохо. Поэтому старую конструкцию выкинуть и сделать по человечески, а не тюнинговать гайку.
Вы игнорируете одни аргументы и цепляетесь к другим. Это… скучно.edogs
04.03.2017 21:26Да не должно быть в пупке гайки. И мальчик это понимал. В его контрукции, оказалось что гайку прилепили, что бы очко не отваливалось. Это плохо. Поэтому старую конструкцию выкинуть и сделать по человечески, а не тюнинговать гайку.
Должно быть или не должно быть — Вы этого знать не можете, пока не разберетесь в коде. А разбираться в нем Вы отказываетесь, потому что Вам это слишком сложно и проще написать свой, чем разбираться в чужом. В этом и проблема.
На идеологию «весь мир разрушим, а потом...» народ уже насмотрелся в масштабах куда побольше чем программинг.
Вы игнорируете одни аргументы и цепляетесь к другим. Это… скучно.
1) Ошибаетесь. 2) На анекдот.ру тогда лучше сходите:)VMichael
04.03.2017 21:34Должно быть или не должно быть — Вы этого знать не можете
Мы говорим про мальчика. У сущности «мальчик» не должно быть.
И заметьте, мальчик это тоже понимал.
На идеологию «весь мир разрушим, а потом...» народ уже насмотрелся в масштабах куда побольше чем программинг.
Это вообще из другой оперы.
Что касается текущего диспута.
Не нужно обобщать и расширять слова.
Сказано: бывают ситуации, когда переделать с «0» легче, чем разбираться и дорабатывать то, что уже накодили ранее. «Бывает», а не «так делаем всегда».
Как говорится: «но есть нюанс».
Но вам хочется ведь поговорить, нет?
Вы взяли за аксиому, что я переделывают код заново, потому, что не понимаю, что делает старый код. Но начальная цитата звучит так: "… воткнуться в его работу, для того, чтобы корректно внести доработку, было очень затратно..." Это значит, что я понимаю, что должен делать код. Но вот реализация того, что должен делать код, сделана так, что мне дешевле сделать заново.
Если у вас таких ситуаций не бывает, значить ваша вселенная лучше, чем вселенная в которой обитаю я. И вы всегда, всегда дорабатываете существующий код и никогда не переделываете его заново. Я рад за вас, хоть кто то работает в отличных условиях.edogs
05.03.2017 19:07Вы взяли за аксиому, что я переделывают код заново, потому, что не понимаю, что делает старый код.
Так и есть, и Вы это лишний раз подтвердили сказав:
Это значит, что я понимаю, что должен делать код
Попробуйте все же осознать разницу между «я понимаю что должен делать код» и «я понимаю что он делает». При этом первого без второго в сложном проекте не будет никогда.VMichael
05.03.2017 22:14Если у вас не было подобных прецедентов в работе, когда легче сделать заново, чем разбираться в предыдущей реализации, то я не знаю как до вас донести эту мысль.
Я говорю так, потому, что неоднократно и я и другие коллеги применяли это в работе и результат был ожидаем, довольны и программисты и заказчики.
Да, хорошо, я допускаю, что все проекты были простыми в вашей классификации.
Но фраза: «легче сделать заново, чем продолжать развивать то, что сделано до нас» имеет право на жизнь. В этом я убежден твердо.
pankraty
06.03.2017 07:58+1Мне больше знакома другая ситуация — 200+ компонентов в проекте, 1 баг, который надо отловить (или небольшое изменение). В этом случае, хочешь не хочешь, надо разобраться в чужом коде, понять, что откуда берется, куда передается дальше, на что влияет и почему (в случае бага) работает не так. А потом вписать свое решение таким образом, чтобы ничего не сломать. Можно, конечно, попробовать переписать с 0, но это совершенно другая задача, с совершенно другими сроками.
VolCh
06.03.2017 10:34В норме должно быть так, что на багрепорт/фичереквест к плохо знакомому коду, нужно взять разумное время на его изучение и после изучения дать оценку насколько быстро можно исправить локальным патчем, насколько он впишется в существующую архитектуру и какова вероятность того, что у применения патча не будет глобальных последствий. Ну и оценку сколько потребует ресурсов переписывание с нуля.
botyaslonim
04.03.2017 14:25+1Кстати, насчёт переводчиков.
Мой преподаватель по китайскому закончил лучший вуз страны по этому направлению, часто занимается синхронными переводами. Однако, когда ему нужно ехать в командировку помогать переводить по какой-то конкретной тематике (например, военным), читает словари соответствующей направленности. Потому что все тонкости держать в голове невозможно.VolCh
04.03.2017 14:40Но не говорит же военным уже в процессе работы: подождите, я сейчас в словарь гляну, не уверен, как правильно перевести "кучность" в военном контексте.
botyaslonim
04.03.2017 14:44+2Думаю, нет. Но вообще переводчики-синхронисты — белая кость, самые лучшие. Уровень знаний и подготовки наивысший из всех возможных.
michael_vostrikov
04.03.2017 19:29Есть переводчик. Когда он встречает необходимость перевода по незнакомой ему тематике, он перед этим читает словари, потом при переводе использует эти знания.
Есть программист. Когда он встречает необходимость решить ранее незнакомую ему задачу, он перед этим ищет информацию, потом во время решения задачи ее использует.VolCh
06.03.2017 11:04На подобных собеседованиях дают задачи, которые должны быть известны каждому программисту, в крайнем случае опишут в терминах, которые должны быть понятны каждому программисту, а смотрят как он её решает при наличии всей нужной информации по задаче, но без предоставления информации по способу решения (синтаксису языка, стандартным библиотекам и т. п.).
DistortNeo
04.03.2017 15:35Хуже когда наступает этап, когда у программера всплывает необходимость разобраться в чужом коде. Потому что если нагуглить «алгоритм пузырьков» с целью его реализации еще можно, то вот увидев «алгоритм пузырьков» программер не сможет нагуглить что это и будет неделю втыкать и пытаться разобраться спрашивая на форумах.
Если алгоритм сортировки вынесен в функцию BubbleSort или даже вынесен в отдельный класс, да ещё и покрыт тестами, то код переписывать не стоит. Если же сортировка пузырьком заинлайнена (ну а что? всего 5 строчек), то такой код должен быть переписан, логично же.
Gorthauer87
04.03.2017 12:11У меня интересный момент был, в условиях собеседования нормально написал merge sort, а с пузырьком затупил наоборот.
rustler2000
04.03.2017 14:17
greendimka
04.03.2017 14:30+10Найдите 10 отличий?
rustler2000
04.03.2017 17:42+3Блин — второй был по матану. Но суть то таже. Раньше не зазорно такие на столе было держать. А счас в гугл нини
Calc
04.03.2017 17:44+3А это очень много от института зависит и преподавателя.
Нам на многих предметах на экзамене разрешалось пользоваться учебниками.
Смысл в том, что если не понимаешь, даже с учебником не решишь.
А был класс преподавателей, которые «УБРАТЬ ВСЁ СО СТОЛА»
Ну а потом люди выходят из института и переносят их правила на внешнюю жизнь.greendimka
06.03.2017 15:06Эти "убрать всё со стола" обычно весьма тупые по-жизни. Ценят способность зубрить, а не мыслить. И по жизни: настолько "правильные" бывают, что убить хочется :)
Помню даже в школе было: по математике получал оценки меньше соседа, потому что задачки решал не так, как в учебнике — учителю было не важно, что я более рациональный способ применял. Не "по ГОСТу" — минус бал!
Или на английском: были девчонки, которые тексты на пересказ зазубривали. На английском никак не говорили, но вот тексты рассказывали буква в букву: что написано, то и вещали. Их классно было перебивать — пересказывать начинали с самого начала :) Но некоторые учителя это ценили.
greendimka
04.03.2017 14:25+5Работаю на европейском рынке, поэтому про Россию конкретно ничего не скажу (в целом уровень знаний тех немногих, с кем работал — очень высокий).
У меня с некоторых пор есть один единственный критерий отбора кандидатов: желание работать и совершенствоваться. Да, я предпочитаю, чтобы человек писал код в Visual Studio. Но если он этот же код пишет быстрее в блокноте — не вопрос. Если человек способен мыслить самостоятельно, то не важно откуда он будет черпать свои знания для роста: курсы, книги, гугл, стэк оувэрфлоу, что угодно.
Такие вещи, как дипломы, сертификаты, корочки — вообще не котируются, т. к. зачастую владельцы оных представляют из себя ходячие энциклопедии без признаков разума. То есть если пример поставленной задачи имеется в их "энциклопедиях" — они это сделают. Если же задача отличается от примера на 5-10%, то решить не могут.
Простым языком: такие люди щеголяют своими знаниями о том, что помидор — ягода. Основываясь на этих знаниях, и опуская стадию мышления, кладут помидор во фруктовый салат.
Сам за последний год получил много корочек, чтобы щеголять перед клиентами, но по моему скромному мнению наличие корочек и наличие знаний не коррелируют.
Что касается "подглядываний" в гугл среди профессионалов: все этим занимаются, никто об этом не говорит :) И я с подозрением отношусь к людям, которые утверждают, что способны удержать в своей голове мануалы по всем используемым технологиям, да еще и в разных версиях. Правда я таких встречал только в историях про "друга моего друга".
Это общие наблюдения. Конечно же бывают исключения из правил.
Vestild
06.03.2017 02:41+1А как вы тестируете «желание работать и совершенствоваться»?
greendimka
06.03.2017 14:49Первые две недели даю человеку самые разношерстные задачи. Но маленькие, чтобы не потратил все две недели на одну. При чём достаточно типовые, т. е. те, на которые решения у нас уже существуют. Но не такие, чтобы найти решение погуглив.
Например для dev-DBA типовым может быть: пара таблиц + автоматизированные таблицы истории + ограничения через constrasints и триггеры + удобные SP/UF + документация для разработчиков. Важный момент: дать как можно больше разного, чтобы не всплыло через полгода, что человек про индексы не слышал :)
И дальше смотрю, как человек работает. Если, например, везде суёт циклы из курсоров, от недостатка знаний, немножко намекаю как можно улучшить. Дальше самое интересное: ленивые делают ровно столько, сколько я сказал, и ровно так, как я сказал (а я же заведомо не говорю идеальное решение). Не ленивые же откапывают, и делают гораздо больше. Так же я обязательно требую пояснить, почему сделано так, или иначе: это сразу "светит" тупо списавших, остальные же расширяют свой и мой кругозор в процессе беседы.
Метод, возможно, и затратный, но очень эффективный. В последствие на, таким образом отобранных ребят, можно положиться.
dgstudio
04.03.2017 14:25-5Спрашивать алгоритмы на собеседовании — это такой способ самоидентификации в обществе, демонстрация принадлежности к социальной группе, как не показывать поворотники при перестроении — то есть, говорить «я п*дор». Просто на собеседовании неловко спросить кандидата, п*дор он или нет, вот они и маскируют вопрос под алгоритмы.
VMichael
04.03.2017 14:39+2Есть такое. :)
Как то собеседовался в контору, связанную с банковской деятельностью.
Начальник отдела спрашивал конкретно по базам данных рабочие вещи.
Начальник управления спрашивал про какие то древние базы данных (на которых он когда то работал), случайно и я работал с этими БД ранее.
Директор департамента спрашивал некую хрень вроде того, что такое байт и пузырьковую сортировку (сам он уже забыл, что такое программировать).
В итоге последний мне не понравился и хотя на работу меня пригласили, поскольку выбор у меня был, я туда не пошел.
khorn_sv
04.03.2017 14:27+3Ну, допустим, что именно спрашивать на собеседовании — вопрос скорее к предметной области и к политике компании.
А по поводу алгоритмов… Опять таки, тенденция сводится к тому, что фреймворки и библиотеки все больше выступают не в роли вспомогательного инструмента, а в роли абстракций над языком. И получается так, что одна группа людей пишет библиотеки, улучшает их, делает их более эргономичными, увеличивает скорость отклика, и совершенно другая группа людей на их основе строит приложения. И, по все правилам, если абстракция хороша, то конечному пользователю фреймворка должно быть глубоко наплевать на то, какими средствами он там внутри устроен.
Ну, то есть, именно к этому же стремятся люди, когда пишут библиотеки и фреймворки — перестать раз за разом реализовывать одни и те же алгоритмы и паттерны. Чтобы ты кнопочку нажал и, «вжух!», магия произошла. Снижение затрат на обучение, снижение затрат на реализацию. В этом как бы весь смысл, чтобы можно было нанять человека, который не знает алгоритмов и ООП, который бы смог приносить прибыль компании.
То есть, с точки зрения компании, даже лучше, если человек заточен под какой-то один инструмент. Его чек от этого можно смело сокращать.
Правда, я хоть и понимаю все это, но все же хочу знать Computer Science как можно лучше, просто потому, что это определенно дает преимущество. В конечном счете, это просто увеличивает сумму чека и позволяет браться за те задачи, которые представляют интерес.
botyaslonim
04.03.2017 14:42Благодарю сообщество за горячее обсуждение вопроса! Даже не ожидал, что будет столько много комментариев к этой заметке.
Прочитал все, и захотелось ещё немного уточнить один важный вопрос.
На собеседованиях одни люди оценивают других людей. И там, и там не машины, которые могут успешно или нет пройти/зачесть определённый тест. Есть известный уровень допуска, когда оценивается не только формализованная сторона вопроса, но и берутся во внимание более абстрактные детали: как именно кандидат решает задачу, какой у него ход мыслей и так далее. Это понятно. Поэтому ни я, ни, думаю, DHH не имеем ввиду крайность вида «всё нагуглю, если надо». Очевидно, если кандидат, допустим, на позицию JS middle не умеет работать с массивом или не знает, что такое замыкание, ему нечего делать на запрашиваемой позиции.
Однако данный топик может навести на мысли про более общий вопрос: как далеко зашёл т.н. «вынос мозга» — делегирование некоторых функций собственного мозга машинам. Кто как, а я могу сказать за себя: дело в том, что со школы у меня что-то вроде «врождённой грамотности» — я с неохотой учил правила русского языка, но достаточно редко ошибался в написании. А вот с приходом интернета появилась странная привычка: часто хочется проверить, не ошибаешься ли ты в написании даже известных, часто употребимых слов. Лёгкость проверки как бы провоцирует подсмотреть, удостовериться. Таким образом вырабатывается нехорошие привычки, которые, наверное, до известной степени нас всех расхолаживают.
VolCh
04.03.2017 14:45Или высвобождают ресурсы на более полезные/интересные/приятные занятия. :)
botyaslonim
04.03.2017 14:52Вообще, по правде говоря, современный разработчик часто сталкивается с требованием «быстренько тут всё изучить, через неделю релиз». Мне вот такую задачу предстоит сделать на следующей неделе: нужно понять, как устроен какой-то неведомый Business-intelligence-фреймворк :) Если и когда меня потом на собеседовании спросят о некоторых сторонах работы с этим фрейморком, я, наверное, сходу завалю вопрос. Однако, скорее всего, к концу следующей неделе решу поставленную передо мной нынешним работодателем задачу.
Другими словами, ввиду требований бизнеса, с одной стороны, и огромного количества инструментов, с другой, средний программист часто вынужден скакать по верхам.
Antelle
05.03.2017 01:35Именно поэтому на правильных собеседованиях и пытаются узнать, насколько человек может соображать, а не проверять глубину познаний во фреймворке X, который через компании будет не нужен. А проверяется это программированием на доске/бумажке. Вообще говоря, проверять можно не алгоритмы, а что-то другое, но т.к. все программисты, в основном, знают алгоритмы, и эти знания нередко пригождаются в работе — проверяют именно их. Ещё, business awareness, тоже знания, которые пригодятся в работе, и это тоже хорошая тема для правильных собеседований.
Проверка возможностей мозга на чём-то другом вызывает недоумение или срачи, потому что есть много людей, для которых прикладная задача нерелевантна и из-за этого получается дискриминация.
vasiliysenin
05.03.2017 01:43Я обычно пишу код не линейно, то есть вставляю новые строки между старых.
Конечно же пример с сортировкой пузырьком надуманный, его нормальный программист напишет и на бумаге. А вот алгоритм в 20-30 строк на бумаге написать уже сложно. Надо будет переписывать на новый листок чтобы вставить новые строки. И возникает вопрос, как определить правильность сложного алгоритма написанного на листочке на псевдокоде, если кандидатов несколько, они решили задачу, то какого выбрать?
Ведь подготовка к собеседованию с написанием алгоритмов на листочках может занять несколько месяцев, а в реальной работе это окажется почти бесполезно потраченное время.wataru
05.03.2017 15:44В адекватных местах дают писать код не на доске/бумажке, а на ноутбуке в текстовом редакторе (не IDE). Автодополнения и подсветки нет, но можно вставлять строчки и копипастить. При этом абсолютной компилябильности кода тоже никто не просит.
Lailore
05.03.2017 20:29Ух, и программировать надо так же. без IDE. Вот объясните мне реальную причину, почему нельзя давать тестовое задание с подсветкой синтаксиса?
wataru
05.03.2017 20:38+1Потому что у всех своя любимая IDE и ее настройки. Всем не угодишь, и это создает нечестные приемущества.
Второе, в случае с IDE логично будет требовать компилирования кода, и тут возможно много проблем. К коду "на доске" требования гораздо меньше — это экономит кучу времени и нервов на интревью. Если бы мне дали выбирать — пиши в IDE и компиль или пиши в блокноте, я бы выбрал блокнот.
Тестовое задание где надо именно написать полностью рабочую программу — это другой формат интервью, который требует на порядок больше времени. Мало задач можно успеть написать и оттестировать за 45 минут да еще и обсудить детали с интервьювером.
sapl
04.03.2017 16:54+1IDE, наборы библиотек, код своих других проектов, доки и даже SoF — это инструменты разработчика, с помощью которых он работает каждый день. Или ему вместо ноута тетрадку с карандашом выдадут для нового проекта?
Почему не акварель, почему карандаш? Хороший программист должен уметь итак и эдак…
lany
04.03.2017 20:10-1Если берёшь человека на прикладное программирование, необязательно требовать с него детали алгоритмов, но надо чтобы он понимал общий смысл. Но при этом не сортировку пузырьком, а ту сортировку, которая используется в его языке программирования. Скажем, если речь о Java, программист обязан знать, что в Arrays.sort() используется TimSort, который похож на mergesort, только прокачанный, он гарантирует стабильность, может жрать дополнительную память, супербыстр, когда массив уже упорядочен в прямом или обратном порядке (тогда требуется n-1 сравнение) и весьма быстр, если массив почти упорядочен. Если человек не знает этого, это дурной знак. Он напишет нагрузочный тест с упорядоченными данными, а в продакшне окажется, что они случайные и сортировка займёт на порядок дольше.
Или, например, TreeMap. Надо знать, что внутри сбалансированное двоичное дерево, которое поддерживается в состоянии, когда его глубина пропорциональна логарифму от числа элементов, значения в левой ветке меньше текущего узла, а в правой больше. Гарантия глубины достигается наличием некоторого инварианта (если кандидат не знает, что такое инвариант, то лесом его), который восстанавливается при вставке и удалении элемента за логарифмическое время. Всё. Можно попросить написать в псевдокоде поиск (это тривиально из вышесказанного), но требовать реализовать вставку на доске неразумно. Также простительно, если кандидат не знает что там конкретно, RB или AVL, например.
VMichael
04.03.2017 21:00Или, например, TreeMap. Надо знать, что внутри сбалансированное двоичное дерево, которое поддерживается в состоянии, когда его глубина пропорциональна логарифму от числа элементов, значения в левой ветке меньше текущего узла, а в правой больше. Гарантия глубины достигается наличием некоторого инварианта (если кандидат не знает, что такое инвариант, то лесом его), который восстанавливается при вставке и удалении элемента за логарифмическое время. Всё.… Также простительно, если кандидат не знает что там конкретно, RB или AVL, например.
Два вопроса:
1. И что, реально много программистов Java это знают (прямо можно тут опрос запулить, интересно будет, если честно ответят)?
2. А что вы разрабатываете (если не секрет, конечно)?lany
05.03.2017 05:23- Да много.
- IntelliJ IDEA.
symbix
05.03.2017 06:00Ага, попались! Не удержусь от оффтопа! :)
Делитесь инсайдом — что там с IDEA-63201? Легендарный тикет уже, 7 лет ждем!
lany
05.03.2017 06:06Ага, "ты ж программист, почини мне компьютер". Ничего, что я не в команде VCS работаю? Мне бы тоже эта фича пригодилась.
symbix
05.03.2017 06:31Ай, я больше в шутку, на самом деле. Я вот больше всего удивляюсь, как вы там сами-то без нее живёте. Единственное практически, из-за чего в консоль ходить приходится.
lany
05.03.2017 06:34-1Ну как-то не очень часто возникает необходимость коммитить один файл по частям. Вам часто?
symbix
05.03.2017 06:43Там в комментариях к тикету был задан такой вопрос, многие отписали свои кейсы, у меня похоже в среднем.
Я люблю атомарные коммиты с четким описанием изменений, так удобнее потом разбираться.
sapl
05.03.2017 09:36+1Блин вы че шутите?
Если к вам идут люди писать IDE для java (причем лучший IDE для java)
так конечно они должны знать как написать реализацию TreeMap, в этом их работа будет — на уровне java api и ниже.
Холивар о том нужно ли серверному разработчику уметь писать сортировку в уме
VMichael
05.03.2017 13:10Если брать не абсолютные цифры, а относительные, то будет:
1. Нет, не много.
Если брать относительные цифры, то сколько программистов работает в компания пишущих продукты уровня IntelliJ IDEA? Отсюда и весь холивар собственно. Вы же не призываете, всем покупать болид формулы 1, для поездки на дачу?lany
06.03.2017 05:52Ну если каждый формошлёп называет себя программистом, то, конечно, немного. Весь вопрос в терминологии.
Neikist
06.03.2017 08:58+1Программисты разные нужны, программисты разные важны. Просто от того что ваше ЧСВ требует называть программистами только тех кто занимается определенными задачами остальные разработчики софта и веб страничек непрограммистами не станут.
symbix
04.03.2017 21:08Зависит от того, над каким проектом ему работать. Я, скажем, знаю внутреннюю реализацию структур данных в PHP, но мне никогда в голову не придет задавать такой вопрос (разве что кандидат будет уж очень хорош, и захочется порыть совсем глубоко). На практике достаточно знать временную сложность и сложность по памяти, а что там внутри, несущественно.
DistortNeo
04.03.2017 22:10Скажем, если речь о Java, программист обязан знать, что в Arrays.sort() используется TimSort
При условии, что сортируются объекты, а не инты, например. Да и нет никакой гарантии, что алгоритм не поменяется в будущем.
В подавляющем числа случаев имеет значение только один факт: асимтотика O (N log N). Всё остальное важно только при написании приложений на Java для высокопроизводительных вычислений, что само по себе уже звучит странно.
Или, например, TreeMap.
Здесь надо знать, что добавление и удаление элементов имеет асимптотику O(log N), и что используется двоичное дерево — из этого следует, например, рандомный доступ к памяти. Всё остальное не имеет значения. RB, AVL — приходилось ли хоть раз их самостоятельно реализовывать и использовать в проектах?
lany
05.03.2017 05:25При условии, что сортируются объекты, а не инты, например.
Да, про это надо знать, естественно.
Да и нет никакой гарантии, что алгоритм не поменяется в будущем.
Да, если алгоритм поменяется, надо быть в курсе. Следить за новостями в своей отрасли — отличительная черта хорошего специалиста.
RB, AVL — приходилось ли хоть раз их самостоятельно реализовывать и использовать в проектах?
Вы невнимательно читали моё сообщение. Я разве сказал, что надо уметь их реализовывать?
symbix
04.03.2017 20:56+2Подобные вопросы — они рассчитаны на джуниоров, на выпускников универа, которые это относительно недавно изучали и еще должны что-то помнить. Задавать им более глубокие вопросы, на которые они все равно не смогут ответить, поскольку ответ требует опыта, которого у них заведомо нет, бессмысленно. Миддлам и сеньорам обычно задают совсем другие вопросы. Когда такие вопросы задают миддлам-сеньорам, то вряд ли ожидают написания на доске синтаксически корректного безошибочного кода — скорее ждут быстрого объяснения алгоритма, так как бы объяснял его коллеге. А если забыл и не получается быстро вспомнить — вести себя так, как бы вместе с коллегой вспоминал (или переизобретал) этот алгоритм, пользуясь доской для пояснения хода мыслей. Если где-то от сеньоров ждут ответа как от джуниора, что сказать, это глупо.
Ждать синтаксически корректного кода на доске (не от джуниора) — тоже величайшая глупость, конечно. Да и требовать высматривать глазами ошибки типа off-by-one — тоже не особо умно: если человек ищет ошибки пристальным взглядом вместо того, чтобы написать тест и воспользоваться отладчиком, он явно непродуктивен. Я бы гораздо больше оценил, если бы рядом с псевдокодом алгоритма был псевдокод юнит-теста.
symbix
04.03.2017 23:23+8И еще один момент.
Собеседование — это не экзамен в институте. Собеседование — это переговоры двух сторон, цель которых — установить, подходят они друг другу или нет.
К сожалению, часто проводится именно экзамен. Это во многом из-за того, что мы тут гики и нерды, и не умеем вести переговоры — ни собеседуемый, ни собеседующий. Много где такое устоялось, но я уверен, что бизнесу это только вредит.
OlegGelezcov
04.03.2017 23:59-1Тоже многие вещи, которые в том числе на хабре приподносят как очевидные, я не знаю, если не гуглить по этим вопросам, это не мешает мне в работе.
Это не относится к собеседованиям, там однозначно подготавливаться придется, то есть прокачать базу надо, а потом можно снова забыть))
Swiftarrow7
05.03.2017 00:13У меня вопрос: А есть ли смысл проверять знания языка на бумаге? Просто, программу пишет программист в среде, которая может давать возможность дополнения или какого-то включения примитивных конструкций! Тут как мне кажется вопрос к компаниям: Нужен кодер, который разбирается в языке (языках) или именно разработчик, который использует язык как инструмент. Как мне кажется при переходе на новые технологии разработчик сможет обучится новом языку или фреймворку. Отсюда напрашивается: Вы хотите просто писать код, или решать, придумывать или находить решение.
P.S. Разработчик в моём понимании — программиста с базовыми знаниями, обучаемый и умеющий находить решения или изобретать велосипеды, если на то появляется потребность. Кодер для меня — это человек который изучил язык и знает как на нём писать, но при этом не обладает хорошими знаниями в своей области и слаб на принятие правильного решения или нахождение этого самого решения, и при обучении новой области у него возникнут проблемы, которые повлекут за собой его увольнение, а компанию на поиск нового сотрудника.VolCh
06.03.2017 11:09Обычно не проверяют знания языка на бумаге. Проверяют на бумаге умение реализовывать известный алгоритм в коде.
LBL
05.03.2017 00:39+4Проверял и буду проверять базовые знания у программиста любого уровня на собеседовании. Уровень кандидатов с каждым годом только падает. Сейчас нормального senior можно найти отсмотрев человек 20, лет 10 назад хватало и 10. Сортировку пузырьком не можешь написать? Факториал циклом и рекурсией не можешь написать? Не знаешь как устроен linked list, array list и когда надо использовать один, а когда второй? Не знаешь, как реализована hash таблица? Если ты говоришь, что знаешь БД и SQL и не знаешь LEFT JOIN и как устроен индекс, то какой ты на хрен программист. Двоечник ты — только и всего. Разработчик ДОЛЖЕН знать базовые структуры данных и базовые алгоритмы, ДОЛЖЕН знать детали языка программирования, ДОЛЖЕН знать ООП/ООД если язык объектно-ориентированный, должен знать многопоточность и основы синхронизации если позиция об этом. Если он при написании Java программы на листочке пропустит точку с запятой в конце — мне все равно, а вот если он спрашивает, что такое рекурсия — извини — до свидания!
symbix
05.03.2017 00:45Если бы у меня на собеседовании на позицию senior спросили, что такое рекурсия, я бы сразу уточнил, не ошибся ли я дверью. :) Все перечисленное должен знать даже джуниор с претензиями на миддла.
Другое дело, что бывают места, где senior-ами считают тех, кто в других местах и на джуниора не потянет.
А вот ваше капс и общий тон комментария — повод задуматься о том, стоит ли вообще устраиваться к вам.
LBL
05.03.2017 00:54+2Я же хитрый. :-) Откуда мне знать уровень человека, который ко мне пришел? У меня же нет ментальных способностей. Поэтому я попрошу написать факториал. Если напишет через цикл, спрошу написать через рекурсию. И вот тут то и узнаю знает ли он что это.
symbix
05.03.2017 01:07-1По-разному понять можно. По резюме, по ссылке на гитхаб. Если на более серьезные вопросы человек ответить не может — тогда, конечно, можно и к таким вопросам перейти, сказать, что на сеньора не тянет и предложить миддла.
Не удивлюсь, если нормальный senior ваше собеседование пройдет, но работать у вас не захочет.
А что к вам такие приходят — так может денег мало предлагаете? ;)
LBL
05.03.2017 01:23+2Приходят разные. И на сеньора часто приходят с малыми знаниями, но с большими амбициями. Резюме — это только повод начать разговор. Гитхаб — спорно. Или вы считаете, что любой программер должен быть там? Конечно я немного утрирую… Но кандидаты у меня и LRU кэш пишут, и очереди реализуют, и Thread пулы делают, и много еще чего интересного, включая алгоритмические задачки.
symbix
05.03.2017 01:55+2Про гитхаб — считаю, что если кандидат прислал ссылку на свой код, демонстрирующий определенный достаточно высокий уровень, то спрашивать его про факториал циклом-рекурсией — это сразу обидеть человека ни за что. (Если не прислал — это, конечно, ни в коем случае не минус.)
Если утрируете — то понятно, сразу бы так и сказали. :)
LBL
05.03.2017 02:02+2На обиженных воду возят! Слишком обидчивые мне зачем? :-) Если прислал ссылку — обязательно посмотрю. Там обычно есть за что зацепиться. ;-)
guai
05.03.2017 03:01+1потому и на 20 человек один, потому что не только специалист, а еще чтоб самодурство терпеть мог, нужен
тоже бы послал к чёрту интервьюера в факториалом
это значит, что он либо не удосужился посмотреть резюме, где указаны проекты посерьёзнее факториала, либо думает, что я вру
в обоих случаях встаёт вопрос, а надо ли это мнеLBL
05.03.2017 13:41+1Мы с вами не работали. Я вас не знаю. Написать в резюме Вы можете все, что угодно. Собственно многие так и делают. То один директор ИТ (!) со штатом в 2 человека (директор и его зам :-)). По сути админ. То другой с опытом в Oracle в 10 лет не знает, что такое 3-я нормальная форма. Следующий типа писал высокопроизводительные программы, что такое Mutex и семафор не знает — копаем глубже вообще про синхронизации ничего не знает. Другой говорит Hadoop знаю, опыт 2 года. Ок, говорю нарисуйте (не напишите!) как устроено преобразование MapReduce. Такой бред начинается.
Так что я лучше пару вопросов по базовым вещам задам, а то может «До свидание!» — чего время терять.guai
05.03.2017 13:56+1я вас тоже не знаю, и вы мне можете лапши навешать про динамично развивающуюся компанию, никаких задержек зарплаты, интересные проекты, перспективы роста.
только соискатель перед вами должен вывернуться наизнанку, а вы перед ним нетknekrasov
05.03.2017 14:00-1Так это вы же пришли на собеседование, разве нет?
Neikist
05.03.2017 14:18+1Так в закрытии вакансии это вы заинтересованы, разве нет?)
knekrasov
05.03.2017 14:39Лично я могу быть и совсем не заинтересован :-)
Контора может загнуться без хороших сотрудников, и это ее дело. Но если вы уже пришли на собеседование, то почему вы не должны отвечать на вопросы?
Соискатель не обязан выворачиваться наизнанку. Выудить эту информацию должен собеседующий.
guai
05.03.2017 14:40+1вот именно что не по повестке на допрос пришел :)
LBL
05.03.2017 15:45-1Но пришел же. Значит интерес есть. :-)
qw1
05.03.2017 19:42-1Соискатель пришёл не знания свои показывать, а лучше разузнать о потенциальном месте работы, посмотреть, какие там люди и условия труда.
Такой вариант не принимается?VolCh
06.03.2017 11:12А пригласили его чтобы понять его уровень, подходит ли он компании в принципе и заявленной зарплате в частности.
"Со" в слов "собеседование" предполагает взаимный обмен информацией.
LBL
05.03.2017 15:09+1Могу лапши навешать. Потому и говорю, что к интервью надо готовиться. И про компанию потрудись разузнать коль уж собираешься все же прийти на собеседование и вопросы подготовь к работодателю. Я, например, всегда оставляю время для ответов на вопросы соискателя.
DistortNeo
05.03.2017 15:27Если к собеседованию надо готовиться, то это уже получается экзамен, а не проверка реальных знаний. Потому что подготовился — ответил на все вопросы — через неделю забыл, потому что на практике не нужно.
LBL
05.03.2017 15:44+1К любой встрече надо готовиться. Что такое реальные знания? Обидно же если знаешь, по подзабыл.
DistortNeo
05.03.2017 15:57К любой встрече надо готовиться.
Ну да, зарядить телефон, ноутбук, проверить, взят ли с собой паспорт, найти адрес на карте, посмотреть пробки.
Что такое реальные знания?
Знания, которые постоянно используются на практике.
Обидно же если знаешь, по подзабыл.
В этом-то и прикол экзаменов: легко сдать практически любой экзамен на пять, просто потратив три дня на подготовку. Но сдача экзамена не означает способность применения знаний на практике.
Поэтому я не понимаю интервьюверов, которые пытаются проверить академические знания. Может быть, для студентов без опыта работы это единственный вариант их хоть как-то оценить, но для программиста со стажем такая проверка будет непоказательна.
LBL
05.03.2017 16:16В этом-то и прикол экзаменов: легко сдать практически любой экзамен на пять, просто потратив три дня на подготовку.
Не согласен. Будучи в свое время разработчиком Java считал, что я ее хорошо знаю. Готовясь к сертификации понял, что знаю ее плохо. Сдав экзамен понял, что теперь знаю хорошо.
Поверьте, программист со стажем затратит на элементарные вопросы 5-10 минут, далее мы покапаем поглубже.DistortNeo
05.03.2017 16:26Ага, есть люди, которые специально ходят по собеседованиям не с целью устроиться на работу, а с целью понять, какие знания сейчас востребованы.
Сдав экзамен понял, что теперь знаю хорошо.
И не забыли через неделю-месяц эти знания за ненадобностью? Везёт!
Я, например, абсолютно уверен в том, что не знаю всех нюансов C++, что не мешает мне на нём программировать. Просто невозможно знать всё.
Поверьте, программист со стажем затратит на элементарные вопросы 5-10 минут, далее мы покапаем поглубже.
Это как в анекдоте: "Вам шашечки или ехать?"
LBL
05.03.2017 17:11Ничего не забыл до сих пор. Сколько лет Вы программируете на C++? Я допускаю, что Вы не знаете все библиотеки, но если остались секреты в самом языке — значит есть куда расти.
Idot
05.03.2017 17:40Увы, сейчас вопрос «Сколько лет Вы программируете на C++?» начинает смахивать на «Сколько лет Вы программируете на PL/1?». Потому что вижу, что с каждым новым стандартом язык всё больше и больше пухнет.
DistortNeo
05.03.2017 20:56> Ничего не забыл до сих пор. Сколько лет Вы программируете на C++? Я допускаю, что Вы не знаете все библиотеки, но если остались секреты в самом языке — значит есть куда расти.
Сколько программирую — не помню. На C++ я пишу не очень много — только низкоуровневый код для обработки изображений, для высокоуровневых же вещей предпочитаю что-нибудь поудобнее. Поэтому ничего, кроме STL, не использую.
Но я в курсе новых стандартов, постоянно слежу за ними и активно использую новые возможности. Но постоянно вылезает что-то интересное: достаточно посмотреть высокорейтинговые вопросы на SO (ссылка), чтобы понять, насколько язык сложен и сколько в нём ещё секретов.
Но знание этих секретов в основной массе только удовлетворяет моё любопытство, потому что в продакшне спорные моменты недопустимы.
VolCh
06.03.2017 11:18Реализовать в коде какой-то алгоритм — повседневная задача для программиста любого уровня. Придумать алгоритм и реализовать его — повседневная задача для программистов среднего и высокого уровня.
Адекватный работодатель не откажет вам, если вы не понимаете задачу "вычислить факториал рекурсией", сообщит формулу (читай — алгоритм вычисления) факториала и определение рекурсии, а потом будет смотреть как вы реализуете уже известный вам алгоритм. Если вы рекурсивные функции постоянно используете, просто не знаете, что они так называются, то справитесь. Если вас концепция, что функция может вызывать саму себя, вводит в ступор, то вряд ли вы подходит даже на джуна.
knekrasov
05.03.2017 13:59+3Ну вопрос-то правильный. Раз обиделись — значит оно вам точно не надо, не ходите туда. Компании нужен не человек с богатым и хрупким внутренним миром, а член команды.
У одного кандидата я однажды спросил, чем отличается интерфейс от абстрактного класса. И он обиделся! И я рад, что он у нас не работает. Потому, что
- если ты работаешь в индустрии и любишь свое дело, то почему пусть даже детские вопросы тебя обижают? я бы ожидал здесь другую эмоцию, но никак не обиду
- почему ты думаешь, что интервьюер изначально знает, насколько ты крут? Знал бы заранее — интервью было бы не нужно.
- почему ты думаешь, что целью вопроса было узнать твои энциклопедические знания? Вопрос мог касаться твоего умения внятно излагать свои мысли.
- или ты заранее ожидаешь пакости от собеседующего? тут уже вопрос адекватности имхо
guai
05.03.2017 14:17-1а мне вот чота кажется, что той компании нужен холоп, и пусть будет благодарен, что собак не спустили.
их много, а меня мало. хочу уважения с порога, а не допроса с пристрастием. хочу с их стороны подготовки к интервью, хочу чтоб не тратили моё время попусту.
а воду они возят пускай на покорных, т.к. обиженные к ним не пойдут, пока совсем не припрёт
пускай дальше тратят время техлидов на проведение 20 собеседований, чтоб закрыть одну несчастную вакансиюknekrasov
05.03.2017 14:34+2Допрос выглядит слегка по-другому. А у вас есть право выбора — и это замечательно!
Вы (гипотетический вы) не пошли работать «холопом» (а на самом деле не подошли в качестве винтика механизму по зарабатыванию денег), а контора не стала трудоустраивать человека, который ей не подошел (не взять человека на работу всегда дешевле, чем его уволить впоследствии).
Все счастливы и цель коммуникации достигнута.guai
05.03.2017 14:46только гипотетическое моё время потрачено впустую, а так да, всё ок
LBL
05.03.2017 15:15+1ну так можно было просто не приходить и остаться на месте если все устраивает.
Кстати, время (читай деньги) компании вы тоже потратили.guai
05.03.2017 15:56+1вы своё время тратите по глупости, и это ваши проблемы. сами себя загнали в невыгодную ситуацию с пониженным демографическим составом нормальных соискателей, а теперь превозмогаете. даже вон остальных пытаетесь убедить, что так и надо.
людям не нравится, когда с ними как с идиотами, особенно когда они реально что-то стоят. с этим тезисом, надеюсь вы спорить не станете, остальное вытекает из него.LBL
05.03.2017 16:07Адекватные люди прекрасно понимают, что они не семи пядей во лбу, не являются Стивами и Биллами, т. к. тогда я бы к ним пошел на собеседование. :-) Вот с этим тезисом я согласен. Что им нравится и что не нравится я узнаю на собеседовании, задавая, в частности, неудобные для них вопросы.
guai
05.03.2017 16:32у вас какое-то альтернативное понимание адекватности. адекватные хорошие специалисты, понимают, что они хорошие, понимают, что их мало, понимают, что, исходя из этого, могут быть более требовательны к той конторе, куда пойдут работать.
адекватные плохие специалисты, а таких, кстати, гораздо меньше (ну потому что им себя еще сравнить не с кем), да, будут понимать, что им надо прогибаться.
ну а вам-то которые нужны?LBL
05.03.2017 17:39+3Альтернативное понимание к вашему — безусловно. Адекватные хорошие специалисты понимают, что, чтобы мне понять насколько они адекватны, насколько они хороши, насколько они специалисты, мне нужно время и ответы на мои вопросы. Понятие «мало» — это не значит, что единицы. Это вот специалистов по COBOL в России единицы. :-) Понятие «прогибания» вообще не уместно. Это рынок. На рынке есть спрос и предложение. В этом плане прогибаются и со стороны спроса, и со стороны предложения. Какой бы вы не были гуру вам же никто не дает миллион в день, хотя вы возможно считаете, что это единственно приемлемая зарплата. Если вы весь такой из себя стержневой, то почему я ничего не знаю про супер успешную компанию GUAI, в которую я бы хотел устроиться работать?
guai
05.03.2017 18:02для того, чтобы вы имели возможность оценить кандидата, есть резюме, в котором всё можно проверить, и дипломы и места работы, позвонить да спросить.
а компании с моим ником вы не знаете потому, что я занимаюсь тем, в чем компетентен, в отличие от вас, набирать людей вы явно не умеетеLBL
05.03.2017 18:31+1Резюме лишь повод начать беседу. Оценивать по резюме пока сам не убедился очень рискованно. Анекдот в тему:
Приходит программист на собеседование, а у него чего там только не написано. И то знает, и это, и там участвовал, и здесь проектировал. Интервьюер сходу говорит «Вы нам подходите! Мы вам даем 10 млн годового дохода в долларах. Пожалуйста, покупайте только Феррари, т.к. на Бугати у нас ездит только Генеральный. Не пользуйтесь, пожалуйста, корпоративным самолетом чаще 2-х раз в неделю для посещения вашей виллы в Испании, которая надеемся будет достаточно скромна, не более 10 млн. долларов»
Кандидат кричит: «Да Вы гоните!». Интервьюер спокойно: «Вы первый начали. Оставьте в резюме только то, что действительно знаете».
Хороших спецов я нанял очень много, работая в разных компаниях. Построил не один отдел с нуля. Кол-во реализованных проектов — огромно. От предыдущих работодателей слышу только хорошие отзывы на бывших своих коллег. Со всеми, которые прошли испытательный срок до сих пор прекрасные отношения.guai
05.03.2017 18:45Хороших спецов я нанял очень много, работая в разных компаниях. Построил не один отдел с нуля. Кол-во реализованных проектов — огромно. От предыдущих работодателей слышу только хорошие отзывы на бывших своих коллег. Со всеми, которые прошли испытательный срок до сих пор прекрасные отношения.
«Да Вы гоните!» :)
напишете пузырек тут в каментах — может и поверю ;)LBL
05.03.2017 18:49void bubbleSort(int[] arr) { for (int i = arr.length - 1; i >= 0; i--) { for (int j = 0; j < i; j++) { if (arr[j] > arr[j + 1]) { int t = arr[j]; arr[j] = arr[j + 1]; arr[j + 1] = t; } } } }
VolCh
06.03.2017 11:22Резюме — лишь первый уровень отсеивания неподходящих кандидатов и обычно с достаточным уровнем объективности проверить можно лишь малую часть, указанной в нём информации..
guai
06.03.2017 12:48А вы пробовали?
Вообще-то если какую-то часть инфы из резюме вы не смогли проверить, помочь вам в этом может сам кандидат.
И самая прелесть тут в том, что этим занимается отдел кадров, а не техлид.VolCh
06.03.2017 14:13Пробовал. Собственно интервью и состоит в проверке сведений указанных кандидатом с помощью кандидата.
Отдел кадров не может проверить, что кандидат знает и умеет делать. Максимум подтвердит факт получения образования, формальный опыт работы, в идеале предоставит/подтвердит рекомендации.
guai
06.03.2017 14:41-1Вы эту ветку каментов читали?
Мой оппонент считает, что техлид должен всё проверять, начиная с сортировки пузырьком и факториала. Я пытаюсь отстоять позицию, что это глупо. Если в резюме есть что-то более серьёзное, и это можно подтвердить. Ну например прошлая должность кандидата была такой же — то это делать лишне и вредно. Мотивирую тем, что если б меня спрашивали пузырек на собеседовании, я б сильно удивился, и скорее всего закончил бы на этом разговор. Т.к. это пустая трата времени соискателя, полных нубов можно отфильтровать удалённо. Такие дела.
Места работы, дипломы — это всё проверяется, причем hrами. Репки на битбакете и гитхабе может тоже глянуть человек того же уровня, что и вакансия — ну и т.п.
Человек утверждает, что у них из 20 соискателей одного берут. По полдня на собеседование. Итого 2 недели времени техлида на вакансию — я думаю, что это офигеть, как много.
Am0ralist
05.03.2017 16:32Ну, если честно, то утверждать, что они свое время тратят по глупости можно лишь посетив их собеседование при четком понимании своего уровня.
А при таком обсуждении понять труднее, ибо а) реальность описать словами сложно, б) все под теми или иными словами понимают немного разное. И получается, что люди даже спорить умудряются, говоря одно и тоже, но разными словами и не верно трактую друг друга.guai
05.03.2017 17:22человек пишет: «Уровень кандидатов с каждым годом только падает»
нигде не падает, а у них падает. я это объяснил бы тем, что репутация о них особая складывается.
не удивительно с такими-то закидонами :)VMichael
05.03.2017 17:45«Уровень кандидатов с каждым годом только падает» — не, ну это общий мем. Он, по моему, всегда звучал.
Бывает звучит так: «На нашу зп уровень кандидатов с каждым годом падает».
Еще бывает так:
— А ты пробовал зп поднять?
— Да бесполезно это, все равно специалиста не найти хорошего!
:)
А если посмотреть еще более издалека, то каждое новое поколение, как то хуже предыдущего (по мнению предыдущего) :)LBL
05.03.2017 18:09И вода 10 лет назад была мокрей. :-)
Есть одна общая проблема. Сейчас зачастую программист мыслит квадратиками, не понимая как этот квадратик устроен. Для ряда задач — так и надо делать — дешево и сердито. И таких спецов большинство. Ребята и девчата, которые имеют писать квадратики, знают внутренности других квадратиков и понимают где можно соединить квадратики беспроблемно, а где придется таки писать серьезный код — вот этих кандидатов стало меньше.VMichael
05.03.2017 18:15Значит на них спроса нет.
Ну есть 100 — 1000 вакансий, где высокие требования с адекватной требованиям компенсацией.
А программистов, не знаю, сотни тысяч, быть может.
И работает принцип Парето. 20% усилий дают 80% результата.
Т.е. усилий большинства хватает на хлеб с маслом, как ни крути.kmu1990
05.03.2017 18:38Вы очень своевольно интерпретируете принцип Парето. Если так, то почему тогда не интерпретировать его как: 20% разработчиков (как раз таки не большинство), создают 80% результата?
VMichael
05.03.2017 19:54Такой вот он многогранный принцип Парето.
Как сказанное вами противоречит тому, что я сказал?
Тех усилий, которые прилагают большинство программистов, хватает этим программистам на хлеб с маслом.
Так яснее?kmu1990
05.03.2017 20:05Всмысле как? Очевидно, 20% не большинство программистов — я вам показал, что этот принцип можно как угодно поворачивать, чтобы подтверждить свою позицию — какой удобный принцип.
Тех усилий, которые прилагают большинство программистов, хватает этим программистам на хлеб с маслом.
Может и яснее, но это своершенно другое утверждение по сравнению с:
Так яснее?И работает принцип Парето. 20% усилий дают 80% результата.
Кроме сомнительного использорвания принципов, у вас еще есть плохая привычка говорить за других (большинству хватает, где вы взяли эту информацию?) и использорвать взятые из воздуха числа (100-1000, сотни тысяч, откуда это?). И про спрос на серьезных кандидатов попадает в эту же кучу, большие компании практически не переставя ищут кандидатов, и не каких папало.VMichael
05.03.2017 20:40Ну я вообще ужасный человек. Даже карма говорит об этом.
Я не говорил о 20% программистов, это ваша фраза.
Я говорю в контексте обсуждения в этой ветке.
Тут говорилось (не мной), что большинство программистов такие сякие, не знают алгоритмов сортировки.
На что я и сказал, значит этому большинству, хватает на хлеб с маслом.
Они приложили свои 20% усилий и получили 80% своего результата.
Принцип Парето для них срабатывает.
Чем вам не нравится это?
Или вы сертифицированный специалист по принципу Парето?
Про большие компании.
Сколько больших компаний?
Априори меньше, чем маленьких (это утверждение не вызывает возражений)?
Сколько вакансий высококлассных спецов в больших компаниях?
Все? Или таки меньшее количество?
В сумме по рынку, таких вакансий меньше, весьма меньше.
Вот специально для вас сходил на hh.ru
Распределение по з.п. С++
до 55 000 руб — 177
от 55 000 до 105 000 — 102
от 150 000 до 200 — 69
от 200 000 — 29
Видим, что свыше 150 00, примерно 30%, почти тот же Парето.
Если еще проанализировать требования, то может оказаться, что и требования по алгоритмам так же ложаться.
А ЗП в районе 100 000, это весьма неплохая ЗП.
И ее вполне может хватать для того, что бы дальше не напрягаться.
Ну как вариант.
Не нравится, предложите свой.kmu1990
05.03.2017 21:00Они приложили свои 20% усилий и получили 80% своего результата. Принцип Парето для них срабатывает.
Да с чего вы это взяли?Вот специально для вас сходил на hh.ru
Распределение по з.п. С++
до 55 000 руб — 177
от 55 000 до 105 000 — 102
от 150 000 до 200 — 69
от 200 000 — 29
Итого всего 377 вакансий? Вам не кажется это число маленьким, чтобы делать на его основании какие-то выводы?
Сколько вакансий высококлассных спецов в больших компаниях?
Вы, очевидно, не поняли мое утверждение, мое утвержджение — большие компании набирают специалистов (и не только классных) постоянно, не только когда у них открыласаь какая-то вакансия для классного спеца. Потому что классному специалисту (и это чуть более высокий уровень, чем умеет реализовать сортировку пузырьком — не великое достижение) работа в большой компании найдется. При условии, что он знаком с базовыми вещами и умеет свои мысли превращать в алгоритмы, а алгоритмы в код.
Все? Или таки меньшее количество?
А ЗП в районе 100 000, это весьма неплохая ЗП.
Если вы живете в Питере -> Красноярске -> Хабаровске, то может быть. А если вы живете в Дублине, то очень сомневаюсь.И ее вполне может хватать для того, что бы дальше не напрягаться.
Ну как вариант.
Не нравится, предложите свой.
Мне в первую очередь не нравится аргументация вашей своей позиции, на что я и пытаюсь обратить ваше внимание.VMichael
05.03.2017 21:06Я думаю не важно где, в Дублине, в Москве или еще где то.
В России 100 000 рублей, в Дублине, может быть это 10 000 $ в месяц, не знаю.
Суть от этого не меняется.
Вы абстрагироваться от конкретных чисел умеете?
Ну, не буду уподобляться и переходить на личности.
Дайте свой вариант, почему «хороших» программистов не так много, как бы хотелось, с вашей отличной аргументацией.kmu1990
05.03.2017 21:28Вы абстрагироваться от конкретных чисел умеете?
Я то умею, а вы? Напомню вам, что это вы назвали конкретное число взятое опять же из воздуха лишь бы было какое-нибудь.
Дайте свой вариант, почему «хороших» программистов не так много, как бы хотелось, с вашей отличной аргументацией.
Я вам ничего давать не буду, как я уже сказал, я показываю вам слабость вашей аргументации, а вы пока только в штыки все воспринимаете.
Я указал вам на факт, что спрос на специалистов есть (не каких попало и не только крутых, а самых нормальных — разбирающихся в основах) как минимум в больших компаниях, откуда он берется, учитывая, что каждый год куча вузов выпускает кучу «программистов» по всему миру, для меня загадка. Но факт есть факт — специалистов не хватает.VMichael
05.03.2017 21:37+1Посмотрел ваш профиль.
Вы молоды и вы в академической среде.
Может быть поэтому не понимаете моих аргументов.
Цифры я привел не конкретные, а относительные, что бы можно было навскидку оценить порядок.
Мой аргумент — достаточно вакансий с приемлемой зарплатой, что бы большинство выпускников (самоучек), решили не сушить себе мозг «лишними» алгоритмами, а устроились на работу в другие места.
Если бы распределение вакансий было другое — на хороших вакансиях можно жить, а на других жить впроголодь, тогда был бы массовый спрос на хороших программистов, а так есть массовый спрос на массовых программистов, которые приемлемо закрывают потребности бизнеса.
Если вам и сейчас не нравится аргументация, то все, я опускаю руки (вероятно тогда действительно ученые мужи оторваны от жизни, раз простая житейская логика не укладывается у них в голове).kmu1990
05.03.2017 21:40Боюсь ваша «простая житейская логика» не имеет право называть логикой. И то что я в академической среде не запрещает мне также иметь отношение и к реальной разработке. Но да, я бы предпочел, чтобы вы «умыли руки».
VMichael
05.03.2017 21:44Это просто сделать, не комментируйте мои комменты.
Не кормите троля.
P\S Потому и проблема с персоналом частая, из-за высокомерия и гордыни некоторых товарищей.
LBL
05.03.2017 18:41Спрос то есть. По остальному могу сказать, что у меня прекрасный опыт перевода проекта из Индии, который писали 2 года 20 человек, в Россию, где за полгода команда из 5 человек написала практически все с нуля с выходом в продакшен. И я по коду понимал, что в Индии код писали выпускники ПТУ. :-) Боюсь, что мы идет в этом же направлении.
VMichael
05.03.2017 20:02Да в жизни можно разных примеров наприводить.
Я вот знаю человека, который в одиночку заменил команду из 4 человек.
Правда инсульт с ним приключился и этот пример я не могу назвать успешной историей.
Или вот попадалось где то исследование, что люди с геном, который влияет на обучаемость, оставляют меньше потомства. Желтизной отдает, но вокруг действительность мне говорит тоже самое. И вывод авторов исследования — в общей массе человечество тупеет.
Идем и идем в этом направлении.
Уверяю вас, появится критичный спрос, появится и предложение.
Сейчас значит преобладает спрос на создателей бизнес приложений, которым сортировки писать не приходится, образно говоря.LBL
06.03.2017 01:38Вообще мой посыл в другом. Даже создатель бизнес приложений из кирпичиков должен понимать, что он делает. Если он делает кирпичиками получение сущности из базы данных, то должен знать, что это запрос в базу данных и вероятно по некоторым полям надо построить индекс. Что если ты делаешь ThreadPool из 10 потоков и видишь, что очередь растет, то надо подумать об увеличении кол-ва потоков. Если ты делаешь постоянные вставки в середину списка, то ArrayList не лучшее решение и т.д.
DistortNeo
06.03.2017 03:43Что если ты делаешь ThreadPool из 10 потоков и видишь, что очередь растет, то надо подумать об увеличении кол-ва потоков.
А на утечку памяти можно предложить поставить побольше памяти в сервер, да перегружать сервис по расписанию.
Надо знать:
- сколько у нас доступных потоков в системе;
- что делают задачи: потребляют ли много CPU или постоянно находятся в режиме ожидания;
- насколько критична скорость выполнения задач: иногда лучше, чтобы задача помариновалась в очереди, но выполнилась быстро;
- насколько задачи независимы: есть ли блокировки, которые могут значительно замедлить выполнение большого количества задач.
Если ты делаешь постоянные вставки в середину списка, то ArrayList не лучшее решение и т.д.
Не факт, что асимптотически лучшие алгоритмы будут быстрее, если длина массива небольшая.
LBL
06.03.2017 20:01Отличный анализ. Именно этого я и жду от разработчиков. Если коротко: «Знать, думать и делать»
symbix
06.03.2017 00:35Ну так это потому что уровней абстракции становится все больше и больше, и требуется все более глубокое погружение, чтобы добраться до сути.
Тем не менее, фундаментальные знания все те же, и людей, ими владеющих, меньше, мне кажется, не стало. Другое дело, что стало больше укладывателей квадратиков — но это только потому, что для многих задач и этого достаточно.
symbix
05.03.2017 03:30Знаете, по итогам этой ветки у меня создалось ощущение, что вот этот комментарий я написал в том числе и для вас.
Буду рад, если ошибаюсь. :)
LBL
05.03.2017 13:54+1Это не переговоры — и это базовая ошибка в вашей логике. Это интервью. Во всяком случае на первом этапе. Один спрашивает — другой отвечает. На этом этапе мне, как работодателю, важно понять как вы мыслите, что знаете, что умеете, сможете ли работать в команде, как вы работаете в стрессе (читай в критической ситуации) и даже ваша обидчивость мне также важна.
VMichael
05.03.2017 13:59Так же как важны все эти вопросы другой стороне.
Да, когда человеку, образно говоря, есть нечего, это интервью.
А если он вполне себе работает и доволен собой, это переговоры.
Как кандидатов много, так и работодателей много.
Если вы такой прямо таки резкий чувак, типа, чуть что — «до свиданья!», как с вами дальше то работать? ;)LBL
05.03.2017 15:21Если я человека переманиваю, то скорее всего я его знаю и тогда это переговоры. Зачастую даже не в офисе. Если я беру человека с рынка, то я его не знаю и тогда это интервью. Хотя я всегда готов ответить на вопросы соискателя в конце интервью если есть понимание, что продолжение разговора возможно.
Am0ralist
05.03.2017 14:29+1Ну а с другой стороны человек оценивает вашу (не)адекватность по полученным вопросам и в итоге тоже делает вывод «тварь ли он дрожащая или право имеет».
Ведь не только у вас стоит задача не взять плохого.
У человека напротив тоже стоит задача не попасть под управление самодуров, если варианты есть, а не стоит вопрос, что жрать нечего.
symbix
06.03.2017 00:25Мой поинт как раз в том, что ошибка у вас.
Да, один спрашивает, а другой отвечает. Но уже и на этом этапе кандидат делает свои выводы. По тому, какие вопросы задают — выводы о том, какие знания потребуются и какого рода задачи надо будет решать. Если я претендую на вакансию senior, а вопросы задали джуниорские и на этом закончили, то мне, скорее всего, будет неинтересно. Если видно, что мое резюме не читали и присланные примеры кода не смотрели, наверняка работа примитивная и в компании большая текучка. Если проводят стрессовое собеседование, наверняка в компании неприятная атмосфера.
Так что переговоры, пусть и неявные, уже тут начинаются.
LBL
06.03.2017 01:28Если кандидату задали джуниорские задачи и на этом закончили, то значит он даже с ними не справился. Пришлете код — я «допрошу» по коду. Будет только резюме — начну с резюме. В любом случае я проверю почти все, где напишите, что вы strong. Насчет стресса — это не ко мне. Это тут кто-то сказал, что для кандидата собеседование уже стресс. Никакого дополнительного давления я не оказываю.
VolCh
06.03.2017 11:26Если кандидату задали джуниорские задачи и на этом закончили, то значит он даже с ними не справился.
Далеко не факт. Возможно просто в компании нет никого, кто мог бы задать неджуниорские вопросы.
LBL
06.03.2017 19:58Не льстите себе. :-)
VolCh
06.03.2017 20:44Я так работу предыдущую получил. Потом выяснилось, что итогом собеседования было: "Я почти ничего не понял, но мужик явно больше меня шарит".
DrPass
07.03.2017 13:49Я вспоминаю свой первый «взрослый» контракт в 1999-м, после полуработы на институтской кафедре. Разместили мы с товарищем объявление в газете, что два программиста ищут работу. Нам позвонили из кадрового агентства, девочка слабо представляла, что такое программист, но у неё была заявка от работодателя с этим словом. Поэтому она спросила «Вы программисты?». Я сказал, что да. На этом собеседование с эйчаром мы прошли. Дальше непосредственно профессиональное было. Это была типография, у которой один заказчик захотел веб-сайт. У нас сначала уточнили, программисты мы или нет. Мы сказали, что программисты. Потом спросили, умеем ли мы делать сайты. Сказали, что умеем. Потом спросили, сколько стоит сайт. Мы сказали, что сайт с информацией о компании и каталогом продукции стоит 600 долларов. После этого подписали контракт, получили предоплату, вышли с товарищем из их офиса. И пошли в интернет-клуб читать статью о том, как делаются веб-сайты.
К слову, мы его сделали и заказчик остался доволен :)
Danik-ik
05.03.2017 20:07Переписать на рекурсию лучше попросить вычисление чисел Фибоначчи. Тут-то и выяснится понимание сложности алгоритмов (особенно — бесполезной сложности). Не отказался — звоночек. Обиделся — ушёл. Объяснил культурно, почему это неправильно — плюс в карму. Да, это провокация, но она даёт ответы и на профессиональные, и на поведенческие вопросы.
VMichael
05.03.2017 00:52+2Уровень кандидатов с каждым годом только падает.
Может быть желающих работать в вашей конторе с каждым годом становится меньше? Ну как вариант.
OlegGelezcov
05.03.2017 00:55Другими словами — вы бы не взяли Хэннсона на работу, пусть горит в аду со своим RoR, если баблсорт расписать не может?))
LBL
05.03.2017 01:05+3Я думаю он лукавит. Я абсолютно уверен, что он может его написать. И уж он точно знает и сложность этого алгоритма и другие алгоритмы сортировки.
zzzcpan
05.03.2017 03:05-2Нет, он не лукавит. Он может его написать дома. Сесть спокойно, вспомнить, написать код, написать тесты, выловить эдж кейсы и прочие прелести императивного кода. Но не с ходу, в незнакомой обстановке, под присмотром чужих людей, со стрессом, с кучей предубеждений в свою сторону по поводу внешнего вида, манеры общения и т.д.
Реальная разработка не имеет ничего общего с решением глупых задачек на листочках и уж наверняка никто из синьоров не практикуется в такой ерунде, потому чтобы пройти такие интервью им надо готовиться, как к экзаменам в институте. Но мало кто будет. Очень наивно думать, что вы хороших людей отбираете, в лучшем случае случайных среднестатистических, а то и вообще хуже среднего, но хорошо умеющих проходить интервью.
Но я так понимаю, что вам все равно, это какой-нибудь аутсорс или крупная компания, где и так все подряд сойдут.DrPass
05.03.2017 03:45+2Но не с ходу, в незнакомой обстановке, под присмотром чужих людей, со стрессом, с кучей предубеждений в свою сторону по поводу внешнего вида, манеры общения и т.д.
Ну а зачем тогда вообще ходить на собеседования, если это такая сложная штука, незнакомая обстановка, чужие люди и предубеждения, что отшибает напрочь способность решить детскую задачку? А что он будет делать, если у него в реальной работе вдруг случится дедлайн, или у крупного клиента выскочит крупный и срочный баг? Я понимаю, что бывают гениальные парни, которым прощаешь все их чудачества, но с другой стороны, в мире полно хороших инженеров без подобных психологических проблем.
Моё ИМХО — нет ничего страшного, если вы нечаянно отсеете специалиста, который по каким-то особенностям мышления не смог решить простую задачку на собеседовании. Это куда лучше, чем если вы нечаянно возьмете на работу специалиста, который эти простые задачки в реальной жизни нормально решать не умеет.zzzcpan
05.03.2017 04:10А что он будет делать, если у него в реальной работе вдруг случится дедлайн, или у крупного клиента выскочит крупный и срочный баг?
Сядет спокойно и будет делать, это же совсем другая ситуация. Или чужие люди тоже будут ходить наблюдать за ним и оценивать дальнейшую его судьбу каждый раз? Тогда такую работу никто не выдержит.
На самом деле нет никаких «психологических проблем», те же экзамены без подготовки никто не сдает. Интервьюверы просто сами не понимают, что делают.
нет ничего страшного, если вы нечаянно отсеете специалиста
А если нечаянно не отсеете не специалиста? Сейчас же есть даже курсы всякие для подготовки к таким глупым интервью, кто угодно может пролезть.DrPass
05.03.2017 05:00+2Сядет спокойно и будет делать, это же совсем другая ситуация
Не такая уж и другая. Это стресс, это письма от тимлида, звонки от менеджера и т.д.
На самом деле нет никаких «психологических проблем», те же экзамены без подготовки никто не сдает. Интервьюверы просто сами не понимают, что делают.
Ну так и участников собеседования тоже ведь не по результатам анонимного голосования выбирают. Если человек явился на собеседование, то очевидно же, что он до этого общался с эйчаром, где-то публиковал своё резюме, как-то заинтересован в этой вакансии и имеет (или хотя бы считает, что имеет) соответствующую квалификацию. Наоборот, это на экзамены многие «приплывают по течению», потому что раз попал в ВУЗ, хоть добровольно, хоть потому что папа с мамой отправили, от них уже не денешься. А собеседование, это как раз сознательный шаг взрослого человека.
И если для этого взрослого человека оказывается неожиданностью и неразрешимой проблемой то, что на этом собеседовании вдруг оказались чужие незнакомые люди, да ещё и спрашивают чего-то, то я даже и не знаю, как к нему относиться. По-моему, работать в команде ему в любом случае противопоказано. Благо, любой, самый нездоровый интраверт, сейчас вполне сможет найти удаленную работу практически без необходимости общаться с живыми человеками.
А если нечаянно не отсеете не специалиста? Сейчас же есть даже курсы всякие для подготовки к таким глупым интервью, кто угодно может пролезть.
А к каким именно «глупым интервью»? Напомню, мы говорили про интервью, где задают вопросы, непосредственно касающиеся профессиональной компетенции. У сеньора в круг его обязанностей разработка софта также входит, и ему тоже надо уметь программировать.zzzcpan
05.03.2017 15:11-2непосредственно касающиеся профессиональной компетенции
Нет, извините, такие вопросы не касаются профессиональной компетенции. Это все не пересекается с реальной разработкой.DrPass
05.03.2017 17:20+3Какие вопросы? Придумать в уме и написать на бумаге алгоритм чего-нибудь? Ещё как касаются. Более того, я вам скажу, это необходимый и достаточный критерий отбора людей, которые могут работать на какой-либо специализации программистов, и которые программистами работать не могут в принципе. Понимаете, вызубрить API какого-нибудь фреймворка может практически любой человек, у которого есть память. А вот разложить собственно задачу по этапам уже может далеко не каждый. Я могу в пример привести нашего же UX-дизайнера. Этот парень играючись может составить удобные формы, красиво подобрать цвета по актуальным гайдлайнам. Знает все финтифлюшки/особенности HTML5, CSS3 и т.д., может сваять морду на Angular, например. Но когда нужно написать какую-то бизнес-логику хотя бы в интерфейсе на клиенте, для него в порядке вещей сначала написать return, а потом продолжение метода. Потому что вот не умеет он составлять алгоритмы, не так работает у него мышление. А собеседование на фронтэндщика, в котором не будет проверки на умение программировать, пройдёт таки да, без проблем.
zzzcpan
06.03.2017 19:09-3Какие глупости. Я помню когда я учился все до единого сдали экзамен по программированию на первом курсе с этими самыми пузырьками, включая людей у которых даже компьютеров не было. Думаю догадаетесь, что не многие из них могут работать на какой-либо специализации программиста. Это все-таки совершенно другие навыки.
Когда-нибудь поймете или нет, не знаю, знаю что некоторые жалеют со временем, что такими глупостями занимались. Но обсуждать тут это похоже бесполезно, да и все равно у абсолютного большинства этот процесс не излечим, особенно у аутсорса и крупных компаний. Там всегда практически кто попало будет набирать людей абы как, без малейшего понятия. Что и хорошо, так они талантливым командам конкуренции составлять никогда и не будут.
LBL
05.03.2017 14:23Именно поэтому к собеседованию надо готовиться, а не считать, что вас возьмут за ваше резюме или красивые глаза и умный вид. Конечно мне не все равно в каком виде ко мне придет кандидат. Если, пардон, от него воняет БОМЖом, то вот как он будет на работу ходить? А вот в джинсах ли, в костюме ли — мне все равно. Манера общения тоже важна, т.к. если кандидат не сдержан и всех посылает при первой же проблеме — он работать в команде не сможет.
Реальная разработка в разы сложнее чем прохождение интервью. Именно поэтому у меня нет четкого алгоритма проведения интервью. С каждым кандидатом все с чистого листа. Вариант с хорошо проходящими интервью у меня не проходит.
Поскольку я нанимаю для себя, то мне как раз не все равно. Потому и заморачиваюсь.Am0ralist
05.03.2017 14:36Реальная разработка в разы сложнее чем прохождение интервью.
Да ладно, там пахать надо, вокруг более менее знакомые люди (команда) от которых ты примерно понимаешь, что ожидать, а ты делаешь то, что знаешь и умеешь.
А вот в интервью с тебя социализацию требуют. Крутые навыки общения с абсолютно незнакомыми людьми, которые вообще возможно на твои красные носки к зеленым кроссовкам агрятся. И при этом показывать себя с лучшей стороны, причем именно с той, которая требуется работодателю.
Для некоторых людей это принципиально разные по сложности вещи.LBL
05.03.2017 15:37вопрос вхождения в команду — «Крутые навыки общения с абсолютно незнакомыми людьми» — тоже крайне важно.
На красные носки и зеленые кроссовки мне наплевать.Am0ralist
05.03.2017 16:17вопрос вхождения в команду
Редко требует менее 1-4 часов, как на собеседовании.
И уж тем более эти навыки никак не коррелируют с хорошим уровнем программирования.
На красные носки и зеленые кроссовки мне наплевать.
В обсуждениях на хабре было, и что человек был уверен, что получал несколько раз лучшие условия, потому что в костюмчике приходил, и что другой, к сожалению, не может взять и пойти на абстрактное собеседование в футболке любимой металл-группы.
Все таки неформальное общение и формальное (как на интервью/собеседовании) — сильно разные для некоторых людей вещи. И даже если Вам это не важно, собеседник этого не знает.LBL
05.03.2017 16:24Редко требует менее 1-4 часов, как на собеседовании.
И уж тем более эти навыки никак не коррелируют с хорошим уровнем программирования.
Я уже говорил. Мне нужен не только хороший программист, но и член команды.
И даже если Вам это не важно, собеседник этого не знает.
Именно поэтому надо приходить в нейтральной одежде. Знаете есть такое понятие casual. Можно в smart casual. Кстати, металлист в футболке с любимой группой ко мне приходил. Нанял — работает.Am0ralist
05.03.2017 16:46Так а чем плох человек, который потихоньку за пару недель-месяц вольется в команду? Вам же не на пару месяцев человек нужен?
Очень много встречал в разных отраслях специалистов, с которыми не пять минут требуется на вливание в коллектив, зато потом достаточно дружно получается общаться и решать общие вопросы.
И наоборот, что человек, который за 5 минут ко всем в доверие влезает в итоге оказывался не таким уж хорошим выбором в итоге с точки зрения полезности.
Так что все таки наладить общение за пару часов интервью — для кого-то больший стресс, чем аврал на работе. Наоборот, я лично во время аварий/авралов больше концентрировался всегда — если только не вся работа в эдакий аврал превращается. Хотя есть нюанс, что я не программист)LBL
05.03.2017 17:50Ничем не плох. С чего вы решили, что для меня месяц это много? Мало того, я вам секрет выдам, что программисты в основном интроверты и для них действительно сложно взаимодействовать вместе. Однако, все мы понимаем, что к успеху приходят единицы «одиноких волков» и командная работа крайне важна.
Am0ralist
06.03.2017 13:08программисты в основном интроверты
Хотя это тоже далеко не всегда так, однако мы возвращаемся к тому, о чем я изначально написал: интервью и собеседование для человека может быть более сильным стрессом, чем обычный аврал. Именно потому, что там необходимо отработать по слабой функции человека, а в аврале — по прокаченному.LBL
06.03.2017 19:57+1Анекдот:
Стюардесса после тряски говорит: «Ну что вы так разволновались? Это обычная турбулентность. Спокойно. Успокаиваемся. Все? Нормально? Капитан? Первый пилот? Молодцы. Пойду успокою пассажиров.»
Так вот я никого по головке гладить не буду. Детский сад на прогулке закончился. Взрослая жизнь трудна и сурова.
zzzcpan
05.03.2017 15:09Я вам пытаюсь объяснить, что такие интервью вообще никак не коррелируют с уровнем разработчиков. Более того, вы понятия не имеете, какого уровня были разработчики, которых вы отсеяли, но смело предполагаете, что «нормальных» не отсеяли и еще и жалуетесь, что раньше «нормальных» было больше. Это называется survival bias, кстати, все наниматели им страдают. На самом деле проблема только в вас, в вашем понимании ситуации и в ваших процессах. Вы по сути отбираете только тех, кто вам нравится, но не тех, кто хорошие разработчики. И в этом нет ничего позорного, почти все страдают таким. Но хотя бы не стоит себя обманывать.
LBL
05.03.2017 15:32Как можно взять тех, которые не нравятся? Мне же с ним работать. Тем не менее снижение общего уровня образования в России налицо. До этого пускай я брал одного из 10, но при этом парочка была еще хороших разработчиков. Они просто не подходили по используемым технологиям и менять стрим не хотели. Сейчас с этим стало хуже.
DistortNeo
05.03.2017 16:02+1Мне кажется, это не снижение уровня образования, а последствие роста спроса на разработчиков. Вот предложение и расширилось за счёт менее качественных кадров, у которых лет 10 назад шансов не было.
NickKolok
05.03.2017 01:59+1За столом сидели двое. Первый — широкоплечий, высокий мужик с окладистой, до пояса, бородой. Вторым был Ксенобайт, обряженный в длинную белую рубаху с широкими рукавами. Оба напряженно смотрели в стоявшие перед ними стаканы. Ксенобайт вещал. Кажется, он уже был порядком захмелевшим.
— Вот я и говорю, — подавленно говорил он слегка заплетающимся языком. — Применение всех этих стандартных библиотек скотинит и развращает программиста. Низводит его до состояния быдла. Животного. Собаки Павлова. Загорелась зеленая лампочка — вызывай эту функцию. Загорелась синяя — другую. А почему?! П-почему лампочки загораются?!
Последнюю фразу Ксенобайт произнес с тоскливым надрывом. Гордо выпрямившись, ударил себя кулаком в грудь, потом снова сник.
— Н-никто не помнит. Никто не помнит, откуда там эти лампочки и почему горят. Ты меня понимаешь? Понимаешь, что я чувствую, когда смотрю на эти лампочки?
Мужик мрачно кивнул, выдав что-то вроде «угу» и сдвинул с Ксенобайтом стаканы.
Призрак. «Бета-тестеры»
TheDeadOne
05.03.2017 08:48За почти уже 12 лет руководящей работы через мои руки прошло, пожалуй, около сотни соискателей. Может быть мне не везло, но те, кто на собеседовании бойко выдавал академические знаний и мог сбалансировать на доске красно-чёрное дерево, оказывались в последствии абсолютно не способны к решению задач бизнеса. Поэтому в последние годы я полагаюсь на обзорную беседу, практическое задание на пару-тройку дней и испытательный срок. Кадрам последний пункт, конечно, очень не нравится.
LBL
05.03.2017 13:57Почему кадрам не нравится испытательный срок?
VMichael
05.03.2017 14:04Некоторые «кадры» просто пытаются снизить себе количество работы с оформлением приема на работу/увольнением сотрудников.
И когда вакансия снова открывается, добавляется работа по поиску кандидата, первичный отбор которого делают кадры.
Бывают планы по «закрытию вакансий» которые висят на кадрах.
Не везде, конечно. Это вопрос конкретной дурости в конкретной компании.LBL
05.03.2017 14:28Уволить человека на испытательном сроке в разы легче, чем без оного. Все остальное — это действительно про дурость. :-)
Am0ralist
05.03.2017 14:40А можно уточнить, испытательный срок по закону с нормальной оплатой или как?
А то встречал в духе две недели бесплатно, но если останешься — то заплатим. Или, платим сильно меньше три месяца, но потом сказка начнется. С понями. Не вдохновляют такие условия.LBL
05.03.2017 15:33У нас зарплата на испытательный и потом одинаковая.
Am0ralist
05.03.2017 16:27Собственно, из Ваших предыдущих комментариев я почему-то даже не сомневался в этом, если честно.
А вот как у сетующего, что людям не нравится испытательный срок — мне интересно. Так как тоже не понятно, чем людям соблюдение ТК не нравится.
TheDeadOne
06.03.2017 03:59Не бесплатно, но меньше. И если человек хорошо себя показал в первый месяц, то испытательный сразу прекращается.
Am0ralist
06.03.2017 14:44Собственно ответ на ваш вопрос, почему не нравится — на рынке слишком много хитрожопых нехороших людей, которые таким образом оптимизируют затраты.
Проще найти место без таких заморочек.TheDeadOne
07.03.2017 04:16Под кадрами я имел ввиду кадровую службу. Соискателей, которым не нравилась бы такая схема, я ещё не встречал. Куда чаще встречал толковых людей, которые заваливали техническое собеседование только потому, что нервничали. Что касается оптимизации с помощью вечного испытательного срока на какой-либо ставке: Такая схема может хорошо работать с грузчиками, например. Но высококвалифицированным специалистам нужно время на «вход», в первые месяцы работы прибыль они не приносят, скорее расходы.
Mikluho
05.03.2017 11:08Ох уж этот вечный холивар…
Каждый раз смотрю и удивляюсь — как же люди в споре суть его упускают. И ведь даже озвучивают порой ключевые разногласия, но спор не прекращают. Спор ради спора.
А ведь как всё просто (и было сказано уже не раз): программисты разные нужны, программисты разные важны. :)
Просто слово на всех одно.
Так почему же спорщики так уверенно трактуют в универсальный вариант «правильного программиста» частное суждение «мне нужны вот такие» или «я считаю правильными именно вот этих». Но ведь не бывает универсальных программистов.
Не проще ли уж начать дополнять термин? Типа «нужен хороший программист на фабрику данных», или «спец по моделированию физических процессов», или «умеющий в одно лицо создать систему поддержки бизнеспроцесса», или даже «мастер скоростного кодирования по готовому ТЗ». Тогда сразу будет понятно, почему один должен алгоритмами дышать, а второму они до лампочки :)
Пара моих личных примеров.
Я сам «матёрый» программист, начинал ещё в 90-х, и всю жизнь имею дело с реальным бизнесом. Именно поэтому любая задачка для меня начинается с user stories & use cases. Потом добавляем потенциал развития и жизненный цикл программы/системы. Потом уже можно подумать о том, как и что писать. И вот как-то до явной реализации алгоритмов я доходил пару-тройку раз, не более. Да, в институте писал алгоритмы, и помню некие общие подходы… Главное, что в жизни пригождается — понимание вычислительной сложности. Ибо без него можно на ровном месте систему в down уложить. Чаще, конечно, за этим следить надо в области sql.
Зато понимание общих концепций, паттернов и т.п. — это то, что спрашиваю у senior-ов. (Весьма забавно получить ответ про паттерны от tech lead/architect в духе «да пофиг что использовать, ибо decorator, wrapper, adapter и facade суть одно и то же»). И да, про паттерны я спрашиваю только про те, которые собеседуемый сам заявляет как понятные и используемые.
С другой стороны, сам, проходя собеседования, если натыкался на кучу вопросов по алгоритмам, честно говорил «ребята, вам нужен не я. Вот систему запроектировать — это ко мне, а алгоритмы… потребуются — найду. А помнить без нужды — нафиг надо»…
LBL
05.03.2017 14:56+1То, что Вы написали во второй части показывает, что Вы уже давно не программист. Архитектор, проектировщик, тим лид — как угодно, но не программист.
По первой части приведу простой пример плохого кода, вызванного тем, что человек не понимает структуру хранения данных. Надо провести итерацию по парам key-value в HashMap. Делаем цикл по ключам и достаем внутри цикла значение get-ом. Дурное абсолютно решение и все равно так пишут.
Другой пример — надо осуществить поиск в неупорядоченном массиве. Можно написать в две строчки — sort и binarySearch, а можно подумать правильно ли это. А еще можно подумать если надо осуществлять поиск, то может надо как-то перепроектировать, чтобы поиск делать по чему-то более быстрому.
И вы хотите сказать, что тут не нужно знание в базовых алгоритмах?DistortNeo
05.03.2017 15:30По первой части приведу простой пример плохого кода, вызванного тем, что человек не понимает структуру хранения данных. Надо провести итерацию по парам key-value в HashMap. Делаем цикл по ключам и достаем внутри цикла значение get-ом. Дурное абсолютно решение и все равно так пишут.
Кстати, в JavaScript только так и можно делать.
michael_vostrikov
05.03.2017 16:43Тут нужно. А чтобы правильно выделить бизнес-сущности, правильно спроектировать работу бизнес-процессов с этими сущностями, правильно организовать хранение в постоянном хранилище и загрузку их оттуда, и запрограммировать все это с использованием всяких SOLID, не нужно.
А если вы скажете, что мол в БД тоже всякие хитрые алгоритмы, то это не важно, потому что я все равно не могу их поменять. Для их использования достаточно описания в документации или пояснений на хабре/SO, которые можно найти как раз через гугл.LBL
05.03.2017 17:41Слышу голос аналитика или архитектора, но никак не программера. :-)
michael_vostrikov
05.03.2017 18:36Ну может где-то аналитики и архитекторы составляют подробное задание для программеров типа сделать вот такие сущности, вот так хранить их в БД, вот такое наследование/композицию сделать, вот так сделать инъекцию зависимостей, а программисты потом по списку просто кодируют. Но я такого не встречал.
Зато встречал необходимость правильной организации кода и правильного использования имеющихся инструментов. И какой-нибудь binarySearch это один из винтиков на уровне конкретной реализации. Для каких-то задач программирования своя реализация таких алгоритмов нужна, для каких-то нет.
Mikluho
05.03.2017 20:36Это вот то самое! Кого именно называть программистом? Дайте однозначное определение, и можно будет сделать перечисление тех самых базовых навыков. А без этого, ответ один — программист должен, как минимум, уметь программировать ;)
Mikluho
05.03.2017 20:32Я может по сути уже давно и не программист, но до сих пор пишу код, и этот код работает хорошо и приносит заказчику прибыль, а коллегам не приносит лишней головной боли… Но даже если брать времена весьма далёкие, я также, как и сейчас, почти не сталкивался с потребностью явно писать сложные алгоритмы. И мой продукт не был хуже от того, что я не знал эти алгоритмы.
Говоря про ваши примеры, у меня первый вопрос в голове — а зачем это нужно? какие данные на входе, что нужно на выходе? в каком case это будет использоваться? Ведь даже тот же неупорядоченный массив… Мне чаще встречаются задачи вида «выбрать измассивасписка элементы, для которых выполняется бизнес-условие, и преобразовать элементы в другой вид». В большинстве случаев никакие пред-сортировки и прочие шаманства не дадут ничего, кроме лишнего кода. А оптимизации чаще всего лежат на несколько уровней выше конкретного участка кода…
И уж совсем отдельный вопрос, что же такое «базовые алгоритмы»? :)
Знание каких базовых алгоритмов помогло бы в 2000-м превратить обычный asp-сайт в веб-ферму?LBL
05.03.2017 20:51С каких это пор факториал или пузырек стал сложным алгоритмом? :-)
Базовые — сортировка, поиск, вычисление hash-а.
Базовые структуры — связанный список, хеш таблица, очередь, стек.
Далее по опыту и по резюме.
Jtalk
12.03.2017 00:49приведу простой пример плохого кода, вызванного тем, что человек не понимает структуру хранения данных
Каким образом знание структуры хранения в конкретной реализации HashMap для конкретной JDK поможет не писать дурной код? Или что, если заменить HashMap на TreeMap, вышеописанный подход станет верным? Банальное отсутствие опыта и вкуса, проверяется за 10 минут просьбой поревьюить кусочек плохого кода.
а можно подумать правильно ли это
Так если вам нужны люди, умеющие думать, зачем у них спрашивать заученные строчки из википедии? Может, попросить у них подумать «на камеру» вместо этого?LBL
12.03.2017 01:50Спишу Ваш вопрос на то, что Вы не Java разработчик.В противном случае — это очень грустно. Реализация HashMap в Java не меняется лет этак 15. Это по поводу «для конкретной JDK». Всякие улучшайзеры, например generics, я не беру в расчет. Конечно, замена на TreeMap в данной задаче итерирования не станет верным. Надо знать, что итерироваться необходимо по entrySet и что это быстрее вне зависимости от TreeMap или HashMap, чем итерироваться по keySet c дальнейшем запросом value через get(). А вот почему быстрее — вы сможете узнать, когда, например, хотя бы один раз заглянете в исходный код этих мапов, т.е. изучив структуру хранения.
Так некоторые не утруждают себя даже тем, чтобы заучить «строчки из википедии». :-) А подумать «на камеру» у всех будет шанс. У меня заковыристых задач в голове достаточно.Jtalk
12.03.2017 14:59Нет, я Java-разработчик. И именно поэтому я знаю, что, помимо того JDK, который вы называете «в Java», есть и другие JDK, свободные и весело-вендорские, со своими реализациями, ошибками и заморочками. И именно поэтому я считаю, что наличие вкуса и умение читать документацию важнее заучивания наизусть кишок оракловой реализации.
А давайте, может, раз уж мы все тут такие эксперты по внутренностям JDK собрались, вспомним про реализацию EnumMap? Может, если мы используем EnumMap, тыкаться каждый раз get'ом в цикле будет нормальной идеей? Мы ведь ЗНАЕМ ее внутренности и как они работают, почему бы и не завязаться на это, да?
А вот почему быстрее — вы сможете узнать, когда, например, хотя бы один раз заглянете в исходный код этих мапов, т.е. изучив структуру хранения
А можно я изучу исходный код JIT и, возможно, узнаю, что он сможет развернуть одно выражение в другое без потери производительности? Что, получается, как в «Камень-Ножницы-Бумага», знание JIT бьет чтение исходников HashMap? Тогда, получается, вам нужно переставать спрашивать внутренности коллекций и просить цитировать исходники компилятора? Или, может, все-таки задуматься над прекращением попыток сопоставить кругозор кандидатов с собственным, игнорируя все за пределами их пересечения?
А «строки из википедии» я тоже не заучиваю. Время — слишком ценный ресурс, чтобы тратить его на удовлетворение самолюбия местечковых Software Development-царьков.LBL
12.03.2017 16:37+1есть и другие JDK, свободные и весело-вендорские, со своими реализациями, ошибками и заморочками
Есть, но только в промышленности они не используются. Пришлите мне реализацию HashMap, кардинально отличающуся от Сана-оракловой?
Может, если мы используем EnumMap, тыкаться каждый раз get'ом в цикле будет нормальной идеей?
Да ладно? ;-) Т.е. доступ по ref (итерация по keySet) + доступ по idx (массив) лучше чем просто доступ по ref (итерация по entrySet)?
наличие вкуса и умение читать документацию важнее заучивания наизусть кишок оракловой реализации
Эх! Почитали бы исходный код, тогда бы увидели, что HashMap и EnumMap на одном абстрактном классе построены. А если бы посмотрели как реализован ConcurrentHashMap поняли бы, что такую высококлассную реализацию мог сделать только человек, реально знающий «кишки» виртуальной машины в части синхронизации.
А можно я изучу исходный код JIT
Нужно. Это уже высший класс. И если мне на собеседовании вы расскажете, что JIT компилятор сделает так, что в случае EnumMap «тыкаться get-ом в цикле» быстрее, то это будет оценено по верхнему уровню.
Или, может, все-таки задуматься над прекращением попыток сопоставить кругозор кандидатов с собственным, игнорируя все за пределами их пересечения?
Кругозор у меня широкий. У большинства кандидатов — его подмножество (я же читаю и исходный код и документацию, а вы только документацию. :-) ) Новое не игнорирую, а вот Вы за пределами прочитанной документации не вылезаете. При чем настолько не вылезаете, что даже элементарные вещи забываете.
Про царьков посмешило. Про википедию тоже. Есть вещи, которые ты просто знаешь. Алфавит, русский язык, таблица умножения и т.д. — совсем базовые знания. К этому добавляются базовые профессиональные знания — базовые алгоритмы, базовые структуры. Вы гордитесь тем, что не знаете элементарных вещей? Не царское дело? Ну и кто здесь царек? :-)
zip_zero
12.03.2017 21:37Извините, а можно я встряну? Долго следил за вашими комментариями — и не могу понять: в какой отрасли вы работаете, что реально используете свои знания о внутреннем устройстве ConcurrentHashMap? И почему так уверены, что они нужны каждому программисту в вашей команде?
LBL
12.03.2017 22:39+1Можно. И не нужно извиняться. Вы знаете я работал в разных отраслях и знания о внутренностях Java всегда помогали. Особенно там, где крайне важно быстродействие системы.Я не сказал, что «каждому программисту в моей команде» нужны такие знания. У меня хорошая команда и там есть программеры разного уровня. Я лишь сказал, что такого рода знания помогают писать программы лучше, качественнее и не делать детских ошибок. Это общий мой подход. Если ты используешь какую-то библиотеку, framework, то почитай документацию, а потом посмотри как он/она устроен(а). Я считаю, что это правильно и профессионально. Благо в Java практически все исходники открыты. Обычно этот код пишут и вылизывают досконально и чтение такого рода исходников отличный способ повысить свой профессионализм. У меня всегда в IDE подключены исходники jar-ников, а при отсутствии таковых — декомпилятор. Если возвращаться к исходной дискуссии, то меня крайне удивляет бравирование части хабровцев отсутствием знаний в элементарных вещах Computer Science, которое выдается как «крутой профессионализм». Для меня это верх идиотизма.
VolCh
06.03.2017 11:39вот как-то до явной реализации алгоритмов я доходил пару-тройку раз, не более.
А что вы понимаете под алгоритмом? user stories & use cases для вас не алгоритмы? Пускай примитивные линейные даже, но это чистой воды алгоритмы.
kolpeex
05.03.2017 12:49+2Должны, не должны. Никто никому ничего не должен.
Не нравится, что на собеседовании требуют написать алгоритм сортировки — не пиши, если хочешь обоснуй почему это не является критерием для выбора — уверен, адекватные интервьюеры адекватно оценят такой отказ.
Если тебе не все равно, то ты можешь понять, что именно хочет увидеть интервьюер, и показать ему это. Он реально хочет увидеть доскольное знание алгоритмов сортировки? — Вряд ли, а если и хочет, а ты не знаешь, то и не надо тратить время друг друга.
Bvp254
05.03.2017 13:43С требованиями «Написать алгоритм» сталкивался только когда собеседовали студентов и малоопытных кандидатов, чтобы понять какими знаниями они обладают.
От потенциально опытных кандидатов ждали совсем другого, в большей степени задавались вопросы по предстоящим задачам и проблемам (актуальным или уже решённым командой), чтобы понять, на сколько кандидат «в теме» реальных боевых ситуаций…
Наверное, мне везло работать с очень толковыми и адекватными людьми.
knekrasov
05.03.2017 21:23+1Мне вот интересно, из тех, кто здесь переживает за соискателей, которым (о ужас!) задают детские задачки из профессиональной области, кто-нибудь собеседовал других людей?
Мне правда интересно. Мне кажется, тут есть корреляция.
rkosolapov
06.03.2017 07:42+1Не надо путать фундаментальные вещи (умение написать тривиальный алгоритм и порассуждать о нём) с мимолётными нюансами типа синтаксиса миграций.
Первое — маст для инженера.
Idot
06.03.2017 12:44Пузырьковая Сортировка — это вообще первый алгоритм, который я учил. Потому я его очень хорошо помню.
Fid
09.03.2017 00:36+6Как пройти собеседование:
Зазубрите алгоритмы факториала, сортировки, вертения деревьев, складывания чисел, переводы в другую систему, стеки, списки.
Не говорите про деревья, а то попросят вертеть их на листочке.
Выучите теорию по ооп — постебите собеседователя: перегрузка, и просто знак "+" для цифр и строк — это частный случай полиморфизма, а собеседователь этого 99% не знает.
Выучите пару паттернов и названия остальных — но не называйте их, а то заставят написать примеры. Что вы последнее назовёте — то и спросят подробнее. Уверен что собеседователи ничего кроме синглтона и фабрики никогда не использовали. Это коммерческая компания, а не исследовательский институт проблем матана и оптимизации. Узнайте что такое агрегация итп и как это рисуется на схемах uml-like, стрелочки, узнайте как правильно закрашивать стрелочки. ))
Найдите долбанутые логические задачи, например про ханойские башни, индейцев в колпаках, почему люки круглые и прочий бред от г-гонтор. Есть книги с такими задачами для собеседований белых досок стиля.
Посмотрите задачки по sql, почитайте про нормализацию. С вашим ORM вряд ли что-то напишите на sql когда спросят у доски.
Почитайте Кнута. Не тратье время на чтение 10000 страниц про ваш фреймворк и его глубокое изучение и синтаксис языка — его спрашивать не будут. Всё равно спросят про сортировку и вертение деревьев.
Будьте готовы писать на листочке или на компе где нет IDE. Попадались такие д-бы которые пишут в блокноте, ладно бы оперативки из-за джавы не было, лет 10-5 назад, но сейчас чтобы тупо «поддерживать себя в форме». Видать много денег у конторы где пишут без автодополнения и проверки ошибок средой. Наконец возьмите с собой флешку со всем необходимым — своими наработками, сорсами, IDE на флешки в конце концов.
Почитайте про протоколы, OSI, TCP/IP, REST, SOAP, COM… технологии из смежных других областей. всякая вёрстка, фронтенд, бэкэнд, админство, ассемблер, гит, аджайл-маджайл-канбан-ватерфол-акулум-мукулум… бывает любят задавать вопросы из другой области — хотят чтобы вы были на все руки мастер т.к. у г-контор денег нет на узких специалистов.
Привентивно пройдете тесты на каком-нибудь it.mail.ru. Возможно будет что-то из этого.
Поищите на гитхабе сорцы по названию конторы. Наверняка кто-то выкладывал тестовое. Запилите его привентивно.
Узнайте как компания относится к опенсорсу: контрибутит или нет. Если заядлая проприетари типа ms, то удалите\скройте всё с гитхаба, типа вы чтити nda. Если контрибутят, то наоборот открывайте.
Правильные ответы на другие вопросы:
Семейное положение: женат\есть девушка, есть дети\жена беременна. Даже если их нет. (Типа вы не свалите с конторы в другую контору или город быстро).
Проживание: местный, ипотека. (не привязанных к городу не горят желанием брать)
Армия — отслужил/не берут по здоровью.
Хобби — программировать, решать сверурочно задачи из конторы за бесплатно, ни в коем случае не кататься в байкер клубе.
Для девушек — не люблю детей и не хочу их (чтобы в декрет не свалили).
Где родители\поехали бы к ним если они заболели — умерли.
Оставались ли до ночи в конторе — да.
Почему свалили с прошлой конторы — тут сами соврите чё-нить правдоподоное.
botyaslonim
09.03.2017 00:39Вы стебётесь, а меня на последнем собеседовании на позицию фронтенда спросили про метод обхода графа, выводили на разговор про алгоритм Дейкстры (потом уже почитал, что это)
Fid
09.03.2017 05:57+2Ну я ж говорю, почитайте Кнута. Я не удивлюсь если про алгоритм Дейкстры спрашивали бы и верстальщиков — зарплату сбить, показать своё чсв… :D
khim
09.03.2017 14:13Алгоритм Дейкстры — это едва ли не самое простое, что бывает в программировании. И если его не требуют исполнить просто назвав его (умение рассказывать про алгоритм по названию — это как раз бессмысленный навык), а предлагают до него «дойти», то не вижу в этом ничего плохого: в конце-концов из-за того, как устроен CSS он «сидит» и под верстальщиками тоже, так почему бы им не знать про него чуть-чуть?
botyaslonim
09.03.2017 14:19Вопрос был: как решить задачу нахождения кратчайшего пути. «Применить алгоритм» за ответ не считался :)
khim
09.03.2017 14:44Хороший вопрос, плохой ответ, да.
Для того, чтобы придумать алгоритм Дейкстры не требуется глубоких мыслей, он придумывается «влёт».
Я понимаю если бы вас КМП, БМ или там BFPRT просили на интервью придумать. Но Дейкстру? Это ж база! Этому алгоритму больше лет, чем вам, скорее всего, и он не был придуман ещё раньше просто потому что понятия алгоритм 100 лет назад не существовало!
Умение придумывать алгоритмы — это и есть базовый навык software engineerа и если вы не можете придумать Дейкстру, то что вообще вы сможете придумать? Шаг влево, шаг вправо — расстрел? Если на Stack Overflow алгоритма нет — то всё?botyaslonim
09.03.2017 14:50А что посоветуете почитать по алгоритмам? Допустим, я не знаю самых основ. Нужен понятный, практичный материал для программиста, не для математика
qw1
09.03.2017 15:05+1Если вы зачем-то решили заморочиться и прокачаться в том, чего от вас требует khim, то читать ничего не надо, это тот же готовый ответ, что с SO. Лучше порешайте задачи со школьных олимпиад по информатике. Именно школьный уровень, не ВУЗовский.
Fid
09.03.2017 16:28-3Вопрос идиотский. Эту ересь проходят на 1-3 курсе и потом любой прогер который занимается коммерческим программированием, а не решением олимпиадных\спортивных задачек успешно его забывает, в лучшем случает помнит только название. Ну нафига зубрить и помнить эту ересь. Если что-то не используется на практике, то оно забывается — принцип работы памяти в мозгу. Что-то я сомневаюсь что вы каждый день используете алгоритм Дейкстры. Ну только лишь на собеседованиях, чтобы гнобить пришедших. Конечно я помню что алгоритмы такие есть и если будет такая задача, то найду уже протестированное решение. Есть например в языке написанные отлаженные методы сортировки, распаралеленные с ассемблерными вставками. Но нет, плять, давайте городить свой велосипед по памяти с 1 курса, который был лет 15 назад, только лишь бы потешать своё чсв и начальника. Потом весь день это отлаживать. Это блять коммерческая разарботка, время — деньги. arr.sort() блядь и всё!
DrPass
09.03.2017 16:58+2Ну нафига зубрить и помнить эту ересь
Речь не про «зубрить и помнить», а про «придумать».
Кстати, будете смеяться, но вот прямо сейчас сижу, пишу модуль оптимизации поставок, и да, в нём есть поиск кратчайшего пути в графе. И, блин, в библиотеке нет метода graph.findShortestPath(). И очень хорошо, что я два десятка лет назад был студентом, и помню про существование алгоритмов Дейкстры, Флойда и т.д.Fid
09.03.2017 18:42Придумать нельзя, если нет ассоциации с названием.
Это что-то из разряда «а придумайте-ка метод Владиченко-Складчеко-Кругозорова обхода графа». Wat? Que? Чта? Но вы запомнили этот метод просто как «обход слева-направо». Но если бы вы знали, то легко бы додумали. У человека ассоциативная память.
git clone Deikstra/goes/home/in/wrong/blakc/niga/neiroboorhud
import graphs
graph.findShortestPath()
bingo. close task.khim
09.03.2017 19:25+1Придумать нельзя, если нет ассоциации с названием.
Вы с дуба рухнули или как? Задача была: найти кратчайший путь в графе. Зачем вам нужна «ассоциация с названием», чтобы эту задачу решать?
Грубо говоря вопрос: за сколько часов можно доехать от Москвы до Магадана. Простейший переборный алгоритм — смотрим куда мы можем доехать из Москвы за час, за два, за три… С учётом того, что ехать можно по разным дорогам с разной скоростью — «замётанный» участок будет причудливо расти. Как только он включит в себя Магадан — всё, ответ у нас в кармане.
Но вы запомнили этот метод просто как «обход слева-направо».
Да мне пофигу как вы его запоминали. Вот есть бумажка, ручка, карта дорог… считайте.Fid
09.03.2017 20:17-1Для того, чтобы придумать алгоритм Дейкстры не требуется глубоких мыслей
Я вот ебу что алгоритм обхода графа называется алгоритмом Дейкстры. (Я это знаю конечно, но всё же. Я знаю что есть такие алгоритмы.). Этих вариантов обхода десятки и зазубривать фамилии авторов или названия алгоритмов нафиг надо, когда они отличаются незначительно. Это как спрашивать назовите десятого соавтора книги по сям которую вы читали 10 лет назад.qw1
09.03.2017 20:20+1Если вы знаете десятки вариантов обхода графа, то… вы приняты! :)
khim
09.03.2017 22:03Если бы он знал десятки алгоритмов обхода, то вряд тут бы раздавались такие соловьиные песни на тему того, что знать Дейкстру — необязательно.
Знать имя Дейкстры — таки и вправду не требуется. Придумать (если уж не можете вспомнить) алгоритм, находящий искомое за O(N?) — таки требуется.
Есть алгоритмы, которые действительно не так-то просто изобрести (примеры я приводил выше) и вот их — на собеседовании спрашивать не стоит. Но «пузырёк» или Дейкстру… вполне. Их можно «изобрести» с полминуты, если даже вообще никогда их в глаза не видели.
Если вы настраиваете на том, что вы — шофёр, а что там у машины под капотом — вас не волнует, то, извините, в автогонщики вы не годитесь. Тут — та же самая история.
DrPass
09.03.2017 19:36Придумать нельзя, если нет ассоциации с названием.
Смотря как ставить задачу. Если вам поставили задачу «придумать алгоритм Флойда», то наверное проблематично, по крайней мере, если вы не учились на программиста. Если вам поставили задачу «придумать алгоритм поиска кратчайшего пути в графе», то я не вижу особых сложностей. Ну кроме того, то вы не знаете что такое «граф» и о чём вообще речь. Но мне кажется, нет ничего плохого, что работодатель откажет такому кандидату, даже если он и знает тот фреймворк, с которым ему придётся работать. Невежество в своей профессиональной сфере нельзя оправдывать какими-то там другими навыками. Мы всё-таки специалисты, а не ремесленники.
git clone Deikstra/goes/home/in/wrong/blakc/niga/neiroboorhud
import graphs
graph.findShortestPath()
Ну да, только если мы говорим о продакшене, а не о баловстве, вы должны не просто нагуглить что-то в гитхабе, а провести ревизию кода, чтобы понимать, что он написан так, как вам надо, а не ректально. И решает вашу задачу, а не добавляет вам новых проблем.greendimka
09.03.2017 21:58-1Невежество в своей профессиональной сфере нельзя оправдывать какими-то там другими навыками.
Очередной адепт имёно-дато-логии.
У меня по истории была твёрдая двойка. Я отлично знал по каким причинам произошло то или иное событие, благодаря чему действительно извлёк уроки из истории. Но учительнице было важно не то, чему нас история учит, а то, в какой день, к примеру, какой-нибудь правитель на престол взошёл. Не в историческом смысле день (т. е. информация о предшествующих и текущих событиях), а тупо — дата.
Каким образом знание фамилии автора алгоритма связано с профессиональными качествами?
khim
09.03.2017 22:11Каким образом знание фамилии автора алгоритма связано с профессиональными качествами?
Никак не связано. Если вы вернётесь исходному вопросу, то увидите, что нужно было не имя вспомнить, а алгоритм написать. Я вас уверяю — если бы в этот момент был изобретен и написан алгоритм Дейкстры и не было бы произнесено «сакрального имени» — проблем бы не было.
Но ведь произошло не так. «Применим алгоритм» — это ж не ответ. Сколько времени ваш «алгоритм» будет работать? А памяти сколько потребуется? Это всё, как бы, стоит знать. А как он «у умных людей» называется — действительно неважно, не в этом дело, тут вы правы.
DistortNeo
09.03.2017 19:23Достаточно просто знать, что для определённых задач существуют эффективные алгоритмы по их решению, знать их сложность, чтобы знать, что и где искать. Человек, не слышавший о Дейкстре, вряд ли сможет решить задачу с графами. А вот слышавший, но забывший, легко эти знания восстановить.
Олимпиадный код и продакшн — две большие разницы. На олимпиадах на реализацию алгоритмов нужно тратить не больше 5-10 минут, поэтому их нужно знать. В случае продакшна же условия и требования совсем другие.
khim
09.03.2017 19:42+1В случае продакшна же условия и требования совсем другие.
Вы абсолютно правы. В случае продакшна вам нужно уметь отвечать на вопрос: на входе 100 цисел, на выходе 100, наш алгоритм выполянет 1'000'000 операций — это уже предел или можно что-то побыстрее/попроще?
Грубо говоря, нужна не информация об алгоритмах, а метаинформация: вот эта вот комбинация стандартных функций — уже асимптотически хороша или мы тут время транжирим?
На олимпиадах на реализацию алгоритмов нужно тратить не больше 5-10 минут, поэтому их нужно знать.
А продакшн нужно быстро понять — стоит свой велосипед изобретать или нет. И в большинстве случаев это тоже нужно делать быстро. Ибо иначе вы можете построить большое и красивое здание — вот только у него в фундаменте будет O(N?)… и что вы будете делать, когда это обнаружите? Обвешаете его кешами всякого рода? Да, можно и так. Но лучше — заметить это на этапе проектирования и использовать другую архитектуру.
Грубо говоря — когда задают такие задачки, то хотят найти, всего навсего, людей, которые не будут изображать алгоритм Шлемиэля. А «любой прогер который занимается коммерческим программированием», увы, порождает этих Шлемиэлей десятками и сотнями.DistortNeo
09.03.2017 23:57-1Грубо говоря — когда задают такие задачки, то хотят найти, всего навсего, людей, которые не будут изображать алгоритм Шлемиэля.
… которые напишут идеальный код, когда он уже станет неактуальным.
А продакшн нужно быстро понять — стоит свой велосипед изобретать или нет.
Есть ещё третий вариант: предусмотреть возвращение к этому вопросу в будущем, если он станет актуальным. Код должен быть спроектирован таким образом, чтобы неэффективный алгоритм в любой момент мог быть заменён на эффективный без переделывания всей системы.
khim
10.03.2017 00:41+1Код должен быть спроектирован таким образом, чтобы неэффективный алгоритм в любой момент мог быть заменён на эффективный без переделывания всей системы.
Все проблемы в информатике можно решить добавлением ещё одного уровня косвенности — за исключением слишком большого числа уровней косвенности.
Я сам лично получал ускорение на порядок за счёт отказа от такого подхода.
Есть ещё третий вариант: предусмотреть возвращение к этому вопросу в будущем, если он станет актуальным.
Зачем это делать если можно заранее это оценить? Чтобы утилизировать «любых прогеров которые занимаеются коммерческим программированием»? Так есть более дешевый способ: не брать их на работу!DistortNeo
10.03.2017 00:57Зачем это делать если можно заранее это оценить?
Да, можно заранее оценить, что конкретное место будет узким при определённых условиях, но если эти условия довольно отдалённые, то лучше написать простой код за 5 минут, чем эффективный за пару часов. А если таких мест много?
Если клиент хочет продукт как можно скорее, и готов переплачивать за оптимизацию в будущем, это его право. И значит, работодатель будет поддерживать быстрые в реализации неэффективные решения.
khim
10.03.2017 01:09Да, можно заранее оценить, что конкретное место будет узким при определённых условиях, но если эти условия довольно отдалённые, то лучше написать простой код за 5 минут, чем эффективный за пару часов.
Для того, чтобы сделать таковы вывод вы должны примерно понимать — сколько ресурсов займёт тот или другой подход. А как вы это сделаете если вы относитесь к оценкам сложности как к «ну нафига зубрить и помнить эту ересь»?
И значит, работодатель будет поддерживать быстрые в реализации неэффективные решения.
Работодатель — сколько угодно! Проблема в том, что работодатели редко возмущаются тем, что кандидатов «гоняют по алгоритмам».
Возмущаются как раз «будущие работники». Они-то почему за работодателя решили, что ему нужны «быстрые в реализации неэффективные решения»?
am-amotion-city
10.03.2017 08:55Зачем это делать если можно заранее это оценить?
В 99% процентах случаев заранее это оценить невозможно. Это не значит, что лепить можно все, что угодно. Но вот так напрямую оценить, где будет узкое место заранее нереально. Если мы, конечно, не ToDo реализуем.
Можно сортировать
O(N??)и не знать проблем, если сортируются электронные адреса одного пользователя. А еще бывает, что оптимальныя сортировка для нас не работает, потому что у нас хэши не как у всех, а, например, подряд. Или добавление бывает только по 854 записи за раз. Или еще что.
Ну и, помимо прочего, back pressure в современных системах всегда будет более вероятным источником проблем, чем неудачный алгоритм сортировки.
Именно поэтому появился термин premature optimization. И именно поэтому эффективность алгоритмов в стандартных задачах принято ковырять в последнюю очередь.
DrPass
10.03.2017 11:46+3В 99% процентах случаев заранее это оценить невозможно. Это не значит, что лепить можно все, что угодно. Но вот так напрямую оценить, где будет узкое место заранее нереально. Если мы, конечно, не ToDo реализуем.
Вообще, это как раз то, что отличает джуниора от опытного разработчика. Опытный программист как раз заранее понимает последствия выбора того или иного решения, в том числе и по производительности. Я бы сказал с точностью до наоборот, в 99% случаев все узкие места прекрасно видны ещё на этапе проектирования. Вы же не каждый день вступаете на терра-инкогнита непонятной исследовательской работы. Обычно вы делаете вполне привычные и понятные вам задачи. Что вы не способны оценить заранее? Что вот тут отсутствие индекса может уложить запрос, а вот тут при частом одновременном доступе могут возникать блокировки потоков? Да бросьте.VolCh
10.03.2017 12:08Именно, и решение использовать более подходящие для данной конкретной ситуации библиотеку или алгоритм с целью избегания будущих вероятных проблем, не является преждевременной оптимизацией при прочих равных, прежде всего при примерно равных трудозатратах на реализацию вариантов.
Выбор лучшего решения вообще сложно называть оптимизацией, если ресурсы на выбор практически не тратятся, а ресурсы на реализацию выбранного решения плюс-минус одинаковы. Оптимизация начинается когда тратся ресурсы специально на улучшение какой-то метрики продукта, как правило за счёт ухудшения других метрик.
am-amotion-city
10.03.2017 15:12более подходящие для данной конкретной ситуации библиотеку или алгоритм
Такое ощущение, что вы в Палате Мер и Весов работаете, а не в IT. В какой конкретной ситуации? Как вы можете знать для хоть сколько-нибудь неочевидной задачи, какой алгоритм выбрать? Пример из буквально вчера: с завтрашнего дня мы подписались на некий поток данных, около 500 сообщений в секунду, каждое по полкило весом. Мы их хотим хранить, быстро по ним искать (и через год тоже), и по факту прихода какого-нибудь особенного (точный критерий «особенности» пока не точно определен) — должен срабатывать триггер, и вестись выборка из другого списка, в котором предполагается хранить подписчиков.
Предлагайте ваш алгоритм (и заодно тип хранилища данных, варианты оповещений, инфраструктуру). Вы ошибетесь с гарантией 100%. Пока оно не пошуршит в продакшене пару месяцев, пока размер этого добра не перевалит за сотню гигов — любое гадание на кофейной гуще довольно бессмысленно.
Это не выдуманная задача, это типовая задача. Но и не отсортировать сто элементов в дереве, конечно.
VolCh
10.03.2017 16:29Недостаточно четко поставленная задача. Формат и структура сообщений, например, какой? По чему искать будем? Насколько критичны несрабатывания триггеров? А двойные срабатывания? Должен ли сохраняться порядок сообщений? Допустимо ли, что триггер сработал, но сообщение не сохранилось? Что делать если ошибка в триггере?
В любом случае, опыт подсказывает, что просто хранить их в "сыром" виде в одном файле и искать по регулярке "фуллсканом" будет недостаточно. Нужны алгоритмы более заточенные под хранение больших данных и поиска в них. Через два месяца в продакшене (может быстрее, может дольше) будет ясно насколько удачно было выбрано решение, но простое в лоб не проработает и дня, наверное. Хоть какая-то оптимизация поиска по сравнению с полным перебором простого потока данных тут явно требуется.
am-amotion-city
10.03.2017 18:30-1Я теряюсь прямо.
Это не вы ли только что сказали «Именно» первым словом в комментарии на:
Опытный программист как раз заранее понимает последствия выбора того или иного решения, в том числе и по производительности. Я бы сказал с точностью до наоборот, в 99% случаев все узкие места прекрасно видны ещё на этапе проектирования.
? В том-то и дело, что непонятно какой формат и структура сообщений (то есть, сейчас-то понятно, но у другого провайдера они могут оказаться совершенно другими), по чему ичкать будем — тоже непонятно пока. Несрабатывания, как везде, критичны. Двойные — совсем плохо. И так далее.
Я ж говорю, как только мы про реальные боевые задачи начинаем разговаривать, а не про сортировку пузырьком — так терра совершенно инкогнита и заранее высосать из пальца правильный алгоритм почти никогда невозможно.
Да, совсем острые углы отсекаем, и взлетаем, как умеем. И уже в полете отказываемся от трациционных хранилищ данных, языков общего назначения, сами кропаем доморощенный поиск, который умеет только то, что нам надо, но умеет это очень хорошо и так далее.
Ну право слово, пусть аусорс за три копейки решает, как лучше деревья сортировать, а в реальной жизни алгоритмами не отделаешься, когда вокруг тридцать слабых звеньев и каждое норовит отвалиться по-своему.
Никогда узким местом не станет обход дерева, или сортировка.
DrPass
10.03.2017 18:59? В том-то и дело, что непонятно какой формат и структура сообщений (то есть, сейчас-то понятно, но у другого провайдера они могут оказаться совершенно другими), по чему ичкать будем — тоже непонятно пока. Несрабатывания, как везде, критичны. Двойные — совсем плохо. И так далее. Я ж говорю, как только мы про реальные боевые задачи начинаем разговаривать
Вы знаете, это «не реальная боевая задача». Я допускаю, что такое может быть, но описанный вами случай — это крайне редкое исключение, с которым в «реальных боевых задачах» практически никто никогда не сталкивается. Обычно подобные требования как раз формализованы, и форматы, объемы, запросы известны/согласованы.am-amotion-city
10.03.2017 19:35-1А у нас такое каждый день. Я тщательно выбирал работу, чтобы было интересно.
VolCh
10.03.2017 19:09Я вовсе не говорил о выборе оптимального (по неизвестным метрикам даже) решения на века для задачи со множеством неизвестных за 5 минут. Я как раз о "совсем острые углы отсекаем". В вашей задаче очевидно, например, что линейный поиск со сложностью O(N) загнется очень быстро.
qw1
10.03.2017 12:34Именно поэтому появился термин premature optimization
Есть ещё «предварительная пессимизация» :)
VMichael
10.03.2017 16:08Ну, если задача бизнеса покрасить всего 300 метров шоссе, то алгоритм Шлемиэля весьма подходит для этого.
khim
09.03.2017 18:08Это блять коммерческая разарботка, время — деньги
Именно так.
arr.sort() блядь и всё
А теперь давайте посчитаем. Пусть ваш подход «хуяк-хуяк и в продашн» привёл к тому, что нам требуется на одну миллисекунду больше для того, чтобы обратать запрос. И пусть у нас не слишком нагруженный сервис — 100K QPS (по нашим меркам — это средне). Можете примерно прикинуть сколько вам потребуется лишних машин, чтобы обрабатывать возросшую нагрузку? Или это для вас — слишком сложно тоже?
Эту ересь проходят на 1-3 курсе и потом любой прогер который занимается коммерческим программированием, а не решением олимпиадных\спортивных задачек успешно его забывает, в лучшем случает помнит только название.
Позиция такого «любого прогера» имеет имя: application engineer. Если вы идёте на позицию software engineerа, то извольте уж если не вспомнить Дейкстру, то хотя бы придумать.
Количество раз, когда его можно было бы с пользой применить — десяток раз в год, да. Но если вы «помните только название», то вы даже не задумаетесь о том, что вместо трёх вложенных циклов выполнящих миллион операций может быть что-то побыстрее!Fid
09.03.2017 18:50Когда такие задачи возникают, то тогда идёт ресёрч, анализ, оптимизация. сравнение нагрузки итп. Но блеа, если вы будете писать эту оптимизацию весь день, а не тупо arr.sort(), а у вас нагрузки не такие большие, а в 99% это так, то купить железку стоит дешевле, чем заплатить сотрудникам за написание этого кода дейкстры, анализ, оптимизацию и в конце концов контора с такой «оптимизацией» и перфекционистами тупо прогорит и все будут искать новую работу.
khim
09.03.2017 23:55Купить железку стоит дешевле, чем заплатить сотрудникам за написание этого кода дейкстры, анализ, оптимизацию и в конце концов контора с такой «оптимизацией» и перфекционистами тупо прогорит и все будут искать новую работу.
Очень рад, что вы так переживаете за финансовое состояние вашего будущего работодателя, но, может быть, всё-таки стоит предоставить этим заниматься людям, которые за это призваны отвечать?
Но блеа, если вы будете писать эту оптимизацию весь день, а не тупо arr.sort(), а у вас нагрузки не такие большие, а в 99% это так, то купить железку стоит дешевле.
Я прекрасно понимаю что подход «хуяк-хуяк и в продашн» и «любой прогер который занимается коммерческим программированием» тоже имеют право на существование. Но это не повод требовать от вашего будущего работодателя именно этого подхода. Если вам не нравятся подобные требования — вы всегда можете на работу к нему не устраиваться, ведь так?
Последние 10 с лишним лет «наша контора с «оптимизацией» и «перфектионистами»» вполне справляется с тем, чтобы получать вполне себе неплохую прибыль каждый год, так что перехода на «хуяк-хуяк и в продашн» мы в ближайшее время не ожидаем…Fid
10.03.2017 05:52Очень рад, что вы так переживаете за финансовое состояние вашего будущего работодателя, но, может быть, всё-таки стоит предоставить этим заниматься людям, которые за это призваны отвечать?
Если у вас стоит просто задача по сортировке и вы делаете её не 5 мин arr.sort(), а весь день — оптимизируете, ищете лучшее решение. То ПМ, начальство спросит какого хрена мы потратили не 1/12 человеко-часа, а допустим 8 часов = в 100 раз больше, то думаю вы долго не задержитесь в такой компании. Бизнесу пофиг на ваши алгоритмы, ему главное быстро закрывать задачи.
Я очень рад за вас, если это так. Но как по факту, как на известной картинке с Грефом:
На собеседовании: У нас хайлоад, мега оптимизированный код, мега оптимизация, мега параллелизм, мега аджайл, мега машин лёрнинг, мега бигдата, мега алгоритмы из диссертаций лучших учёных.
После собеседования: быстре быстрее, если вы не выльете это неоптимизированное дерьмо на прод к концу дня, то вас всех лишат премии или уволят.
Возможно вы приближены в владельцам/начальству и вы просто думаете что у вас всё оптимизировано перфекционистами, но наверняка другим сотрудникам просто похер, как говорится делай что говорит начальство и не лезь с предложениями по оптимизации. :Dkhim
10.03.2017 18:37Бизнесу пофиг на ваши алгоритмы, ему главное быстро закрывать задачи.
Ещё раз: не решайте, пожалуйста, за бизнес, что ему нужно, Ок? Он как-нибудь без вас разберётся.
После собеседования: быстре быстрее, если вы не выльете это неоптимизированное дерьмо на прод к концу дня, то вас всех лишат премии или уволят.
У нас скорее уволят если «выльется дерьмо на прод». Мой рекорд — changelist, который reviewился полгода. И вопросы там обсуждались как раз по эффективности применяемого алгоритма. Обычно, конечно, быстрее, но пара недель — вполне себе типичный срок если что-то нетривиальное делается.
То ПМ, начальство спросит какого хрена мы потратили не 1/12 человеко-часа, а допустим 8 часов = в 100 раз больше
Совершенно верно. Потому на сотню вызовов qsort у нас три или четыре места, где алгоритм реализован руками. И мы понимаем почему мы на эти места потратили в 100 раз больше.
А вот как собираетесь это понимать вы, если вы про всю эту «ересь» давно и благополучно забыли?Fid
10.03.2017 19:32Ещё раз: не решайте, пожалуйста, за бизнес, что ему нужно, Ок? Он как-нибудь без вас разберётся.
Я буду решать за бизнес, т.к. обычно владелец\инвестор\директор ничего не понимает в коде и смотрит в первую очередь на количество закрытых задачь и количество потраченных денег за зарплату, а не оптимизацию под капотом. А потом после 1 задачи с changelist на полгода всех увольняет т.к. только 1 задача сделана за полгода.
А вот как собираетесь это понимать вы, если вы про всю эту «ересь» давно и благополучно забыли?
Я их не забыл, я помню что они есть. По памяти конечно на 100% не воспроизведу, не если встанет задача то тут будет ресерч, подымание архивов с arxiv.org с лучшими алгоритмами и т.п. и бурление что и как лучше сделать. Просто как по мне — не надо изобретать велосипед, если алгоритм или код уже есть. Тут вопрос больше в деньгах. Полгода обсуждать и пилить оптимизацию или использовать встроенную sort(). А потом ревью через полгода, а что ты сделал для репа в свои годы за полгода, а ты «обсуждал», а сколько закрытых задачь — 1. Конечно эта оптимизация на полгода бужет сэкономить конторе очень много денег в далёкой перспективе, но думаю руководство не заметит что вы вообще что-то делали. И пиши потом заявление по собственному. :)
saboteur_kiev
10.03.2017 19:52Пожалуйста, не путайте директора/владельца/инвестора и бизнес (бизнес-аналитики, бизнес-пользователи, L1/L2 саппорт). Именно они выставляют вам требования и техническое задание.
Задача программиста — выполнять поставленные перед ним задачи. Если же вы архитектор, то ваша задача была обсуждать это все с бизнес-аналитиками, и вашим ПМ, а не ждать полгода, пока всех уволят.
С другой стороны, если заказчик совсем самодур, то может быть это был и не плохой вариант — уволиться и найти нормального.khim
10.03.2017 20:35С другой стороны, если заказчик совсем самодур, то может быть это был и не плохой вариант — уволиться и найти нормального.
По-моему тут не заказчик самодур, а исполнитель. Который за заказчика решает — какие задачи ему решать, как и когда.
khim
10.03.2017 20:25Я буду решать за бизнес, т.к. обычно владелец\инвестор\директор ничего не понимает в коде и смотрит в первую очередь на количество закрытых задачь и количество потраченных денег за зарплату, а не оптимизацию под капотом.
Нет — вы таки не будете. Потому что вас на работу не возьмут. И правильно сделают.
А потом после 1 задачи с changelist на полгода всех увольняет т.к. только 1 задача сделана за полгода.
Кто сказал что параллельно с этим changelist'ом не было других?
Просто как по мне — не надо изобретать велосипед, если алгоритм или код уже есть.
Этот вариант — тоже имеет право на существование. Но не там, где на собеседовании просят написать сортировку на листочке бумаги.
Тут вопрос больше в деньгах. Полгода обсуждать и пилить оптимизацию или использовать встроенную sort().
Совершенно верно. Но если вы «всё для себя решили» и решили, что «изобретать велосипед не нужно, пока с существующего все чемоданы не попадают», то, возможно, нам с вами не по пути.
greendimka
10.03.2017 22:31+2Я буду решать за бизнес
Гнать вас в шею, идиотов таких. Уже несколько случаев видел, когда компании доходили до банкрота из-за того, что CTO или прогеры с завышенным чувством "я самый умный" принимали решения за владельцев, а так же скрывали критически важную информацию, прикрываясь пресловутым "ничего не понимает в коде".
Откройте свою компанию, наймите людей, начните решать реальные бизнес задачи, и тогда увидите, как вы ошибаетесь.
Fid
11.03.2017 12:58-1В том то и дело, что решать — в смысле быстро делать задачи чтобы они обходились заказчику\начальнику\инвестору дёшево, а не так чтобы полгода писать одну задачу по сортировке, как это делал предыдущий товарищ khim, к этому времени у заказчика уже просто не будет денег на оплату команды, а команда будет искать новую работу. Хотя конечно подход имеет место быть чтобы вытягивать деньги из заказчика под предлогом оптимизации.
Компания открыта, люди наняты, решаем, не ошибаюсь.DrPass
11.03.2017 13:53+2В том то и дело, что решать — в смысле быстро делать задачи чтобы они обходились заказчику\начальнику\инвестору дёшево
А вы не спрашиваете у заказчика, как ему на самом деле надо, быстро и дёшево, или, например, чтобы качественно было? Или чтобы эксплуатация/сопровождение было дешевле, а не разработка?Fid
11.03.2017 14:32-2Спрашиваю. Все хотят дешёво. Но по заказчику видно, с какими целями он пришёл, крупный он или нет, будет ли он жопится из-за каждого потраченного часа или нет. Как правило об эксплуатации и сопровождении они начинают думать только уже после ввода в эксплуатацию проекта, а на этапе разработки жопятся из-за каждого часа, лишь бы всё работало «на соплях», типа потом допилим и не хотят слышать про будущее сопровождение.
khim
11.03.2017 19:25+2Вы явно пришли из какого-то другого мира. Мира, в котором есть какие-то мифические заказчики, которым нужно «дёшево и сердито».
Ну, может быть в вашем мире никому ничего и не нужно. Но есть ведь и другие миры! Ни у Mozilla Corporation, ни у какого-нибудь Yandex'а нет никаких заказчиков — и, соответственно, нет и «ввода в эксплуатацию проекта».
Я, собственно, из этого мира. Где софт создаётся годами, а эксплуатируется десятилетиями (постоянно при этом меняясь). И вот тут за «лишь бы всё работало «на соплях», типа потом допилим» по головке не погладят — ибо «допиливать» вам же нужно будет! А ещё оно ведь и упасть может — а это вообще катастрофа, так как ваши потенциальные пользователи могут «развернуться и уйти» — и повторно их вам привлечь будет ой как непросто.Am0ralist
12.03.2017 00:16-1Ага, яндес.диск, который имел очень занятный инсталятор?
Вроде как Яндекс.навигатор под андроидом с их найденной странной любовью к слежке за пользователем?
Гугл хром и хромиумы, которые до определенной версии не умели убирать за собой установочные пакеты (и выжирали у пользователя кучи гигабайт на диске С, особенно с учетом, что их у неопытных пользователей скапливалось штук по 5 разных)?
Как показывает практика, у тех, у кого нет прямых заказчиков относятся к своему софту не настолько уж утопично, как вы тут описываете.khim
12.03.2017 08:37Гугл хром и хромиумы, которые до определенной версии не умели убирать за собой установочные пакеты (и выжирали у пользователя кучи гигабайт на диске С, особенно с учетом, что их у неопытных пользователей скапливалось штук по 5 разных)?
Вот давайте не рассказывать сказок и ужасов, а? Уже хотя бы тот факт, что вы тут рассказываете про «хром и хромиумы» говорит о том, что вы говорите о предмете, которого не знаете совсем.
Хромиум вообще не имеет того компонента, на который вы жалуетесь, так что ошибок в нём не могло быть по определению. А что касается Хрома — так это как раз классика: Мы тестировали Windows 95, 95OSR2, 98, 98SE, Me, NT 4.0, 2000 и XP. Мы проводили тестирования с установленным IE 5.01, 5.5 или 6.0. Мы тестировали американские, испанские, французские, израильские и китайские версии Windows. Но мы не совсем ещё добрались до польских.
Как показывает практика, у тех, у кого нет прямых заказчиков относятся к своему софту не настолько уж утопично, как вы тут описываете.
Ляпы у всех случаются б но как показывает практика если бы те, у кого нет прямых заказчиков относились бы к софту так, как вы тут расписываете, то вместо того, чтобы получить «штук по 5 разных Хромов» вы бы не получили ни одного, так как версия «лишь бы всё работало «на соплях»» на пресловутой «польской Windows» попросту не заработала бы, а не оставляла бы ошмётки «где не положено».Am0ralist
12.03.2017 12:29Уже хотя бы тот факт, что вы тут рассказываете про «хром и хромиумы» говорит о том, что вы говорите о предмете, которого не знаете совсем.
О да, это были фантомные дистрибы в профиле юзера, которые мне привиделись. Конкретно это было из моей реальной практики, когда на компе, где резко кончилось место на диске С, несколько гигабайтов оказалось занято чисто дистрибами хрома и нескольких хромиумов, число которых было 3-4, и лежало это в их юзерпрофилях. С учетом, что подобное поведение я встречал неоднократно (просто не в настолько запущенных случаях) в определенный период несколько лет назад, то не надо мне рассказывать «сказки», чего могло и чего не могло быть.
как показывает практика если бы те, у кого нет прямых заказчиков относились бы к софту так, как вы тут расписываете,
Ссылка будет на то, как я расписываю здесь?
Я всего лишь один раз указал, что в реальности то, как расписываете вы — это тоже редкая утопия в мире ПО без конкретных заказчиков.
Ибо там как раз таки вал делают, чтоб конкуренты не обошли, у которых уже 100500 версия браузера вышла с кучей достаточно сырых ништяков, пока вы одну ошибку в чейнджлоге полгода правили.khim
12.03.2017 23:54Конкретно это было из моей реальной практики, когда на компе, где резко кончилось место на диске С, несколько гигабайтов оказалось занято чисто дистрибами хрома и нескольких хромиумов
Ещё раз: у Хромиума нет (и никогда не было) инсталлятора и автообновления.
Если вы обнаружили на машине 5 или 10 копий Хромиума, то это значит что кто-то скачал и поставил 5 или 10 версий Хромиума.
Согласитесь странно жаловаться на баги в компоненте которого в природе нет, да?
И этот же самый факт очень серьёзно намекает на то, что и с Хромом тоже не всё так просто — кто его знает кто и как там этот самый Хром ставил? Может они «усовершенствовать» систему решили и из автозагрузки компонент, который, помимо прочего, старые версии в фоновом режиме удаляет убрали — опять-таки: ССЗБ. Какой-нибудь идиотской «чистилкой реестра».
Если в половине случаев у вас совершенно точно вина не разработчиков Хрома, а в другой половине возможно не их вина — то я бы не стал такой случай рассматривать как доказательство того, что разработка Хрома ведётся по принципу «бац-бац — и в продукте».Am0ralist
13.03.2017 00:26Сейчас буду нарываться на минус в карму, но надоело:
То есть вот те файлы по не помню сколько мегабайт — это не инсталяторы хрома были, ага.
С указанием версий, угу.
В папках профилей этих самых хромов и хромиумов. Которые находятся в папках юзеров, в подпаках аппдата.
Десятками экзешников.
И ручками их туда неопытные пользователи писали!
Слушайте, как у вас складно получается выдумывать.
До этого вот вы выдумали наезд на то, как я тут что-то «расписывал» (с) и за него и не извинились, и не привели ссылку на мое негодное поведение.
Теперь еще выдумываете, что я не могу отделить то, что юзер творит от поведения программ.
Что ж, вот это я за пару минут в яндексе нашел:
http://5kopeek.blogspot.ru/2013/01/cleaning-disk-space-used-by-google-chrome.html
Это не говоря о том, что еще была фича с тем, что он еще и папки предыдущих установленных версий вместе с кешами сохранял (поискать за вас в яндексе ссылку на тостер?). Всех, блин, предыдущих установленных версий.
Итак, мне ждать от вас извинений за то, что вы меня уже дважды пытаетесь выставить идиотом?
PS. А не, вы до этого успели мне карму слить. Во всяком случае она изменилась практически синхронно с вашим комментом. Чего еще ждать от таких, как вы.Dionis_mgn
13.03.2017 10:55+2У вас очень правильный никнейм.
И в споре вы используете довольно подлый приём: подмену понятий. «Вот яндексы и гуглы пишут софт с багами — они быдлокодеры и вообще писать не умеют». Баги пишут все (сюрприз!). И вы тоже. И я. И Гугл и Майкрософт и Столман и Линус и…
Вы пытались понять, что вам сказал khim? Найдите любой оффициальный инсталятор Хромиума под венды. Как только получится — покажите.
Проблема с неудалением старых дистрибутивов может быть связана с проблемами в окружении. Вам это прямым текстом указали. Такие же проблемы могут быть у автора статьи, на которую вы сослались. Это так сложно понять? Зато брызгать сарказмом — это легко, да.
greendimka
13.03.2017 12:03До этого вот вы выдумали наезд на то, как я тут что-то «расписывал» (с)
Людей, которые в своём тексте пишут "(с)" после типо-цитат, воспринимают всерьёз, IMHO, лишь во вконтакте.
botyaslonim
10.03.2017 13:58Тут маленькое уточнение: это было собеседование на фронт-енд. Тут практически нереально повесить браузер с помощью неверного выбранного алгоритма обхода, если только это не что-то очень специфическое вроде работы с SVG. Есть просто огромная куча других способов убить производительность
qw1
10.03.2017 15:17Я думаю, даже на этой страничке, если выбрать квадратичный алгоритм (от количества комментариев), будет подтормаживать.
DistortNeo
10.03.2017 15:59Это да. Уже генерация списков из сотни элементов уже может заставить браузер серьёзно задуматься, если делать совсем по-простому, например, через append в jquery. По сравнению с этим способ сортировки этих списков на производительность действительно не влияет.
Cord
10.03.2017 00:09+2Вся соль в детализации требований, кто такой этот «программист».
Люди имеют в голове разные трактовки. При столкновении с чужим, отличным от своего, мнением возникает пресловутый когнитивный диссонанс, устранить который люди пытаются спором.
Вот на примере профессии «водитель».
1. Согласно ПДД
Водитель — лицо, управляющее каким-либо транспортным средством, погонщик, ведущий по дороге вьючных, верховых животных или стадо.
2. В бытовом понимании — водитель легковой или грузовой машины.
3. А еще есть водитель спортивного автомобиля.
Три этих трактовки под одним словом. И если пытаться требования к водителю спортивной машины предъявить рядовому водителю — это будет нелепо.
Так с чего же мы спорим о том, нужны алгоритмы или нет, или там знание определенных структур данных?
Точно так же
1. Если человек будет писать простые сайты на CMS — нафига ему алгоритмы? Гораздо важнее, чтобы он владел стэком front-endа, который сегодня переживает очередной бурный виток развития. Ибо за 1 день реакт или там ангулар не выучишь.
2. Если человек будет заниматься поддержкой и развитием, например, криптографического софта — его базовые алгоритмы, конечно, спросят. Но гораздо больше потенциальных работодателей будет интересовать знание матаппарата из соответствующей области (малая теорема Ферма какая-нибудь, гипотезу Танияма-Шимуры могут спросить ради интереса, или математику асимметричных алгоритмов шифрования типа RSA)
3. Если человека будут брать на Highload — скорее всего, спросят про архитектурный опыт. Про понимание, какие технологии он пробовал в боевых проектах, знает ли их слабые места (Redis, который забит весь, при падении не взлетит при перезагрузке сервера; какие-нибудь там распределенные файловые системы, тюнинг Postgres, или банальность, что нельзя кэш-файлы класть в одну папку — при огромном числе на определенных файловых системах читать оттуда будет очень долго).
4. Если человека будут брать на разработку SQL — спросят про индексы, про какие-то особенности работы оптимизаторов запросов, еще что-нибудь.
Ну а в конторы типа Гугла, Фейсбука и тд берут людей, которые имеют хорошее базовое фундаментальное образование — Computer Science + матан. Потому что да, там могут бросить человека и пилить фрэнд-фид в фейсбуке, и систему распознавания лиц на фотках, и даже вообще свою файловую систему или там транслятор PHP в плюсы / вариант виртуальной машины, чтобы не закупать 100500 новых серверов под растущий трафик.
И да, освоение базовой программы на уровне понимания дает гарантию, что у человека есть данные, такие, как талант к программированию в классическом понимании, хорошая память на технические штуки. Это дает гарантию, что мозги у него заточены от природы под такие задачи плюс в них вложено то, что должно быть вложено (=экономия средств компании на обучение).
В свою очередь можно сказать, что есть разные пути к успеху, и можно, не зная этих алгоритмов и не идя стандартным путем, при наличии большого таланта, сделать какой-нибудь крутой продукт (типа распознавания предметов или фильтрации спам-комментов — очень актуально, кстати), и тебя либо купят, либо возьмут вместе с командой.
tl;dr Конечным для компании является то, может ли человек решать задачи, которые будут перед ним вставать, хватит ли у него таланта и опыта. Отсеивают либо по стандартным параметрам (если освоил CS / матан => пойдет), либо по достижениям (успешные проекты на Гитхабе, или взлетевшие стартапы).
А вы, как кандидат, можете честно прикинуть, в чем вы сильны (или вас прет и вы можете стать сильны). И не пытаться втиснуться в прокрустово ложе чужих идеалов, а выбрать ваш путь.
Успехов вам в нашем нелегком деле. Ведь сегодня в мире — наше время.Cord
10.03.2017 00:11Кстати, почти год назад был похожий срач (цикличность истории?),
и я писал похожий по смыслу комментария пост
https://habrahabr.ru/post/279651/
khim
11.03.2017 19:44Вся соль в детализации требований, кто такой этот «программист».
Вы, конечно, правы. Когда мы долго и упорно обсуждаем статью, которая, на минуточку, посвящена процессу интервьюирования в Amazon'е, Facebook'е и Google, а потом в комментариях вдруг возникают заказчики, которым нужно дёшево, то я даже не знаю что об этом сказать…
Люди имеют в голове разные трактовки. При столкновении с чужим, отличным от своего, мнением возникает пресловутый когнитивный диссонанс, устранить который люди пытаются спором.
Ну не было у этих компаний заказчиков никогда! И не будет! Некому там «жопится из-за каждого потраченного часа»! А посчитать и припомнить убытки, которые фирма понесла из-за вашего «срезания углов» (или, наоборот, прибыль от того, что вы снизили потребности в железе) — вам могут. Уж не говоря о том, что руководителями этих компаний (у Amazon'а — подразделения) работают люди, знакомые с алгоритмами и программированием не по-наслышке.
Как можно обсуждать этот мир с позиций «заказчиков» и «ввода в эксплуатацию проекта»?
VolCh
На собеседованиях не требую синтаксической правильности, сразу говорю, что пишите псевдокод похожий на целевой язык. И не требую проверки всех граничных условий. Но прошу назвать некоторые, которые кодом не предусмотрены. В общем, относитесь к людям так, как хотите, чтобы они относились к вам. Гуглом пользоваться запрещаю.
exfizik
Граничные условия — это, кстати, хороший «дополнительный вопрос».
Lailore
В реальной работе тоже запрещаете?
TheShock
Если в реальной работе на каждый вопрос лезть в Гугл — очень долго результата ждать будут. Обычно без Гугла не могут любители СтекОверфлоу-дривен-девелопмента.
sergyx
«Вы так говорите, как будто это что-то плохое»(с) ))
TheShock
Что именно? Что человек не способен ни на что кроме СОДД? Мы ведь еще про собеседование говорим?
А чтобы понять, что решение на СО подходит для специфики — это тоже можно нагуглить? А недостатки решения, о которых не сказали, потому что для примера автора это не недостаток, а для нашего приложения это критично тоже на СО нагуглится?
Я пять лет собеседовал людей в свою команду для разработки игр на js в Варгейминге. И я знаю, что большинство решений на СО нельзя вставлять в свой код без предварительной подготовки?
От те все минусы указывают, что здесь значительно больше людей обиженных на окружающих за собственную неудачу на собеседовании, Чем людей, которые имеют реальный практический опыт с двух сторон — кандидата и собеседующего.
Ну от нагуглит он мне первый попавшийся более менее подходящий ответ. И что мне это даст для понимания, подходит ли в команду этот человек? Ведь это даже не покажет, понимает ли он — может просто неудачно вкладку открыл.
Люди думают, что если бы Гугл, то сразу же на синьйорные позиции, которые раньше имнедоступны были они бы сразу смогли устроится?
Неужели вы думаете, что технари, которые проводят собеседования такие идиоты? Что мы не можем отличить, когда человек запутался, потому что нервничает или забыл синтаксис, который ему подскажет иде от людей, которые просто слишком слабы для этой позиции?
Может для типичных сайтиков бездумный СОДД вполне подходит. А в чем-то менее типичное всегда есть своя специфика.
VMichael
Ну, тут не только люди с «другой» стороны баррикады.
Просто вы очень уж жесткую позицию занимаете.
В мире интернета, да без гугления?
Да и такое пренебрежение «для типичных сайтиков бездумный СОДД вполне подходит».
Почему же бездумный сразу? А вы попробуйте наклепать типичных сайтиков. Та еще работенка.
Не вижу ничего плохого в гуглении.
Это как была у нас бабушка, преподаватель высшей математики в институте.
Да, пользуйтесь, говорит, учебниками на экзамене, на здоровье, только сумейте задачи решить.
Ну да, будет по первой гуглить (если ближе никто не может отвлечься, что бы подсказать), потом будет гуглить меньше и меньше.
Хотя речь про таких себе «синьоров», которые прямо таки должны все знать. :)
Я правда по БД, обычно в новой команде больше времени уходит, что бы структуру базы уяснить, чем на гугление.
SurfCalavera
На физтeхe (во всяком случае в моe врeмя) на многих экзамeнах, включая по-моeму гос по физикe, официально можно было использовать учeбники. Это очeнь правильный подход и на рeальный рeзультат — провeрку понимания, а нe зубрeжки — никакого негативного влияния нe оказываeт.
VMichael
Согласен.
0xd34df00d
Только на письменных. На устных нельзя.
SurfCalavera
не буду спорить, давно все ж было. но на устных тоже на определения/стандартные решения вопросов вроде не было никогда, скорее «ну на билет вы ответили, это ясно, давайте-ка просто поговорим». тут уж никакой учебник не спасет.
но это наверное оффтоп злостный уже.
Dionis_mgn
На собеседовании Вас не просят вспомнить алгоритм. Вас просят его реализовать. Это простая проверка Вашей способности выразить что-то простое на целевом ЯП.
Если Вы решили вспоминать алгоритм на собеседовании — Вы, скорее, его завалили. ИМХО.
VolCh
Ну и проверка на адекватность. Если не помнишь, то нужно просить описание алгоритма, а не пытаться натужно его вспомнить.
opencloser
не знаю, на чем вы пишите и какие задачи выполняете, но я тоже не помню когда последний раз писал сортировку пузырьком(наверное школе), но я легко могу восстановить алгоритм, т.к. его не нужно помнить если понимаешь его суть.
Quilin
Это потому что сортировка пузырьком — наивный алгоритм. А сможете описать суть например БПФ?
khim
Хотя для интервью (волнение, руки дрожат, голова «кипит») это всё же сложновато IMO.
Quilin
Возможно, распишусь в собственной неполноценности, но думаю, что для меня этого было бы недостаточно. И не думаю, что это так уж плохо. В конце концов, программисты в реальности сильно отличаются от голливудских программистов. Никто и никогда не сидит с таймером, чтобы в последние десять секунд успеть написать квиксорт, чтобы остановить ядерный взрыв (или даже задеплоить хотфикс). Если программисту для подобных вещей надо будет заглянуть в гугл, это не страшно, на мой взгляд.
opencloser
Если Вы о преобразовании Фурье, то с точки зрения математики, еще не успел забыть с университета, а вот с точки зрения программирования мне не приходилось сталкиваться, сомневаюсь, что я решил бы эффективно подобную задачу, без подглядывания в умные книжки.
Dionis_mgn
Собственно, я именно это и сказал =) Необходимости помнить эти алгоритмы — нет. В ряде случаев даже нормально не знать их суть. Например, требовать от JS-программиста знать суть QSort/MergeSort/etc — очень странно. Но если он не смог за полчаса ни один алгоритм сортировки сочинить… Ну я бы не хотел с таким JS-разработчиком работать.
Strowitzki
СОДД — что это?
VMichael
СтекОверфлоу-дривен-девелопмент
zip_zero
Насчет типичных сайтиков и бездумного SODD.
К примеру, реальная задача: есть легаси REST сервис, который крутится на Tomcat и есть HTTP-клиент для этого сервиса. Вместо русского текста: сервис возвращает краказябры, клиент возвращает краказябры, в логах краказябры. Поэтому нужно начать везде использовать UTF-8 и проверить, что это действительно так.
Как решал бы здоровый человек — убедился бы, что:
1. БД использует правильный collation (ага, гуглим какой для кириллицы:
Cyrillic_General_CI_AS);2. JDBC-драйвер использует UTF-8 (ага, гуглим параметры инициализации:
useUnicode=true;characterEncoding=UTF-8);3. установил кодировку сервлета в параметрах Tomcat (снова гуглим, выясняется:
URIEncoding="UTF-8"в настроечном файле);4. на этом этапе сервис начинает работать нормально, гуглим про клиента. По умолчанию он общается с сервисом в Latin1, документация подсказывает второй параметр в конструкторе про кодировку. ОК.
5. и вишенка на торте — ставим везде UTF-8 в логах:
На все ушло порядка 10 минут, с проверкой на каждом этапе. А вы здесь говорите про «бездумное гугление». Я понимаю, для кого-то не проблема переключить в голове пять разных технологий, но блин. Кто-то пишет калькуляторы, а кто-то — компиляторы. Это нормально.
VolCh
По сути это всё не задачи разработчика, максимум вынести параметры инициализации в конфиги.
Quilin
Вот игра в responsibility-ping-pong отнимает в разы больше времени чем гугление.
VolCh
Я про то, что это не SODD, задача к разработке мало отношения имеет, это диагностика проблемы эксплуатации.
qw1
Не важно. Так же могут придираться к работе админа. Мол, ты должен все настройки по памяти помнить. Ну или встроенный man читай. Если начал гуглить — провалился.
Cord
Классная фраза, я бы взял как заголовок даже.
greendimka
Я и сам предпочитаю досконально изучить какой-либо вопрос, а не пользоваться поверхностными ответами. Но мои желания и мои возможности не всегда совпадают. Стековерфлоу дривен девелопмент экономит уйму времени, не только когда нужно быстро что-то вспомнить, но и когда сталкиваешься с «неизвестной территорией». Мы живём в конкурентном мире. Если вы не станете пользоваться имеющимися средствами экономии, за вас ими воспользкются ваши конкуренты.
TheShock
А если собрать команду, которая без гугла шагу ступить не может, то вам потом сольют репутацию, заберут назад деньги и ничего не купят несмотря на то, что вы зарезились раньше конкурентов и в удачную дату.
СО хорош чтобы подсмотреть дополнительное мнение, если у разработчика есть свое. Если разработчик неспособен без СО даже поговорить на собеседовании с другим технарем, то он может подойти разве что на вакансию джуна или слабого мидла.
Не забывайте, мы сейчас говорим именно про собеседования.
greendimka
"Если разработчик неспособен без СО даже поговорить на собеседовании с другим технарем" — мне кажется такой разработчик и на СО вопрос сформулировать не сможет.
VMichael
А что, в приведенном вами примере про Бетмена, была именно такая команда, которая без гугла шагу ступить не могла? Вы это точно знаете? Если да, расскажите. плиз, интересно.
zip_zero
Долго ждать результата будут, если НЕ лезть в Google.
Если вы считаете иначе — либо у вас феноменальная память, либо слишком простая работа.
TheShock
Вы б посмотрели мои статьи, что-ли, перед тем, Как предположения делать
0xd34df00d
Посмотрел. Согласился с предыдущим оратором.
RussDragon
Всегда казалось, что в наше время 80% навыков программиста/инженера – умение думать и добывать необходимую для задачи информацию, и только оставшиеся 20 – знания какого-либо языка или технологии. ИМХО, конечно.
TheShock
Зачем вы подменяете понятия «умение думать» и «умение нагуглить ответ на вопрос»? Как раз никто не приносит с собой на собеседование ноутбук и не предлагает пользоваться гуглом, потому что хочется проверить умение думать.
Или вы думаете, что я, как собеседующий — это такой робот, который сверяет, совпадает ли ответ с листочком и если нет, то отказывает даже талантливому кандидату?
RussDragon
Простите, конечно, но с каких пор умение искать и добывать информацию в доступных источниках перестало быть умственной деятельностью? Честно, я не представляю разработчика, который был бы высококлассным специалистом и при этом бы не пользовался на работе гуглом.
IvanPulo
Конечно умственная, но это то что отличает инженера от кодерочка.
RomanArzumanyan
Ходил на собеседования с ноутбуком. Сажали в комнату на 40 минут с Wi-fi и гуглом и просили написать код для алгоритмической задачи. Это и есть проверка умственных способностей инженера: из подручных средств собрать работающее решение конкретной проблемы.
Да и вообще — полным полно таких задач, на которые было бы неплохо найти хоть какое-нибудь решение, а потом уже его совершенствовать.
areht
> Зачем вы подменяете понятия «умение думать» и «умение нагуглить ответ на вопрос»?
Я думаю есть вопросы над которыми надо думать, а есть вопросы, которые надо гуглить. И это разные вопросы. Вы на собеседовании какие задаёте?
DrPass
Ну так «в продакшене» и на собеседовании требования к вопросам различаются. Тот же «написать алгоритм чего-то» в боевых условиях предполагает нагуглить и проверить реализацию, а на собеседовании означает «пошевелить мозгами и придумать реализацию самому».
areht
> требования к вопросам различаются
К ответам?
Если требования на собеседовании отличаются, значит отбирать вы будете не тех, кто нужен в продакшене. Конкретно с вашим примером — велосипедостроителей. А приличный человек на такой вопрос может и обидеться.
Задавать вопросы на собеседовании — это как KPI выставить. Что попросите, то и получите.
DrPass
К вопросам.
Нет. Конкретно с моим примером — программистов :)
Вы, (если вы программист, конечно), должны прекрасно понимать, что такое абстракция. Задание на собеседовании — абстракция, которая показывает умение программиста решать задачи какого-то там типа. Реализовать, грубо говоря, хеш-таблицу на собеседовании — это не означает, что выполнивший это задание программист способен делать только хеш-таблицы, и ничего более, и если его посадить за разработку, он будет переписывать хеш-таблицы, алгоритмы сортировки и поиска по ключу. Это всего лишь значит, что он умеет придумывать алгоритмы, а значит, в принципе профпригоден.
Ну, не приличный, а слишком нежный. Взрослый человек переживёт, не помрёт. Вы же, приглашая на собеседование человека, которого не видели в работе и не имеете по нему рекомендаций, не можете знать заранее, так ли он крут, как написал в резюме.
areht
> Это всего лишь значит, что он умеет придумывать алгоритмы, а значит, в принципе профпригоден
В целом, велосипедостроитель — профпригодный программист. Не эффективный, но профпригодный.
Только вот по хеш-таблице нельзя сделать вывод о том, что он умеет придумывать алгоритм. Он его вспомнил. Его на прошлом собеседовании тоже хеш-таблицу спрашивали, а на позапрошлом — пузырёк.
> Взрослый человек переживёт, не помрёт.
Конечно не помрёт. Но лично у меня некоторые собеседования вызывают неприязнь, а другие интригуют. Если я прихожу и вижу темный подвал, 17" мониторы и странные вопросы на собеседовании — я туда работать не пойду.
Ну конкретно написать хеш-таблицу — это не странный, но очень скучный вопрос.
DrPass
Может быть и вспомнил. Если вдруг это стало трендом и спрашивают везде, конечно. Я, например, не вспомню, я просто знаю принцип и буду придумывать, если спросят. Но практика показывает, что трендом не стало, и даже банальный пузырёк люди обычно выводят, а не вспоминают.
А если вы приходите, видите обычный офис, 24" мониторы, и у вас просят написать алгоритм — вас это меньше пугает, чем тёмный подвал и 17" мониторы?
Ну извините. Если что, попросите собеседующего рассказывать вам анекдоты ;)
areht
> и даже банальный пузырёк люди обычно выводят, а не вспоминают.
Лично мне хватает хитрости притвориться, что я «вывожу» )
Если собирать бинго для собеседования, то пузырёк, хеш и синглтон там точно будут.
> А если вы приходите, видите обычный офис, 24" мониторы, и у вас просят написать алгоритм — вас это меньше пугает, чем тёмный подвал и 17" мониторы?
Да, меньше. Но при прочих равных, что я пойду работать не туда, а в офис класса А с 2 27" мониторами. И где анекдоты рассказывают.
И смузи на халявуgreendimka
Вступлюсь за TheShock. Человек, вообще-то дело говорит.
К примеру, я сам не помню ни одной реализации алгоритмов сортировки. Оно мне не нужно по специфике работы.
Но, если понадобится, то я отлично знаю, где мне достать реализацию этих алгоритмов — гугл и СО.
А вот по каким критериям выбрать наиболее подходящий, отшлифовать его, и правильно применить мне помогут мои знания в голове. Их на СО быстро не схватишь. Они пришли из книг, из мануалов. Именно эти знания помогают моим продуктам работать, а не загибаться, моля о том, чтоб их пристрелили.
Зазубрить 3 разных алгоритма — круто, но бесполезно, если не знать, что такое, узко говоря, вычислительная сложность, а широко говоря — теория алгоритмов.
И в этом кардинальный минус СтекОверфлоу-дривен-девелопмента. Люди собирают куски кода, лепят всё вместе, но не понимают почему, например, в финансовых операциях (и то — не всех) нужно использовать банковское, а не математическое округление: какое было в найдёном примере — то и возьмут.
Каждый второй новоиспечённый гэймдевелопер — это вчерашний дизайнер. Эти ребята проходят недельный курс С++, находят какую-нибудь биржу кода и контента, лепят лепят, а на выходе получают эффективный прожигатель заряда акума телефона. Им невдомёк, что сцена отрисовывается в несколько слоёв не просто так, а для повторного использования многих слоёв в последующих кадрах. Им — пофиг. Ведь можно взять куски кода, слепить их… уяк, уяк — в продакшн!
Они думают, что NoSQL решения реально круче RDBMS. Потому что маркетологи им так сказали. А спроси их что такое RDBMS? "британский бойз-бэнд, да?"
Широкий кругозор очень важен для любого программиста. Что мы имеем сегодня? Нежелание мыслить.
Кто смотрел сериал "Друзья", вспомнит отличную зарисовку: Джо взял хорошо написанное письмо, и каждое слово заменил тезаурусом на синоним. Каждое, отдельно от контекста. Получилась белиберда, хотя и смешная (https://www.youtube.com/watch?v=yGR78nzyznM).
Такой же нелепый результат получается и при использование СО/гугл, обладая лишь поверхностными знаниями. Продукт получается, вроде бы как проходящий по спецификации, но воняет жутко: мобильный апп — батарею сжирает, сайт визитка — проц на 100% загружает, сервер — дедлокит...
Будет хороший проект на JS, обращусь за помощью к TheShock — программистов с таким критическим образом мышления всё меньше остаётся в нашем, хипстерами пропитанном, мире.
symbix
Совершенно верно, есть большая разница между "помнить" и "понимать".
Без гугла моя работа будет менее эффективна не потому, что не хватает знаний, а потому, что знаю суть, но не помню деталей, и их намного быстрее нагуглить, чем вспоминать или выводить.
@TheShock просто неудачно сформулировал свою мысль, уверен, что он имел ввиду не такую ситуацию, а именно тупой копипаст с SO.
VMichael
Возможно в нашем мире задач требующих такой уровень столько нет?
Поэтому и проходит оптимизация, как и везде, в этой жизни.
Не требуется столько краснодеревщиков. Не все отращивают мышцы, как у Шварца, не все могут водить автомобиль, как гонщик Формулы… и т.д. Просто на всех не хватит такой работы, да может и не всем дано.
Зато вот «сайтики» или мебель стандартную, выпускают очень много людей.
Мир стремится достигнуть большего, при меньших затратах. Этот закон везде работает.
Ну, в самом деле, посадите TheShock клепать сайтики.
Он окажется не эффективен для этой работы, по параметру цена/качество, потому, что слишком дорого стоит.
slavaZim
Не пойму понять, что за «СтекОверфлоу-дривен-девелопмент». На stackoverflow не принято просить, чтобы за тебя писали код или реализовывали какой-то функционал (помимо минусов, которые сразу прилетят, это напрямую противоречит правилам форума). На моем опыте, на SOF чаще всего обращаются с просьбой найти конкретную ошибку. Не уверен, что искать ошибку самому это всегда сильно быстрее, чем найти аналогичную ситуацию и ее решение (сильно сомневаюсь).
Neikist
Имеется ввиду нагуглить решение в виде вопроса и чьего то ответа на so, а потом его тупо скопипастить.
VolCh
Нет, конечно. Но там есть требование писать синтаксически правильный код :)
DrPass
Честно говоря, это разные вещи. Я, когда собеседую человека, тоже прошу написать алгоритм сортировки, и не даю пользоваться гуглом. И это я делаю не потому, что мне интересно, знает ли он алгоритмы сортировки. Мне не это интересно. Наоборот, я уверен, что кроме вчерашних студентов, их никто наизусть не помнит. Мне интересно, может ли он *придумать* алгоритм, т.е. умеет ли человек вообще программировать.
То, что он в реальной жизни сможет нагуглить сортировку, это и так понятно. А вот нагуглить алгоритм работы контроллера насосной станции, которые мы изготавливаем, он не сможет. У него будет блок-схема от инженера-гидравлика, и ему самому нужно будет сочинять алгоритм работы машины состояний и т.д. Вот это я и хочу увидеть на примере сортировки массива, способен ли человек взять задачу, разложить её на шаги и запрограммировать.
Divers
Не стебусь, но что даже в компанию, где пишут софт для насосов у вас есть возможность выбирать из нескольких кандидатов? Или вы спрашиваете про сортировку, и не важно отвечает или нет — все равно принят?
DrPass
Ну а чем софт для насосов принципиально отличается от софта, например, для смартфонов? Тем, что у такой установки разрешение экрана не FullHD, а всего 320х480 (я тут тоже не стебусь), и она не поддерживает блютус? Позвонить на неё, кстати, в принципе можно :) Она имеет ADSL-модем для телеметрии.
Мы же на эти задачи ищем не программистов с опытом работы с насосами, а программистов, имеющих опыт программирования микроконтроллеров. Обычное программирование промышленных контроллеров, ничего военного и уникального.
VolCh
Навскидку я писал непубличный софт для:
Это не считая "сайтиков", краулеров, конверторов и т. п., где предметная область по сути чистая информатика — взять информацию в одном виде и показать/сохранить её в другом. И без них минимум с десяток программно-аппаратных платформ (включая гетерогенные сети на экзотических ныне основах) по 2-3 языка на каждую часто.
Неужели думаете, что какие-то насосы (пускай даже несущие угрозу миллионам людям) меня испугают, а DrPass откажет мне лишь потому, что у меня нет опыта работы конкретно с насосами?
TheShock
+1. На доске код можно писать очень сокращенно, если все детально устно комментировать. Например, для js и разговора о композиции вполне пойдет такой код:
С точки зрения языка тут много ошибок, но если вы понимаете тему настолько, что можете устно объяснить ее — это очень легко.
TheShock
Конечно, Если речь о разговоре хотя бы на мидла или синиора и понятно, что синтаксис человек знает. Никогда джунов не нанимал, а там слегка другие законы, но вполне возможно, что мне бы захотелось проверить, что человек правда знает основы синтаксиса.
Psih
Сортировку я писал последний раз в 2005 году, на Pascal.
За всю мою карьеру мне каким либо алгоритмом, который нужно было реализовать самому, пришлось сталкиваться 2 раза. Оба раза гугл помог мне найти гораздо более лучшее решение, нежели я бы написал сам.
После 12 лет в деле, написать сортировку на доске звучит как оскорбление. Вам надо сортировки писать, или вам нужно что-бы кто-то исправил ваше приложение, которое заваливает 5 серверов, где должен справиться 1 веб сервер + сервер базы данных?
khim
Psih
Если вы ищите человека по алгоритмам, вы пишите это в объявление о найме, а не говорите об этом на собеседовании.
К тому же, если мы говорим о 500 серверах, то о сортировке пузырьком спрашивать вообще глупо.
Давайте не будем мешать тёплое с мягким — мы говорим не только о разных позициях, но и о разных уровнях, типах задач и инструментах.
Я не работаю с алгоритмами, я не планирую с ними работать и лезть в науку или обработку огромных массивов данных — это не моя область. Если мне понадобится это делать — я найму специалиста, который этому посвятил свою карьеру.
khim
Почему глупо? Вы можете себе представить человека способного создать распределённую сортировку на кластере в 10000 машин, но не способного написать пресловутый «пузырёк»? Я — нет. Никто же не говорит о том, что вы должны уметь писать только пузырёк!
VolCh
Простите, а кем вы работаете? Не программистом же, ведь бОльшая часть работы обычного программиста и состоит в реализации алгоритмов, когда поданных сверху, когда придуманных самим. Весь написанный нами код (по крайней мере императивный) и является записью алгоритмов в конкретной нотации, будь то PHP, C, Assembler или Python, записью последовательности действий по достижению нужного выходного состояния при определенном входном.
michael_vostrikov
Одно дело придумать алгоритм для решения бизнес-задачи, и совсем другое сделать свою реализацию алгоритма для решения технической задачи.
VolCh
Если вы только придумываете алгоритмы, но их не реализуете, то вы не программист, а, например, аналитик, который ставит задачи программистам.
michael_vostrikov
* Придумать конечно означает придумать как реализовать и реализовать. Разговор ведь про программирование.
Я о том, что «реализовать алгоритм оформления заказов» и «реализовать алгоритм сортировки с вот такой сложностью» это разные понятия «реализовать алгоритм». Первая бизнес-задача, вторая техническая. Реализации первых используют реализацию вторых. И вот реализацию вторых во многих случаях делать не надо, потому что они уже есть в виде библиотек или встроенных возможностей.
DrPass
Вообще, нет. Это просто разные предметные области. А суть работы одна и та же. Может быть, сложность конкретной задачи отличаться. Причём не факт, что оформление заказов будет проще — например, если в процессе присутствует функция расчета автоматического дозаказа.
michael_vostrikov
Если бы это было так, никто бы не давал задачи на алгоритмику. Проверяли бы только ООП и умение закодить задачу.
Вот про это многие и говорят, а другие говорят, что это и не программирование вовсе)
VolCh
Следует различать задачи на алгоритмику ("реализовать сортировку с временной сложностью O(n*log n)", "реализовать воркфлоу заказа с такими-то ограничениями"), то есть на придумывание или поиск готовых алгоритмов, и задачи на реализацию готовых алгоритмов ("реализовать сортировку массивом пузырьком", "реализовать воркфлоу заказа конечным автоматом с таким-то графом переходов статуса заказа")
VolCh
Не согласен. По крайней мере в случае обычного разработчика, пускай и уровня выше среднего ("сеньора"), но без исполнения функций аналитика.
И там, и там на входе алгоритм, оперирующий какими-то сущностями и задача разработчика перевести его в код. Если разработчик не может реализовать алгоритм сортировки таких простых сущностей как коллекция целых чисел, то можно ли его подпускать к более сложным типа товаров в корзине покупателя интернет-магазина?
michael_vostrikov
Опять же, одно дело любая сортировка, которая решает задачу (сортирует), и другое конкретный алгоритм с конкретной сложностью и требованиями по памяти. Одно дело, когда дается полное описание алгоритма, и надо по нему написать код, и другое, когда дается название, а описание и характеристики должен сказать разработчик на собеседовании и без гугла.
VolCh
Как кандидат реально сталкивался с ситуациями когда даётся название, а полное описание по вопросу: "деталей не помню, вам по памяти писать или не тратить время вообще"? Подход понравился, использую теперь с другой стороны баррикад :)
saboteur_kiev
Заменим «алгоритм сортировки» на «алгоритм хеширования», И вот уже 90% программистов отсеивается из программистов.
Заменим на «алгоритм шифрования», желательно каким-либо более устойчивым, чем SHA1, и останется 1% тех, кто собственно работал в разработке алгоритмов шифрования.
Давайте не будем цепляться к словам — понятно же, что человек писал не об алгоритмах вообще, а именно о технических алгоритмах, которые есть не на SODD а в виде best practice.
VolCh
Да в том-то и дело, что нормальный программист должен уметь на бумаге набросать алгоритмы сортировки, хеширования и шифрования. Неоптимальные, работающие только на простейших случаях, но должен.
saboteur_kiev
Я еще пойму, если нужно написать простейший работающий алгоритм пузырьковой сортировки. Его действительно можно использовать.
Но зачем писать простейший, пусть даже работающий, но совершенно небезопасный алгоритм шифрования, который в принципе не рекомендовалось бы использовать даже в хобби-проектах?
Проще спросить на словах, чтобы человек пояснил теорию что такое соль и как ее применять, что такое коллизию и привел пример. Но просто писать на бумаге, пусть даже псевдокодом…
В общем окей, у каждого свое видение как подбирать команду.
VolCh
Просто проверить способность человека из вольного описания алгоритма создать его формальное описание на псевдокоде, близкому к целевому языку.
DistortNeo
Устроят ли тогда такие ответы: сортировка — пузырёк; хэширование — разбиение данных на блоки по 4 байта и последующий XOR, шифрование — XOR 4-байтных блоков с фиксированным ключом?
Или нужно блеснуть знаниями и вспомнить, как вычисляется MD5 или SHA1, вспомнить, как работают RSA и AES? Особенно при условии, что на практике будут использоваться только библиотечные реализации этих алгоритмов.
VolCh
Устроят.
TheShock
SHA1 как раз алгоритм хеширования, а не шифрования.
c0rp
Мне кажется умение делать исследование вопроса — лучшее качество для разработчика. Например можно понаблюдать как человек это делает. Выбирает первый попавшийся ответ или сравнивает с другими. Сверяется ли потом с документацией. Правильно ли задает вопросы? Может ли объяснить ответ, который он выбрал. Поделитесь пожалуйста, что за мотивация запрещать гуглить?
Dreyk
как жаль, что таких людей мало среди интервьюеров =)
VolCh
Отсеивать тех, кто понимает, что без Гугла он ничего сделать не сможет в рамках целевого языка. Опять же по себе сужу. С гуглом я на абсолютно незнакомом языке (со хорошо знакомой парадигмой типа ПП и ООП) скорее всего решу какую-то простую задачу типа пузырьковой сортировки за разумное время.
aamonster
Проверка разных навыков. Для проверки, что человек может сделать, когда у него все инструменты под рукой — есть тестовое задание, которое можно решить дома.
А задачки на доске/на листочке, теоретически, нужны лишь для того, чтобы поговорить о решении (ну не дашь для этого сложную задачку, зато возможности адаптации решения — хорошая тема для разговора). Но на практике — почему-то люди на них отсеиваются (в примере с сортировкой — как если бы человек не то что не воспроизвёл по памяти quick sort или пузырёк, но даже не смог бы на коленке придумать хоть какую-то сортировку за O(n?) или написал вместо неё slow sort)
khim
Перед тем как оценивать вашу способность решать сложные, творческие задачи и разбираться в хитрых хитростях (с Гуглом, конечно, куда ж без него) нужно убедиться в том, что вы простейшую, самую тривиальную задачу не решите так, что потом нужно будет консилиум собирать, чтобы разрушения чинить.
Просто потому что если вы «увязните» в сложной задаче — у нас найдутся десятки, сотни людей, которые смогут вам помочь и разобраться. А вот если вы «налажаете» в чём-то простом… то может оказаться что два датацентра встанут и мы получим убытки примерно в размере вашей зарплаты за 100 лет.
Вот и всё. Как вы умеете решать сложные задачи — несомненно важно, но куда важнее — знать умеете ли вы решать задачи простые.
c0rp
Спасибо! Вы заставили задуматься об этом в другом ракурсе. Никогда не смотрел на собеседование с такой точки зрения.
Около месяца назад смотрел выступление на тедтолкс, где человек говорил тоже самое. https://youtu.be/YyXRYgjQXX0. Его выступление конечно же не про собеседование разработчиков, но про собеседования вообще. Забавно, но только сейчас я понял его совет.
Он говорит что при собеседовании важнее исключить неподходящих людей, чем пропустить подходящего. Можно сказать что False Positive ошибка предпочтительнее, чем False Negative при стремлении недопустить в команду неправильных людей.
guai
отсеять откровенно некомпетентный народ может и сам хр без технического народа.
у вас правда в конторе десятки-сотни народу ничем не занимаются, только решают чужие проблемы? и они вот прям самые скиллованные из всех?
или всё-таки у них есть свои задачи, от которых еще надо оторваться, въехать в чужую проблему, решить ее, а потом опять вспоминать свою задачу столько же времени?
c0rp
У нас принято помогать друг другу. И да, чаще всего помогают самые скиллованные. Они не делают это все время, у них есть и своя работа. Взаимопомощь и код ревью укрепляет отношения внутри команды. Благодаря этому джуны и мидлы боятся сделать что-то плохо, нечитаемо или неверно. А главное, они не бояться задавать вопросы. И в этом стремлении писать хорошо их мотивирует совсем не бизнес, а что-то другое, чисто человеческое. Если никто не будет помогать, ничего этого не будет. Будет тупое производство кода.
Зря вы зацепились за гиверов и тейкеров, тут вопрос не о людях и их работе, а о целях собеседования. я не имел ввиду что нужно переложить концепцию выявления гиверов при собеседовании разработчиков. Я имел ввиду что идея «лучше отсеять вредителей, чем не нанять приносящего пользу» мне понравилась. Как это делать совсем другой вопрос.
guai
ну конечно, если проверять то, что в работе на хрен не надо, на собеседовании, и не проверять нужные скиллы, неизбежно возникнет необходимость хотя бы снизить процент полной лажи. тогда да, принять недоумка хуже, чем не упустить гения. особенно если это что-то типа госконторы, из которого этого недоумка потом сложно уволить.
но почему бы просто не проверять нужные навыки сразу, а не придумывать под это идеологию какую-то?
я вижу в этом необходимость только в том случае, если это какое-то двойное слепое собеседование :) так нет же, соискатели тоже заинтересованы в том, чтоб не ходить на заведомо неподходящее собеседование и прийти на перспективное, и в резюме они обычно пишут, что умеют
я как-то раз видел со стороны собеседование, где человека спрашивали, знает ли он, что такое переменные.
и интервьюерами в этом случае были мужик из заводского цеха и какой-то абстрактный начальник. то есть полная лажа со стороны hr.
вот только в этом случае я вижу плюсы от проверки пузырька
khim
И как вы их предлагаете отсеивать?
Ещё раз: потому что важнее не то, что кандидат умеет делать, а то чего он не умеет — но пытается.
Вы вообще сколько людей в своей жизни проинтервьюировали? За исключением тех, которых вам знакомые порекомендовали?
А если я вам скажу что на телефонном интервью больше половины соискателей не могут написать ничего? Ну вот совсем ничего — ни FuzzBuzz, ни пузырка, ни чего-либо подобного?
zip_zero
Вот я — на бумажке не смогу написать ничего — ни физбаз, ни пузырька. Ни на одном языке программирования. Уверяю с честными глазами, что знаю их три, а основной — один.
Давайте обсудим:
1. с какой стороны меня это характеризует как специалиста?
2. чем плохо для компаний меня нанимать?
DrPass
Либо вы в любой мало-мальски сложной ситуации теряетесь, либо вы действительно так себе специалист. Для меня непонятно, как можно не написать тот же самый физбаз на бумажке, если человек знает хоть какой язык программирования. Синтаксис циклов, условий и определения массивов — это штука, которая в любом случае должна быть в голове, а не в гугле. Разработчик без локального кеша самых основных знаний так же неконкурентоспособен, как и процессор без кеша.
Ну как минимум риски выше, чем в случае кандидатов без этих проблем.
zip_zero
С позиции «нужно рассудить и решить здесь и сейчас» вы правы, но есть подвох.
Если встретите кандидата, который не может написать физбаз, спросите его номер телефона, день рождения или что-нибудь еще, что он вроде «должен» знать. И удивитесь…
Люди разные. У кого-то собеседование вызывает заметный стресс и с каждым случаем нужно разбираться. Времени ровно час. Мы все куда-то спешим.
DrPass
Это абсолютно разумный критерий проверки, но есть нюанс. На собеседования же никто «с места в карьер» не скачет. Т.е. не бывает такого, что приходит кандидат, ему сразу говорят: «Берите ручку, первый вопрос физбаз, второй баблсорт. Садитесь, пишите, время пошло.»
Есть этап знакомства, есть этап общих вопросов. И когда доходит до практической задачки, уже и так прекрасно видно, кандидат растерян/перепуган, или нормально всё воспринимает. Поэтому и к результатам теста уже относишься вполне объективно.
khim
Разумеется есть. Потому писать пресловутый «пузырёк» они за вас не будут. А вот исправлять приложение, которое заваливает 500 серверов и с которым вы уже месяц совладать не можете — будут.
Потому умение вами самостоятельно справиться с пузырьком важнее, чем умение совладать с 500 серверами.
shir
А зачем вообще на собеседованиях просить что-то писать? Дайте тестовое задание похожее на то чем сотрудник будет заниматься на работе. Пусть дома спокойно сделает его и даст вам код. А вы так же спокойно никуда не торопясь посмотрите его. И пусть хоть чем пользуется. Какая разница в гугле он посмотрел алгоритм, в толстом бумажном справочнике или сам на ходу придумал, главное чтоб он задачу решал за отведенное время.
Мы на собеседовании вообще не просим решать какие-то задачи, т.к. у нас уже есть код который кандидат написал в качестве тестового задания и по нему очень хорошо видно его уровень.
Suvitruf
Проблема с тестовым в том, что неясно сколько по факту человек времени потратил на его решение. У нас был печальный опыт найма сотрудника, когда с тестовым он справился неплохо, а в итоге выяснилось, что этот человек работает в 3 раза медленнее остальных наших разработчиков.
zharikovpro
Есть как минимум два хороших способа засечь время для выполнения небольших задач и один — для больших.
1) Тесты на Codility
2) Посадить человека с ноутбуком за стол, дать задачу, засечь время
3) Дать человеку рабочую задачу за деньги и поставить дедлайн. Если выполнил вовремя и согласен продолжать за те же деньги — значит с большой вероятностью работает удовлетворительно.
Suvitruf
1) У нас тестовое на Unity3d.
2) На удалёнку ищем. Это, во-первых. Во-вторых, я бы как соискатель отказался от такого тестового, что за контроль такой? Недавняя история с устройством на работу в Амазон вспоминается; то ли тут, то ли на гиктаймс была статья. Как следствие, я бы таким образом явно не стал человеку тестовое давать. Это, как минимум, не слабый стресс для него.
3) Разработчик как правило ищет работу не в конкретную контору. При прочих равных, вряд ли он будет тратить время на тестовое в таких условиях.
zharikovpro
Да, в случае удаленки + Unity первые два варианта — не вариант :) По поводу третьего — меня удивляет ваш подход, честно говоря. Что значит «разработчик ищет работу не в конкретную контору»? Как это связано с тестовым заданием? Разработчик ищет работу, есть тестовое задание для этой работы.
> При прочих равных, вряд ли он будет тратить время на тестовое в таких условиях.
Ключевые слова в моем предложении — «за деньги». Что значит «в таких условиях»? Самые нормальные обычные рабочие условия. Есть работа за деньги. В вашем случае — удаленно, на Unity 3D.
VolCh
Разработчик выбирает одну работу из множества примерно одинаково заинтересовавших. В одних просят прийти на собеседование, в других просят сначала сделать тестовое задание, а потом прийти на собеседование. Зачем делать тестовое, если предложения одинаковые?
Suvitruf
Тут ещё дело не только в нежелании делать тестовое, но и в том, что в компанию, куда вы хотите устроиться, также и другие люди подаются.
В итоге, пока вы делаете тестовое (даже оплачиваемое) для одной компании, можете упустить рабочее место в другой. Вон у zagayevskiy можно спросить. Он несколько недель потратил на тестовое для ZeptoLab. За это время вакансию, где тестового нет, уже и закрыть могут. Правда, в его случае, он целенаправленно в ZeptoLab шёл…
VolCh
Лично для себя вижу два варианта, когда соглашусь делать тестовое не "на бумажке" прямо на собеседовании на 10-15 минут:
Tsimur_S
Второй вариант является разновидностью(входит в подмножество?) первого :)
VolCh
Скорее наоборот, например заметно выделяются среди рыночных предложение с условием "Кратко о себе: https://google.com"
t-nick
1) Codility — полный бред, даже хуже вопросов по алгоритмам у доски. Может там и можно создать свое уникальное задание, но те, что давали мне, были задачками далекими от реальных и представляли собой классические олимпиадные задачки. Все бы ничего, но в них очень много граничных условий, которые очень сложно продумать за отведенное время. В итоге получаешь очень низкий рейт из-за мелкой ошибки вроде (< вместо <=). Все задачи, что мне давали, гуглились. Это значит, что проходят эти задания не те, кто честно пытаются их решить, а обычные Stack Overflow Driven девелоперы или олимпиадники (которые часто не так хороши в разработке реальных проектов).
2) Довольно хороший подход из моего опыта как со стороны кандидата, так и со стороны собеседующего.
3) Тут уже зависит, есть ли подходящие задачи для такого аутсорса.
zharikovpro
Я несколько раз проходил тесты на Codility как первый этап. Потом переходили к пункту 2, обычно. И на этой стадии я нередко выяснял, что codility нужен чтобы отбраковать людей, которые совсем не умеют писать код и простейшие алгоритмы (никак олимпиад, например может быть простая функция для преобразования массива по заданному правилу). Без подобного отсева на следующие этапы, по утверждениям рекрутеров, будет тратиться неоправданно много ресурсов впустую. Есть же статьи в т.ч. на хабре про то, как много людей не умеют писать код, на примере FizzBuzz. Так что есть смысл сделать комбо. Быстрый отсев через Codility-like (задание поставьте хотя бы FizzBuzz), потом переход ко второму или третьему варианту.
t-nick
Отсеивать можно, но тут важно не перегнуть палку. Я проходил вроде бы 3 теста на Codility. Уровень сложности задач был от очень простых до реально олимпиадных, при чем время на олимпиадные было меньше, чем на простые. Однако даже для простых задач есть набор тестов, которые по сути должны являются требованиями, но вы о них ничего не знаете. Соответственно ваш код могу запустить, например, с массивом очень большой длины на которую вы не рассчитывали, а условие задачи об этом умалчивает, и вы получите очень низкий рейт. Некоторые даже давали второй шанс с указанием результатов, в котором был список тестов: зеленых и красных. Но в попытке пофиксить один тест можно с легкостью завалить два других (вы ведь не видите код теста, только его абстрактное название) и еще ухудшить рейт. На код обычно вообще не смотрят при этом, так как тест дает рекрутер (видимо даже не советуясь с нанимателем) и пропускает только основываясь на рейте.
symbix
С простыми задачками, которые писать три минуты, можно сделать проще — во время скайп-интервью попросить расшарить экран и написать код (конечно, надо заранее предупредить об этом, чтобы человек подготовил себе среду разработки). Быстрый отсев имеет смысл, только если у вас поток кандидатов огромный, а на таком отсеется процентов 80. Вряд ли это такой частый случай. Зато видно, что человек не гуглил готовое решение.
symbix
Гуглятся, кстати, зачастую неэффективные, брутфорсные решения, не удовлетворяющие требованиям по алгоритмической сложности.
Но то, что гуглится, позволяет сэкономить время: там часто удобнее сначала написать брутфорсный вариант, а потом уже искать "правильное" решение, используя брутфорсный в качестве теста. Гуглом можно сэкономить минут 5-10.
(То, что полный бред — не оспариваю и целиком согласен, см. мой коммент ниже.)
t-nick
В моем случае гуглились именно что правильные решения с учетом всех граничных условий. Я когда их находил, уже после отправки задания (пытался быть честным, да и интересно было самому решить), — сильно расстраивался, так как понимал, что рейт будет завален.
symbix
Я до отправки гуглил только последнюю, которую не решил. Когда нагуглил решение (причем это был не код, а статья об олимпиадной задаче и формула, описывающая суть решения) — офигел, понял, что у меня на это ушло бы часа три, реально олимпиадная мозгодробилка. Вместо решения поставил комментарий со ссылкой и написал, что копипастить не хочу, а сам решить не смог. :)
Первые две потом погуглил — правильных решений не нашел, одни брутфорсные. Видимо, свежие задачки попались. Я их решил, но в граничных условиях немного накосячил. Сразу после отправки понял, где, и написал об этом в емейле, проканало. :)
symbix
Codility — это вообще фигня бессмысленная. Умение решать околоолимпиадные задачки очень слабо коррелирует с умением решать прикладные задачи.
Я его прошел только потому, что хотел попасть на toptal, а там это стандартный этап отбора. Покоробило, но решил — что уж там, один раз — не гондурас. :) Была бы вакансия в какую-нибудь ничем особо не примечательную конторку — отказался бы сразу.
i360u
А что мешает человеку, выполнившему тестовое задание быстро, впоследствии работать медленнее остальных? Мой опыт говорит — ничего не мешает. Мой опыт также говорит, что медленнее — не значит хуже (если вы, конечно, не студия-потогонка). А вот детальное обсуждение результатов тестового задания, с дополнительными сопутствующими вопросами — дает отличное представление о том, что человек умеет и знает на самом деле.
Suvitruf
Я число 3 не просто так привёл. Этот сотрудник делал таски в 3 раза медленнее, а баги в его коде мы отлавливаем до сих пор.
Минус, безусловно, и в нашу сторону, у нас нет нормального процесса код ревью =\
Проблема в том, что тестовое должно быть не слишком большим. Как следствие, довольно сложные штуки туда не впихнёшь. Тестовое показывает, что человек владеет технологией/движком. А вот уже при работе с конкретными вещами на проекте возникают проблемы.
i360u
Тестовое задание любого объема должно включать в себя "скользкие места", которые, если даже не будут замечены, можно (нужно) будет разобрать при обсуждении.
Ну вот попался вам криворукий персонаж, это понятно, но почему из этого опыта вы делаете странный вывод о том, что скорость выполнения задания — главный параметр, по которому его стоило отсеять? ИМХО в Ваш случай — это чистый фейл того, кто проводил техническое интервью.
Suvitruf
i360u
Danik-ik
Я при устройстве на нынешнее место работы заранее знал, что смогу взяться за задание не раньше, чем через неделю — просто не было времени, работал (отделка, сантехника, всё такое, а дома нет возможности поставить MS SQL). Поэтому меня этот вопрос (демонстрация реально затраченного времени) затрагивал очень сильно. Так что неделю я потратил на анализ ТЗ на бумаге и задавал много вопросов — предупредив, впрочем, когда смогу реально приступить к проекту. А готовый проект отправил вместе с репозиторием (типа трекинг работы). В результате оказалось, что про Гит там ни сном, ни духом (мне, впрочем, разрешили — в моём единоличном ведении отдельное приложение), а решающую роль сыграли заданные вопрсы...
zharikovpro
> Минус, безусловно, и в нашу сторону, у нас нет нормального процесса код ревью
Кроме этого возможно, что нет грамотной постановки задачи, приемочных тестов с приличным code coverage и QA и т.д. и т.п.
> Проблема в том, что тестовое должно быть не слишком большим.
См. выше. Это не проблема, когда за уделенное вам время и предоставленные результаты вы начинаете платить деньги. Тогда «тестовое» задание может быть сколь угодно большим и сложным и результаты пойдут в работу. На самом деле это реальная работа. Просто посмотрев результаты вы либо примете человека в проект, либо нет. Вот и вся суть «теста».
Suvitruf
Мы над проектом более 3 лет работаем. Человеку только чтоб разобраться в нём, как минимум, пару дней потратить придётся. То есть, мы заплатим за неделю, а по факту за день работы. Таких соискателей несколько. Если не касаться вопроса денег, то это много времени занимает с нашей стороны, а команда у нас небольшая.
Это не фриланс заказ на какой-то небольшой скрипт, который работает и ладно.
zharikovpro
Тестовым заданием оторванным от работы протестить работу в проекте где неделю разбираться надо конечно не получится. Если у вас только неделю в работу въезжать надо… ну вы либо это оплачиваете работнику, либо продолжаете есть кактус, либо что-то меняете в процессе разработки (я НЕ утверждаю что он плохой, может действительно у вас там rocket science). Можно только посочувствовать.
И да — подбор хорошего программера в крупный/сложный проект занимает много времени. Ну а что делать. На периоде в год неудачный выбор принесет большие убытки, а удачный — большой профит, так что это все равно стоит того. Вы наверняка это и сами все понимаете, так что у нас наверное и нет спора как такового.
VolCh
1) Проблема вхождения в проект
2) Нет гарантий, что результаты пойдут в работу, а деньги платить надо. Предлагать же вариант "если мы возьмём вас на работу, то оплатим и время, потраченное на тестовое" очень похоже на развод, особенно если с десяток соискателей на одну позицию.
areht
> Просто посмотрев результаты вы либо примете человека в проект, либо нет. Вот и вся суть «теста».
Это суть испытательного срока
Xandrmoro
А человека, который делает таски в 3-5 (буквально) раз медленнее, но баги вылазят через полгода и связаны с неверно сформулированными в тз граничными условиями, а на ревью правится разве что кодстайл вы бы тоже не взяли?
Suvitruf
Вы какие-то абстрактные вопросы приводите, когда я конкретный пример привёл =\
Проблема была не в ТЗ, так как другой сотрудник по такому же ТЗ нормально всё сделал.
Xandrmoro
Но вы-то подаёте это так, как будто вообще не стоит брать разработчиков, которые не хреначат код нон-стопом и вообще скорость — главный параметр при собеседовании.
VolCh
Как неверно сформулированные в ТЗ граничные условия могут привести к багам в коде? Баг — неверно реализованное ТЗ, а если ТЗ не соответствует бизнес-задаче, но верно реализовано в коде, то баг в ТЗ, а не в коде.
shir
Мне кажется такие вещи скорее исключение чем правило. Мой опыт осмотра более сотни тестовых заданий показывает что если человек его нормально сделал то и задачи он делает нормально в том числе и по скорости, а те кто медленно работает у них и по тестовому были проблемы.
У нас был только один случай когда человек сделал на почти отлично тестовое задание, а потом не справлялся со своей работай. Но это стало понятно в первый же месяц испытательного строка и мы с ним быстро распрощались. Я так думаю что тестовое задание он просто не сам делал. Но это опять таки исключение. Чтоб отлавливать такие исключения есть испытательный срок.
tandzan
Я был пару раз на месте этого сотрудника — когда на проекте куча легаси, сакральные знания утеряны пару поколений программистов тому назад, либо они в головах "дедов", с которыми они делиться не хотят. Вы точно уверены, что ввели его в проект, или сразу винтовку в руки и на передовую?
unabl4
Медленно-то в каком плане? Набора кода или проектирования, продумывания архитектуры, уточнения требований и условий? Если второе — то это не плохо, а скорее даже хорошо. Если первое — это временное явление, которое с опытом нивелируется, выучит синтаксис, паттерны конетного языка (или набора языков) и т.д.
Suvitruf
1) Медленно набирает. Hot keys почти не использует. А человека мы нанимали изначально удалённо, про это узнали, только когда в офисе все вместе собрались.
Чем же хорошо? Я приведу конкретный пример. У нас в игре есть различные персонажи, у каждого свои спелы. Стояла задача сделать спелы для нового персонажа. Человек провозился несколько недель. Уже прошло несколько месяцев после увольнения, но баги то тут, то там всплывают.2)
Другой сотрудник для уже следующего нового персонажа сделал все спелы за пару дней. Ну да, сложность проектирования новых спелов +- может отличаться, но не в 3-4 раза по времени.
Error1024
Я почти не использую хоткеи в некоторых средах, где проще через гуй сделать что-то, что я теперь разработчик никакой из-за этого?
Suvitruf
Copy/paste тоже мышкой?
Error1024
Нет, хотя в редких случаях бывает мышкой.
Что меня бесит — так это когда некоторые функции можно использовать исключительно используя клавиатуру, некая «недоступность» для изучения/напоминания, ты просто должен запомнить все эти комбинации.
Suvitruf
Но я сомневаюсь, что у вас сильно производительность страдает от этого. Знаете ведь все эти шуточки про «секретарш, который набирает текст 1 пальцем»? Вот примерно такое качество набора было у этого программиста. Я считаю, что это неприемлемо, тем более, что человек был на роль лида.
Stasgar
Ну на роль лида все-таки следует отбирать повнимательнее, что-же вы так)
Suvitruf
Первые несколько месяцев работали только удалённо. А вот когда съехались в один офис, тогда и осознали свою ошибку…
unabl4
1) Я всего два хоткея знаю, которые и использую. Оба для Sublime Text. Первый чтоб скопировать текщую строку, а второй, чтоб быстро выделить слово в разных местах и сделать быструю автозамену.
2) У вас такой пример. У меня есть другой пример. Человек пишет код довольно быстро и крайне бездумно. Любит приступать сразу же, без какой-либо подготовки. Никаких паттернов, никакой выдержанной структуры, продуманной архитектуры. Разные отступы? Ой, ну и ладно. Спагетти-код all the way. Зато да, якобы работает. Тестируется всё это дело так же как и пишется — на глазок.
DistortNeo
Ну и что такого, что медленно набирает? Программист — не секретарь. Главное — решение задачи за приемлемые сроки.
Я бы с большим подозрением смотрел на человека, который бы не использовал отладчик. Да, есть люди, которые пользуются только отладочным выводом, потому что отладчик — слишком сложно. И я не о консольном gdb говорю, а о обычных IDE.
Suvitruf
DistortNeo
Нет, не вижу. У обычного программиста скорость набора выше, чем скорость мысли.
Или задача сводилась просто к бездумному набору большого количества кода?
Suvitruf
Задача была реализовать новые спелы для персонажей. Нормальный разработчик это сделал за 2 дня. Медленный такое же задание за 2 недели.
DistortNeo
Мне эта информация никак не помогает оценить количество кода, необходимое для решения задачи.
Скорее всего, дело не в скорости набора кода, а в том, что претендент был тугодумом, т.е. просто долго пытался понять, что и как надо делать.
rombell
Приходя в новый существующий проект, я дико торможу. Потому что нужно уложить в голове новую схему, взаимосвязи, местные практики, а параллельно с этим — выгнать оттуда предыдущую. Но зато через два месяца в голове всё утрясается, и то, что поначалу занимало неделю, делаю за день или меньше, и часто знаю о коде и проекте больше, чем те, кто делали его год. Видимо, у вас бы я испытательный срок не прошёл.
Suvitruf
Человек у нас уже проработал 5 месяцев до этого…
VolCh
А как бы вы посмотрели на человека, который устанавливает отладчик на продакшен сервер?
Interreto
Так вам наборщик кода нужен или разработчик? К примеру я мало набираю кода в течении дня, большая часть времени уходит на проектирование, нахождение решения, профилирование, оптимизацию, отладку бизнес логики… то чем должен заниматься разработчик, а не строчить гавнакод
Suvitruf
Я вот не понимаю, вы все шутите так или на полном серьёзе? Речь не о том, что человек обдумывает задания долго; сам факт того, что он даже copy/paste делает мышкой — это уже звоночек. Я бы даже сказал ЗВОНОЧЕК.
greendimka
Скажите, за использование нестандартной цветовой схемы в IDE у вас сразу увольняют, или сначала выговор?
Idot
В чём такая принципиальная проблема в том, что кто-то делает так как ему лично удобно?
Вы что упоротый фанат командной строки ненавидящий графические интерфейсы?
Suvitruf
Пускай делает, но если это не мешает работе.
Нет, я человек, который хочет нанять сотрудника, который будет помогать нам в разработке проекта, а не человека, который будет просиживать часы и за это получать з/п.Idot
Судя по минусам в Карму мне и DistortNeo — у кого-то из манагерров нехило бомбануло, от того что ему написали, что работа программиста не измеряется количеством написанных вд ень строк.
Suvitruf
Я и не говорил, что работа программиста измеряется количеством строк кода. Я вам простую аналогию приведу: вы чем будете сверлить стену, отвёрткой или дрелью? В данном случае медленный (не в плане кодинга, а в плане сдачи тасков) сотрудник — это отвёртка.
IvanPulo
Я думаю, все проще. Если человек сосет в таблице умножения, то очень маловероятно ожидать успехов в решении дифференциалов. Я не говорю что такое невозможно, но искать корнеркейсы и как работодателю набивать шишки чтобы понять эту простую истину, смысл?
Suvitruf
Человек с тестовым заданием справился хорошо, при разговоре тоже не было ничего подозрительного.
Interreto
и что? я работал с человеком который пользовался трекболом, его в топку? я еще как то наблюдал за кибер «спортсменами», были крутые чуваки которые одной мышкой с доп. кнопками делали хот кейшиков… дело в навыках и моторике
Suvitruf
Вы видите в моих сообщениях то, чего там нет. Если продуктивность НЕ страдает, то его дело. Но если таски делаются в разы медленнее, чем должны, то да, в топку. Медленный набор — это лишь 1 из пунктов не в пользу этого сотрудника. Само собой только за это его бы никто увольнять бы не стал.
VolCh
Тестовые задания люди не любят делать, если просто ищут работу, рассматривая множество предложений.
Suvitruf
Ещё от позиции зависит. Если поиск сотрудника идёт на роль лида или т.п., то соискатель думает, что его портфолио и так красноречиво за него говорит и делать тестовые не хочет в принципе.
VolCh
Угу. По крайне мере если условия предлагают среднерыночные.
shir
Мы с такими не работаем. Если человек не хочет делать тестовое задание то просто дальше с ним не общаемся. В моей практике было два случая когда взяли без тестового задания:
Я сам тогда рядовым сотрудником работал. Кандидат на собеседовании сказал что-то типа "чего это я такой крутой и буду тут тестовое делать?". Начальник его взял. Гонору от него было… И делал он проект один месяца три. Так и не сделал. Потом я за него почти с нуля за неделю все написал. Все сроки профукали. Через год со скандалом уволился.
Сениор тем более должен делать тестовое. Ооооочень много случаев когда собеседовались на должность сениора, при этом не могут сделать тестовое задание на сениора (задача взята из реального проекта и подобная задача возникает в каждом втором проекте). А когда предлагаешь сделать тестовое на мидла, то выясняется что и его не все могут сделать. Если ты такой крутой программист, что хочешь быть сениором, то сделать тестовое тебе не составит труда.
VolCh
"Вас много, а я один". Одно дело, когда одно-два интересных предложений и на них предлагают тестовое задание на день работы где-то и совсем другое, когда предложений с десяток и на каждом предлагают тестовое на день работы.
shir
И вы на все хотите пойти и на всех условия одинаковые что все задания надо делать?
Ну тестовое задание на день работы сениора это действительно многовато. Наше где-то на 2-4 часа расчитано (я надеюсь).
VolCh
"нас устраивает запрошенная вами в резюме на сайте ххх сумма, когда вам будет удобно прийти на собеседование? Кратко о себ: занимаемся разработкой" вс "нас устраивает запрошенная вами в резюме на сайте ххх сумма, сделайте тестовое задание во вложении и сообщите когда вам будет удобно прийти на собеседование? Кратко о себ: занимаемся разработкой". Куда сначала пойдёте? Начнёте ли писать тестовое для второй, если в первой сспросят "прямо сейчас готовы приступать?", а на ответ "у меня ещё одно собеседование запланировано" скажут "приступайте прямо сейчас и мы вам даем на 15% больше чем вы просили".
shir
Погуглю что за фирмы и какие условия. Но если все одинаково то пойду сперва к тем кто сперва собеседует. Тех кто "приступайте прямо сейчас и мы вам даем на 15% больше чем вы просили", скорее всего пошлю — такая поспешность это явно что-то не здоровое. %)
greendimka
"такая поспешность это явно что-то не здоровое" — почему вы так думаете? Рынок, конечно, переполнен программистами, но кто сказал что они все хорошие? Если вам такое предлагают, то не просто так.
t-nick
Была ситуация почти как в 2. но с исходом как в 1. Только вместо тестового мне предоставили код какого-то проекта. Кандидат при этом хорошо знал основы языка (Objective-C) и платформы, поэтому решили взять, хоть и не без сомнений.
Еще одной причиной был обычный для IT дифицит кадров. настолько большой, что компании боятся отпускать более-менее вменяемых кандидатов. Если сегодня вы не берете кандидата «сходу» и предлагаете ему тестовое задание, то завтра он примет офер другой компании.
am-amotion-city
Представления не имею, что называете «сеньором» вы, но на тех, кого называю сеньором я, идет охота хедхантеров. В очереди стоят, чтобы только я согласился безо всяких тестовых заданий поехать поговорить с работодателями.
shir
Наверное поэтому нам и тяжело найти сениора :).
Но не представляю как можно брать человека на работу не видя того что он может сделать. Ну да, open source всякий можно использовать, но большое количество проектов (кода) далеко не у всех хороших программистов есть в open source (сам тому пример, буквально пара небольших открытых проектов есть). Всякие статьи/конференции тем более не показатель.
Но это все уже немного другой вопрос, как мне кажется
am-amotion-city
Это иллюзия и самообман. На дворе 2017 год. У всех людей, могущих претендовать на позицию сеньора есть мегабайты кода в open source и минимум несколько тысяч репутации на SO.
Остальных — я на сеньора даже резюме смотреть не стану.
shir
Зря вы так думаете. Знаю не мало хороших программистов (про себя скромно умолчу) у кого очень мало open source. И уж тем более репутация на SO (это я бы вообще не рассматривал, т.к. чтоб заработать там репутацию надо не столько знания, сколько время). Далеко не у всех есть время чтоб занимать open source'ом. Хорошо если начальство/клиент позволит выложить в open source то что было в рабочее время написано. А если нет, то где взять время даже не представляю.
am-amotion-city
Я с самого начала и сказал: мы разное понимаем под понятием «сеньор». Сеньоры работают на позициях, на которых есть заранее оговоренное время (обычно — 1 день в неделю) на занятия open source’ом, домашними проектами. Также сеньор в рабочее время часто отдыхает на SO, потому что 8 часов в день без остановки писать хороший код невозможно. Ну и, разумеется, сеньор часто коммитит в основные чужие репозитории проекта. Мы недавно включили Riak в стек — мои коммиты сразу появились в коде официального клиента для наших языков.
Сеньоров нанимают, чтобы вообще за ними не следить, чем хочет — тем и занят. У меня бывают дни, когда я просто не в настроении и ухожу в полдень гулять по улицам.
«Хороший программист» — это мидл, там другие требования. Но я недавно понял, что и от мидла уже хочу кода на гитхабе: людей вокруг много, мне не трудно подождать подходящего.
shir
Да, действительное разное. Я под сениором понимаю программиста который умеет, в первую очередь, сложные задачи решать, над архитектурой думать, умеет понимать место проекта в бизнесе клиента и т.д. А не то где и как он работает.
Вы прям в каком то идеальном мире живете. Себя я не буду брать (я, можно сказать, фрилансом занимаюсь, и при желании могу хоть сколько часов на OS выделять, но в ущерб деньгам), но доводилось сталкиваться с хорошими программистами которые работают на ставке мидла и тянут весь проект и просто не знают насколько они хороши и что в другом месте они могли бы получать больше и иметь лучшие условия. От чего они по факту не перестают быть сениорами.
am-amotion-city
Я живу в нормальном мире, в котором сеньоров мало. Иначе смысл, вложенный в слово, высыпается из него.
В том, чтобы быть мидлом нет ничего плохого. 95% компаний живут без сеньоров вовсе. 95% программистов никогда не становятся сеньорами. В этом и есть смысл классификаций.
А если любого разработчика с опытом и мозгами называть сеньором, но у меня есть разделение гораздо понятнее: девелоперы (это то, что вы называете сеньором) и обезьяны (это то, что вы называете мидлом).
VMichael
В общем вы Д'артаньян, а остальные… понятно кто.
am-amotion-city
Вы ничего не поняли, что неудивительно.
Я нигде, ни разу, не заявил, что считаю себя сеньором. Я говорил, что выполняю некоторые из требований, которые считаю естественными для сеньоров. Но нет, мне не хватает баллов по очень многим показателям, чтобы уверенно назвать себя сеньором.
Меня немного смешит, что вокруг вот тут на хабре развелось столько сеньоров, что хоть новую страну из них собирай, но и кода в опенсорсе нет, и на СО ходить мамка не велит, и зарплата обсуждается, и по всему видно, что доверить боевой микросервис страшно (потому что если кода в опенсорсе нет, как я пойму, как этот человек справляется со своими задачами?).
Но если вам всем так необходимо считать себя сеньорами — да хоть господами богами считайте.
0xd34df00d
А что там на SO делать? Код-то я писать люблю, за последние лет пять только один день без коммитов был, а вот с людьми общаться я люблю уже меньше. В свободное или непродуктивное на работе время я лучше статьи почитаю.
am-amotion-city
Этот комментарий здесь на хабре уже выглядит как оксюморон, но это бы и ладно.
Читайте статьи, я что, против что ли? Хоть рассаду выращивайте. Просто сеньор — это набор навыков и умений, а не «пишу код хорошо». Просто писать код я аусорсеров найму за полцены. Сейчас программистов, которые способны написать километр очень внятного изящного архитектурно продуманного кода — вагон.
Сеньора же отличают другие навыки, в частности — менторские. Так что тут все просто: хотите позицию сеньора — покажите вашт наработки в этой области. Кроме репутации на SO более-менее объуетивных параметров нет. Вот и все.
Ну и да, лучше помочь одному индусу написать хороший код, чем трепать языком тут с горсткой неудачников :)
VolCh
Закрыты NDA — ещё вопросы? И ваша классификация явно не укладывается в общепринятую. Менторские качества от сеньора обычно не требуются, это качества для лидов, которые должны вести людей за собой. От сеньоров требуется в этом плане консультировать интернов, джунов и мидлов при необходимости (определяется лидом или ПМ-ом в общем случае), а не тащить их.
am-amotion-city
Нет, больше никаких вопросов, до свидания. Ищите контору, которая вам на слово поверит, или попросит баблсорт на доске изобразить.
Обще- — это кем? Людьми, которые хотят называться сеньорами невзирая ни на что? Так, чтобы в каждой конторе было по пять сеньоров на одного мидла и половину джуниора? Тогда да, отличается.
Потому что, как я миллион раз выше в ветке уже повторял, сеньоров не может быть много. И менторские качества ему необходимы, потому что очень многие сеньоры в тимлиды не хотят. Кроме того, тимлид — это должность, а сеньор — звание, их странно противопоставлять.
VolCh
Зачем мне искать, я от них отбиваюсь :)
Людьми, которые ищут себе сотрудников. Понимая под миддлом сотрудника, который может решать обычные задачи самостоятельно в разумное время, а под сеньором сотрудника, который может самостоятельно решать сложные задачи в разумное время, проводя декомпозицию и простые их части делегируя при возможности менее квалифицированным.
Сеньор — это должность, Senior Software Engineer/Developer, в русском бюрократическом переводе — старший инженер/техник-программист. Лид — тоже должность, ведущий инженер-программист.
Да, не может быть сеньоров много, вернее больше чем миддлов/джунов в устоявшемся режиме развития или даже стагнации отрасли, поскольку каждый сеньор должен побывать джуном/миддлом, но не каждый джун/миддл дорастет до сеньора. Но поскольку отрасль развивается и каждый день число джунов растёт уже много лет, то растёт и число сеньоров каждый день.
0xd34df00d
К сожалению, не такой уж и вагон. Не хватает даже их.
Значит, мы просто разных людей называем сеньорами. Нестыковки в терминологии — бывает.
Вот статьи на хабре, вот статьи в рецензируемых журналах (правда, уже не совсем по программированию), или вам SO обязательно как инструмент для того, чтобы делиться знаниями?
am-amotion-city
Вы путаете причину со следствием, как мне кажется. Я нигде не говорил, что я чего-то требую от соискателей. Я лишь сказал, что у сеньоров оно обычно есть и так.
Да, наверное, встречаются потенциальные сеньоры у которых чего-нибудь нет. Статьи (лучше бы, конечно, свой автономный блог на английском)? — Прекрасно. Код не на гитхабе, а на дискетке? — Тоже ничего.
Но в современном мире так получается, что все мной перечисленное, повторюсь, обычно есть и так. Сеньоры сами по себе всем этим обрастают, не чтобы успешно ходить на собеседования, а просто в силу личностного развития. Когда вдруг понимаешь, что тебе есть, о чем рассказать на конференции, или твои коммиты начинают принимать в мейнстрим того языка, на котором ты сейчас пишешь.
Вот и все, что я хотел сказать.
0xd34df00d
И при этом не слишком хикка, чтобы на эти самые конференции ходить.
am-amotion-city
Сеньоры ходят на конференции, и рассказывают о своей работе. Это — часть понятия «сеньор».
Иначе — мы говорим о «хорошем разработчике». Такие тоже нужны, я с радостью приму такого на аутсорс, например. Но в офисе мне такой фрик не нужен.
VolCh
Очень у вас обширное понятие.
am-amotion-city
Иначе сеньоров будет столько, что яблоку упасть негде. Это все-таки высшая ступень принятой иерархии, не вижу причин считать таковым любого, кто способен написать хороший код.
Мы же просто грамотных людей в писатели не записываем.
VolCh
Высшая ступень — техлиды, ведущие инженеры по советско-российским классификаторам.
khim
Теперь наконец стало понятно в чём беда. В общепринятой лестнице Senior Software Engineer — это где-то 4-5я градация в лестнице из 10-12 уровней. Дальше там идут Staff Software Engineer, Senior Staff, etc. То, о чём вы говорите — это, скорее, какой-нибудь Google Fellow или Intel Fellow. Гораздо выше на лестнице, чем просто Senior.
Но как рахз они даже и в 2017м редко чего выкладывают на GitHub! В лучшем случае там может оказаться код, который они писали несколько лет назад!
Тут скорее научные статьи и конференции могут быть, чем профиль на GitHub…
am-amotion-city
Ну если у вас после них идут кто-то у кого в названии есть слово Staff, то мы вряд ли поймем друг друга.
Бгг. В Гугл и Интел идут только те, кому миру сказать самим нечего, за редчайшим исключением. Я как раз сейчас активно отговариваю одного из наших сеньоров идти в Гугл на позицию руководителя направления. Скука смертная же.
Не в лучшем, а в любом. И код — не парное мясо, с годами не протухает.
khim
Код — нет, а человек — может и да. Вы на работу код собрались нанимать или человека?
shir
Подведем итог спора:
Осталось запилить новый пост на хабре с опросом и выяснить кого больше :)
edogs
Добавьте 6 категорию.
Сеньор это тот кто получает зарплату сеньора в соответствующей должности:)
Потому что в итоге именно работодатель решает подходит ли оный кандидат на должность сеньора или нет.
am-amotion-city
Ничего себе итог.
Итог вот какой, на самом деле: одни считают, что в классификации они обязательно идут на самой верхней позиции, невзирая на то, что и открытого кода не производят, и на SO их злой работодатель не пускает, и времени у них на помощь сообществу нет.
Другие им возражают, мол, верхние позиции в любых рейтингах существуют не для того, чтобы почесать ЧСВ всех желающих, но для того, чтобы можно было обозначить действительно лучших, и что для попадания в такую категорию необходимо прикладывать много усилий, помимо восхищения собственным уровнем. В частности, помимо уже перечисленного: не зависеть от работодателя, не обращать внимания на зарплату, быть педагогом для всей команды и многое что еще.
И, заметьте, ваша точка зрения тут популярна, а моя — нет. Знаете, почему? — Потому что все хотят быть сеньорами не прикладывая никаких усилий, кроме работы в рабочее время за большую зарплату.
Так не бывает. То есть, бывает, конечно, просто это уровень среднего мидла. Писать хороший код и решать архитектурные проблемы могут миллионы.
maxpsyhos
Нет, ваша точка зрения не популярна потому, что для вас сеньор — это некое место в мироздании, какая-то абстрактная великая миссия, тяжкий но почётный пост спасителя
галактикииндустрии.То есть вы попросту путаете понятия «сеньор» и «гуру».
А для нас, «тёмного» народа, сеньор — это в первую очередь позиция в команде. Да, конечно, есть какой-то средний по отрасли уровень скила, который определяет этот уровень, но он и сильно гуляет от команды к команде и состоит в основном из навыков, непосредственно связанных с работой.
am-amotion-city
Вы, наверняка, думаете, что возражаете мне этим комментарием, а на самом деле просто идеально проиллюстрировали все мной сказанное. Гуру — это Кнут, Керниган, Ричи, и так далее.
То, что описал я — как раз сеньоры. И да, повторюсь, в 95% компаний сеньоров нет, и хорошо. Но мы тут вроде бы обсуждали собеседования, то есть пока компании нет: надо оценить уровень кандидата по засоренному им эфиру.
Так вот у сеньоров — есть портфолио. Всегда.
А если портфолио нет — это мидл в лучшем случае.
Который, конечно, придумает миллиард бессмысленных оправданий, чтобы называться сеньором. Которые, разумеется, будут проигнорированы адекватным работодателем.
khim
А давайте поговорим конкретно, а? Применим физические подход: рассмотрим предельный случай.
иИ есть конкретный кандидат. Без «портфолио», без open-source проектов, без репы на Stack Overflow.Вот у нас есть конкретные тезисы:
Так как: таки «давай досвиданья» — или может ещё подумать?
0xd34df00d
Ну, технически, стоимость false positive при найме существенно выше стоимости false negative в значительной части областей.
am-amotion-city
Вы упоролись, что ли?
https://github.com/google/protobuf
и еще дозиллион строк кода: https://research.google.com/pubs/jeff.html
Вы там ниже пишете:
В 2017 — это глупость, граничащая с абсолютной неадекватностью. Для особо одаренных повторяю: pet projects, pull requests во все, чем пользуется ваша команда, просто что-то, что контора может выложить в опен сорс.
И да, если у вас этого нет, это значит только то, что вас нелепо рассматривать в качестве сеньора. Вот и все. Это нормально.
VolCh
Даже pull request в публичный репозиторий, используемый в работе, может быть рассмотрен как нарушение NDA, коммерческой тайны и т. п. Локальный форк для внутренних патчей и всё. Более того, есть конторы в которых использование опенсорса запрещено, вернее запрещено использовать софт без прямого двустороннего лицензионного договора с правообладателем или его законным представителем в России.
am-amotion-city
Дык можно ведь и на наркодилеров работать, там вообще могут в бетон закатать за коммиты в open source.
Я никак не пойму, что вы пытаетесь доказать: что есть неадекватные работорговцы, работа с которыми приводит к деградации разработчиков? Не сомневаюсь.
Зачем нормальному работодателю с девелоперами, на такое согласными, связываться-то? Повторю, наверное, в стотыщпятисотвосьмой раз: на дворе 2017 год. Тенденция такова: у достойных внимания на позицию сеньора разработчиков всегда (ну хорошо, за редчайшим исключением) есть портфолио.
Да, мы рискуем пропустить маньяка-йети, который программирует не выходя из леса. Ну как бы и хрен с ним. Зато есть внятный критерий отбора и не нужны пузырьки на собеседовании: покажи профили github/so, и поговорим.
VolCh
Есть вполне адекватные работодатели, которые не считают допустимым делиться со всем миром (прежде всего с конкурентами) бесплатно тем, за что они платят деньги.
И не путайте наличие портфолио и наличие истории вкладов в опенсорс проекты.
С этим критерием отбора вы рискуете получить специалиста, который:
а) решает прежде всего задачи сообщества, а не ваши, но за ваш счёт
б) не считает нужным вообще хранить в тайне какую-то информацию
в) будет конфликтовать даже по поводу лицензий под которыми выкладывать рабочий код, скажем, будет считать что MIT недостаточно православна
Был такой печальный опыт.
am-amotion-city
Нет, не рискую. Я не вслепую беру человека, я с кандидатами разговариваю.
Такой критерий помогает мне сразу от входа отсеять людей, которые мнят о себе минимум, что они — великие разработчики, а на деле не имеют времени/желания программировать.
С оставшимися я разговариваю. Экономия времени — впечатляющая. В моем и нашей компании мире сеньором называется человек, который может не только о себе сообщить, что он — сеньор, а все остальное накрылось NDA, но и доказать это. Повторяю: настоящие сеньоры обрастают этим багажом между делом.
VolCh
Это вы называете настоящими сеньорами людей, у которых есть доказательства того, что они активно участвуют в жизни опенсорс проектов. При этом у них может не быть ни дня опыта промышленной разработки.
am-amotion-city
Неправда. Необходимо, но не достаточно. Это просто понять, попробуйте.
У сеньора есть много отличительных признаков. Если любого одного недостает — до свиданья. Один из них в 2017 году — код для сообщества.
Переформулирую: нам не интересны гуру подковерной разработки. И мы такие не одни, а в хорошей компании. Но я ни в коем случае не навязываю этот паттерн отсева. Просто сообщаю, что так удается собрать самую сильную команду в двухмиллионнике.
DistortNeo
Наверное, всё дело в том, что программисты, пишущие код только под NDA, не имеют возможности для саморазвития. Они просто исправно пишут код, за который им платят деньги, а не который им самим хочется писать.
VolCh
Очень сильно зависит от компании. Не надо путать задачи, которые решают кодом и сам код.
am-amotion-city
Дык к сеньорскому возрасту можно бы научиться получать деньги за код, который приятно писать.
qw1
Код может быть для интересной задачи, но закрытый. Или такой, что бесполезно выкладывать, вроде численных экспериментов в некоторых очень узких областях, или алгоритм управления рубильниками для балансировки нагрузки в электросети.
am-amotion-city
Ох, зря вы это, сеньоры заклюют.
VolCh
Сообщений с десяток, если не больше, вы навязываете именно этот критерий отсева как первый из решающих :) Я же правильно понимаю, что вы даже на собеседование не пригласите человека, если у него на гитхабе, битбакете и т.п. нет аккаунта?
am-amotion-city
Ох. У нас бывают открыты позиции мидлов и джуниоров. Добро пожаловать, пока кандидат не позиционирует себя как сеньора.
Если вдруг — требования отличаются.
Dionis_mgn
Можно поглядеть Ваш GitHub-аккаунт?
am-amotion-city
Я, в принципе, отправил личным сообщением, но аргумент «сам дурак» — так себе аргумент, и я выше по ветке сто раз повторил, что не уверен, что дотягиваю до сеньора сам.
Dionis_mgn
Не имею привычки называть людей дураками только лишь по тому, что их мнение отличается от моего. Мне просто любопытно, чем мне стоит обзавестись, чтобы считаться Вами годным разработчиком.
Насколько я понял, аккаунт, что Вы мне показали — рабочий, т.е. там представлена работа, за которую Вам платят деньги? Тогда да, этот аккаунт мне не интересен. Вам чертовски повезло, что Ваш работодатель так относится к сообществу и активно делится наработками. Это здорово! Но я вижу сложившуюся ситуацию так, что бОльшая часть компаний всё ещё закрывает свои наработки. Поэтому всё, что сможет показать разработчик на собеседовании, каким бы крутим он ни был — свои личные проекты, которые он делает в свободное от работы время. Увы. Вот мне и интересно, какая у меня должна быть активность в разработке pet-проектов, чтобы котироваться организацией, подобной Вашей как годный разработчик.
am-amotion-city
Как же я люблю вот эту волынку. Конечно, разумеется, мне чертовски повезло, я ведь в рубашке родился. Меня провидение оторвало от дивана и отправило поработать в Германии, чтобы набраться опыта. Лично господь подарил мне во сне навыки и умения, обучил примерно десяти языкам программирования и четырем человеческим. На меня было сниспослано руководство, которое вожделело выкладывать все в открытый доступ и платить мне за это хорошую зарплату. Меня буквально выписали в Барселону, как только я понял, что это и есть город, в котором я хочу жить и работать.
Нет, спешу вас разочаровать. Все было не так. Это я убедил руководство выкладывать код, которую напрямую не закрыт NDA. Это я оторвал свою жопу от дивана и сначала уехал в далекую и совершенно неизвестную Германию, потом вернулся, а потом определился с Испанией и почти год целенаправленно искал работу здесь. Это я сам согласился но говнопохапе, чтобы получить визу. Это я неоднократно разговаривал лично с директором, объясняя ему выгоду от участия в open source на длинном отрезке времени. Это я заставил команду вести корпоративный блог. И после всего этого мне довольно странно читать вот это вот волшебное «повезло». Да хрен там, я работал над этим.
Если хотите посмотреть на мои личные проекты — их там тоже есть. И не нужно передергивать: между «годными разработчиками» и «сеньорами» — пропасть, и я это постулировал с самого начала.
Я внятно изложил?
Dionis_mgn
Ой молодец какой! Возьми с полочки какую-нибудь вкуснятку.
Это какой код то? Какие-нибудь вспомогательные скриптики? Может, ещё что-то? Насколько его много относительно того, что напрямую покрыт NDA? Думаете, в других проектах его много?Я опущу ту часть про Ваши путешествия как не имеющую отношения к сути разговора (если вдруг Вы считаете, что эта проблема связана с географией — нет, не связана; я вот в американской компании работаю; такого пристального слежения за кодом нигде пока ещё не видал).
Вы правда считаете, что разработчики в «закрытых» компаниях не стремятся делиться с сообществом? Стремятся. И посылаются далеко. Нашу команду начальство посылало на 4 буквы (в английском нет известных мне направлений из трёх букв) пару раз. И аргументы их не интересовали. Вы, конечно, можете сказать, что недостаточно эти разработчики старались, надо было сильнее жопу рвать (ну, как Вы, например). Но что, если Вам просто немного… да, с тем, что Вы имеете возможность публиковать свои рабочие наработки — Вам, помимо всего прочего, повезло. Это, кстати, ничуть не умаляет Ваших заслуг. В том числе на поприще популяризации OpenSource.
Хорошо, давайте пойдём с другой стороны. Покажите мне любой GitHub-аккаунт, которым, по Вашему мнению, стоит обзавестись, чтобы считаться сеньором. Изначально то меня именно это интересовало.
am-amotion-city
Вот такой пойдет: https://github.com/KronicDeth/
И вообще, я не вижу никаких причин сеньору соглашаться работать на дядю, который что-то запрещает. Такие вещи оговариваются на берегу, и «спасибо, но нет», если в компании вдруг все так закрыто, что ага.
И нет, повторяю еще раз: мне не «повезло». Это мой сознательный выбор.
VolCh
Есть тренд, что чем больше запретов, тем выше зарплата.
am-amotion-city
Есть тренд, что когда ты не первый месяц в профессии, зарплата не играет первостепенного значения, да и второстепенного тоже. Мы ж не шпалы кладем, с голоду не помираем, вроде.
Я не представляю себе, сколько мне надо заплатить, чтобы я согласился отключать твиттер, не ходить на SO, или не пилить open source когда мне вздумается.
DrPass
Это целиком и полностью зависит от ваших потребностей, а не от стажа. Я, например, хочу домик в хорошей европейской стране. Но домик в 30 км от Женевы стоит порядка $700K. А зарплаты хорошего программиста, увы, хватает и на еду, и на хороший отпуск, и на неплохую машину… но на домик в Женеве не хватает.
И если мне предложат зарплату, которая сделает его ближе, я прекрасно обойдусь без, ах божечки, твиттерного трёпа в течении 8 часов в день, и без работы над пет-проектами в оплаченное работодателем время. Тоже мне, ценности нашли.
И уж тем более, споров с работодателем/заказчиком на тему, можно ли выкладывать мой код, сделанный по его ТЗ, на гитхаб в публичные репозитории. Да ради бога, он за него заплатил, он вправе решать его судьбу. Я абсолютно бесплатно сделаю так, как он попросит, даже без всяких NDA.
am-amotion-city
Ничего с тех пор не изменилось, даже потребности не сильно возросли. Рабская психология — неистребима.
В твиттер ходят, чтобы ссылки на актуальные статьи в своей профессиональной области получать сегодняшним днем, а не в ужасном переводе на желтушном сайте типа говнохабра.
DrPass
У вас специфический сарказм. Но как говорится в смежном источнике, «кому и кобыла невеста». Кто-то считает, что жить хорошо на съемной квартире, а отдыхать с рюкзачком в палатке, а кому-то нравится свое собственное жильё, машина, и комфортный отпуск.
Вы, наверное, единственный пользователь твиттера, который использует эту свалку студенческого трёпа с такой целью. Если вам, конечно, поверить.
am-amotion-city
Да всем нравится, и что? Ну, за исключением того, что в Швейцарию я не то, что жить, я на конференции езжу с неохотой: такая скука, что хочется запить через 20 минут после приземления, это все вами перечисленное — само собой. Как из этого следует необходимость вылизывать жопу начальству?
Даже не знаю, какая фамилия вас заинтересует. Джоэл Сполски, например, ведет активный интересный твиттер. Джо Армстронг. Вирдинг. Кармак. Роб Додсон. Да все, собственно.
DrPass
Ну просто потому, что вас вряд ли возьмут на работу, которая вам позволит достичь какой-то связанной с финансами цели, если вы будете качать свои права на всякую откровенную чушь.
Я не уверен, что вас туда приглашали. Не из-за профессиональных качеств (их я не знаю), а просто потому, что я там был, и знаю, что вы говорите ерунду. Ни Женева, ни Цюрих ничем в плане времяпровождения не отличаются от любого другого крупного европейского города.
Нууу… и как, там есть что-то, повышающее вашу квалификацию? Если вам так нужны для развития рассуждения Спольски или рассказы Кармака, ну расскажите начальству, что без этого никак. Вам разрешат. В конце-концов, ваш собственный телефон или планшет у вас практически нигде, кроме сверхсекьюрных контор, не отберут, можно подобную публицистику для убивания времени хоть учитаться при желании.
Понимаете, есть наёмная работа, есть фриланс. Если вы фрилансер или предприниматель, то у вас нет начальства, и вообще непонятно, к чему этот спор. Если же вы наёмный работник, то вы выполняете условия, под которые заключили сделку, в том числе и соблюдаете правила распорядка (то, что вы почему-то называете «вылизывать жопу»), нравятся они вам или нет, а работодатель выполняет со своей стороны (обеспечивает условия для работы и платит зарплату). Если вы этого не делаете, то вы просто как специалист — говно. Хорошего специалиста характеризует не только умение писать код, но и добросовестность отношения к своему делу.
am-amotion-city
Мне приглашение не нужно: сел в машину, да поехал.
Ладно, если для вас все крупные европейсие города на одно лицо — искренне желаю вам поскорее накопить свои сколько там надо и обзавестись недвижимостью в глубине Швейцарии. Я, когда выбирал пригодное место для работы, от предложений в Швейцарии отказывался сразу. Люблю, когда море в шаговой доступности, с людьми есть о чем поговорить, а в самую лучшую в мире (на мой вкус, естественно) картинную галерею можно доехать на машине.
Неужели же так трудно понять: я никогда не предлагал нарушать условия договора (например, потому, что я не гнида). Я все время говорю о том, что в условия договора на берегу надо закладывать важные для тебя вещи. Потому что начальников вокруг до хрена, а я — один, и никакими деньгами приличного человека купить и заставить делать то, что ему не по душе — нельзя. В идеале, конечно.
DrPass
Ну тогда вам надо и понять, что «запреты болтовни в твиттере» или там «рабочий графис с Х часов до У часов» при нормальном отношении работодателя и хорошей компенсации для большинства спецалистов абсолютно несущественные вещи. А рассуждать на тему «как это я могу опуститься до такого уровня, что буду работать там, где не одобряют твиттер», это все равно что заявлять, «я не готов работать в такой убогой конторе, где мне, элитному суперразработчику, скрам-мастер не будет ласково чесать яички во время митингов».
am-amotion-city
Не нужно говорить, что мне надо делать, и я не стану говорить, куда вам надо идти.
Ну давайте, что ли, я объясню для особо внимательных, откуда у меня появился в рассуждениях «твиттер». Вся заметка, под которой мы ведем эту бессмысленную беседу, — ни что иное, как несколько скринов треда в твиттере, который начал DHH, и в котором я принимал участие те две, что ли, недели назад, когда это случилось. DHH не семи пядей во лбу, но общаться с ним интереснее, чем, например, с вами.
Каждый выбирает, конечно, сам, во что вписываться. Но на то большинство рабов, которые подписываются ради денег на любое говно, заявленное работодателем в качесте обязаловки — мне насрать, я не Мария Тереза.
Я до сих пор не бросил эту ветку только ради тех, кто, может быть, придет, почитает, и взвесит все за и против наших подходов: вы-то пока теоретизируете насчет домика в скучной стране, а я уже живу там, где мне хочется и работаю так, как мне нравится.
DrPass
… и почему-то свято уверены, что ваше непонятное «нравится» — такое хорошее, что его надо рекламировать до усрачки. Поверьте, в мире не существует такой потребности в высокооплачиваемых и необременённых ответственностью специалистах, чтобы у вас появилось сколько-нибудь значительное количество последователей. Если вы, конечно, высокооплачиваемый, а не живёте в копеечной съемной квартире где-нибудь в испанском колхозе.
am-amotion-city
Не надо свои проблемы проецировать на окружающих. Про необремененность ответственностью — ваш горячечный бред.
Говнокодеры с девяти до шести — вот в них как раз потребность заметно падает, частью из-за аутсорсовых демпингов, частью — из-за просто переизбытка людей, которые в профессию пришли за баблом.
Ответственные люди не могут программировать с девяти до шести, и любым вменяемым работодателям это давно известно.
И я никого не агитирую. Я рассказываю, откуда берется тот открытый код, которым сейчас многие любят пользоваться. Рассказываю, что отдавать — полезнее, чем тупо получать. Окупается сторицей. Вот вам вид из окна нашего офиса, так сказать, в подтверждение моей точки зрения:
DrPass
Так сразу бы и сказали, «парни, я затеял этот спор, дабы понтануться, смотрите у меня тут море-океан под окном и дефки на пляже в бикини, а вы там давитесь в своих кубиклах» :)
Я — человек аполитичный. В 20 лет поработал админом в одной известной в 1990-х политической партии, посмотрел на эту штуку изнутри, увидел, сколько там говна, и больше туда ни ногой. Поэтому ваши политические/коммунистические лозунги про открытый код я тоже воспринимаю крайне скептически.
Потому что открытый код — это просто открытый код. Вы, как автор своего кода, абсолютно вольны с ним делать что угодно, хранить под замком, продавать или раздавать всем. Если вы сделали код по заданию работодателя, то это служебная задача, и имущественные права на неё у заказчика, и что делать с кодом, это уже его дело. Если это не закреплено документально, то это можно оспорить при желании, но это уже нифига не fair play, и мы такой вариант не обсуждаем.
И вот говорить, что надо раздавать свой код другим — это все равно что говорить «надо раздавать свою зарплату другим». Не надо. Хорошо раздавать или не хорошо раздавать чей-то код, вы не можете знать. Этой информацией обладает только его владелец.
И ничего особо страшного в том, что какие-то библиотеки являются проприетарными, тоже нет. Код — это не лекарства и не продукты первой необходимости. Мы так или иначе почти все занимаемся коммерческой разработкой. Если нашли бесплатный код, который решает вашу проблему, ну ок, спасибо, сэкономили денюжку вашему заказчику. Если какая-то нужная библиотека не является бесплатной, совершенно не проблема её купить или написать.
am-amotion-city
Если бы я хотел понтануться, я бы выложил эту картинку в начале треда. Не я начал спрашивать, не в колхозе ли я работаю, правда? Задали косвенный вопрос — я выложил ответ, мне не жалко. У меня таких фотографий полно?.
Представляю, какой вы код пишете, если не в состоянии уследить на нитью простой дискуссии. Я нигде не утверждал, что в проприетарном коде есть что-то плохое, или что нужно бороться за выкладывание кода, защищенного NDA.
Давайте еще разок попробую, в простых для понимания выражениях: старайтесь больше отдавать, чем берете, и вам воздастся. Приглашением в компанию, которая дружит с сообществом, не закрывает каждый свой выкидыш (большинство, кстати, это делает только потому, что код показать наружу банально стыдно), поощряет сотрудников, не контролирует каждый их шаг, осознает потребности, хорошо платит, наконец.
Повторюсь, я не агитирую, я просто рассказываю случайно зашедшим людям, что это выгодно на длинном отрезке времени. А просто гнать бабло — нет. Вот и все. Вы просто удачно подвернулись со своими домиками в нигде.
DrPass
Давайте расскажем случайно зашедшим людям более полезные вещи:
1. Переходить на личности плохо.
2. Хамить плохо.
3. Навешивать ярлыки, всего лишь на тех людей/организации, которые делают не так, как вы, плохо.
4. А дружит ваша компания с сообществом или нет — как раз пофигу.
Поэтому ваше «рассказываю случайным людям» приносит куда больше вреда, чем пользы. Но по крайней мере, у вас есть возможность понтануться офисом, это у вас не отнять.
Недвига, кстати, в Испании нынче недорогая, как и еда, как и шмотки. Куда дешевле, чем в Москве. Позволить себе это несложно. Другое дело, что там, скажем так, тоже на любителя. Летом там днём такая жарища, что никакими деффками в бикини меня туда не заманишь.
am-amotion-city
То есть, ваши правила — хорошие, годные, а мои — «приносят куда больше вреда, чем пользы». Ню-ню.
Вот я люблю, когда о стране судят по дешевым курортам.
greendimka
Лично ездил по всей Испании летом, и так же не хотел бы там работать летом. Что на юге, что на севере, что в центре. Жара — она не для всех.
am-amotion-city
Вы бы подправили Википедию тогда, а то пацаны-то не в курсе, что там у них жара-не-для-всех.
Насчет имени: я стесняюсь своего присутствия на ресурсах типа pornhub, хабрахабр и подобных, поэтому и пользуюсь фейковыми именами.
greendimka
Вы меня подловили, сдаюсь.
Хорошо, что вы стесняетесь не ресурсов, а именно своего присутствия на них. Если бы я писал то, что пишите вы — тоже бы стеснялся.
Мне прям интересно стало, что, а главное в какой манере, вы там — на pornhub, комментируете :D
saboteur_kiev
«типа pornhub, хабрахабр и подобных»
Какое замечательное сравнение.
DistortNeo
Для меня, например, идеальная температура на улице — от 15 до 20 градусов, а температура выше 25 градусов просто некомфортна. Поэтому если в Москве я испытываю дискомфорт только 1-2 месяца в году, то в Сан-Себастьяне будет 4-5 месяцев неприятной жары.
am-amotion-city
Это очень интересно, но не несет никакой практической информации (кроме той, что вы не умеете читать сводные таблицы из десяти строк).
Испания в разговоре появилась исключительно как иллюстрация того, что я работаю там, где я хочу. Я никого же не агитировал, да и не приглашал, если честно. Вам Испания не только температурой не понравится: тут не так много работы, зарплаты заметно ниже среднеевропейских (€60K, например, — для Испании уже очень много, и далеко не сразу; в то время, как в Германии можно торговатся за 80 от входа).
У каждого такое место свое, разумеется. Если вам идеально подходит ваш сегодняшний офис/дом, то эта ветка вообще не для вас.
Я лишь утверждаю, что при наличии портфолио на github’е и SO (и, желательно, персонального блога на английском) — работу в том месте, которое вас полностью устраивает найти в тысячу раз проще. Сами вас найдут.
Меня норвеги и англичане, например, постоянно вызванивают — вот это, наверное, климат для вас. И я лишь говорю, что для современного разработчика, претендующего на работу мечты — github и SO существенно ускоряют ее, этой самой работы мечты, осуществление.
Только и всего. И пока меня не начали попрекать тем, что я работаю в колхозе и отдыхаю в овраге с рюкзаком пустых бутылок вместо подушки, а также тем, что мне бесконечно повезло в этой жизни — я вообще ни слова не сказал про себя лично.
Я про тенденцию. Которая может пригодится молодым.
saboteur_kiev
> Приглашением в компанию, которая дружит с сообществом, не закрывает каждый свой выкидыш (большинство, кстати, это делает только потому, что код показать наружу банально стыдно), поощряет сотрудников, не контролирует каждый их шаг, осознает потребности, хорошо платит, наконец.
Назовите такую компанию? А желательно хотя бы десяток таких компаний, и желательно, чтобы они выжили на рынке хотя бы лет 5. Затем мы посмотрим сколько рабочих мест подобные компании могут обеспечить на все население земного шара.
> Повторюсь, я не агитирую, я просто рассказываю случайно зашедшим людям, что это выгодно на длинном отрезке времени. А просто гнать бабло — нет. Вот и все.
Вот и выясним действительно ли это так. Потому что взять да тот же один Microsoft — IMHO он один может покрыть по количеству рабочих мест все те компании, которые вы назовете.
am-amotion-city
Полное ощущение, что я по слепоте и неопытности промахнулся в адресной строке и попал на форум домохозяек.
Гипотетический Microsoft разумеется покроет по количеству рабочих мест все компании, где хочется работать. И что? Платят там мало, скука смертная, бюрократия, говнокод. Причем тут это вообще? Я где-то говорил, что хочу трудоустроить всех быдлокодеров? Ваша логическая ошибка называется «подмена частного общим»: я говорил с точки зрения хорошего программиста, которому не нужен миллион рабочих мест, нужно, прикиньте, одно.
Как дети, честное слово.
greendimka
Как ребёнок, честное слово. Вот профиль у вас вроде женского рода, а комментарии — пишите от мужского.
VolCh
Бывают и другие материальные интересы кроме выживания.
Да пилить обычно никто не запрещает, запрещают выкладывать рабочие наработки.
0xd34df00d
Любой работник в первую очередь решает свои задачи (заработать на пожрать, получить удовольствие от решения задач, и так далее). Если ваши задачи при этом выполняются хорошо, то какая разница, чьи ещё задачи и когда он решает?
DistortNeo
Большинство работодателей не любит недозагруженных работников.
Работотаделю выгодно максимально быстрое решение своих задач, поэтому ситуация, когда эффективный работник выполняет норму, а затем отдыхает, работодателя не устраивает. Работодатель предпочтёт платить такому сотруднику больше, лишь бы он не занимался посторонними задачами.
0xd34df00d
Это, возможно, работало бы, если бы работодатель занимался копанием ям лопатами. Однако, в случае интеллектуального труда оценить, кто и сколько времени на чьи именно задачи потратил, и какой профит в перспективе это даёт, сложнее.
Я охотно могу представить такого жадного работодателя, который не даёт работнику потратить час в неделю на свои задачи (да хрен с ним с опенсорсом, там ещё интеллектуальные права замешаны, статьи по теме для общего развития почитать, скажем), и которого этот работник потом шлёт нафиг, когда в пятницу вечером усё сломалося. А как же, 40 часов, ТК.
Недальновидно, короче.
khim
Да, вы отрыли часть вещей, которые Джефф Дин создал несколько лет назад. Вещи, которые он делает сейчас — вы не увидите ещё три-пять лет (а часть — не увидите никогда в принципе). И что — вы будете о нём судить вот о той верхушке айсберга, которая всплыла на github'е? Вот по этим нескольким случайно убежавшим процентам того, что он сделал?
Извините, но вы несёте чушь сейчас. Подавляющее большинство компаний свой код никому показывать не хочет и не будет. Тот факт, что сейчас на github кода, выложенного разработчиками из Гугла составляет несколько процентов от всего кода, который ими написан как бы говорит сам за себя.
Нет — мы рискуем пропустить нормальных 90% кандидатов и набрать людей, которые, вместо того, чтобы решать поставленные перед ними задачи, тратят время на разные второстепенные вещи. Если вас это устраивает — да ради бога. Но не нужно делать вид, что это — нормальный подход.
khim
Там нет кода.
Xandrmoro
Синьоров и должно быть много, это уровень, достаточный для решения большинства задач — а большинство задач весьма несложны.
А для задач выдающихся есть чифы, светочи знаний, постигшие дзен решения задач, которые уходят на неделю в
запойастрал и выходят оттуда с решениями, до которых простой смертный не додумается. Вот их действительно мало.khim
Проблема в том, что am-amotion-city со своим «великолепным» подходом отошлёт всех этих чифов одним росчерком пера отправит за дверь. Вместе с кучей сеньоров и прочих. Ибо подавляющее большинство написанного в мире кода — закрыто NDA, хотите вы того или нет. А создавать код чисто для того, чтобы am-amotion-city понравиться далеко не каждый сеньор захочет.
guai
был у меня случай, пока одна контора проверяла моё тестовое задание, я уже устроился в другую фирму
они потом звонили, но поезд ушел
куча причин не делать тестовые задания.
если еще работаешь, то тратить на него будешь выходные, в которые отдохнуть надо, иначе потом вся рабочая неделя на текущей работе, где тебе бабки платят не за красивые глаза, будет менее продуктивной. дела всякие есть в выходные, которые копились всю неделю.
а если не работаешь, то тратишь сбережения, и чем быстрее выйдешь на новую работу, тем быстрее почувствуешь себя спокойно и уверенно, а не под гнетом осознания таящих финансов.
ukt
Был опыт, когда предлагали тестовое задание на две недели.
На вопрос: «Оплачивается?», ответили «Нет». И это уже на собеседовании предложили (предупредить с берегу, видимо, никак). Разумеется, я от такого щедрого предложения отказался, они, в свою очередь, тоже мне отказали…
И подобное хотел каждый из десятка предлогателей, физически невозможно выполнить все тестовые из отобранных предложений.
Какие то тестовые были сделаны за ради интереса самой задачи.
Конкретно мне тестовые задания нравятся, позволяют работать мозгам в интересных областях, но тут нужно быть осторожным, что бы не поработать бесплатно на «эффективных» менеджеров.
Psih
Если честно, то лично я там где дают тестовое задание сразу отказываю — это означает, что они ищут мидла, а не сеньора/тимлида.
Если мне говорят «вот доска/лист» — спасибо за приглашение, но досвидание. Опять же, ищут не пойми кого и заниматься придётся задачами которые не соответствую моему уровню.
А причина проста — в резюме записана пачка проектов, которые я делал. Часть из них под капотом имеют то, с чем 95% разработчиков просто не сталкивается. К тому же есть Github, где можно посмотреть код/issues/обсуждения. С багажом в 12 лет за плечами гораздо важнее впишусь ли я в команду или нет, а не могу ли я написать сортировку из головы — нет, не могу и даже не буду пытаться готовиться к этому. Они мне за потраченные на дорогу и собеседование время денег не платят, а я теряю по факту целый день абсолютно бесполезно (нормально работать в этот день уже не получится). Ну и плюсом они тратят свои деньги бесполезно, потому что сами не знают что хотят. А это уже звонок, в какой обстановке придётся работать.
IvanPulo
Это означает что мозги у соискателя либо атрофировались либо не было. Нагуглить решение — 98% людей. Особой ценности не представляют, то что у вас резюме, это показывает участие, а не вклад.
Calc
sort($array); // Представим что это пузырек
wait($some_time); // надо подождать так как он долгий
я очень далек от глобального мира программирования, но я очень лизок к IT и людям.
Так сошлись звезды, что я 10 лет управляю и обучаю людей в любой области IT.
Последние 2 года нахожусь в Мобильной разработке и занимаюсь аккумуляцией занний в организации + управлением отделом разработки + обучением. Сам много раз был на собеседованиях на программиста и в 90% случаев я как баран смотрел на человека, который задавал явно те, вопросы, которые он сам может выполнить только потому что он проводит это собеседование.
У меня уже давно наступил порог запоминаемости, чтобы запомнить что то новое — я забываю что то старое.
Решение простое. То что записано и можно найти за 2-10 секунд, можно забыть.
Никогда не понимал требований написать алгоритм. Ты должен знать отличие одних от других, должен знать когда какой использовать, сколько кто стоит, но от руки писать — идите работать в писари.
knekrasov
Ну тут работает принцип «не помнишь — придумай», задачи специально «детские», чтобы могло подойти «наивное» решение в лоб. Адекватный технарь не будет требовать идеального решения, ему важнее увидеть, как вы думаете, когда решаете задачу, как реагируете на критику (вы же наверняка точку с запятой пропустите или индексом промахнетесь — это нормально!). У интервьюера час времени, чтобы определить, кто перед ним находится. Любая такая крупица информации о вас будет ценной.
Am0ralist
А у меня со школы проблема запоминать связку «название фигни — содержимое фигни». То есть, например, по названию теоремы в стереометрии вспомнить ее текст. А доказать несколькими способами не по учебнику — такой проблемы не стояло. И да, для меня текст теоремы и ее название — были фигня. Их любой дурак может заучить, потратив кучу дней жизни. А вот быстрей меня решить задачу — не сможет, что и продемонстрировали потом экзамены во всей красе.
Ну и вот с пузырьком этим — реально, не помнил я на момент прочтения статьи, что это название значит, хотя и учил более десятка лет назад. Хотя парочку самых простых сортировок придумаю на раз два и один из них окажется тем же пузырьком. А вот вы помните, например, алгоритмы численного интегрирования, а? Или поиска минимума двухмерной функции? Это же детские алгоритмы, вот я же несколько из них помню, не являясь программистом, остальные — тоже должны.
Причем для каждого, внезапно, окажутся разными эти наборы детских алгоритмов, которые все должны знать, причем еще и со всеми вариантами наименования…
Попросить показать, как ты думаешь — это нормально. Но тогда уж вначале текстовое описание что ли пусть дают. Потому что не всем эти вещи были нужны на протяжении долгих лет работы и жизни.
knekrasov
Ну если схематично, то помню (особенно, если нарисовать кривую и стобики под/над ней, а потом вспомнить, что это могут быть не прямоугольные столбики, а трапеции, и что это, кажется, как-то было связано с фамилией Симпсон). Только что это лично вам как интервьюеру бы дало? :-)
Так не молчите об этом! Адекватный интервьюер это оценит.
Согласен, во всем нужна мера.
TheDeadOne
Помню, пришёл как-то в стародавние времена устраиваться программистом Python, и дают мне задачу обменять значения двух переменных. Я не долго думая пишу
Собеседующий явно ожидал другой вариант, этот его не устроил. Объяснить, почему я не могу пользоваться естественными возможностями языка не смог. Но в попытках предложил написать на другом языке. Дальше был std::swap из С++. Он даже сбегал с листочком к компьютеру. Потом был чисто Сишный вариант с xor'ом, уже из вредности. И многое другое, вплоть до ассемблера, где мы начали обсуждать вопрос о том, являются ли регистры третьей переменной. Работу я, конечно же, не получил, но после первого примера уже и не хотел.
Neftedollar
А документацией?
Когда уже встретился с пяткой языков, иногда забываю как цикл писать на пацтоне( правда я и собеседования по нему не прохожу) и такие вещи гуглю. Половина вопросов к гуглу это посииск документации еще треть это гуглинг ошибки. Конечно, без Гугла вам будут долго в док-ции копаться.