Кстати, должен добавить, что у меня коллега год лечился от выгорания. В Европе это официальный диагноз, который предполагает длительный больничный от трех месяцев до года, или даже более. Вы пишите, что просто расслабиться, да поехать в отпуск не помогает, а тут так и нельзя. Человека отправляют почти на фул-тайм на психологическую групповую терапию, где он обязан находится, если не ошибаюсь, четыре дня в неделю по шесть часов. Можно, правда, пару раз брать «отпуск» на неделю-две. Там в группе они занимаются в принципе чем угодно, беседуют в группе между собой и с каждым лично также работает психотерапевт. Через десять месяцев у него таки выявили ядро выгорания, вот как у вас с гештальтом удалось себя осознать, еще два или три месяца закрепляли результат — и через год он вернулся к работе. Уже второй год полноценно работает и все у него на данный момент прекрасно.
Спасибо огромное, хорошая яркая статья о личном опыте. Я, видимо, дошел приблизительно до третьей стадии на предыдущей работе, но потом поменял мето работы, и стало легче, хотя определенные признаки остались. Пока что стараюсь максимально отделить работу от хобби, и если дома в выходные не включать ноут, то в понедельник обычно снова хочется на работу :-)
Я уже почти смирился с тем, что не буду пилить никаких оупен-сорсов или хобби прожектов в свободное время, лучше поделать спорт, позаниматься с детьми или разобрать, наконец, фото из отпуска.
Вторым же — какое там выгорание, нужно впрягаться и тащить, на тебе ответственность, семья, родители.
А потом алкоголь, скрытое насилие в семье, депрессия и самоубийства.
Мне в этом контексте вспомнилось, что старшее поколение советует лечить депрессию копанием огорода. Мол, пока копались в картошке, не было никакой депрессии, а вы тут все городские теперь, сидите в своих офисах и грустите. А как-то я нашел очень емкий абзац про женскую депрессию у, внезапно, Достоевского, написанный 150 лет назад. Так что была депрессия, еще как была, просто не знали как лечить и кнутом гнали на работу. А мужики на выходные сваливали на рыбалку, подальше от «злой жены», а дома грызлись каждую минуту. Действительно, как в анекдоте: депрессия есть, а слова нет…
Вот буквально последний пример, был у нас на собеседовании разработчик в возрасте немножко за 50. Опыт работы сначала в RnD в университете, потом почти 10 лет в двух компаниях, тоже RnD, распознавание образов, довольно сложные задачи он там решал. Резюме на меня произвело довольно хорошее впечатление. Мы собеседовали его на позицию разработчика системы обработки изображений, однако в работе нужно не только обрабатывать изображения, но и дизайнить сам конвеер обработки и его взаимодействие в реальном времени с аппаратными и пользовательскими подсистемами, это часть промышленной сортировочной машины.
Для собеседования у нас есть простые задачи двух типов: в одних дается несложный кейс на дизайн, нужно построить диаграмму классов, диаграмму событий, разделить ответственности. Во второй задаче нужно написать алгоритм, проанализировать его, оптимизировать и протестировать.
Не смотря на многолетний разнообразный опыт, данный товарищ с кейсом на дизайн не справился вообще в принципе, а при построении алгоритма не смог внятно построить тесты и запутался в std, причем ладно бы в сигнатурах библиотеки, я и сам, бывает, в них путаюсь, но он не знал и концепций. Оказалось, что на практике он не дружит ни с UML, ни с С++11, ни с оптимизацией кода. Интересно, что этот кандидат прошел первый раунд собеседования, который проводил не по-наслышке знакомый с технологиями человек, но не разработчик, а продакт менеджер. И пока мы во время второго раунда спрашивали о технологиях, он очень бойко отвечал, но как только дело дошло до задачи, так сразу и оказалось, что все грустно.
Я писал об обучении в гугле в контексте позиции алгоритмиста, подразумевающей наличие знаний, которые указывают вам направление, куда решать и что гуглить. Если мне нужен именно алгоритмист, что я буду делать? Правильно, буду проверять знание и умение оперировать хотя бы базовыми понятиями, дам несложную задачку, чтобы человек ее решал, а не решил. Даже если кандидат знает заранее решение задачи, это не означает, что он сможет полноценно ее проанализировать на собеседовании.
Вот ровно так же, как человек переводит факты в систему знаний до собеседования, так же он будет делать и после собеседования
Если человек делал это до собеседования, то он сможет ответить на вопросы. Даже в стиле «о, я помню было такое, напомните мне вот это, а я додумаю дальше». Это вполне приемлемо.
Вопрос только во времени и иногда в желании, а не в принципиальной невозможности.
Принципиально возможно все, вопрос только в том, должна ли компания тратить время и деньги на то, чтобы заново обучить человека тому, что он должен был бы изучить в университете.
Да я же не зверь какой, не знает кандидат эту задачу, даем другую. Но я уже сколько раз сталкивался с ситуацией, когда человек с опытом вообще не умеет решать задачи. Ни дизайн решения, ни само решение, ни юз-кейсы проанализировать, ни входные данные. Технологии знает — а с зачами просто ноль. Я не сомневаюсь, что он успешно пишет какой-то вполне себе работающий код, костыли к нему делает, старается. Но сколько времени мы потратим, чтобы он стал писать код на уровне качества нашей команды? Очень сложный вопрос, ответ на который «от пары месяцев до бесконечности». Готова ли команда брать такие риски? Нет, не готова.
Поймите мою точку зрения правильно. Современные технологии делают огромное количство знаний в CS просто ненужными. И на большинство позиций все эти алгоритмические задачи, вопросы о распределении памяти и прочие сложности действительно не имеют смысла, в чем я с вами и с другими комментаторами абсолютно согласен. Но иногда люди с этими знаниями чертовски нужны, и найти их с каждым годом все сложнее. Но эти знания нельзя просто найти в гугле, это все же сложная система, требующая для освоения пару лет серьезного обучения, после которых вполне можно без привлечения гугла решать с нуля различные задачи. Даже на собеседовании за полчаса можно набросать анализ задачи и возможный путь ее решения. Даже если человек предложит экспоненциальный лобовой перебор, но сможет указать на эту экспоненту, и после подсказки сможет предложить более эффективное решение, то это уже хорошо. Далеко не все могут даже первое.
Слова «вечность» и «каждый термин» — это гипербола, если что.
Сформулирую еще раз. Позиция алгоритмиста подразумевает, что у человека в голове наличествует определенная система знаний, которая в свою очередь означает, что человек знает базовые термины. Наличие тех или иных определений в голове и умение ими оперировать и решать задачи — или хотя бы анализировать задачи — обычно выявляется постановкой алгоритмических задач на собеседовании.
Умение гуглить, т.е. быстро получать факты и подсказки очень условно соотносится с системой знаний. Факты — это не знания. Знания — это книжка, или курс, это дни чтения. Если мне нужен специалист по алгоритмам, я буду ожидать от него умение оперировать базовыми понятиями без помощи гугла. Если мне будет нужен спец по нейронным сетям, то на базовые вопросы он тоже должен будет отвечать без помощи гугла, пусть даже без терминов, пусть своими словами.
Если же без подсказки человек не умеет понять и указать направление решения задачи, то я делаю вывод, что решать такие задачи он не умеет, с гуглом-ли или без. Если простую задачу он сможет решить, то я уверен, что с гуглом он решит и любую сложную.
Чтобы загугленная информация стала действительно знакомой, опять же, в голове должна быть система, в которую новые знания будут встроены. Если же в голове каша, то новый термин только увеличит ее количество и густоту.
Это все менее касается разработчиков, которые больше работают с приклаными библиотеками, где нюансов больше чем принципов, а нюансы действительно сложно запомнить в таких количествах, и тут уж гугл в помощь. Но чем позиция ближе к Computer Science, тем больше нужно держать в голове, просто потому что CS — это логичная система знаний, а не необъятная совокупность фактов.
Сложные статьи обычно подразумевают довольно высокий уровень базовой подготовки. Если вы начнете гуглить каждый термин, то чтение займет вечность. Поэтому неумение решать простые задачи с собеседования для работодателя вполне может означать неумение решать и сложные рабочие, даже с помощью гугла.
Я прекрасно понимаю, зачем на собеседовании дают алгоритмы :-) Тем более вы сами пишите, что алгоритмы, пусть и не часто, но есть, на интервью в МС мне как про эти случаи и рассказывали.
Вы это лучше расскажите моему оппоненту, которого бомбанул вопрос про поиск циклов в односвязном списке, как не релевантный работе.
Мне очень сложно провести границу между вопросом на знание и понимание алгоритмов и структур данных и подавляющим большинством задач на собеседованиях. Расскажу, пожалуй, историю из жизни.
Я как-то был на собеседовании MS, где как раз давали такую задачу на смекалку, белую доску, маркер и 45 минут общения с «экзаменатором». Я готовился по книжке задач собеседований MS, половину задач я знал, но это не помогло по очень простой причине: важно не решить задачу, важно показать, как вы будете подходить к решению. При этом на вопрос «что вы делаете на работе» у каждого инженера из MS загорались глаза и он начинал рассказывать про оптимизацию трафика хранилищ данных, гео-привязку или быстрый поиск по огромным наборам данных. И каждый раз было понятно, что смекалка и умение правильно решать задачи — это основа их работы, а задачи на собеседовании в целом оправданы.
Чуть позже я проходил собеседование в другой компании, из Долины. Там задачи на алгоритмы были действительно сложные, а рабочие задачи, о которых рассказали инженеры, были совершенно с алгоритмами не связаны. Ну разве что одна из них, мне ее и дали на собеседовании, я ее решил за час с маленькой подсказкой. Зачем им были нужны крутые алгоритмисты и такое сложное собеседование — я так и не понял, и в этом случае с вами согласен, такая форма собеседования там была, скорее всего, не нужна.
Как соискатель вы, возможно, не знаете, зачем задают те или иные вопросы. То что кажется вам совершенно излишним, может оказаться ежедневной реальностью работы.
Ну собственно, на собеседовании вы и показали, что у вас это было 0 раз и вы не знаете основ Computer Science, хотя работаете в отрасли 10+ лет.
А вопрос развернуто звучит так: вот есть структура данных и нужно на ней алгоритм, как бы вы решали эту задачу учитывая особенности структуры, проанализируйте граничные случаи, обоснуйте, составьте тест-кейсы. Интервьювера в данном случае интересует не готовое решение — его-то скорее не будут ожидать вообще — а то, как вы будете над ним думать. И лучше всего наблюдать процесс решения на белой доске.
В моей практике ковыряния в недрах кода встречалось такое, что Кнут и в страшном сне представить не мог. Так что если это вам не встречалось, то это еще не значит, что это не нужно на работе, на которую вы хотет попасть.
Работая больше десяти лет разработчком алгоритмов и повидав разных людей, я много размышлял на тему «обучения в гугле», популярный ныне подход, когда зачем учить, если можно нагуглить. Мой опыт показывает, что если задача выходит за рамки применения стандартной библиотеки, то далеко не всегда можно нагуглить хоть что-то. Часто задачи приходится действительно решать, читать статьи, проводить параллели. Этот процесс невероятно затягивается, если вообще не становится невозможным, если человек не знаком с областью и не обладает системой знаний, как общих, так и узкоспециализированных.
Так вот, с моей точки зрения, в контексте разработки алгоритмов в конкретной компании, оба вопроса — и про списки и про размещение в памяти — были бы уместны. Первый покажет ваши знания структур данных, без хорошего понимания которых в алгоритмах делать нечего. Второй покажет, что вы имеете представление о методах оптимизации размещения объектов в памяти. Не теоретически, а практически. Причем, задачу даже не обязательно решить, я бы просто смотрел, как вы ее решаете, этого более чем достаточно. Опять же, уместны только в том случае, если в работе этим приходится заниматься. Но при разработке алгоритмики игры вам разве не прийдется с этим столкнуться? Неужели движок UE все, ну вот прямо все сделает за вас?
Я хотел уточнить про такие вопросы. Я уже пару раз сталкивался с ситуацией, когда человек приходит на позицию С++ разработчика с уклоном в алгоритмику. Читаешь резюме — все отлично, интересные задачи, успешные проекты. А потом задаешь примитивный вопрос типа вашего про односвязный список, и оказывается, что собственно писать код для решения примитивной задачи человек и не умеет, потому что привык из готовых кирпичей собирать решение, не заботясь особо ни о производительности, ни о качестве кода.
Поэтому, когда вас спрашивают о сортировке списков, возможно, у компании есть собственный движок чего-то, во внутренностях которого иногда приходится иметь дело с вещами, которые современные движки от пользователей успешно скрывают.
У нас, например, довольно много низкоуровневого С++ кода, и не умеющий с ним работать человек нас автоматически не устраивает. С моей точки зрения, джун должен уметь решать как минумум простые задачи, его этому в универе на лабах учили. Мы его уже в свою очередь научим, как из простых решений собрать большие, как думать в контексте системы и так далее. Учить программированию все же не наша задача, а собирание решения из готовых деталек — это не программирование сложной системы со всеми ее низкоуровневыми нюансами.
1. Для этого предпочтительнее использовать перегрузку функций. Если у вас есть функция с набором опциональных null-параметров, то, возможно, вам пора подумать о рефакторинге кода, потому что скорее всего такая функция нарушает принцип единственной ответственности.
2. Никто не мешает проверять optional на отсутствие значений, так же как и указателей на nullptr. Мне кажется, это скорее дело вкуса и стиля, а не новомодных плюшек.
Я с вами асбсолютно согласен! Как подумаю, что какую массу возможностей теряю, перестав использовать void *, так буквально плакать хочется…
Спасибо за статью, написано очень понятно и просто!
Вы в списке вариантов применения std::optional упоминаете передачу ресурсов с отложенным доступом. Мы используем std::optional в нашем коде, но про такую возможность я слышу впервые. В статье этот вариант не раскрыт, вы не могли бы, пожалуйста, привести пример такого использования? Заранее спасибо!
Полгода назад переводил огромный проект с Qt4 на Qt5, поменялись по большому счету только некоторые заголовки, и некоторые минорные вещи в API, в целом за пару дней работа была закончена.
Присвоение… не работает, т.к. нужны не сырые (raw) строки, а предобработанные с помощью Jekyll.
Промучался с этим, наверное, день. В документации и на StackOverflow найти ответы не получилось. Наконец, вспомнил про вашу статью и нашел в ней эту строку. Спас много нейронов. Спасибо вам огромное!
Я уже почти смирился с тем, что не буду пилить никаких оупен-сорсов или хобби прожектов в свободное время, лучше поделать спорт, позаниматься с детьми или разобрать, наконец, фото из отпуска.
А потом алкоголь, скрытое насилие в семье, депрессия и самоубийства.
Мне в этом контексте вспомнилось, что старшее поколение советует лечить депрессию копанием огорода. Мол, пока копались в картошке, не было никакой депрессии, а вы тут все городские теперь, сидите в своих офисах и грустите. А как-то я нашел очень емкий абзац про женскую депрессию у, внезапно, Достоевского, написанный 150 лет назад. Так что была депрессия, еще как была, просто не знали как лечить и кнутом гнали на работу. А мужики на выходные сваливали на рыбалку, подальше от «злой жены», а дома грызлись каждую минуту. Действительно, как в анекдоте: депрессия есть, а слова нет…
Для собеседования у нас есть простые задачи двух типов: в одних дается несложный кейс на дизайн, нужно построить диаграмму классов, диаграмму событий, разделить ответственности. Во второй задаче нужно написать алгоритм, проанализировать его, оптимизировать и протестировать.
Не смотря на многолетний разнообразный опыт, данный товарищ с кейсом на дизайн не справился вообще в принципе, а при построении алгоритма не смог внятно построить тесты и запутался в std, причем ладно бы в сигнатурах библиотеки, я и сам, бывает, в них путаюсь, но он не знал и концепций. Оказалось, что на практике он не дружит ни с UML, ни с С++11, ни с оптимизацией кода. Интересно, что этот кандидат прошел первый раунд собеседования, который проводил не по-наслышке знакомый с технологиями человек, но не разработчик, а продакт менеджер. И пока мы во время второго раунда спрашивали о технологиях, он очень бойко отвечал, но как только дело дошло до задачи, так сразу и оказалось, что все грустно.
Если человек делал это до собеседования, то он сможет ответить на вопросы. Даже в стиле «о, я помню было такое, напомните мне вот это, а я додумаю дальше». Это вполне приемлемо.
Принципиально возможно все, вопрос только в том, должна ли компания тратить время и деньги на то, чтобы заново обучить человека тому, что он должен был бы изучить в университете.
Да я же не зверь какой, не знает кандидат эту задачу, даем другую. Но я уже сколько раз сталкивался с ситуацией, когда человек с опытом вообще не умеет решать задачи. Ни дизайн решения, ни само решение, ни юз-кейсы проанализировать, ни входные данные. Технологии знает — а с зачами просто ноль. Я не сомневаюсь, что он успешно пишет какой-то вполне себе работающий код, костыли к нему делает, старается. Но сколько времени мы потратим, чтобы он стал писать код на уровне качества нашей команды? Очень сложный вопрос, ответ на который «от пары месяцев до бесконечности». Готова ли команда брать такие риски? Нет, не готова.
Поймите мою точку зрения правильно. Современные технологии делают огромное количство знаний в CS просто ненужными. И на большинство позиций все эти алгоритмические задачи, вопросы о распределении памяти и прочие сложности действительно не имеют смысла, в чем я с вами и с другими комментаторами абсолютно согласен. Но иногда люди с этими знаниями чертовски нужны, и найти их с каждым годом все сложнее. Но эти знания нельзя просто найти в гугле, это все же сложная система, требующая для освоения пару лет серьезного обучения, после которых вполне можно без привлечения гугла решать с нуля различные задачи. Даже на собеседовании за полчаса можно набросать анализ задачи и возможный путь ее решения. Даже если человек предложит экспоненциальный лобовой перебор, но сможет указать на эту экспоненту, и после подсказки сможет предложить более эффективное решение, то это уже хорошо. Далеко не все могут даже первое.
Сформулирую еще раз. Позиция алгоритмиста подразумевает, что у человека в голове наличествует определенная система знаний, которая в свою очередь означает, что человек знает базовые термины. Наличие тех или иных определений в голове и умение ими оперировать и решать задачи — или хотя бы анализировать задачи — обычно выявляется постановкой алгоритмических задач на собеседовании.
Умение гуглить, т.е. быстро получать факты и подсказки очень условно соотносится с системой знаний. Факты — это не знания. Знания — это книжка, или курс, это дни чтения. Если мне нужен специалист по алгоритмам, я буду ожидать от него умение оперировать базовыми понятиями без помощи гугла. Если мне будет нужен спец по нейронным сетям, то на базовые вопросы он тоже должен будет отвечать без помощи гугла, пусть даже без терминов, пусть своими словами.
Если же без подсказки человек не умеет понять и указать направление решения задачи, то я делаю вывод, что решать такие задачи он не умеет, с гуглом-ли или без. Если простую задачу он сможет решить, то я уверен, что с гуглом он решит и любую сложную.
Чтобы загугленная информация стала действительно знакомой, опять же, в голове должна быть система, в которую новые знания будут встроены. Если же в голове каша, то новый термин только увеличит ее количество и густоту.
Это все менее касается разработчиков, которые больше работают с приклаными библиотеками, где нюансов больше чем принципов, а нюансы действительно сложно запомнить в таких количествах, и тут уж гугл в помощь. Но чем позиция ближе к Computer Science, тем больше нужно держать в голове, просто потому что CS — это логичная система знаний, а не необъятная совокупность фактов.
Вы это лучше расскажите моему оппоненту, которого бомбанул вопрос про поиск циклов в односвязном списке, как не релевантный работе.
Я как-то был на собеседовании MS, где как раз давали такую задачу на смекалку, белую доску, маркер и 45 минут общения с «экзаменатором». Я готовился по книжке задач собеседований MS, половину задач я знал, но это не помогло по очень простой причине: важно не решить задачу, важно показать, как вы будете подходить к решению. При этом на вопрос «что вы делаете на работе» у каждого инженера из MS загорались глаза и он начинал рассказывать про оптимизацию трафика хранилищ данных, гео-привязку или быстрый поиск по огромным наборам данных. И каждый раз было понятно, что смекалка и умение правильно решать задачи — это основа их работы, а задачи на собеседовании в целом оправданы.
Чуть позже я проходил собеседование в другой компании, из Долины. Там задачи на алгоритмы были действительно сложные, а рабочие задачи, о которых рассказали инженеры, были совершенно с алгоритмами не связаны. Ну разве что одна из них, мне ее и дали на собеседовании, я ее решил за час с маленькой подсказкой. Зачем им были нужны крутые алгоритмисты и такое сложное собеседование — я так и не понял, и в этом случае с вами согласен, такая форма собеседования там была, скорее всего, не нужна.
Как соискатель вы, возможно, не знаете, зачем задают те или иные вопросы. То что кажется вам совершенно излишним, может оказаться ежедневной реальностью работы.
А вопрос развернуто звучит так: вот есть структура данных и нужно на ней алгоритм, как бы вы решали эту задачу учитывая особенности структуры, проанализируйте граничные случаи, обоснуйте, составьте тест-кейсы. Интервьювера в данном случае интересует не готовое решение — его-то скорее не будут ожидать вообще — а то, как вы будете над ним думать. И лучше всего наблюдать процесс решения на белой доске.
В моей практике ковыряния в недрах кода встречалось такое, что Кнут и в страшном сне представить не мог. Так что если это вам не встречалось, то это еще не значит, что это не нужно на работе, на которую вы хотет попасть.
А если ваша задача, например, свести бухгалтерию на калькуляторе?
Тогда тем более странно, что вы считаете вопрос про простые структуры данных сложным и не подходящим для собеседований.
Я тоже уточнил, что, возможно, кроме движка UE там есть еще что-то.
Так вот, с моей точки зрения, в контексте разработки алгоритмов в конкретной компании, оба вопроса — и про списки и про размещение в памяти — были бы уместны. Первый покажет ваши знания структур данных, без хорошего понимания которых в алгоритмах делать нечего. Второй покажет, что вы имеете представление о методах оптимизации размещения объектов в памяти. Не теоретически, а практически. Причем, задачу даже не обязательно решить, я бы просто смотрел, как вы ее решаете, этого более чем достаточно. Опять же, уместны только в том случае, если в работе этим приходится заниматься. Но при разработке алгоритмики игры вам разве не прийдется с этим столкнуться? Неужели движок UE все, ну вот прямо все сделает за вас?
Поэтому, когда вас спрашивают о сортировке списков, возможно, у компании есть собственный движок чего-то, во внутренностях которого иногда приходится иметь дело с вещами, которые современные движки от пользователей успешно скрывают.
У нас, например, довольно много низкоуровневого С++ кода, и не умеющий с ним работать человек нас автоматически не устраивает. С моей точки зрения, джун должен уметь решать как минумум простые задачи, его этому в универе на лабах учили. Мы его уже в свою очередь научим, как из простых решений собрать большие, как думать в контексте системы и так далее. Учить программированию все же не наша задача, а собирание решения из готовых деталек — это не программирование сложной системы со всеми ее низкоуровневыми нюансами.
2. Никто не мешает проверять optional на отсутствие значений, так же как и указателей на nullptr. Мне кажется, это скорее дело вкуса и стиля, а не новомодных плюшек.
Я с вами асбсолютно согласен! Как подумаю, что какую массу возможностей теряю, перестав использовать void *, так буквально плакать хочется…
Вы в списке вариантов применения std::optional упоминаете передачу ресурсов с отложенным доступом. Мы используем std::optional в нашем коде, но про такую возможность я слышу впервые. В статье этот вариант не раскрыт, вы не могли бы, пожалуйста, привести пример такого использования? Заранее спасибо!
Промучался с этим, наверное, день. В документации и на StackOverflow найти ответы не получилось. Наконец, вспомнил про вашу статью и нашел в ней эту строку. Спас много нейронов. Спасибо вам огромное!