Услышал от саппорта фразу (не дословно): иногда данные теряются, надо с этим жить.
Это у всех так. Амазон - в один прекрасный момент они дропнули все базы и "восстановили" их из бэкапа полугодовой давности. Куда делись все более свежие бэкапы они не знали.
Что именно пригласят - крайне маловероятно, придется упорно себя предлагать.
Пет-проекты... скажу честно, его откроют не более, чем что бы посмотреть на степень грязи в коде. И если код грязный, то уж лучше вообще его никуда не выкладывать. Если нет возможности оценить на стороне, то подключить все возможные анализаторы и пусть они на мозги капают. Когда советуют делать пет-проекты, то это не столько что бы было что показать, сколько что бы вбить знания и навыки в подкорку через практику. Так и на собесе легче будет, когда вживую уже пощупать успел и по детским граблям побегать.
Ну а уйти можно как и везде: зад каменный, голова чугунная, нервы титановые, и учим-бегаем-ищем-готовимся-работаем-крутимся до победного. Если дергаться, обязательно вариант подвернется, порой совершенно неожиданно. А если ждать у моря погоды, то можно и до пенсии в медучреждении кантоваться.
Оказалось, что покупателей прямо-таки очень не устраивает последние 20 % срока годности (особенно если осталось 1–2 дня до конца), эти товары прямо стремились возвращать.
Вот, кстати, отличный показатель того, что руководство само за продуктами или не ходит и не готовит, или скоропортящиеся товары им покупать уже не доверяют. У данных возвратов 2 причины:
Первая причина в том, что большинство закупается на несколько дней, а потому то же молоко может не дожить до момента когда оно понадобится, если ему осталось 1-2 дня.
Вторая причина - это отсутствие доверия к условиям хранения товара. В цепочке минимум 3 звена и любой может нарушить, например, температурный режим хранения, а значит и срок годности фактически уменьшится.
Употребляют, причем больше клиентские разработчики, чем бекендеры. Уж не знаю, пришло оно от одноруких бандитов, девопсов или еще откуда, но появилось оно совсем недавно и вакантное место единого жаргонного термина пока еще свободно.
Например реализовать механизм на уровне оператора, что звонки могут происходить только по предварительному одобрения вызываемого, а вызываемый может сам составлять белые списки.
А потом за отдельную плату пропускать звонки от спамеров. Кому-кому, а опсосам доверия ни малейшего нет.
Потому что новые компиляторы не генерируют код под семерку (потому что Visual Studio - продукт все той же MS), новые библиотеки не выпускаются под семерку (я уже поминал Qt и Boost) по той же причине - компиляторы не компилируют под семерку.
Отлично все компилируется и работает хоть под хрюнделем, хоть под миллениумом. Причина совершенно в другом, 7-ка сегодня занимает тоже место, что и IE6 в начале 10-х.
Даже банальная установка 7-ки сегодня превращается в пляски с бубном, что бы просто работал интернет. Казалось бы, поставить семерку, обновить руками обновлялку и дать ей самой выкачать и установить все обновления. Но нет, в таком режиме она не установит пакеты с современными удостоверяющими центрами и TLS 1.2. Более того, при попытке поставить эти пакеты руками она пошлет далеко и надолго, выдав ошибку. Т.е. если не знать, какие пакеты нужно установить руками перед автоматическим обновлением, то и работать интернет не будет.
Ну ок, а давайте возьмем уже готовую сборку, на ней же все работает... Ага, работает... костылями в самом хроме. А значит, если ты должен поддерживать 7-ки у конечных пользователей, то нужно реализовать кастомную проверку сертификатов, как сделал гугл.
И это только верхушка айсберга, под капотом там еще много иных проблем, которые нужно подпирать костылями, а потом на проверку этих костылей тратить больше времени, чем на общую проверку работоспособности. Как в 14 году я радовался, что больше не нужно поддерживать IE6, так в 24-м я радуюсь, когда больше не нужно поддерживать 7-ку. И именно это и есть причина, почему все больше разработчиков отказываются от ее поддержки.
на каждом новом месте спрашивают "ну как, получилось разобраться и понять?"
Ну такие вопросы обычно надо воспринимать как: "все нормально идет или стену уже лбом ломаешь, а подойти спросить страшно?". К сожалению, очень частая проблема.
Будучи детьми мы не строили цепочки, потому что были мелкими и не очень умными.
И цепочки, и капитолий любой ценой, приходили в голову аккурат после того, как надоедало играть с читами. Первая в качестве замены читу на бесконечный ход, второе читу на ресурсы. Восемь-не восемь, а 4-5 вспомогательных героев всегда носились по карте, собирали ресурсы, и раз в пару недель выстраивались цепью и передавали армию. Происходило это в районе 2001 года, в тогда еще только появлявшихся компьютерных клубах, и мне тогда было лет 13-14.
В основе лора там лежат не Герои, а серия Меча и Магии, без приставки про Героев. Тоже начинал знакомство с Героев и был очень сильно удивлен, когда с ММ6 познакомился. Когда фентези "неожиданно" превращается в жесткую фантастику и выламывает этим мозг.
Основная проблема - это время. Имея всего час на техинтервью, нужно проверить базовые знания языка, базовые знания архитектуры, базовые знания в области/основных библиотеках, опыт работы, да еще и успеть оценить кандидата как человека, на сколько хорошо он впишется в команду. При этом 5 минут в начале занимают расшаркивания и знакомства и еще минут 10-15 в конце занимают вопросы кандидата.
Та же задача со строками требует не 5 минут на подумать в условиях приличного стресса, как на экзамене, если ты с ней никогда не сталкивался раньше. И в этом проблема с большинством алгоритмических головоломок. Т.е. либо человек знает/заучил ее решение, либо ему нужно больше бороться не только с задачей, но еще и с собой, особенно не видя какого либо практического смысла в самой задаче и видя ее общую оторванность от реальности.
И т.к. люди на ТИ приходят именно как на экзамен, то выдернуть из этого состояния человека очень тяжело. Что я в ГЭКе в универе много лет сидел на защите дипломов, что я ТИ проводил. Возраст у людей вроде разный (и не всегда в пользу ITшнеков), опыта за плечами много, а поведение и состояние очень похожее. Так и ждешь в ответ на вопрос фразы "во валит, гад". И не дай бог он закуклится, как студент, и в молчанку играть начнет. Если студент после такого получит диплом и исчезнет, то у кандидата можно и адового токсика просмотреть. Прямо удивительно порой, как люди могут меняться, после того как скорлупу сбрасывают.
Ну и на последок, я не люблю для собеса задачи у которых есть идеальные и близкие к ним решения, слишком легко пропустить того, кто знает ответ. Намного полезнее посмотреть как человек бьется в паутине, когда у всех решений есть свои плюсы и минусы, и надо выбрать из них какое-то одно. За одно и человек расслабляется часто, потому что оказывается в обычной рабочей обстановке.
ЗЫ. Так, Остапа опять понесло немного не в ту степь, извиняюсь, стирать лень.
Бы ли бы все адекватные, подобные статьи регулярно бы не появлялись. Но неадекватов действительно много, я и сам на них нарывался. Когда тебя начинают гонять на конкретные алгоритмы, никак не связанные с вакансией, это просто убивает.
Как и мидла+ с сеньором на физбазах гонять обычно смысла нет, если у него с логикой проблемы, то он и на устных рассуждениях сыпется по полной.
Большая часть литкода - это далеко не физбазы, а вполне себе стандартные низкоуровневые алгоритмы, о чем и автор статьи писал. Те же вопросы про деревья на собесах стали притчей во языцех не на пустом месте. Так что исключение далеко не редчайшее и встречается очень часто, особенно когда собеседует человек, который сам не понимает что он тут делает, зачем кого-то ищу и когда ему с этим человеком дальше не работать.
PS. На работе "физбазы" как раз применяются постоянно, ибо даже простые табличные круды покрываются ифами для отлавливания пограничных состояний. ))
Собственно, все задачи класса "а как это сделать", это и есть физбаз чистой воды.
В контексте собеседования проверятся не физбазы на базовое знание операторов языка, а более хитрые вещи, типо плавающих окон, деревьев, графов и т.п. вещей, зачастую не применяемых в той компании. где это спрашивают.
Где-то на форме контролы отображать/скрывать по сложным условиям.
Не сложнее классического физбаза.
Где-то данные будут иметь сложную структуру, и надо будет чуток обработать.
Чуток обработать - это далеко не найти "самую длинную подстроку первой строки, являющуюся подстрокой второй строки", за исключением специфических областей деятельности. И это даже не 5% задач, потому что большинство задачи подобного класса не встречает годами.
Ну серьезно, кастомные деревья я писал один единственный раз за 14 лет работы, всяким наркоманским вычматом с его сглаженными окнами, матричными преобразованиями и прочими веселыми методами пользовался только на первой работе, и то там специфика такая была, что сопромата с математикой было больше. чем непосредственно разработки. А сейчас у меня вообще даже базы данных нет, что бы хоть откуда-нибудь много данных взять и что-либо с ними делать, а оперативные данные не выходят за десятки единиц. За то бизнес-логика с кучей пограничных ситуаций и точек отказа, так что ни в какие готовые алгоритмы не укладывается.
Еще раз повторюсь, алгоритмические задачи надо проверять там, где они действительно будут использоваться. И в большинстве мест работы оно вообще никогда не применяется или с этим сталкиваются полтора человека из всей команды, что бы целенаправленно искать человека со знаниями, которые скорее всего никогда не будут использоваться.
Я даю реальную задачу, которую надо было комиттить в прод. И она неотличима от литкодовских.
А если в работе такие задачи не встречаются? Тогда какой смысл гонять по подобным задачам?
Для большинства мест работы - это 50% архитектура, 30% бест практикс, 10% умение просчитать пограничные случаи и 9 процентов знание языка, 1% знание О, что бы нечто типо O^2 по одному набору данных не делать.
Алгоритмы надо спрашивать там, где алгоритмы реально используются, а иначе это поиск дворника в ларек, но обязательно с высшим образованием и званием КМС по бальным танцам.
Любой булшитер сможет вас заболтать, а настоящий гений, но интроверт будет 10 минут только ээкать и нууукать.
Буллшитер как раз быстро ломается и в лютую воду скатывается, потому что готового решения у задачи не существует, а проанализировать несколько возможных решений без навыков и опыта банально невозможно. Причем те самые интроверты, которые до этого пол часа нукали, мыкали и экали, магическим образом начинают говорить без остановки, потому что мозг на рабочие рельсы автоматом переключается и выдает информацию быстрее, чем тело озвучивать успевает. С детальным анализом, потенциальными проблемами, узкими местами и даже с наброском возможной архитектуры решения.
Но сложность задачек надо подкручивать под количество кандидатов на место.
А зачем? В надежде найти самого лучшего на ближайшие 3 года? Скорее будет вакансия, которая не закрывается месяцами, и зашивающаяся команда, которой всего лишь был нужен еще один крудописатель или кнопкорисователь, что бы мыло смыть.
Начнем с того, что даже физ-базз и перекладывание джсонов - это тоже алгоритмы, хоть и простые.
Под алгоритмическими задачами далеко не физбазы понимаются, давайте все таки не будем в софистику уходить.
Пузырек - это обобщенный синоним сферического алгоритма в вакууме, который лежит в основе задачи, будь то хэши или подсчет змей попугаями.
При этом, в работе нужно писать over9000 CRUD'ов, перекладывать 100500й JSON из одной кью в другую, разгребать четырехтомники войны и мира легаси и, иногда, находить и фиксить наитупейшие ошибки и опечатки уровня физбаза, написанных в условиях: усе пропало и должно быть пофикшено вчера. Причем эти ошибки исключительно из-за того, что команда уже в состоянии свеже-выкопавшихся зомби от усталости.
На техинтервью обычно выделяется всего час и тратить большую часть своего времени на проверку маловажных навыков... ну это даже себя не уважать. А ведь надо успеть еще пробежаться по основным возможностям языка, платформы и практикам, оценить человека с точки зрения вливания в команду и не забыть оставить время на вопросы от кандидата.
При том, что вместо любых головоломок обычно достаточно дать "простую" задачу на подумать, класса "как бы вы решали такую-то проблему", причем жизненную, а значит не имеющую идеального решения, в отличии от алгоритмических. За 15 минут можно увидеть практически всю подноготную человека, включая его реальный опыт работы и общий уровень. И приправить все это каким-нибудь физбазом или куском легаси на пяток минут, как раз навыки ревью оценить.
Если что, это я с позиции интервьюера пишу. Одно дело, когда в работе действительно нужно умение решать алгоритмические задачи. Другое дело, когда достаточно минимальных знаний уровня О и отличий между основными коллекциями платформы/языка/фреймворка.
Скорее типичная грабля физбаза, которая по хорошему должна быть исправлена при вычитке своего же кода. Вот если кандидат упорно ее не видит, тогда да, можно кричать ахтунг.
Это у всех так. Амазон - в один прекрасный момент они дропнули все базы и "восстановили" их из бэкапа полугодовой давности. Куда делись все более свежие бэкапы они не знали.
Что именно пригласят - крайне маловероятно, придется упорно себя предлагать.
Пет-проекты... скажу честно, его откроют не более, чем что бы посмотреть на степень грязи в коде. И если код грязный, то уж лучше вообще его никуда не выкладывать. Если нет возможности оценить на стороне, то подключить все возможные анализаторы и пусть они на мозги капают. Когда советуют делать пет-проекты, то это не столько что бы было что показать, сколько что бы вбить знания и навыки в подкорку через практику. Так и на собесе легче будет, когда вживую уже пощупать успел и по детским граблям побегать.
Ну а уйти можно как и везде: зад каменный, голова чугунная, нервы титановые, и учим-бегаем-ищем-готовимся-работаем-крутимся до победного. Если дергаться, обязательно вариант подвернется, порой совершенно неожиданно. А если ждать у моря погоды, то можно и до пенсии в медучреждении кантоваться.
Вот, кстати, отличный показатель того, что руководство само за продуктами или не ходит и не готовит, или скоропортящиеся товары им покупать уже не доверяют. У данных возвратов 2 причины:
Первая причина в том, что большинство закупается на несколько дней, а потому то же молоко может не дожить до момента когда оно понадобится, если ему осталось 1-2 дня.
Вторая причина - это отсутствие доверия к условиям хранения товара. В цепочке минимум 3 звена и любой может нарушить, например, температурный режим хранения, а значит и срок годности фактически уменьшится.
И, конечно же, эти причины складываются.
Употребляют, причем больше клиентские разработчики, чем бекендеры. Уж не знаю, пришло оно от одноруких бандитов, девопсов или еще откуда, но появилось оно совсем недавно и вакантное место единого жаргонного термина пока еще свободно.
Иногда даже с уточнением Е2Е4.
С солью и приправами, до полного выкипания воды и с легкой обжаркой после этого.
А потом за отдельную плату пропускать звонки от спамеров. Кому-кому, а опсосам доверия ни малейшего нет.
Отлично все компилируется и работает хоть под хрюнделем, хоть под миллениумом. Причина совершенно в другом, 7-ка сегодня занимает тоже место, что и IE6 в начале 10-х.
Даже банальная установка 7-ки сегодня превращается в пляски с бубном, что бы просто работал интернет. Казалось бы, поставить семерку, обновить руками обновлялку и дать ей самой выкачать и установить все обновления. Но нет, в таком режиме она не установит пакеты с современными удостоверяющими центрами и TLS 1.2. Более того, при попытке поставить эти пакеты руками она пошлет далеко и надолго, выдав ошибку. Т.е. если не знать, какие пакеты нужно установить руками перед автоматическим обновлением, то и работать интернет не будет.
Ну ок, а давайте возьмем уже готовую сборку, на ней же все работает... Ага, работает... костылями в самом хроме. А значит, если ты должен поддерживать 7-ки у конечных пользователей, то нужно реализовать кастомную проверку сертификатов, как сделал гугл.
И это только верхушка айсберга, под капотом там еще много иных проблем, которые нужно подпирать костылями, а потом на проверку этих костылей тратить больше времени, чем на общую проверку работоспособности. Как в 14 году я радовался, что больше не нужно поддерживать IE6, так в 24-м я радуюсь, когда больше не нужно поддерживать 7-ку. И именно это и есть причина, почему все больше разработчиков отказываются от ее поддержки.
Ну такие вопросы обычно надо воспринимать как: "все нормально идет или стену уже лбом ломаешь, а подойти спросить страшно?". К сожалению, очень частая проблема.
И цепочки, и капитолий любой ценой, приходили в голову аккурат после того, как надоедало играть с читами. Первая в качестве замены читу на бесконечный ход, второе читу на ресурсы. Восемь-не восемь, а 4-5 вспомогательных героев всегда носились по карте, собирали ресурсы, и раз в пару недель выстраивались цепью и передавали армию. Происходило это в районе 2001 года, в тогда еще только появлявшихся компьютерных клубах, и мне тогда было лет 13-14.
В основе лора там лежат не Герои, а серия Меча и Магии, без приставки про Героев. Тоже начинал знакомство с Героев и был очень сильно удивлен, когда с ММ6 познакомился. Когда фентези "неожиданно" превращается в жесткую фантастику и выламывает этим мозг.
Им в ответ распечатку подтверждения оплаты с госуслуг и никаких проблем.
Основная проблема - это время. Имея всего час на техинтервью, нужно проверить базовые знания языка, базовые знания архитектуры, базовые знания в области/основных библиотеках, опыт работы, да еще и успеть оценить кандидата как человека, на сколько хорошо он впишется в команду. При этом 5 минут в начале занимают расшаркивания и знакомства и еще минут 10-15 в конце занимают вопросы кандидата.
Та же задача со строками требует не 5 минут на подумать в условиях приличного стресса, как на экзамене, если ты с ней никогда не сталкивался раньше. И в этом проблема с большинством алгоритмических головоломок. Т.е. либо человек знает/заучил ее решение, либо ему нужно больше бороться не только с задачей, но еще и с собой, особенно не видя какого либо практического смысла в самой задаче и видя ее общую оторванность от реальности.
И т.к. люди на ТИ приходят именно как на экзамен, то выдернуть из этого состояния человека очень тяжело. Что я в ГЭКе в универе много лет сидел на защите дипломов, что я ТИ проводил. Возраст у людей вроде разный (и не всегда в пользу ITшнеков), опыта за плечами много, а поведение и состояние очень похожее. Так и ждешь в ответ на вопрос фразы "во валит, гад". И не дай бог он закуклится, как студент, и в молчанку играть начнет. Если студент после такого получит диплом и исчезнет, то у кандидата можно и адового токсика просмотреть. Прямо удивительно порой, как люди могут меняться, после того как скорлупу сбрасывают.
Ну и на последок, я не люблю для собеса задачи у которых есть идеальные и близкие к ним решения, слишком легко пропустить того, кто знает ответ. Намного полезнее посмотреть как человек бьется в паутине, когда у всех решений есть свои плюсы и минусы, и надо выбрать из них какое-то одно. За одно и человек расслабляется часто, потому что оказывается в обычной рабочей обстановке.
ЗЫ. Так, Остапа опять понесло немного не в ту степь, извиняюсь, стирать лень.
Бы ли бы все адекватные, подобные статьи регулярно бы не появлялись. Но неадекватов действительно много, я и сам на них нарывался. Когда тебя начинают гонять на конкретные алгоритмы, никак не связанные с вакансией, это просто убивает.
Как и мидла+ с сеньором на физбазах гонять обычно смысла нет, если у него с логикой проблемы, то он и на устных рассуждениях сыпется по полной.
Большая часть литкода - это далеко не физбазы, а вполне себе стандартные низкоуровневые алгоритмы, о чем и автор статьи писал. Те же вопросы про деревья на собесах стали притчей во языцех не на пустом месте. Так что исключение далеко не редчайшее и встречается очень часто, особенно когда собеседует человек, который сам не понимает что он тут делает, зачем кого-то ищу и когда ему с этим человеком дальше не работать.
PS. На работе "физбазы" как раз применяются постоянно, ибо даже простые табличные круды покрываются ифами для отлавливания пограничных состояний. ))
Собственно, все задачи класса "а как это сделать", это и есть физбаз чистой воды.
В контексте собеседования проверятся не физбазы на базовое знание операторов языка, а более хитрые вещи, типо плавающих окон, деревьев, графов и т.п. вещей, зачастую не применяемых в той компании. где это спрашивают.
Не сложнее классического физбаза.
Чуток обработать - это далеко не найти "самую длинную подстроку первой строки, являющуюся подстрокой второй строки", за исключением специфических областей деятельности. И это даже не 5% задач, потому что большинство задачи подобного класса не встречает годами.
Ну серьезно, кастомные деревья я писал один единственный раз за 14 лет работы, всяким наркоманским вычматом с его сглаженными окнами, матричными преобразованиями и прочими веселыми методами пользовался только на первой работе, и то там специфика такая была, что сопромата с математикой было больше. чем непосредственно разработки. А сейчас у меня вообще даже базы данных нет, что бы хоть откуда-нибудь много данных взять и что-либо с ними делать, а оперативные данные не выходят за десятки единиц. За то бизнес-логика с кучей пограничных ситуаций и точек отказа, так что ни в какие готовые алгоритмы не укладывается.
Еще раз повторюсь, алгоритмические задачи надо проверять там, где они действительно будут использоваться. И в большинстве мест работы оно вообще никогда не применяется или с этим сталкиваются полтора человека из всей команды, что бы целенаправленно искать человека со знаниями, которые скорее всего никогда не будут использоваться.
А если в работе такие задачи не встречаются? Тогда какой смысл гонять по подобным задачам?
Для большинства мест работы - это 50% архитектура, 30% бест практикс, 10% умение просчитать пограничные случаи и 9 процентов знание языка, 1% знание О, что бы нечто типо O^2 по одному набору данных не делать.
Алгоритмы надо спрашивать там, где алгоритмы реально используются, а иначе это поиск дворника в ларек, но обязательно с высшим образованием и званием КМС по бальным танцам.
Буллшитер как раз быстро ломается и в лютую воду скатывается, потому что готового решения у задачи не существует, а проанализировать несколько возможных решений без навыков и опыта банально невозможно. Причем те самые интроверты, которые до этого пол часа нукали, мыкали и экали, магическим образом начинают говорить без остановки, потому что мозг на рабочие рельсы автоматом переключается и выдает информацию быстрее, чем тело озвучивать успевает. С детальным анализом, потенциальными проблемами, узкими местами и даже с наброском возможной архитектуры решения.
А зачем? В надежде найти самого лучшего на ближайшие 3 года? Скорее будет вакансия, которая не закрывается месяцами, и зашивающаяся команда, которой всего лишь был нужен еще один крудописатель или кнопкорисователь, что бы мыло смыть.
Под алгоритмическими задачами далеко не физбазы понимаются, давайте все таки не будем в софистику уходить.
Пузырек - это обобщенный синоним сферического алгоритма в вакууме, который лежит в основе задачи, будь то хэши или подсчет змей попугаями.
При этом, в работе нужно писать over9000 CRUD'ов, перекладывать 100500й JSON из одной кью в другую, разгребать четырехтомники войны и мира легаси и, иногда, находить и фиксить наитупейшие ошибки и опечатки уровня физбаза, написанных в условиях: усе пропало и должно быть пофикшено вчера. Причем эти ошибки исключительно из-за того, что команда уже в состоянии свеже-выкопавшихся зомби от усталости.
На техинтервью обычно выделяется всего час и тратить большую часть своего времени на проверку маловажных навыков... ну это даже себя не уважать. А ведь надо успеть еще пробежаться по основным возможностям языка, платформы и практикам, оценить человека с точки зрения вливания в команду и не забыть оставить время на вопросы от кандидата.
При том, что вместо любых головоломок обычно достаточно дать "простую" задачу на подумать, класса "как бы вы решали такую-то проблему", причем жизненную, а значит не имеющую идеального решения, в отличии от алгоритмических. За 15 минут можно увидеть практически всю подноготную человека, включая его реальный опыт работы и общий уровень. И приправить все это каким-нибудь физбазом или куском легаси на пяток минут, как раз навыки ревью оценить.
Если что, это я с позиции интервьюера пишу. Одно дело, когда в работе действительно нужно умение решать алгоритмические задачи. Другое дело, когда достаточно минимальных знаний уровня О и отличий между основными коллекциями платформы/языка/фреймворка.
Скорее типичная грабля физбаза, которая по хорошему должна быть исправлена при вычитке своего же кода. Вот если кандидат упорно ее не видит, тогда да, можно кричать ахтунг.