На Хабре с завидной периодичностью возникают посты от возмущенных программистов, которые справедливо (наверное) негодуют, почему на собеседовании никто не спросил про их прошлые проекты, не посмотрел их код, но задавал шаблонные справочные вопросы или заставлял решать алгоритмические задачи, которые, скорее всего (в 99%), не будут применяться на вакантной работе.
Чтобы уменьшить поток этих публикаций (святая простота), ниже будет краткий, но лаконичный справочник по типам собеседований, которые вам стоит ожидать от конкретного типа компании. Справочник основан на личном многолетнем опыте. Надеюсь, это поможет вам (именно тебе, да) выбрать лучшую стратегию успешного получения работы.
Собеседование в мировую it компанию
Пример | Яндекс, Гугл, Майкрософт, Амазон |
Количество кандидатов | сотни (тысячи) |
Тип собеседования | вступление в армию |
Ожидаемые вопросы | алгоритмические задачи |
Многие программисты хотят попасть в такие компании, потому что там сухо и тепло (и корпоративные ипотеки под низкие проценты). Поэтому компании просто завалены резюме от кандидатов со всех концов страны (или мира). Чтобы хоть как-то отбирать кандидатов, компании приходят к фильтру по алгоритмическим задачам.
Потому что это:
- Стандартизировано. Все задачи известны, их много, все решения заранее не заучишь, требуется хорошая теоретическая база.
- Унифицировано. Все интервью можно проводить одинаково: 40 минут на решение задачи кандидатом, разбор и оценка его типичного решения.
- Просто и эффективно. Поверьте, если бы можно было как-то иначе найти хорошего кандидата из сотни посредственных, то крупный бизнес бы искал по-другому.
Резюмируем
«Вас много, а я одна!» — кричит нам крупная контора, которую мы дружно закидываем своими резюме. Нам дают сложный, скучный и бесполезный в работе фильтр из задачек. Кто-то проходит, а кто-то — нет (я — нет).
Хотите, чтобы отбор был без задачек? Ну… Давайте сговоримся и будем подавать от всех нас лишь одно резюме в месяц, уверен, тогда уж точно найдется время спросить у кандидата про его прошлые проекты. :)
Собеседование в аутсорсную компанию
Пример | Епам, Люкссофт |
Количество кандидатов | десятки |
Тип собеседования | отбор дойной коровы |
Ожидаемые вопросы | справочные материалы и чуть-чуть задачек |
Давайте сразу проясним: цель любой аутсорсной компании — продать ваше время разработчика задорого, а потом забирать себе часть вашей зарплаты (половину). Это основная бизнес модель.
А значит:
- Вы должны выглядеть круто для продажи.
- Вас можно легко перекидывать с проекта на проект.
Отсюда и вытекают вопросы на собеседованиях. Вас будут гонять в хвост и в гриву по всем технологиям, которые вы указали в резюме. Потому что от этого зависит, как быстро вас можно будет пристроить к новому заказчику, какие сладкие эпитеты ему можно будет рассказать про вас, какие именно сокращения технологий можно будет вписать в ваше внутреннее резюме, чтобы оно выглядело «пожирнее» (Spring, EJB, Node.js, Kafka, Redis, Mongo, MySql, JMS, MMQ, UPR, ABCDEFG, ну вы поняли).
Ах да, чтобы казаться солиднее, еще можно у кандидата пару задачек на алгоритмы спросить. Ну а что, вон, Яндекс же так делает.
Резюмируем
«А насколько вы — выгодное вложение для перепродажи?» — хищно смотрит на вас контора. Ну а мы же не лыком шиты, да? Хитро улыбаемся в ответ, зубрим все определения перед собеседованием, решаем несколько простейших алгоритмических задачек (обход дерева в ширину, ага), а потом заламываем хорошую цену за свой будущий труд. И возможно, с грустным лицом, компания согласится отдавать вам не меньшую, а большую часть ваших заработанных непосильным трудом денег.
Собеседование в небольшую компанию
Пример | смотри вакансии в своем городе |
Количество кандидатов | единицы (десятки) |
Тип собеседования | отбор для дела (или души) |
Ожидаемые вопросы | всегда по-разному |
В небольших и средних компаниях, которые выпускают свой продукт или занимаются автоматизацией на заказ, обычно нет общих для всех правил отбора новых кандидатов.
Всё зависит от конкретных людей, проблем, фазы луны. Где-то вас попросят решать задачки (потому что так делает Гугл), где-то будет тестирование на знание всех методов библиотек (потому что так делает Люкссофт). А где-то вам предложат разобрать ваш код, поспрашивают о ваших предыдущих проектах, и вообще, вы мило побеседуете обо всем на свете на 2 часа, а потом эти ребята станут вашими лучшими коллегами на много лет вперед (слезы умиления).
Резюмируем
Индивидуальность каждой отдельной компании. Часто именно конкретные люди выбирают лучшую стратегию отбора, и тут уж вы либо подходите под эту стратегию, либо нет. Самый человечный отбор кандидатов со всеми плюсами и минусами: бардак, анархия, и это прекрасно!
Спасибо за потраченное на статью время и удачных собеседований, коллеги!
sshikov
Про Люксофт и.т.п. — все сильно упрощено. Бывает и не так, и совсем не так. Я как работал в первом, так и нанимал из второго на проекты. Но как ориентир чего следует ждать — наверное годится.
rfq
для меня в Люксофте основным перпятствием был английский язык. С письменным у меня хорошо, но проверяли устный по телефону на бытовые темы (проверяли не программисты, а преподавательницы английского). А по телефону, с низким качеством звука, не очень-то разберешь, о чем спрашивают.
remzalp
ну как бы и в реальной жизни довольно много общения будет по каналам связи, так что обстановка приближена к боевой
Kwisatz
Это все решается на раз два, вам нужна неделя-две практики и воспринимать на слух станет куда проще. (если компания международная то внутри нее наговорить не проблема) Кстати это вам никак не поможет если у вас не было опыта разговора с индусами или англичанами, с ними еще плюс столько же.
IgorPie
Ищутся онлайн курсы, где лектор — индус и воспринимать становится значительно проще.
Вот то, что с английским делают французы, это действительно боль.
DrunkBear
Большинство англоязычных бесплатных курсов по BigData читают индусы, причём с разными акцентами — отличная практика (практически всегда — с субдитрами на английском).
Заодно и расширить границы познания.
Gryphon88
Испанский и китайский варианты английского, имхо, ещё грустнее.
opxocc
Испанский не слышал, но японский вариант куда хуже китайского, вживую довелось пообщаться с японцем и китайцем, с китайцем мы довольно быстро нашли общий язык и примерно в равной степени не понимали английский друг друга, а вот что говорит японец я ну никак не мог понять, сказывается их привычка перекладывать английский на звуки японского алфавита.
Areso
Они серьезно говорят что-то вроде «Са-ба», или это из разряда
городскихайтишных баек?opxocc
Да, server — сарва (ну или са-ва, да), database — дэтабейсу, client — кураянт и т.д. и т.п. Еще сильно мешало то, что начинаешь переспрашивать — входит в ступор, но это может особенность конкретного японца :)
trixy
если они говорят на японском — да, так слова заимствуются.
khim
Если два класса японцев: те, которые общались с нэйтив спикерами, и те которые не общались.
У них просто в языке в принципе не бывает две согласлых подрят (за исключением «н», кажется). И все слога открытые. Ну и «л» и «р» — это один звук.
И при этом английские слова они любят… но странною любовью. Вот возьмите To Love-Ru. Что это вообще может значить? А это, оказывается «Trouble».
Вот для вас «To Love-Ru» и «Trouble» похожи? Хотя бы отдалённо? А для японца — они вообще одинаково читаются…
Но это если они в японской фирме работают. Если они найтив спикеров слышат (работают в Google или Microsoft), то уже через год говорят почти без акцента.
Gryphon88
Все японцы, с которыми я общался, принципиально говорили только на японском. Возможно. повезло.
Viceroyalty
del
XAHOK
Индусы вполне нормально говорят. Самое сложное было с итальянцами, т.к. они и на английском говорят очень быстро и ты просто не успеваешь осознавать что он говорит. Помогает только полное отключение мозга и полное забывание всех остальных языков, ибо на это уже времени не остается.
harry2019
Индусы — нормально? Это шутка или издевательство?
DrunkBear
Захотелось поговорить с итальянцами, на фоне которых индусы говорят нормально.
Или имеется в виду
XAHOK
Примерно такое
XAHOK
Это привычка
dimkrayan
а меня как-то собеседовала по телефону рекрутер из Великобритании. А у них как будто совсем другой телефонный кодек используется и звук в телефоне звучит очень непривычно.
В общем, не взяли меня туда.
Koderka
Для Люксофта собеседование велось (по состоянию на два года назад, как сейчас обстоят дела — не знаю) на конкретный проект его менеджером и тимлидом (или старшим специалистом). Технические интервью были по технологиям, использующимся на проекте, и о том, насколько кандидат ими владеет. Спрашивали о конкретных задачах, которые решал кандидат на прошлых проектах. Впрочем, какие вопросы задавать решал интервьюер. На некоторых проектах могли и по теории погонять, и задачки позадавать.
Что важно — в компаниях такого рода собеседование ведется руководством проекта и на конкретный проект. Переброска между проектами, о котором здесь говорилось (т.н. Internal Mobility) по сути мало отличается от приема на работу внешнего кандидата: те же собеседования и с теми же людьми.
sshikov
Я примерно это же и имел в виду. Просто мой опыт с Люксофтом был в 2005, поэтому ссылаться на него сегодня мало смысла. Но суть в том же — брали на проект, и только на него, и ни в коей мере не для того, чтобы куда-то продавать.
stanislav888
Код который программист выложит для просмотра работодателем, может быть написан кем угодно. И даже если написан самим кандидатом то может в корне отличатся от того что тот заливал в прод каждый день.
Я вот очень долго над этим думал и пришёл к выводу что тут всё логично. Вопросы по алгоритмам задаются не от хорошей жизни. Работодатель может не знать того фреймворка с которым работал кандидат. Потом, у работодателя скорее всего другой фреймворк. Получается что работодатель не может правильно оценить кандидата в немного другой сфере, которую он не знает. А кандидат скорее всего не ответит на вопросы о фреймворке работодателя. Итого, рассказывать\спрашивать что то о вещах из повседневной работы рискованно. Можно не найти общий язык.
Поэтому, среди возможных остаются вопросы по тонкостям языков программирования и по теоретической базе, которая должна быть у любого кто серьёзно изучал программирование. А те кто изучал несерьёзно нафиг не нужны. ФормоШлёпов и своих обычно хватает.
Большинство того что спрашивают на собесах это не rocket science, а умещается всего в 2-х книгах на темы: паттерны ООП, алгоритмы. Надо всего лишь осилить две книги, чтобы пройти 60-70% собеседований. И это не обязательно должны быть самые сложные книги в своём роде.
chapuza
Да ладно? Три уточняющих вопроса на собственно собеседовании прояснят это за 60 секунд.
Компания должна создать кандидату именно что условия, в которых он пишет тот код, который понравился. И компании это нужно гораздо больше, чем самому кандидату.
Я не представляю себе фреймворк (да, даже язык, если честно), на котором я не смог бы разобрать и оценить код, предоставленный кандидатом, которого я собеседую.
У хаскелиста, джаваскриптовика, шарписта и эмбедщика эти базы имеют примерно ноль пересечений. Глубокое знание ООП для наших задач, например, я бы вообще отнес в минусы (как и склонность гоняться за наносекундами у эмбедщиков).
stanislav888
Например если вы не работали с Qt то вам будет сложно с разбегу понять всякие делегирования, модели данных и пр. залёты. Это всё даже разрабы с опытом иногда не понимают.
Было бы неплохо если все они будут знать сложность алгоритмов. Иначе могут влепить какой нибудь алгоритм который, вроде как работает в тестах, но в проде завешивает весь сервис.
JustDont
Я уже много беседовал на эту тему со свидетелями Священной Big O, и мне довольно-таки надоело, но напишу еще раз тут: для фронтэндера, например, вопрос знания сложности алгоритмов в лучшем случае примерно третий по важности, и на собеседовании особо не значим. Почему? Потому что высокая алгоритмическая производительность на фронтэнде иногда нужна, но весьма редко; а вот знать, как браузер грузит ресурсы и рендерит страницу — нужно практически для любого реального проекта. Быстродействие будет определяться именно этими двумя вещами, а не тем, что вы где-то там внутри дуболомно изобразили O(n!), вот только n всё равно выше десятка не вырастет даже в теории.
ЗЫ: Я, к слову, уже встречался в реальности со свидетелями Священного Big O, которые ради того, чтоб нарисовать таблицу ячеек так на 10К, фигачили собственные хешмапы (дело еще было до того, как в JS появился стандартный) и прочую порнографию. Таблица при этом нещадно тормозила, потому что в big O пацаны смогли, а в оптимизацию рендера нет. И перерисовывали все 10К ячеек по любому изменению.
stanislav888
Я по большому счёту не утверждаю хорошо это или плохо. Мой поинт был в том что всё это вполне можно осилить даже несмотря на очевидную ненужность.
JustDont
Осилить можно что угодно — от лямбда-исчислений до борьбы с компилятором за каждый байт памяти. Беда только в том, что этого настолько много, что на осиливание всего вам не хватит всей жизни. А на освежение памяти относительно того, что вы осилили — так и еще меньше. И когда вы с каким-то набором знаний приходите на собеседование, а там у собеседующего очень даже свои представления о том, что, как ему кажется, кандидат мог бы осилить — вот там и начинаются нестыковки.
sultonaka
Эх, как с языка сняли!
stanislav888
Лично у меня было около 20-и собеседований по теме С++ за последние три года. На английском, русском, заочно, с работодателями, заказчиками и всяким мудачьём, которое просто хотело получить консультацию бесплатно.
Большинство этих собеседований успешно прошёл. И на основании этого сделал выводы, что нужно знать что бы пройти. Собсно этими выводами я и поделился выше.
А вы мне пытаетесь доказать как оно должно быть. Да мне оно без разницы, как это всё должно выглядеть. Я не собираюсь изменять мир трудоустройства к лучшему и кого то персонально убеждать.
Не нравится моё личное мнение — пожалуйста.
adictive_max
stanislav888
Про «паттерны ООП» это одна книга — ru.wikipedia.org/wiki/Design_Patterns на худой конец можно и википедию поштудировать.
Про алгоритмы и структуры данных книг много. Есть даже видеолекции на английском. Это тема сложная, поэтому попробуйте все что найдете. Самой простой книгой считается «Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих»
Я бы НЕ советовал книги Седжвика по алготитмам. У него язык изложения и переводы ИМХО читаются очень плохо.
В процессе изучения можно подглядывать на youtube по отдельным темам, если совсем тяжело доходит.
Gryphon88
Что про Скиену скажете? Кнута я не осилил, искал лайт-версию.
stanislav888
Даже не слышал про такого. А «лайт-версий» вполне достаточно. Надо только найти, которая из них влезает в голову.
Gryphon88
Я вот про эту говорил, если вдруг кому интересно. Доступно, понятно, с примерами из практики, жаль, что обзор популярных библиотек подустарел.
Kwisatz
Омг, я вас цитировать буду) Я их адептами называл, но так гораздо лучше)
А это самая частая ошибка на фронте и по сей день. И даже крутые фреймворки не спасают, хотя уже все сделали, чтобы этого было поменьше.
Может быть как раз изза того, что ребятки, которые ваяют классные фронты, не проходят собеседования с выкрутасами вроде: «отсортируйте пузырьком имея только каменный топор и березу», расплодилось такое дикое количество сайтов с фронтом, писанным левой пяткой пушистых тапочек.
vvbob
Мощно задвинул! :)
Как-то я эти страхи не разделяю, о том что вот кандидата не спросим ничего по алгоритмам и он нам повесит весь прод. Если у вас код ревью в принципе нет, то так, конечно, может случиться, но в реальной жизни, с нормально поставленной разработкой такого не стоит бояться.
Да и подавляющее большинство задач, которые реально решаются, не требует оптимизации. Выгрести данные запросом, протащить их по всем слоям сервиса, отмаппить их в DTO и отдать через API наружу… Обычно там все шаблонно и данных на каждом этапе немного (ибо пагинация) — сложно так налажать что-бы все ну совсем плохо стало.
SpiderEkb
Насчет «большинства задач»… Ну не знаю… Сильно зависит от предметной области. Мне в этом смысле «везло» (или везло — тут как посмотреть). Долгое время работал в промавтоматизации — там постоянно сталкиваешься с жесткими таймаутами. Не уложился — тебя послали. Разрыв соединения, реконект, перепосылка пакета и все такое прочее. Посему — будь добр извернуться, но все необходимые действия уложить в отведенное время.
Сейчас работаю с высоконагруженными системами. Не сказать что 100%, но есть отдельные задачи, которые должны быть оптимизированы до предела. Иначе… Ну вот из недавнего — у одного из банков в период предновогоднего пика транзакций на пару часов перестали проходить платежи по пластику.
Хорошо это для банка? Очень нехорошо. Нет, денег ни у кого не пропало. Ни копейки. Все в конечном итоге отработало, но репутационные потери налицо. Клиенты недовольны — пришел в магазин перед НГ закупиться, а расплатиться картой на кассе не можешь…
И там тоже вопрос был в оптимизации одного модуля.
Понятно, что такое не везде и не всегда, но есть области где налажать неоптимальным кодом можно запросто и достаточно серьезно. И этот момент приходится постоянно держать в подсознании когда что-то пишешь. Т.е. первый проход — как написать чтобы работало, второй — а можно написать чтобы работало быстрее и с меньшим ресурсопотреблением?
vvbob
Ну, оно очевидно, что там, где жесткие таймауты и требования к быстродействию, есть смысл спрашивать и про большое О и про аппаратные заморочки всевозможные и про опыт оптимизаций…
Мой спич был о том что все это часто требуют на вакансиях, где будешь месяцами перенаправлять байты из БД в REST, с помощью фреймворков, и где даже постаравшись будет очень сложно все это сильно замедлить использованием кривого алгоритма.
SpiderEkb
Согласен, что на собеседованиях часто просто тупо лупят по взятому откуда-то шаблону, абсолютно не задумываясь насколько этот шаблон применим к специфике работы в данной конторе.
Вообще, попасть на хорошее собеседование та еще удача, как я понял. И, опять же, иногда если не прошел через собеседование, то думаешь — вот и слава богу что не прошел. Не хочу я тут работать.
Было у меня такое один раз…
ra2003
Ой, можно у Вас стащить "левую пятку пушистых тапочек"? https://cv1.pikabu.ru/video/2020/01/26/1580040782263219333_458x658.webm
Kwisatz
Да ради бога) Классная картиночка)
mayorovp
Но ведь это и называется "не смогли в Big O".
JustDont
Это классическое «к пуговицам претензии есть?!». У них в коде — всё прекрасно и минимальная алгоритмическая сложность, а что происходит за границами их кода — им не очень интересно было. Самое забавное, что я одного из этих прошлых авторов лично спрашивал — мол, а зачем это всё, если у вас перерисовка кривая? На что мне было сказано, что чёт всё медленно было, а значит надо было улучшить сложность! Ну и улучшили, только быстрее не стало. Отчитались, что они молодцы, а проблемы все на стороне браузера.
mayorovp
Ну так и проблема-то, получается. именно в этом подходе "к пуговицам претензии есть?!", а не в Big O.
Тем более что на самом-то деле именно их код был алгоритмически неоптимален.
abar
Вот я знаю про Big O, а при этом уже сколько времени работаю, но каждый раз когда на проде обнаруживается какой-то завтык — у меня инстинктивное желание вопить про «неэффективную структуру данных» и что нам нужно немедленно всё останавливать и денормализовать всю структуру в БД для оптимизации под чтение (прямо как нас в универе учили!), а опытные коллеги вместо этого просто вставляют очередной индекс, получают 10-кратный прирост к производительности и спокойно работают дальше. Уже сколько раз себя по рукам бил, а до сих пор желание не проходит.
Так что да, алгоритмы в вакууме — это хорошо, но практическое понимание мест, которые *имеет смысл* оптимизировать — всё-таки важнее.
mayorovp
Ну, индекс-то, если рассмотреть его уровнем ниже, и есть денормализация структуры хранения для оптимизации "под чтение"...
dss_kalika
И в них немало от оптимизации сложности алгоритмов )
LinearLeopard
Извиняюсь, за глупый вопрос, последний раз базы трогал именно в универе. А как там можно ускорить чтение, помимо индексов?
BugM
Денормализация и избавление от джойнов в hot path часто помогают ускорить чтение. Но это после добавления всех возможных индексов, естесвенно.
Ps: Это не руководство к действию. Это тема для поговорить.
LinearLeopard
Спасибо за ответ. Что джойны лучше убрать, где можно, это понятно. Под денормолизацией понимается ввиду хранение не 2 таблиц, которые нужно джойнить, а сразу сджойненную? Извиняюсь за ещё один глупый вопрос.
mayorovp
К слову, у SQL Server есть индексированные представления, которые как раз и позволяют хранить сразу сджойненную таблицу. А в Enterprise-редакции он ещё и использует такие представления при оптимизации запросов, что превращает их во что-то вроде индекса по двум таблицам.
a-l-e-x
если это тема поговорить — то partitioning, clustering, parallel reading from different nodes, etc…
в некоторых базах данных нет явных индексов вообще, что не мешает читать со скоростью много гигабайт в секунду…
Keyten
Как я понимаю, stanislav888 говорит не об умении работать с красно-чёрными деревьями, а о базовом понимании, что for внутри for внутри for это плохо.
LinearLeopard
Главное, чтобы потом не надо было отобразить табличку, в которой более 100 элементов. А ведь иногда ещё и 1000 может прийти. Очень не каждый выдержит такое. Jira и confluence вот не всегда справляются.
JustDont
Я даже не представляю, как при отображении таблички получить что-то хуже n^2. А n^2 отобразит сколько угодно информации, сколько вообще имеет смысл показывать человеку за один подход; и узкое место опять таки будет не в n^2, а в рендере, если только вы каждую ячейку не заполняете чем-то вычислительно сложным, рассчитываемым прямо в клиенте. Впрочем, для этого уже даже wasm завезли.
Cerberuser
Так в том-то и дело, что для рендера это самое n^2 на каждую перерисовку — это уже много. Даже n — и то иногда может оказаться много.
JustDont
Скажу еще проще: в браузере рендер DOM-дерева таблицы на N ячеек в общем случае имеет очень плохую вычислительную сложность (потому что допускает многократный ре-рендер части таблицы, в максимально плохом случае при рендере каждой новой строчки произойдет ре-рендер всех предыдущих) с очень большой константой, против чисто вычислительных операций в JS. В частном случае (table-layout: fixed) — линейную, со всё так же большой константой. Чтоб ваши вычисления со сложностью m*N^2 стали более узким местом, чем браузерная перерисовка со сложностью M*N (M сильно больше m) — вам придётся очень сильно постараться. И это только table-layout: fixed, что уместно далеко не всегда.
khim
Это всё, конечно, прекрасно, но я работал с табличками на 10000 строк. Да, грузятся они долго, конечно — но зато потом их листать можно быстро и нужное место находится легко.
А вы зайдите, пожалуйста, сюда и попробуйте пролистать вот это вот… не хочу ругаться матом.
А ведь там всего-навсего порядка 2000 картинок.
Так что, может, и нужно «очень постараться» — но почему-то людям, не умеющим в Big O это удаётся с трогательной регулярностью.
Причём чем «феншуйнее» страница и чем более модные технологии там использованы, тем больше шанс, что всё это будет тормозить нещадно и жрать память как не в себя.
Так что вы уж извините, но я останусь при своих: если человек не умеет писать программы без применения алгоритма маляра Шлемиэля — то его не нужно брать никуда. На на фронт, ни на бэк, никуда вообще.
Про фибоначчиевы кучи и алгоритм Шёнхаге — Штрассена при этом знать, в общем, необязательно…
JustDont
Мы уже обсуждали это — убогая бесконечная лента на патреоне убогая как раз потому, что авторы не смогли в понимание, что там у них и как перерисовывается. И перерисовывается оно всё каждый раз с нуля при каждой догрузке ленты. Вот вы нажали на кнопочку «Load more» — и у вас вся лента сверху донизу перерисовывается, просто чтоб вместо кнопочки load more показать спиннер. А потом оно догрузится — и еще раз столько же.
При этом я почти уверен, что авторы не без основания считают, что в их собственном коде с алгоритмической сложностью всё прекрасно. Там наверняка ничего сложнее O(n) ;-)
khim
Что, собственно, и является классическим «Шлемиэлем». И если уж люди такое допускают — то это действительно, не люди, умеющие в алгоритмы, а «свидетели Священной Big O».
Да, мне от «знания алгоритмов» нужно, чтобы человек умел избегать алгоритма маляра Шлемиэля (или умел доказывать что это невозможно там, где это невозможно). И все задачи, которые я даю — всегда именно на это.
А вовсе не на знание хитромудрых алгоритмов из вумных книжек.
JustDont
Я бы не называл это «неумением в big O», потому что вполне может статься что при попытке это выяснить (каким-нибудь условным собеседованием или экзаменом) вы от такого человека услышите про big O в её академическом понимании больше, чем сами знаете.
Это неумение пользоваться выбранными инструментами — процессором, про что пишет Джоэл, или реактом, что наблюдается в ленте патреона. При этом совсем даже не стоит исключать того, что какими-то другими инструментами все эти же люди умеют пользоваться гораздо лучше. И еще не стоит забывать о том, что в зависимости от инструментов и создаваемого софта — будет вполне допустимо определенными инструментами не владеть или владеть крайне плохо, без каких-либо видимых последствий.
LinearLeopard
Ну уже n^2, в начале было факториал. :)
А вообще всё зависит от задачи и сценариев использования. Допустим у нас данных даже 10000, допустим даже таблица строится за квадрат (т.е. 10^10), это для процессора, который может выполнять десятки миллирдов операций (как раз таки 10^10) несколько секунд (если не считать рендеры, я не знаю, как они работают, туда не лезу). А потом кому-то надо с этой таблицей работать и на каждой перезагрузке получаем уже k*N^2, где k — число перезагрузок, что вызывает уже боль. А не дай бог, потребуется сделать операцию над каждой ячейкой и она будет перересовываться именно после каждой ячейки. Уже получаем куб. В общем я согласен с вами, что знание рендера очень важно, но квадраты пихать тоже не стоит.
JustDont
Факториал был как абстрактный пример крайне плохой сложности, которая, однако, на малых n едва ли будет значима.
Лично у меня глагол «работать» не вызывает никаких ассоциаций с «давайте заново перестроим таблицу по квадратичной сложности». Что вы имеете в виду?
nohuhu
Глас вопиющего в пустыне… Людям, которые работают с простыми, очевидными, и прекрасно контролируемым условиями в back end, никогда не понять хаоса и дикого Запада front end.
khim
Вы так говорите, как будто я front end не делал. Делал. И не раз. Нет там никакого хаоса. Хаос есть только в одном, всем известном месте — и он не имеет никакого отношения ни к back end'у, ни к front end'у.
До back end'а он недобирается исключительно в силу того, что люди, способные его устроить о его сушествовании не знают…
JustDont
Нет, до бэка вся эта классика меньше доходит просто потому, что в бэке деление на «работает» и «не работает» чуть более определенное, в то время как на фронте прекрасное промежуточное состояние «работает в правильную фазу луны, при должных жертвоприношениях, и если не трогать красную кнопку» — оно частенько длится весь жизненный цикл продукта, и вполне себе удовлетворяет бизнес (а кого не удовлетворяет — перетопчутся).
nohuhu
При всём уважении, ваши слова только подтверждают разницу между "делал, и не раз" и "занимаюсь этим постоянно". Вы этот хаос или намеренно игнорировали, или просто не успели заметить.
Если даже не вдаваться в поэзию, то самый поверхностный анализ ситуации позволяет увидеть, что благодаря наличию:
… и т.д., и т.п., поверхность потенциально проблемной области в front end разработке в разы больше, чем в back end. Если не на порядки.
Просто для примера, из свежего: у вас в практике часто бывало, чтобы на серверной стороне в код без спросу внедрился случайный третьесторонний модуль и начал блокировать вызовы к каким-либо микросервисам? И его не убрать никак. А у нас это норма жизни, ad blockers или какие-нибудь расширения в браузере могут в любой момент поломать что угодно. И объясняй потом бизнесу, почему их интеграция с каким-нибудь Appcues не работает и как её починить (а починить нетривиально).
И таких ситуаций, факторов, ошибок, особенностей, да просто багов — сотни, тысячи их. И каждый день что-то новое.
Мы из Хаоса (tm).
mayorovp
Забавно, но именно на бэке я с этой ситуацией и столкнулся впервые. KIS что-то портил в запросах к чужому серверу по HTTPS со сжатием (которое Content-Encoding), пришлось добавить настройку для отключения этого самого сжатия.
nohuhu
Это всё же не совсем то, о чём я говорил. Прокси-сервисы и middleware тоже ломаются иногда, настройки слетают, и всё такое.
Но в back end практически не бывает так, чтобы без каких-либо изменений в вашем коде/настройках/Dockerfile/K8s/whatever, вдруг внезапно всё сломалось и перестало работать.
А на frond end — легко. Домен третьесторонней интеграции кто-то добавил в чёрный список, и привет. Узнать об этом, кроме как из разъярённых воплей обиженных клиентов, вообще никак нельзя. Это не хаос?
khim
А если этих пользователей — полпроцента и, в принципе, всё равно всё работает… то так ли уж важно и нужно на это реагировать?
Гугл какой-нибудь отлично «забивал» на пользователей Opera даже тогда, когда Opera была лидирующим браузером, а Гугл отчаянно боролся за российский сегмент (у них тогда даже пара центров разработки в России была).
И ничего — это не помешало ему вытеснить сначала Рамблер, а потом и Яндекс.
XAHOK
Да регулярно. Просто на фронте — это адблоки и сотоварищи, а на бэке — это сисы, баги и кривые деплои у сторонних сервисов, проблемы у облаков, ДЦ, хостеров и т.п. В последний раз поперло куча падений по таймауту при обращении к базе в облаке на обновление записей, последний релиз за месяц до, последний деплой за неделю до. Ничего не делали, примерно 10% запросов падают по таймауту.
khim
Но почему-то заявление о том, что наш back end работает с MySQL или PostgreSQL, но никак не с mSQL — воспринимаются нормально… а заявления о том, что HuyanPinyanBrowser не поддерживается — приводят к истерике. Хотя доля у того HuyanPinyanBrowser'а меньше, чем у mSQL… но он предустановлен на любимом ноуте директора — и потому получает самый высокий приоритет.
nohuhu
С точки зрения этого бизнеса (или, вернее, менеджеров), вы тоже всё время хотите чего-то странного. Зарплаты, например.
Я хочу вдаваться в подробности на тему, почему "забить большой болт и всё" нельзя. Это отдельная большая тема.
Я вам о другом говорю: забить большой болт не работает. Можно забивать сколько угодно, это не поможет. Никак. Потому что у 95% пользователей всё равно будут разные браузеры, разные платформы, и разные устройства. От мощных десктопов до туповатеньких Chromebook, от последних iPhone до дешёвых китайских клонов какой-нибудь младшей модели Samsung Smartwatch. Какие критерии вы предлагаете использовать для исключения тех и этих, чтобы ваша жизнь была попроще? Назад в будущее, к This site is best viewed in IE6?
По вашим словам мне очевидно, что вы просто не владеете предметной областью. Так и должно быть, front end не ваша специализация. Это моя специализация, и я отлично знаю из опыта и толстой мозоли на лбу, почему нельзя "просто взять и сделать" сайт, чтобы всё работало и все были довольны.
Я стараюсь не вспоминать о битвах с нативным скроллингом документа, который есть сущее, адское зло — а виртуальный скроллинг это тоже сущее, адское зло. У меня в печёнках сидят поля ввода в HTML, обработка фокуса, маски и валидирование значений. Меня тошнит от touch events, от распознавания жестов по таймауту и ловли утёкших таймеров (ручками, всё ручками!). Я молча посылаю пламенные лучи ненависти и поноса в сторону HP, Lenovo и прочих умников, выпускающих лаптопы с тачскринами, которые никак особенно не определяются в браузере и потом к чертям ломают всю обработку событий, потому что смешать pointer events и touch events это — а чо, у нас в Windows работало? Я плачу кровавыми слезами каждый раз, когда мне нужно лезть в caniuse.com и подтверждать, какие фичи из CSS3 работают в последнем мобильном Сафари, а какие нет. И т.д. и т.п., конца и края этому нет (и не будет).
Можно всё это игнорировать, для личных проектов сойдёт — кому они нужны, кроме вас. А для коммерческих проектов не сойдёт, и игнорировать уже не получится. Добро пожаловать в добрый, светлый мир front end. :)
khim
Так с какого перпугу я должен перед этими людьми бить чечётку?
Ну так если хотите — так и сделайте. Кто мешает? Вдавайтесь…
Потому что с одной стороны — я вижу рассказы про то, что нужно вот обязательно делать всё «феншуйно» с использованием кучи костылей, а то, не дай бог, отпадут три с половиной пользователя, который пользуются странным антивирусом на ноуте Lenovo с тачскриром… с другой стороны — наблюдаю не работающий уже неделю в Firefox ESR 68.4 интерфейс перевода денег с карты на карты в Yandex.Money… ну и как это сочетается, извините?
Я работал в конторах, которые стремились поддерживать все эти «странные» браузеры и «странных пользователей»… и таких, которые этого не делали.
Практическая разница — во вторых работать гораздо спокойннее… и не скажу, чтобы с сильной потерей зарплаты. А если они существуют «в количестве» (а они таки существуют) — то «забивать болт» вполне можно.
А очень простой критерий — делайте всё так, чтобы оно работало. И всё. И не пытайтесь добиваться попиксельного совпадения с кем-то придуманной «концепцией».
То, что реально нужно для реализации функциональности большей части сайтов отлично отрендерит и IE6. Напоминаю что в 2004м, когда появился GMail — это был самый популярный браузер… и уже тогда там был и приличный интерфейс и загрузка писем в фоне и многое другое.
Для всего этого не нужно использовать «модные» фишки новейших фреймворков и кучу транспайлеров, порождащих в итоге мегабайты кода, с которыми потом еще-еле работают даже топовые системы.
И почему же? Вот конкретно: почему в 2004м со всеми этими MS IE 5 и Netscape 4.8 это было сделать можно, а потом вжух — и сразу стало нельзя?
Ответ: потому что в те времена ответ от службы поддержки на тему «ваш сайт работает на моей загаженной системе со 150 расширениями и кучей добра» был простым: «пожалуйста, воспроизведите проблему на чистой установке Windows и без установленных расширений в браузере». И всё. Нет никакого хаоса.
Просто все забыли старую истину:
Вот фронтендер — он сейчас исполняет роль тогдашнего администратора. Если он чётко решает задачу: сделать определённые операции возможными и удобными — это можно сделать легко, а никакого излишнего хаоса на этом пути не возникает. Если же он пытается сделать так, чтобы «все были довольны» — то в конечном итогде довольных не будет совсем. Все будут чем-то всё равно недовольны — просто разными вещами.
А почему не получится, собственно? Вы так уверенно про всё это рассказываете, как будто я не могу зайти на какой-нибудь lwn.net с этого самого вашего ноутбука с тачскрином и почитать там новости. Могу прекрасно.
А вот на сайты, сделаннаые профессионалами типа вас — не могу. Они разваливаются и глючат.
И не потому что профессионалы плохо знают фичи CSS3… а потому что в попытке провести семь перпендикулярных линий, придуманных заказчиком — они наворачивают такого… добра, что потом это никакое количество костылей не в состоянии заставить работать без глюков.
Вот, собственно, и всё.
На бекэнде можно такой же бардак и гемор себе устроить. Легко. Разрешите вашим контрагентам присылать данные в
.xlsx
и трахайте бекондерам (а не контрагентам) мозги, когда что-то работает неправильно… только почему-то этот подход — непопулярен, а вот десять слоёв костылей, нужных для того, чтобы документ вёл себя не так, как хочет разработчик браузера, а так, как хочет левая пятка младшего помощника — это нормально.nohuhu
В вашем контракте не написано, что вы работаете работу за зарплату? Или вам просто так платят, за красивые глаза? Вам ставят задачи, вы их решаете. Не будете решать — уволят, наймут другого.
Это очепятка была. Не хочу я вдаваться в эти подробности.
Да легко: кто вообще пользуется этим дурацким Firefox? Полтора пользователя, которые никому не нужны?
Ваша самоуверенность вполне типична для back end разработчика, который заглядывал во front end пару раз, не осилил, и теперь делает очень категоричные заявления о том, что реально нужно для большей части сайтов.
Нет, ну ей-богу, скучно. На том давайте и закончим, всего хорошего.
khim
Вы знаете — в контору, которая так ставит вопрос я и сам работать не пойдут. Потому что, как я уже сказал, 90% «хотелок» — просто бессмысленны. И нужно не думать как их сделать, что сделать вместо них. Как в в известной статье:
Вот то же самое и с фронтэндом (да и с бекэндом и с чем угодно): если у заказчика возникают странные идеи (типа установки этого этой самой машины на чердаке), потому что он вычитал что это будет клёво — вы это просто игнорируете. Через неделю он всё равно всё забудет. Если клиент дотошный и всё перепроверяет — делаете так, чтобы всё было по спецификации, но работать с этим было невозможно. Он сам откажется.
Делать нужно то, для чего вы понимаете какова будет конечная цель. И нет, «так написано в документе, который мы согласовали после трёх совещаний» — это нифига не конечная цель. Конечная цель — она от бизнеса зависит. От того, как он деньги зарабатывать собрался. Если у вас нет цепочки, связывающей заработанные деньги с теми требованиями, что у вас на столе — то это всё вообще не требования, которые нужно исполнять, а «хотелки».
А надо бы. Потому что хаос возникает там и только там, где вы допускаете его возникновение.
Принимается. В рамочку и на стену. А теперь посчитаем: Firefox пользуются 9.92% пользователей. И на них забили. То есть «порог отсечения» у нас — что-то в районе 3-5%. Теперь вы тут рассказываете про «мозоль на лбу»… у какого процента пользователей эти самые ноутбуки с тасчринами от HP или Lenovo? 0.1%? 1%? Вряд ли больше.
Ну а тогда они отлично идут туда же, куда и пользователи Firefox. И всё. И нет хаоса.
Если бизнес принесёт статистику, где покажет, что вот конкретно у вас таких пользователей 50% (ну например вы делаете сайт для школ, а им централизованно такие лапотомы закупили) — тогда да, придётся корячиться.
Но у вас не могут быть одновременно 50% пользователей с лаптопами HP или Levono, 50% пользователей iPhone и 50% пользователей Android. Математика, знаете ли.
Так что снова никакого хаоса.
Разруха — она не в клозетах, разруха — она в головах.
С вашей самоуверенностью в том, что никаких других программистов, кроме фронтэндеров и бакэндеров в природе не бывает — это всё равно не сравнить.
Видимо компиляторы или, скажем, софт для вашей стиральной машины — они самозарождаются. Ну или может их эльфы в другой вселенной пишут.
Если вы относите в категорию «не осилил» отказ от игры в игру «чего изволите» — то вы на 100% правы.
А так — я и фронтэнд делал, для стартапа, который потом купили за неплохие деньги и Win32 GUI (для другого стартапа) и пролжоения для мобильных устройств (нет, не для сотовых), лет пять назад пилил порт GCC на одну интересную архитектуру… и нет, «не осилил» — нигде не было. Но и «чего изволите» — не было тоже.
Один только проект был, когда я был «молодой и зелёный» и когда я одну кнопку добавлял две недели (потому что её мог налисовать, там где этого хотел заказчик, только драйвер, а он не имел доступа к GUI, а API изначально не предполагал передачу данных в эту сторону по инициативе приложения, так что его пришлось менять… в общем много чего там было).
Когда я это всё обсудил с заказчиком, то он, конечно, мне всё это оплатил (совестливый был человек, мы с ним потом ещё много лет работали), но задал разумный вопрос: «а почему, когда выяснилось, что это — задача не на два часа, а на две недели… я, чёрт побери, не обсудил это со мной?»
Мой ответ «ну так же было в техзадании написано» его, мягко скажем, не воодушевил. Именно тогда, задолго до чтения статьи Джоела — я понял, что заказчик, в общем-то нифига не понимает что ему реально нужно.
Чуть позже я обнаружил, что есть-таки случаи, когда заказчик твёрдо уверен в том, что он знает что ему нужно… это тогда, когда заказчик — это не конечный заказчик, но посредник (ваш менежер или продажник или, может быть, менеджер со стороны закачика)… но тут ещё смешнее: все эти люди продают мою, ещё не сделанную работу — и берут за это деньги.
Ну так в этом случае это они у меня на крючке, а не я у них: деньги-то они уже получили (или считают, что получили), а работу-то я не сделал. И если я её не сделаю — то вся их долгая деятельность по уговору реального заказчика и подписанию договоров — полетит коту под хвост.
Единственный вариант, когда с заказчиком в принципе никак нельзя договорится, потому что он может вас уволить и нанять на ваше место «дядю Васю с улицы» — это когда то, что вы делаете, может сделать любой дядя вася надёргав кусков куда со StackOverflow… но стоит ли за такую работу держаться?
SpiderEkb
Золотые слова.
Вообще, что-то менять без крайней на то необходимости, да еще использовать при этом какие-то новомодные фичи, которые будут работать только на самых последних версиях клиентских девайсов — классическая чешижопица от нечего делать.
Править только дефекты, допиливать только те фичи, которые реально необходимы.
А по поводу новых фреймворков — в одном месте, где работал, было правило — все новые разработки тестируются на откровенно слабом и старом железе. И если там оно работает и не тормозит, тогда уже переход к тесту на железе реальном. Очень дисциплинировало в плане написания нормального кода. Не борьбы за наносекунды, но просто вдумчивого подхода к тому что делаешь и как делаешь.
Ну на бэке свои проблемы, поверьте :-) И их хватает.
AllexIn
Давно работаю с Qt, но не смог расшифровать ваше сообщение.
О каком делегировании речь?
Модель данных — это про Qtшную реализацию ModeViewAdapter? Так вроде такие вещи надо знать безотносительно Qt или не Qt…
stanislav888
«Делегирование» и «делегаты» это про один из паттернов ООП, который применяется в Qt виджетах. Там много классов которые кончаются на *Delegate. Например QAbstractItemDelegate.
Да, надо. Это «паттерны ООП», о которых вполне логично спрашивают на собесах. Но вот рассказать хотя бы про Model (которые наследники QAbstractTableModel)из всего этого набора, для большинства будет проблемой.
Собсно я об этом и говорю, не надо обижатся на вопросы, надо вего лишь изучить всё это заранее.
AllexIn
Ясно. ТО есть речь про базовый(он даже в википедии первый в списке) паттерн для коллбэков. Есть специалисты, которые не умеют в делегаты?
chapuza
Да дело даже не в этом, пример можно привести и поизящней, но я все равно сомневаюсь, что интервьюер не разберется в ключевом вопросе: хороший тут код, или плохой.
Речь же про то, что проверяющий читает код под сигаретку и вискарик на диванчике, тут можно и среду развернуть, и с отладчиком / реплом поиграться, если уж совсем что-то полузабытое.
Holmax
Ну всё. Собеседование не пройдено.
edpoe
Скорее всего речь идет о реализации MVC в QML, там в дополнение к стандартному ModeViewAdapter есть концепция делегатов, таких элементов, которые сначала где-то описываются, а потом экземплярами создаются во вьюхе, тогда вью становится чем-то вроде контейнера для делегата.
0xd34df00d
Все они… Хаскелисты, значит, тоже...
Ну давайте поговорим про сложность персистентных структур данных (и вообще про персистентные структуры данных), про амортизированные оценки, про связь представления чисел с деревьями, и про прочие подобные вещи.
Часто такие вещи на интервью спрашиваете?
stanislav888
Если внимательно прочитать мои посты то несложно догадаться что я вообще никого не спрашиваю. Я писал не о том что нужно спрашивать, а что надо делать чтобы на вопросы отвечать.
Хотите поменять пагубную практику вопросов по алгоритмам?! Пишите тому кто это делает.
trueMoRoZ
ну так если нужен спец на Qt, может лучше спрашивать кандидата про его опыт именно с Qt, а не про эти сферические алгоритмы?
stanislav888
Насколько я понимаю логику работодателей. Иногда конторе работающей с Qt проще взять просто C++ программиста, который освоит этот Qt за пару месяцев. Ну и что в этом случае остаётся спрашивать кандидата? Если ему ещё только предстоит работать с Qt?
Whuthering
stanislav888
А всё это и спрашивают. И с этим проблем нет. Но если вы хотите значительно повысить свои шансы, то надо будет ответить и на самые противные темы.
AllexIn
Qt достаточно простой и отлично документированный, спрашивать про него особого смысла нет. Максимум — поинтересоваться сталкивались/не сталкивались.
tendium
А как же code review? Ведь то, что человек знает алгоритмы, еще не гарантирует, что в нужный момент он их в нужном месте применит.
soniq
Предлагаете для тех, кто кнопку «аппрув» в ревью нажимает собеседовать отдельно, и уже их гонять по алгоритмам и Биг-О?
Areso
С апруверов спрос больше, логичнее, что их выбирать надо строже.
Но мне кажется, что апруверов чаще назначают, а не набирают с улицы.
Впрочем, если ведется именно набор, то логично для будующего апрувера подготовить несколько задач, где нужно провести код ревью и найти потенциальные затыки, а не просто заставлять цитировать сложности алгоритмов на память.
XAHOK
Чаще проблемы и фризы возникают вообще без всякого O. Мой личный топ:
1. Context.SaveChanges для EF (и прочих ORM) внутри цикла: типичная история из цикла «хорошо висим». Часто бывает при сложной цепочке внутренних вызовов.
2. Грузим весь CSV/Text в память и там его уже парсим. Типичная история падений по памяти и «хорошо висим». Тестовые файлы были мелкими, в таске ни слова, а в реале летают монстры. Про потоковую обработку файлов и буфферы чтения половина разрабов не слышала, вторая половина пользовалась ей в последний раз еще в школе. А для WebAPI и WWW вообще обычная история с их таймаутами и тенденцией переносить туда десктопный софт.
3. Сложные табличные fixed-size файлы запихиваем в БД для простой работы с ними (привет от файлов в гигобайт с миллионами записей). Фризы на импорте, фризы на экспорте, да еще и базой носителем часто бесплатная ограниченная версия выступает и падает по размеру файла базы.
4. У нас многоядерность, все надо параллелить! В итоге пара тысяч потоков сидят на ботлнеке с монитором, в лучшем случае с семафором.
5. Мой любимый маркетинговый фриз: эта операция выполняется слишком быстро, надо обязательно сделать задержку и повесить иконку ожидания!
mayorovp
Где же тут "без всякого O"?
То есть не учли "O" по используемой памяти.
XAHOK
Так сложность как была O(N), так и остается O(N). Сложность операции сохранения одной записи там O(1) получается, т.к. задержки на обращение к бд фиксированны для каждого запроса. Для сохранения всех записей сложность O(N). O(N)+O(N)=O(N).
С одной стороны:
В первом случае оно О(N).
Во втором случае оно O(N): N < K, O(1): N >= K
Пока размер файла не превышает K записей, обе реализации идентичны.
С другой стороны:
Для предупреждения этой проблемы вычислять O совершенно не нужно (не считая того, что далеко не все разработчики вообще помнят про кусочно-непрерывные функции и что такие вообще бывают), просто надо заранее бить шлангом по пяткам за использование потоков данных для затаскивания всех данных в память, когда этого можно избежать. А если при поточной обработке памяти все равно не хватает, то скорее всего проблема с утечками, а не с О.
soniq
Все же, сделать File.LoadToString несравнимо проще, чем правильно собрать потоки. Потом ещё окажется, что нужен случайный доступ к записям и придётся ещё что-то изобретать. Конечно, когда речь идёт о миллиардах записей, это все имеет смысл. Но бывает что там файлец-то в пару килобайт, а вы человека шлангом отмудохали. Неудобно как-то.
XAHOK
Где файл на пару килобайт, в один момент запихнут файл на гиг-другой. Проверено на практике. Как и где ждешь файлов на диске, обязательно подсунут либо сетевой путь, либо примонтируют папку с внешнего сервера.
А правильно собрать тот же StreamReader для поточной обработки — это дело минуты. Ничего сложного там нет, даже логика обработки данных не изменяется. Это так же естественно, как триммить строки и проверять их на null.
Cerberuser
Не мог не вспомнить в ответ вот это.
Dr_Faksov
Во мой знакомый, синьёр, переходил с core power management одного широко известного в мире производителя мобильных процессоров на отладку видеокарт другого не менее известного производителя (а здания у них через дорогу). И о чём с ним можно было говорить на собеседовании? Без нарушения всех подписок о нераспространении? Только алгоритмика.
Я помню он рассказывал про две задачи: первая — в области памяти, заполненной указателями, как можно быстрее найти все закольцованные цепочки указателей.
Вторая — в динамическом массиве, по запросу, за наименьшее количество тактов, а лучше мгновенно, выдать элементы с наибольшим и наименьшим значениями. Изменение размерности массива и перезапись элементов может происходить каждый такт без ограничения по количеству добавляемых\удаляемых\переписываемых элементов, причём никакой отдельной информации о том что менялось — нет.
Надо отметить, что решать эти задачи в ходе собеседования не требовалось. Это было задание на дом. Решение, с описанием найденного алгоритма на разговорном языке, отправлялось по электронной почте.
chapuza
Если ко мне лично придет человек, про которого мне столько известно (в нашем мире все немного иначе, тут нет «три года в core power management в гиганте через дорогу», но аналогий построить можно овердофигища) — я с ним буду разговаривать о жизни за ланчем.
Возможно ближе к кофе мы придумаем вместе три новых «алгоритма на разговорном языке», ему даже писать ничего не придется. Так же, как и я, — выбрасываю, не читая, предложения, отличающиеся от: «Здравствуйте, я — CTO, давайте поговорим за обедом».
Но тут в топике, вроде, речь шла про соисканта без известного в сообществе имени?
0xd34df00d
Если код выкладывается регулярно на протяжении многих лет, то вряд ли.
stanislav888
Согласен. Но не у всех проекты где надо писать открытый код. Скорее у большинства всё по другому.
0xd34df00d
Ну, в рабочих проектах у меня тоже открытый код писать не надо.
panteleymonov
Я за прошлый год был завален предложениями из Яндекса, на которые после первого собеседования уже перестал отвечать и положил следующие письма прямиком в спам.
Так вот кандидат, проходивший собеседование в Яндексе, может смело говорить «вас много, а я один!». Поскольку собеседование проходит по 5-12 раз, с разными оппонентами по одному и тому же шаблону — сидим и пишем программу на листочке. В результате, вы общаетесь как с людьми, которые вас давно ждали, вы начинаете уже в процессе решений понимать друг друга, вплоть до читать мысли и уже готовы устроиться. Так и с людьми, которые уже при встрече начинают мстить вам, как будто вы им в прошлой жизни все загадили — и как результат общего собеседования «Негоден».
Тем не менее, как для любой фирмы есть много кандидатов, так и для любого кандидата есть много фирм, и почему-то ни кто на эту ситуацию не хочет смотреть объективно.
Резюмируя. Не знаю как в остальных макрософаках. Но мне нафиг такое ненужно. Потому как в остальном, также в любой фирме (от мала до велика), хватает неадекватов и неадекватных правил, чтобы на каждый год хватало тем для новых статей — из личного опыта.
scg
Мне как-то Яндекс тоже предложил пройти интервью, начиная с тестирования по алгоритмам. А нужно сказать, что решать олимпиадные задачи на время, да еще когда у тебя над душой стоит проверяющий — самый не комфортный для меня способ работы. Естественно, что шансов пройти даже первый этап у меня не было, и все последующие предложения от Яндекса я игнорировал.
Но тут через Linked-In на меня вышла рекрутер от Яндекса и в качестве испытания предложила тестовое задание, которое нужно было сделать с свободное время и выслать им результат. Неужели они изменили подход к отбору кандидатов? Ведь так работать я умею! Здесь-то я могу развернуться. Потратив пару вечеров я отправил им код и стал ждать ответа. Ждал, кстати, долго: 2-3 недели. Уже даже подумал, что никакого ответа не будет. Но в конце-концов получаю письмо: мол, ваш код нам понравился… И вы выиграли право пройти собеседование. Когда вам было бы удобно пройти тестирование по алгоритмам по Скайпу? Блин, раньше я мог хотя бы провалит собеседование без тестового задания.
vvbob
хахаха :)
Да сейчас та-же ерунда, сразу вызывают решать задачки, меня недавно без тестового позвали, и да, я теперь так-же теперь их предложений не принимаю (а они продолжают звать) только время терять впустую.
SpiderEkb
Меня как-то HR из Я через L-In пыталась схантить. Объясняю что не ищу работу в настоящее время. Не отстает. «Ну хотя бы просто поговорить, может интересно станет...» Ну ладно, поговорить согласился, вдруг действительно интересно.
Назначили время на скайп разговор. Так мало того, что «переговорщик» из Я на полчаса перенес разговор, так еще и начал его со слов «я вам сейчас тестовое задание подготовлю...» Сразу ответил, что тестовые задания мне неинтересны, я не ищу работу в настоящее время, и договоренность была исключительно смогут ли ли они меня чем-то заинтересовать, а уж потом, если да, то смогу ли их чем-то заинтересовать я. На том и расстались.
A114n
Как забавно, тут все рассказывают, как они закрываются от назойливых HR Яндекса. А от меня, наоборот, Яндекс закрылся — сначала отвечали мол «вы нам не подходите», а потом просто совсем перестали отвечать.
scg
Так и мне они говорят: «вы нам не подходите». Только те, кто говорит и те кто хантят — это разные люди.
SpiderEkb
Ниже правильно сказали — это разные люди. А еще ниже тоже правильно — хантеры получают плюсик за каждого, кого они доведут до собеседования.
Именно с яндексом была полностью аналогичная ситуация — когда искал работу, отправлял им резюме. Ответ «сейчас вы нам не нужны, будем иметь ввиду...» в общем, стандартное «пошел ты...» в вежливой форме.
А вот когда уже работу нашел и в LinkedIn появилась текущая позиция, так из того же яндекса полезли хрюшки с призывами пособеседовать…
Koderka
У меня тоже с ними была подобная ситуация: оттуда обращались ко мне по LinkedIn, когда я не искала работу. Когда искала, то увидев вакансию, которая мне подходила, обратилась к одной из рекрутерок, которые ко мне стучались, и спросила у неё актуальна ли эта вакансия. Она сказала, что да, и попросила резюме у меня. Очень быстро она ответила, что я им не подхожу. Ладно. Процесс поиска работы не затянулся надолго. Уже через пару месяцев после того, как я обновила свой LinkedIn с новой записью, ко мне снова постучались из Яндекса :).
ganqqwerty
Очень хорошая классификация, на мой взгляд.
balberbro
Средний срок жизни разработчика в Гугле — 1 года 1 месяц. Это как бы показатель того, что люди там особо не задерживаются. Причины:
1) За счет «магии» бренда получают большой поток наивных разработчиков. Вроде деньги предлагают неплохие, но условия всякие типа: вот тебе небольшая зп, вот там раз в год будет бонус огромный (если пройдешь перфоманс ревью), вот тебе акции (которые сможешь получить через 5 лет). Как итог, пообещали много, и по факту хрен это все возьмешь. Как итог, разработчики прикидывают, что лучше свалить в какой-нибудь стартап, который делает мобильные игры и лутать деньги, чем работать в гугле.
2) Сидение на каком-то самописном легасе говне. Как правило, в больших компаниях куча своих каких-то инструментов. И если ты потратил свое время, чтобы их изучить, то при переходе в другую компанию твой опыт просто обнуляется.
3) Уже давно из компании добра это превратилось в галеры, где менеджеры за счет наивных разрабов решают какие-то свои задачи. То, что там разрабы ночами не спали пили какой-то проект под большим давлением, а потом это все дело похерилось, когда менеджер перевелся куда-то — никого не волнует. Ну и потом на перфоманс ревью еще зп срежут, типа проект заруинился.
4) Ну и самая вишенка. Вот такие компании, на всяких собеседованиях относятся к тебе, как говну. Вот тебе задача какая-то олимпиадная решай, вот тебе белая доска, напиши нам все типы из Python и прочее. И то, что ты там все это сделал (потратил куча времени), вообще не факт, что тебя возьмут.
В общем, во всяких конторах типа Яндекса, либо работают наивные дурачки после универа, которых и хвост и в гривы, либо уже опытные разрабы с опытом 10-15+, которых взяли за большие деньги на какой-то проект, ибо молодняк не тянет.
__
Обычному разработчику, который хоть как-то любит себя и ценит свою работу, лучше идти в в ту же галеру, пилить бизнес логику за хорошие деньги в спокойной обстановке, чем вот эти все яндексы.
Aingis
Знакомый опытный разраб с прошлой работы зачем-то пошёл. Больших денег — увы! — не дали.
cebka
Суметь выбить большие деньги — отдельное искусство, которое, пожалуй, гораздо сложнее умения решать идиотские "олимпиадные" задачки.
blind_oracle
А больших это сколько? Года 3-4 назад HR Я мне предлагал около 300к. Но я к тому времени уже наелся их собеседованиями...
roman_kashitsyn
Эта статистика верна только для Mountain View.
ЗП в Google зависят от региона. В Цюрихе, к примеру, вполне можно получать 165.000 CHF на старте (что уже ощутимо выше рынка). Плюс ежегодный бонус 15-20% от зарплаты. Акции выдают не через пять лет, а каждый квартал. В сумме может запросто получится в 2 раза выше рынка уже через год.
Инструменты в Google такие, что индустрии до них ещё десятилетие расти. К примеру, после Critique (код-ревью тула в Google) от код-ревью на GitHub просто люто, бешено бомбит.
Я бы не сказал. Умение готовить Protobuf и gRPC много где нужно. Ну и C++ в Google хороший.
Краски сильно сгущены. Политики много, но по ночам никто не работает, и зарплаты никто не снижает.
У меня такое только с Amazon было. От собеседований в Facebook и Google впечатления были очень положительные.
Я работал в Яндексе (в Картах), мне там очень понравилось. Много умных талантливых коллег и интересные задачи.
a-l-e-x
А есть ли публичное подтверждение? Это не к тому, что я сомневаюсь. Мне хочется ссылку для торговли по зарплате.
blind_oracle
Какого подтверждения вы хотите? Бумагу от гугла что да мы столько платим?
Могу лишь подтвердить, как варящийся на рынке Цюриха, что слышал о больших суммах.
a-l-e-x
Спасибо большое. Ниже показали пример.
Просто меня спрашивают сколько я хочу денег (не Google к сожалению) в Швейцарии, а я там ещё никогда не работал, и не знаю что сказать.
blind_oracle
Ну, ориентироваться на Гугл когда тебя приглашают не в него довольно странно :)
В среднем по больнице я думаю уровень в 140-150к нормальный, но сильно зависит от.
a-l-e-x
Ну надо же с каких-то чисел начинать. А так — у всех на слуху. И ожидания и зарплаты подтягиваются к лидерам рынка :)
Xobotun
Публичного официального нет, есть публичное неофициальное: https://www.levels.fyi/salary/Google/
Там после раздела "о компании" и графиков есть фильтрация, можно ввести Zurich и указать L3 или L4 в зависимости от самооценки. :)
a-l-e-x
Спасибо большое за ссылку.
lanseg
165000 франков — скорее всего, L5 в среднем по сложности проекте, или L4 в суровом, серьёзном. L3 (самый массовый уровень) вряд ли будет получать больше 130 тысяч.
Ах да, в Яндекс меня не взяли — видимо, я плохо решил задачку на тервер и фигово ответил олимпиаднику-интервьюверу.
adictive_max
bakotin
Поговаривают, что в Близзард в Ирландии сидят в саппорте чуть ли не за кусок хлеба, и снимают аппартаменты на две команты в шестером. А в США разработчики после работы таксуют в убере.
A114n
А, теперь я понял, почему у них приложение батл.нет работает, как будто его студенты писали.
Kwisatz
Шикарно оно у них работает и интерфейс приятный. Вы батенька, видимо от мылору и проих юбисофтов ланчеров не видели, сразу, я вам скажу, перестаешь быть таким требовательным.
A114n
Каюсь, не видел. Но и других приложений, которые подвисают аж до проявления белой границы формы, когда кликаешь внутри этого приложения на ссылку, я тоже не видел уже довольно давно.
mayorovp
А это разве не поведение IE по умолчанию?
rogoz
Они «профессионально» с настройками прокси работают
PavelGatilov
> Вроде деньги предлагают неплохие, но условия всякие типа: вот тебе небольшая зп, вот там раз в год будет бонус огромный (если пройдешь перфоманс ревью), вот тебе акции (которые сможешь получить через 5 лет).
Акции тебе дают после прохода испытательного, каждые 3 месяца после финансового отчета четверти. Бонус дают всегда, 2 раза в год, его размер зависит от перформанса только процентно, но не бывает ниже 80%.
> Сидение на каком-то самописном легасе говне. Как правило, в больших компаниях куча своих каких-то инструментов. И если ты потратил свое время, чтобы их изучить, то при переходе в другую компанию твой опыт просто обнуляется.
В такой компании как правило ты учишься не конкретному фрэймворку или еще чему-то, ты учишься подходу к работе.
> Ну и самая вишенка. Вот такие компании, на всяких собеседованиях относятся к тебе, как говну. Вот тебе задача какая-то олимпиадная решай, вот тебе белая доска, напиши нам все типы из Python и прочее. И то, что ты там все это сделал (потратил куча времени), вообще не факт, что тебя возьмут.
Оплата перелета, отеля, еды и прочего это как к говну? Задачи не олимпиадные, а вполне из практике работы в этих компаниях, а не берут если не можешь решить простенькие алгоритмы.
chapuza
Который не только нигде кроме ФАГМАН не применим, а еще и попросту губителен для хорошего инженера.
Это все только на туземцев действует, как бусы. Ну и да, так ведут себя все компании, которые вообще имеет смысл рассматривать.
khim
chapuza
Понятия не имею. А при чем тут это? Бизнесу обычного размера нужны специалисты, а не винтики.
Whuthering
Какой-то список очень ограниченный и вообще не полный. Например, бывают большие компании, но не FAAANM/FAANG.
Которые тоже большие, очень известные, делают крутые продукты, предлагают вкусный соцпакет (хоть и без массажей с гастрономическими обедами и акциями, но тоже неплохой), и при этом не выносят кандидатам мозг задачами на балансировку деревьев и дизайн круглых люков.
В одной из такой, например, мы некоторое время назад с интервьюером обсудили изменения в новых стандартах плюсов, стратегию выделения памяти в стандартных контейнерах, спинлоки и фьютексы, проблемы рефакторинга легаси в больших кодовых базах, и много другого интересного. То есть были именно вопросы на понимание, как что работает и как и что человек делал до этого.
Аналогично с аутсорсом, в одной большой галере (не такой большой, как епам, конечно, но тоже немаленькой), мне сходу объяснили одну задачу, которую они недавно решали в команде, про взаимодействие определенных компонентов при определенных сценариях и спросили, как бы я ее решал. Ответом было что-то близкое к golang'овым каналам, и мы тут же с интервьюверами накидали на ноутбуке простой прототип такой штуки, поговорили о накладных расходах, обсудили какие для всего этого написать тесты и как спроектировать API так, чтобы разработчик, который будет его использовать, не проклял вас во веки веков. То есть никаких "докапываний до слов и технологий из резюме", никаких вопросов про библиотечные функции, а просто есть реальная задача, обсуждение ее решения, и в итоге оффер :)
Так что автору над своей классификацией ещё работать и работать.
edolganov Автор
Спасибо, будем стараться :)
Loggus66
Предлагаю вариант Facebook-Amazon-Google-Microsoft-Apple-Netflix. Сокращённо FAGMAN.
chupasaurus
На HackerNews уже обшутились, что если смотреть на рыночную капитализацию, то надо использовать MAGA.
UberSchlag
Благорадю, такая мнемоника мне по нраву. Запоминается то как хорошо!
chapuza
Facebook-Uhmazon-CKoogle-Microsoft-Apple-Netflix?
Mikluho
Идея классификации хорошая, но сама классификация уж больно коротка…
Как будто кроме гуглояндексов и аутсорсинговых контор мало «стандартных» примеров.
Вот, из моего личного опыта, то, что встречается на территории России:
1. Всяческие корпорации, сиречь большие конторы. Они ищут очередную шестерёнку. От них чаще всего можно ожидать изрядное число формальностей и анкет (апогей — вопрос о том, почему вы хотите у нас работать, да...), и стандартизованного собеседования с замашками на мировых лидеров, т.е. как у гугла или яндекса.
2. Вендорские фирмы (те, которые разрабатывают софт на продажу и хвалятся топовым местом в нише размером с 5% рынка). Тут, в зависимости от рыночной ситуации, либо рабочую лошадку ищут, либо скакуна-чемпиона. Но от обоих ожидают верности на века. Спрашивают ближе к делу, но часто имеют мутные схемы поощрения, и любят сбивать самооценку кандидата, ради чего придумывают ломовые вопросы для собеседования. Да, кстати, эти чаще все балуются такой формулировкой, когда звонят после собеседования: «вы нам/директору очень понравились, приходите прям завтра на -10% от вашего минимума».
3. Рога и копыта. Тут чаще всего сами не очень знают, кто им нужен и сколько это стоит. Почти всегда ищут через кадровые агентства. Вполне реальный вариант для проведения собеседования пригласить студента, друга директора. Сей «студент», наверняка, будет пытаться подловить вас хоть на чём-то, дабы самому не выглядеть лохом.
Whuthering
У меня в таких "рогах&копытах" когда-то давно было самое короткое и самое приятное собеседование:
Mikluho
Да, и это часто хороший вариант! :)
Т.е. сами по себе такие конторы не обязательно плохие.
valergrad
Я знаю людей которые не знают и не умеют практически ничего, но с легкостью прошли бы такое собеседование потому что у них раздутая самооценка и они думают что знают все. Плюс, например, индусы по моему опыту всегда отвечают «да, знаю», «да, умею» даже если не имеют ни малейшего представления — их этому где-то учат, видно.
Опасный метод проведения собеседований, на мой взгляд.
mad_nazgul
Обычно просто начинаешь говорить «за жизнь».
Что делал, какие были проблемы. Почему делали так, а не эдак.
Обычно если сам более менее в теме, то сможешь оценить насколько глубоко копал соискатель ту или иную тему.
SpiderEkb
Вот именно такого плана у меня было собеседование в альфе. Но, во-первых, у меня был опыт в разработке 25+ лет, причем, на достаточно объемных проектах, причем, с нуля, с формирования архитектуры. Во-вторых, брали на бэкенд, причем, самый глубокий. Под разработку на платфрме IBM i которую в РФ знает очень ограниченное количество людей (и все они сосредоточены в альфе, райфе, росбанке и еще паре-тройке компаний). Т.е. интересовало не знание каких-то фреймворков, а способоность быстро и глубоко вникнуть в особенности платформы (а она очень особенная, с виндой и никсами общего очень и очень мало) и уметь писать эффективный код под высоконагруженные системы (сейчас это порядка 3млрд изменений бд в сутки и постоянно растет).
В общем, был разговор «за жизнь» с теми, с кем сейчас работаю без каких-либо синтетических тестов.
А потом 3 месяца испытательный срок, фактически обучение и проверка «сработаемся — не сработаемся».
Xobotun
А хитрая система от IBM – случайно не мейнфреймы какие? z9 или z11?
SpiderEkb
Мейнфреймы, ага. PowerS9 сейчас. Были 828 на проме и 824 на тесте, сейчас 924 на тесте и, видимо, 928 на проме. Стоит там IBM i, бывш. AS/400
Xobotun
Эх, у меня весь опыт общения с живыми мейнфреймами был только в виде пары лабораторных работ в институте через 3270 терминал. Я так и не понял их ценности, хотя у них внутри всё задублировано, вплоть до системы охлаждения.
SpiderEkb
Тут общение через эмулятор терминала 5250, т.н. «зеленый экран».
Ценность… Очень цельная система. В нее встроено все — БД (DB2), компиляторы языков (CL, COBOL, RPG, C/C++). Очень нравится концепция ILE (Integrated Language Environment) — исполняемая программа может быть собрана из модулей, каждый из которых написан на разных языках. У нас широко используется RPG и C/C++. В рамках одной программы можно писать часть функций на RPG, часть на C/C++ и все это будет работать, главное правильно интерфейсы прописать.
Очень много концепций, которые просто не имеют аналогов в других системах. Те же группы активации в рамках процесса (JOB'а). Много не имеющих аналогов системных объектов типа DTAARA, USRSPC, DTAQUE, USRIDX и т.п.
Сситема изначально объектно-оринтированная. Т.е. основной постулат — «все есть объект». причем, заложено все это на самом глубинном уровне.
Ну и производительность… Тестовый сервер — это SMT8 процессор на 18 ядер, 1800Гб оперативки, два SSD дисковых массива 87 и 15 Тб.
На боевых серверах стоит 4 «книжки» по 4 12-ядерных SMT8 процессора (т.е. в сумме 192 ядра, каждое из которых работает в 8 потоков).
И при всем этом очень жесткие требования к оптимизации кода. Есть целый список «нефункциональных требований» как нужно делать и как делать нельзя. Ну и те задачи, что много работают в фоне, обязательно проходят нагрузочное (помимо компонентного, интеграционного и бизнес) тестирование. А там могут вернуть с замечениями типа:
Т.е. решение некоторых задач требует некоторой изворотливости ума и придумывания хитрых алгоритмов Например, замена order by по неиндексированным полям в sql запросе на предварительное занесение результатов выборки в автосортируемый по нужному ключу массив может дать выигрыш по времени в 5-6 раз. Или разделение запроса на несколько частей с использованием высокоселективной предвыборки с использованием частотного словаря вместо агрегатной listagg в запросе как-то позволило сократить время работы процедуры с 3 сек до 150-200мсек :-)
donRumatta
CLR без IL и JIT? это как(=
SpiderEkb
Э-э-э… Что есть CLR?
Там речь о CL — Command Language в AS/400. Системный язык, часть команд (полный референс порядка 2300 страниц в pdf) может использоваться в интерактиве в терминальной сессии, но можно и программы писать на нем (что характерно, программа на CL компилируется командой того же CL).
donRumatta
Вот что значит, когда встречаются представители разных вселенных(= Common Language Runtime — это .NET-овская среда, которая может выполнять программы, собранные из dll, так же написанных, например, на C#, F#, VB и т. д. Но за счет 2-этапной компиляции сначала в Intermediate Language, а затем уже JIT-ом в машинный код. Что-то общее с вашим случаем чувствуется, но у меня, к сожалению, не хватает знаний, чтобы осознать.
khim
Это только кажется, что Microsoft контролирует всё и вся в Windows. А вот убить нативный код… не может. Потому что System/3, System/32, System/34, System/36, System/38 и так далее поставляются только IBM, а потому «доктор сказал в морг — значит в морг».
Поэтому IBM может сказать «начиная с System/38 праямой доступ к машинному коду отсуствует»… всё. А Microsoft приходится доказывать что «managed code» в чём-то лучше, потому что Win32 API никто ж не отменял (один раз попробовали отменить в особой версии Windows — так в результате она сама отменилась).
SpiderEkb
Да, одна из особенностей AS-ки — есть граница, ниже которой нет доступа никому, кроме собственно разработчиков самой ОС. Вообще. Совсем нет. Никак.
Я не настолько силен в глубинных потрохах AS-ки, но, как понимаю, все компиляторы со всех поддерживаемых в ILE языков (а они все встроены в саму ОС) генерируют модули (аналог объектных файлов), которые и есть набор MI инструкций. Т.е. на этапе модуля уже неважно на каком языке он был написан.
А дальше эти модули уже собираются в единый исполныямый объект (PGM).
Собственно, если у нас программа из одного модуля (один исходник), то можем сразу вызвать CRTBNDPGM и получить на выходе PGM объект одной командой.
А если исходников несколько, то сначала для каждого CRTMOD — создаем модуль, а потом CRTPGM из этих модулей (на этом же этапе происходит разрешение внешних ссылок на функции, располложенные в сервисных программах — SRVPGM — некий аналог виндовых DLL)
у нас основной язык RPG, но многие вещи пишутся на С/С++. Там, где это проще и быстрее. И часто бывает что или программа лепится из нескольких модулей — основной на RPG, вспомогательные функции (ну, скажем, парсинг JSON строк) — на С/С++.
Или на С/С++ пишутся сервисные программы (работа сописками, наборами и т.п. к примеру) функции из которых потом используются в RPG программах.
Там все еще веселее — можно использовать функции из C RTL просто правильно объявив прототип для вызова из RPG — оно само их находит.
Так испоользуем memcmp, к примеру, qsort/bsearch, функции для работы с файлами на IFS (интегрированная файловая система — альтернативный доступ к файлам на AS/400).
В общем, тут много всякой специфики, это свой мир и достаточно занимательный.
SpiderEkb
У TIMI еще один плюс — в исполняемом коде хранится также и набор MI инструкций и метка для какой платформы из этих инструкций собран исполняемый код. Меняем платформу (скажем с 824 на 924), переносим исполняемый модуль. при первом запуске система сравнивает на какой платформе оно запущено и под какую собрано. если не совпадает, то происходит автоматическая пересборка MI инструкций под текущую платформу.
Т.е. исполняемый код при переносе будет оптимизирован под новую платформу. Это и есть TI.
scg
Именно для этого придумали испытательный срок.
Mirocidij
Ну в региональных рогах и копытах индусы, я думаю, большая редокость.
rogrom
3 вариант у меня реально был :)
scg
Недавно был на собеседовании у очередного разработчика «Отечественной ОС». Там, правда, не студенты сидели, но я реально себя чувствовал партизаном на допросе. Они не сколько хотели узнать мои знания, сколько пытались на чем-нибудь подловить.
chekink
Спасибо!
qant
Как по мне, идеально было бы просто начать с методологии обучения работников для проведения собеседования. В крупных конторах будет все плюс — минус как по учебнику, и далее этих стандартов будет просто меньше… В мелких же, как повезет, от простых разговоров, до чего угодно… Тк, как правило, собеседование проводит обычный менеджер, который, просто погуглил что спросить у программиста на собеседовании )
GreedyIvan
Задачки на собеседовании очень хорошо закрывают негодование "они там в HR вообще резюме кандидатов читают"?
DmitrySpb79
Добавлю еще один способ, который несколько раз попадался при поиске работы в Германии — алгоритмические задачки в онлайн-компиляторе. Все полностью автоматизировано — система дает задачу и полчаса-час времени, в конце результат также автоматически прогоняется тестами (оценивается правильность и скорость работы алгоритма) и отсылается работодателю. Цель та же, первичный отсев.
Sm1le291
Codility? Это сейчас повсеместно применяется. Вот намедни Амазон испанский мне такое прислал…
Dywar
Я проходил подобное.
2-х часовое онлайн (восемь вопросов) по JS, C#, SQL, Англия.
В целом понравилось, но стресс, когда видишь что таймер тикает :)
Четыре задачи на синтаксис, дальше алгоритмы.
Больше нравится живое общение.
adictive_max
В целом согласен кроме одного пункта:
У отсева по алгоритмам цель не «найти хорошего» а «не пропустить плохого». Просто когда у тебя сотни соискателей на место, ты можешь себе позволить отбраковать «не глядя» 3/4 хороших кандидатов, ведь и из оставшихся 1/4 будет кого выбрать.Гораздо страннее, когда такие же методы применяет «молодая динамично развивающаяся компания» в которую приходит по 5-6 резюме в месяц.
khim
На самом деле всё ещё смешнее. Если у вас большая компания, то хитрую борьбу c таблицей, о которой так плачет JustDont — найдётся кому сделать. А вот если вы наивно сотворили O(N!) заложившись на то, что «n всё равно выше десятка не вырастет даже в теории»… а оно таки выросло… до пятнадцати (что привело к тому, что ваша страничка стала реагировать на нажатия буквально часами)… это кому-то придётся переписывать. И, скорее всего, в авральном порядке… а им это надо?
А в стартапе да — там замены для человека нет и потому важно не только, чтобы он дров не наломал, но и, чтобы он собственно умел работать с теми технологиями, с которыми он столкнётся… без помощи со стороны «старших товарищей».
JustDont
Не знаю как вы, но я бываю в публичном вебе достаточно часто, чтоб знать, что увы, таки нифига не находится. Равно как и на весь гугл не нашлось никого, кто б мог сделать гуглопочту размером меньшим, чем 6.7 Мб, исключая, конечно, тех мастодонтов, что написали plain-html версию (она очень-очень старая).
Наверное это потому, что всех бросили на тщательные проверки того, чтоб O(N!) нигде не было. А гуглопочту на плохом интернете грузить — ну, наловчитесь и в простую версию ткнете.
Godebug
Собственно, адекватный человек в состоянии понять что требуется изучить и, соответственно, изучит. Опять же, если он хочет устроиться в Гугл.
adictive_max
Это если заранее известно, что именно учить. Зазубрить наизусть ВСЁ — это слегка многовато.
Godebug
Изучить — прочитать и понять. Это вы где про «зазубрить» прочли?
adictive_max
Не у всех всё так просто, что прочитал — и сразу понял.
Godebug
Где про «сразу»? Хабр такой хабр, жесть.
adictive_max
А «не сразу» — это или начинать года за 3-4 до или зубрить.
Godebug
Про сроки речь вообще не шла. Что ещё вы приплетёте?
AlexanderY
Добавлю, с точки зрения маленькой продуктовой компании, почему и зачем мы даём тестовое задание, и как повысить ваши шансы на устройство. Дисклеймер: последние несколько месяцев мы очень неспешно расширяемся, и собеседуем кандидатов удалённо. И, конечно, это всё личное мнение, не более.
Зачем вообще давать тестовое. Первая причина — отсеять хлопцев, рассылающих резюме «на удачу». Может это мне не везло, но иногда попадаются кадры с уровнем «вчера купил книжку по программированию».
Вторая причина — посмотреть, как вообще человек идёт на контакт, как он всё оформит, зафигачит ли он весь код в одном спагетти-стайл файле или все-таки сделает хотя бы зачатки архитектуры. Формальная корректность решения тут на последнем месте, потому что это — неважно. Ошибку в коде поправить легко, а вот научить «делать хорошо» уже гораздо сложнее.
Как повысить ваши шансы на трудоустройство: напишите readme к тестовому заданию. Среднее тестовое с нормальным readme ценнее идеального кода без единого комментария. Потому что становится понятно, как вы думали, какие допущения сделали, почему выбрали A вместо B, какие варианты вообще рассматривали, как вы бы сделали в идеале, если бы это был реальный проект и т.д.
Я понимаю, что на тестовые задания не всем хочется тратить время — и уважаю это. Но если уж вы взялись его сделать, лучше потратить ещё 10 минут на нормальное оформление.
То же самое касается вашего кода на Гитхабе — я вижу ваш профиль, ваши репозитории, ваш код, но не вижу какую задачу вы решали. Как я могу оценить вашу крутизну? У меня нет отправной точки. Серьёзно. Добавляйте readme, вы сразу вырастете в глазах нанимателя.
SpiderEkb
Вот не поверите. Не так давно (менее полгугода назад) брали на работу человека. Опыта — ноль. Алгоритмическое мышление отсутствует напрочь. Но в разговоре за жизнь уловилась в нем некая целеустремленность и желание постичь глубины.
Взяли стажером на полгода. Через три месяца уже посовещались и перевели в штат. Ибо прогресс невообразимый. Первые задачи мы решали просто за него. Ну то есть разжевывали как и с какой строны браться, человек сидел и старательно ушами хлопал. Но потом вгрызался в тему и добивал до победного. И все, что ему хоть раз говорили, все оседало в голове, устаканивалось там и потом шло в дело. Сейчас уже вполне самостоятельный разработчик, коммуникативный, пройдет еще год и будет классным спецом в своей области.
Но на любом формальном тесте посыпался бы в том время. только в разговоре смогли потенциал разглядеть.
JediPhilosopher
Проблема в том, что далеко не все могут и хотят вот так растить человека внутри своей компании. Нет ресурсов, нет менторов. Велика вероятность, что вместо возврата инвестиций на обучение он потом просто возьмет и упорхнет куда-то, где платят больше. И нет, не всегда возможно просто взять и заплатить больше, чтобы не упорхнул — на рынке всегда найдется кто-то богаче вас, кто предложит лучшие условия, особенно если вы — маленькая контора из пары человек.
Поэтому несмотря на весь потенциал, таких людей многим компаниям тоже целесообразно отсеивать. Что они и делают.
SpiderEkb
Согласен. Тут вопрос подхода. Но в нашем случае готового специалиста, знающего AS/400 и RPG найти малореально. Так что все равно готовить человека пока он сможет работать самостоятельно. Так что все равно первые три месяца — обучение. Обычно через полтора два месяца человек уже выходит на несложные боевые задачки (поначалу подбирается что-то небольшое).
Бывают и ошибки, конечно. Второй кандидат, тоже из недавних, на собеседовании полный восторг и радужные надежды, а сейчас вопросы — что с ним делать дальше. То ли попытаться найти подход, то ли распрощаться.
Static_electro
Видел такое. На соседний проект собеседовали кандидата. Двое тех. спецов сказали: "он не умеет в программирование", ПМ сказал: "но есть у него какая-то жилка, возьмем". Прошло три года. Насколько мне известно, до сих пор за ним коллеги код правят...
khim
Ну дык клаcсика жанра же: Он вообще отличный специалист — только не в той области в которой его коллеги.
SpiderEkb
И это тоже верно.
В нашем случае от этого два барьера — во-первых, в очень сомнительном случае предлагается не штат, а стажировка на полгода (20 часов в неделю, т.е. условно полставки). Часто такой вариант бывает интересен студентам старших курсов.
По результатам стажировки уже предлагается или переход в штат (возможно до окончания стажировки), или… Просто окончание стажировки за которой не последовало никаких предложений.
В любом случае, каждый новый сотрудник берется с испытательным сроком в три месяца. Зарплата на испытательном сроке полная, но плюшки типа ДМС и страхования НС не оформляются.
На испытательный срок ставятся конкретные цели. Фактически это срок обучения (напомню — платформа очень специфическая, готовых спецов по ней найти малореально). К концу срока человек уже должен уметь решать несложные (ну так скажем, типовые) боевые задачи (и иметь уже одну-две поставки, хотя бы на уровне бизнес тестирования).
По окончании срока оценка, там уже решается будет человек работать дальше здесь или нет.
Собственно говоря, я к тому, что «конвеерное тестирование» на собеседовании путем раздачи тестовых заданий решение очень простое (для HR), но в качестве фильтра далеко не самое лучшее.
Koderka
Но почему такого работника там держат? И как он испытаательный срок прошел? За три года и менеджеры могли сообразить, что взяли не того человека.
dididididi
Эээээ… А с чего это сотни соискателей на место? Я когда резюме выкладываю, мне раз пять сам Яндекс звонит, а потом еще конторы хедхантинговые в яндекс пытаются устроить. Про Сбербанк я ваще молчу, они мертвого задерут.
Поэтому вот прям про армию желающих лучше не писать.
stanislav888
Тут автор ошибся насчёт Яндекса. Т.к. ему приходится конкурировать со всем аутсорсом в России. Кандидатов там конечно не сотни на место.
Но в случае с Microsoft, Google и т.п. конторами, кандидатов только из Азии могут быть сотни. Причём, вы не представляете азиатский менталитет. Там любой кто навалял «Hello World» будет слать заявки на Senior -ов.
dididididi
Я не думаю, что гугл платит дофигилиард баксов разработчикам, потому что их просто навалом и девать некуда…
khim
Вы вообще читаете хотя бы иногда тексты, на которые отвечает? Да, разработчиков мало, Senior'ов, наваявших в своей жизни пару «Hello World»ов (один — на DB2, другой — на Tkinter) — много.
Вопрос: что со всем этим делать? Всех этих Senior'ов хотя бы билетами для бесплатного путешествия обеспечивать — можно разориться…
dididididi
Еще раз: либо дефицит кадров, либо профицит. И да если нужны программисты, а на рынке мильон шоферов, то это не спасает.
Если кадров дефицит, то зарплаты повышаются, если профицит, то зарплаты снижают. У гугла зарплаты большие и это значит им разработчиков требуемого уровня не хватает. А в начале статьи написано, что наоборот поток соискателей большой.
НУ и логично, если у вас золота мало на тонну грунта, то не стоит ставить на входе микросито, которое откинет 99% золота? Сначала крупные фильтры, потом дробилки, потом фильтры мельче и мельче.
И да я пониманию, что среди них много «брака», но это все равно нелогично вышвыривать всех кто не может написать квиксорт на бумажке без ошибок, верно?
PS Если вы крупнейшая технологичная компания, что ж у вас код такое гавно, что там только сеньоры разобраться могут?
mayorovp
Есть такой эффект: кто умеет программировать — давно нашли себе работу, кто не умеет — ходит по собеседованиям. Вот и получается "парадокс": специалистов на рынке дефицит, а поток соискателей огромный.
dididididi
я не спорю. Если поток огромный поставь сначала грубые фильтры, потом тонкие. А то тонкие быстро забьются, а их дорого менять.
Если поток маленький можно сразу поставить тонкие. У гугла стоят сразу тонкие — на алгоритмы. Значит поток соискателей невелик.
khim
А что они часть «хороших» соискателей отсекают — не наша проблема. Если кандидат реально хороший — он в другом месте найдёт работу, если он только в кавычках «хороший» — ну так и вообще непонятно зачем он нам…
mayorovp
Но алгоритмы — это как раз "толстый" фильтр. "Популярных" алгоритмов довольно ограниченное количество, и их все можно просто выучить.
wataru
Вы однобоко рассматриваете ситуацию. Да, условному гуглу нужны толковые разработчики, которых среди соискателей мало. Но помимо этого им еще надо не нанимать войти-вайтишников, которые программировать-то толком не умеют, зато могут показать условный код с гитхаба и часами рассказывать, какие клевые задачи у них были на прошлой работе (полностью решенные их коллегами). Найм такого работника стоит гуглу гораздо больше чем лишний месяц без разработчика, потому что он был отсеян по ошибке.
dididididi
ну так не трахай мозг. Первый фильтр — английский язык и чтоб не воняло от соискателя, второй фильтр — как работает hashMap, третий фильтр как работает classLoader и gc, потом уже идут в зависимости от специализации базы данных, алгоритмы или еще чо-нить. А они сразу юзают хорошего спеца, чтоб тестить всякое дерьмо про алгоритмам.
khim
Вы берётесь объяснить девочке-рекрутеру, как задавать про это вопросы так, чтобы человек, готовый «часами рассказывать, какие клевые задачи у них были на прошлой работе (полностью решенные их коллегами)» — не проскочил? Нам это сделать, извините, не удалось.
Ну дык хороший спец всё равно нужен, а оценивать ответы на задачки про алгоритмы — гораздо проще.
khim
То же самое и с наймом.
Почему нелогично? Их хороших кандидатов квиксорт сможет написать явно не 1%. А вот из плохих — не сможет его написать никто (понятно что может зазубрить, но подобных задачек много, всегда можно найти такую, которую кандидат наизусть не помнит).
Так что это как раз такой фильтр, который повышает содержание золота в породе.
А кто вам сказал, что могут разобратья только сеньоры? Студенты тоже могут. И разбираются, когда интернами работают. Но, знаете ли, мы нанимаем людей, чтобы они код не читали, а писали. А это — совсем другое дело. Один придурок может столько дерьма накостылять, что потом потребуется десять сеньоров, чтобы за ним этот код чистить… а оно нам надо?
P.S. Почему студенты ничего не могут напортачить? А потому что у каждого из них есть «host» — человек, который обязан следить за тем, чтобы это не происходило. Иногда код правится студентом «до готовности», иногда host принимает код «как есть» и немного его «рихтует» — это не регламентировано. Но отвечает за качество кода не студент, а его «host». А у обычных программистов «host»а нет, они всё сами должны делать…
Aingis
Тут разница в том, какие это соискатели. В тот же Яндекс вчерашние школьники и студенты стремятся пачками. И паттерны с алгоритмами в памяти у них ещё свежи. А вот у опытных разработчиков уже есть много причин не стремиться. Начиная со специальной олимпиады на собеседованиях и заканчивая предлагаемыми после такого офферами. («Ну, а что, мы же Яндекс!»)
dididididi
но это нормально гонять школьников по алгоритмам. Я жалею что меня после школы, когда мозги были свежи и волшебны не гоняли по алгоритмам, а спрашивали про опыт работы))).
SerJook
Чем проще собеседование и чем душевнее подход, тем больше шанс, что я захочу работать в этой компании.
LinearLeopard
Не раскрыта тема приятности в общении. Человек может ответить на все вопросы и прорешать все задачки, но вот предложения ему не дождаться, потому что запах изо рта, в общении тяжёлый, плохо реагирует на критику (а как тогда его код ревьюить), стесняется критиковать сам (а как тогда он джунов будет учить), а ему ещё в джире надо в тикетах отписывать и на митингах что-то предлагать, и вообще, не хочу я его видеть по 8 часов в офисе рядом с собой.
JediPhilosopher
Если эту тему в посте задевают — тут же приходят легионы тех самых людей и начинают орать в коментах и лепить всем минусы. Вообще топики про собеседования на хабре — это такая специальная олимпиада, где все воюют против всех. Так как у каждого, наверное, есть какой-то негативный опыт и душевные травмы от собеседований (причем с обеих сторон баррикад, рекрутеры и собеседующие страдают от процесса не меньше)
LinearLeopard
Не только они. Вообще, наверно, большинство топиков с рейтингом больше 100 — это вот такие холивары, если не все топики.
Dywar
Есть книга «Cracking the Coding Interview» или «Карьера программиста» на Рус.
Так вот в ней целых 2-3 страницы автор отвечает на вопрос — процесс собеседования, почему так? Кому интересно посмотрите.
akdes
Всегда с интересом читаю о всяких тестах, задачах и т.д.
На данный момент я проработал на 3 фирмы (в Германии), на две разрабом, и на одну (сейчас) разрабо-девопс-архитект. Все компании «маленькие», 30-60 человек.
Интервью проходило как-то так:
1. На первую работу, юниором взяли ещё без диплома — экзамен предстоял через несколько месяцев, резюме было с глав. директором, зав по ИТ отделу и Проджект Мэнэджер — после стандартных вопросов о понимании JSON, HTTP, PHP и т.д. и прощупыванием моих качеств по умению учится и т.д., мы расстались, а затем чере пару часов получил договор на мыло…
2. На второй, я продовал себя как мог, ибо рост зарплаты на 25% нужно как-то выбивать (думал я). Однако дальше вопроса, а точнее рассказа о проделанных работ/проектов и пару общих вопросов, знаю ли я jQuery, JSON, HTTP, PHP — также получил контракт на мыло через пару дней.
3. Пришёл, рассказал АЙТИ-Лиду и Проджект М. что делал, что умею, указал на ошибки и сказал как их можно избежать/исправить, покачал головой на это и на то…
Позвали ещё раз, где были только HR и Глав. Директор/хозяин, попили кофе, поговорили о целях и пожали руки, на след. день договор на мыло прилетел.
Тенденция такая, что с опытом и шаганием по лестнице, становится проще себя продать (знаешь то больше), но блин, боюсь я этого момента, если мне при след. резюме тест на какое-нибудь дерево или баблсорт подкинут — я сломаюсь.
SpiderEkb
Вот именно. Я могу рассказать про различные подходы обмена данными между процессами (от тривиальной многопоточки до гетерогенных распределенных систем), сейчас могу рассказать про некоторые аспекты эффективного кода под AS/400 (с учетом особенности работы групп активации, ресурсоемкости работы с USRSPC по сравнению с DTAARA) и т.п… Но вот тот же баблосорт реально не вспомню на память :-)
Jammarra
Проблема в том что собеседования где спрашивают много теории заточены на студентов, которые мечтаю попасть в "крутую компанию" типо Яндекса. И с которыми не о чем разговаривать про их опыт работы. Сам таким был лет 5-10 назад.
Но если говорить о специалистах с опытом работы. Тут такие люди в большинстве своем не очень то стремятся найти работу. Это компании ищут этих специалистов. И пытаются предложить такие условия что бы переманить к себе.
И когда рекрутеры условного Яндекса тебя забалтывают около года "не хотите ли пройти собеседование" И такой лениво "ну ок" То у тебя вообще нет никакого желания вспоминать курс универа, если он тебе в работе нафиг не нужен. Что бы потерять 10 часов условного времени и узнать что тебе предложат ЗП даже меньшую чем у тебя сейчас.
Так что разговор должен начинается с вопроса, что вы готовы предложить что бы я к вам захотел придти. И потом уже если они предложат ЗП в два раза больше и аквариум с акулами на рабочем месте и личный самолет. Появится смысл рвать жопу и проходить тестовое задание. Но большинство компаний именно на вопросе про ЗП сольются. Ибо то что у компании мировое имя, не значит что там хорошо платят рядовому специалисту.
А ну так же причина почему есть смысл заучивать и готовится к собеседованиям, это если ты планируешь релокейт.
Но суть в том что все зависит от того кому больше надо. И когда ты нужен работодателю больше чем он тебе, подобное полоскание мозга вызывает раздражение.
khim
Нет, если вы человек с именем и можете привести с собой команду в 100 человек… то вы же и не будете обычное собеседование, скорее всего, проходить — всё будет проходить в совсем другом месте и на совсем других условиях.
Условия предлагаются для того, чтобы люди не уходили, как бы. А не для того, чтобы кого-то переманить. Заниматься переманиванием, предлагая всё больше плюшек — довольно дурацкое занятие, на самом деле. Будут расти расходы, а качество результата — вряд ли.
То что вы нужны конкретному рекрутеру для получения бонуса — вовсе не значит, что вы нужны компании. Поверьте: если бы вы были нужны работодателю больше, чем он вам — вас бы собеседовали совсем по другому.
Это вообще самая большая ошибка всех, кто куда-либо устраиваться пробовал: они считают, что если рекрутер «телефоны обрывает» — то вы очень нужны компании. Нет — это просто значит, что за вашу голову условный Google может выдать рекрутеру условные $1000, а конторая «Рога и Копыта» больше, чем на условные $100 не расщедрилась.
При этом как раз конторе «Рога и Копыта» вы нужны позарез, а Google и без вас обойдётся… но рекрутер ведь не враг сам себе, ведь правда? $1000 это же гораздо больше, чем $100!
Jammarra
Обойдется компания без меня, да и хрен с ней. По факту все эти "большие компании с именем" тот ещё отстойник с унылыми проектами и поддержками тонны легаси, С кучей дурацкий совещаний, с опнеспесом в котором плюнуть негде и т.д.
Только странно что они так много бабок вкладывают в свою рекламу на хабре и на конференциях что бы хантить людей, которые им не нужны. Но как говорится есть у людей деньги и хотят их выкидывать, то кто я такой то бы их останавливать.
Хороших же IT спецов вагон на рынке вакансий. А вчерашний студент в легкую настроит прод так что бы он не падал прочитав stackoverflow, главное root доступ дать )
SpiderEkb
Вот вам и ответ на вопрос «откуда берется только глючного тормозного софта, жрущего ресурсы как не в себя».
Один вчерашний студент почитал пару страниц stackoverflow и написал некий «продукт». Протестировал его в стиле «вроде сразу не упало — значит работает»
Другой вчерашний студент почитал пару страниц stackoverflow и настроил прод так что «вроде не падает».
Юниттесты? Не, не слышали — зачем это надо, оно и так работает, мамой клянусь!
Оптимизация? Да нафига время тратить — оно и так работает.
Нагрузочное тестирование? А что это такое? А зачем? Походу само понятно станет.
vvbob
А бывает еще так что:
— А запилите-ка ребята мне вот эту фичу, которую по хорошему надо месяц делать, за неделю, так-то оно уже вчера надо было, но хотя-бы так…
…
— Оптимизация? Тестирование? Да бросьте страдать ерундой, давайте быстрее в прод!!! Потом оптимизируете и потестите!
…
— Что? Залили? Отлично! Тут есть еще одна задачка, которую по хорошему полгода надо пилить, но у вас три недели на всё про всё!..
Jammarra
Это в том числе. Но есть и ещё одна причина.
Бизнес выбирая между выпустить продукт быстро или выпустить продукт качественный, выберет быстро и потом будет допиливать напильником. Есть много причин почему так. Например нужно успеть выпустить фишки до конкурентов, нужно протестировать а пойдет ли бизнес вообще, прежде чем вливать бабло и т.д.
Достаточно сказать что половина если не больше софта для CI/CD и т.д. который на всех конференциях облизывают и все тащат в прод все ещё в бета версиях зачастую)
SpiderEkb
Один ответ на оба коммента.
Ситуации бывают разные. Одно дело, когда развлекательный сайт тормозит — ну тормозит и бог с ним по большому счету
А вот когда встает некое производство т.к. в системе уравления компоненты начинают по таймауту отваливаться из-за неоптимального в каком-то месте кода или у банка в период пиковой нагрузки из-за одного неоптимального модуля на несколько часов встает процессинг пластика по всей стране — это уже совсем другое дело. Тут уже бизнесу по карману бьет.
По большому счету опыт разработчика в том и есть, чтобы понимать, какой кусок кода можно сделать побыстрее, но чтобы работало, а какой надо вылизать до блеска котовых причиндалов чтобы не просто работало, но работало максимально быстро.
Jammarra
Работаю в финтехе. Можете мне не рассказывать про надежность процессинга, он слезы вызывает. По факту всем пофиг. Главное платежи не потерять, а пройдут на 20 минут позже, да и черт с ним.
А оно вообще работает на древнем железе и софте с минимум изменений. Какое то обновление станков в произвести огромные затраты, где разработка софта это меньшее из зол и стоит на общем фоне копейки.
Как не странно куда большую боль у бизнеса как раз вызывают например тормоза в каком то ИМ или на развлекательных сайтах, просто это чистая потеря денег. Конкуренция очень большая. А пользователю не хочется мерится с неудобствами. Как только ему лаги и тормоза начнут надоедать он просто уйдет к конкурентам.
А вот на узкоспециализированном софте типо для проиводства всем плевать на качество. Там конкуренции нет. И делают из разряда "жри что дают". И купив станок за 10 лямов, если там будет баг ты будешь с ним страдать лет 5. А на все претензии получать ответ "Иди в жопу, мы заняты"
Или если какая не будь МультиКарта лагает, ну и что ты сделаешь и к кому уйдешь. Опять же это твои проблемы. Жри и страдай.
Есть конечно ещё космос, авиация и т.д. Но это совсем отдельная область. Есть у меня надежда что там не так печально, но с ними не работал, сказать не могу.
SpiderEkb
Ну не знаю… У нас с этим сильно строго. И по надежности и по нагрузке.
Загрузка серверов мониторится постоянно, регулярно аудиты проводятся по потреблению ресурсов. Те задачи, что крутятся в фоне постоянно без нагрузочного тестирования вообще в бой не уходят.
И в промавтоматизации (точнее, близкой к ней области — система мониторинга инженерного оборудования заданий) работал долго. Там тоже все жестко было и по надежности и по таймингам. И все очень просто — плилетела посылка — не успел в таймаут уложиться — все, удаленная сторона считает что ты не получил. Идет перепосылка. После трех перепосылок считается что ты умер, разрыв сессии, реконнект и опять все сначала. Поставить систему колом можно на раз-два просто неоптимальным кодом.
А плохо работающую систему никто не купит, пойдут к конкурентам.
DrunkBear
Вон, недавно кое-какой банк переходил на свежую версию oracle database и не запустили регресс-тесты (все тестеры поразбежались, мвахаха) — процессинг почти всё воскресенье лежал — ичо, думаете, много ушло в другие банки?
SpiderEkb
Тут вопрос не сколько ушло, а сколько не пришло. Хотя, если банк имеет преференции в виде принудительного загона всех бюджетников на зарплатные проекты, то им, конечно, можно особо не дергаться.
Или когда через него в обязательном порядке всякие госзаказы идут.
А если банк работает сам и сам зарабатывает (ну насколько это возможно в наших условиях), то ему приходится заботиться о том, чтобы все работало.
Ну вот из последнего…
От нагрузочного тестирования прилетело
А дальше началось…
Ну и так далее… «Подрядчик» — ваш покорный слуга. По факту внутри два SQL запроса. Оба содержат WHERE VAR IN (<список значений>). Такие запросы внутри RPG (точнее, SQLRPG — тот же RPG, но с возможностью внутри использовать SQL напрямую) программ не параметризируются (в отличии от запросов типа WHERE VAR =? которые можно один раз подготовить (prepare), а потом многократно открывать OPEN… USING :var с разными параметрами.
В результате все переписано на «нативный» RPG c использованием функций чтения по логическому файлу (индексу).
Сложность только в том, что один запрос простой, просто с JOIN, а второй содержит GROUP BY… HAVING COUNT(*) = MAX(CNT) — вот тут пришлось еще индексированный список (сортированный список с поиском по ключу) подтянуть. Но в результате на тестовом юните старая версия работала 21мсек, новая — 7мсек. Сейчас ждем результаты нагрузочного теста — что они скажут, пропустят или нет…
Это лишь один пример, из последнего. И он сильно не единичный, такое сплошь и рядом у нас. После очередного (ежегодного) аудита на производительность составляется длинный список задач на оптимизацию с замечаниями что не устраивает.
DrunkBear
Там был не с производительностью и нагрузкой затык, а просто сломалась интеграция — недотестили, ибо тестеры разбежались, а свежие ещё не поняли, что и где нужно внимательно смотреть.
Или не успели — ежедневно могло быть до 7 совещаний, на которых обязательно личное присутствие, даже если будет обсуждаться количество гвоздик на подарок кому-то.
PS не проще ли в запросах с большим количеством параметров в var in () делать временную таблицу с этими var /sha1(var) и фильровать с помощью inner join на эту таблицу вместо var in?
SpiderEkb
Тут с производительностью есть особенности чисто AS/400. Там есть понятие «группа активации». Например, в рамках одной задачи (JOB) некая программа вызывается несколько раз. В первый раз для нее создается группа активации (можно ими управлять — наследовать от вызывающей программы, всегда создавать новую, создавать, если еще не создана, именованую под конкретную программу и т.п.)
Фактически группа активации есть некий контейнер внутри задачи, в котором сохраняются все статические и глобальные переменные. Т.е. при первом вызове программы они проинициализаируются, а при втором (если группа активации не была принудительно закртыта) они будут иметь те значения, что остались от предыдущего вызова.
Посему, у каждой программы всегда есть кусок кода, который вызывается только один раз, при создании группы активации. Туда вынгосятся (по возможности) всякие «тяжелые» процедуры, которые можно не делать каждый раз. Если рассмотреть наш вариант с SQL запросом
select FIELD1, FIELD2 from TABLE where FIELD3 = var
где var — переменный параметр, определяемый при каждом запуске.
В SQLRPG это делается так:
strSQL = 'select FIELD1, FIELD2 from TABLE where FIELD3 =?';
exec SQL prepare stmtSQL from :strSQL;
exec SQL declare curSQL cursor for stmtSQL;
exec SQL open curSQL using :var;
exec SQL fetch next from curSQL into :fld1, :fld2
exec SQL close curSQL;
тут var — переменная, содержащая параметр для поиска, fld1 и fld2 — переменные в которые получаем результат из очередной строки выборки.
Так вот. В данном случае exec SQL prepare и exec SQL declare выносятся в тот блок кода, который вызывается один раз при создании группы активации. А в той части кода, что вызывается при каждом запуске программы остается только open с текущим значением параметра, fetch и close.
Но. Беда в том, что с массивом переменных это не работает. Т.е. в случае с
select FIELD1, FIELD2 from TABLE where FIELD3 int ('val1', 'val2', 'val3',...)
конструкция
select FIELD1, FIELD2 from TABLE where FIELD3 int (?)
не пройдет.
и приходится при каждом вызове перестраивать запрос:
strSQL = 'select FIELD1, FIELD2 from TABLE where FIELD3 in (' + varlist + ')';
exec SQL prepare stmtSQL from :strSQL;
exec SQL declare curSQL cursor for stmtSQL;
exec SQL open curSQL;
exec SQL fetch next from curSQL into :fld1, :fld2
exec SQL close curSQL;
Именно это и вызвало возражения со стороны сопровождения — вызов prepare/declare при каждом вызове программы. Причем, той, которая вызывается очень часто (она входит в комплекс проверок клиента)
Т.е. дело не в таблицах, а в невозможности правильного создания динамического параметризированного запроса.
А «нативный» RPG имеет набор функций поиска-чтения-записи-изменения-удаления. В данном случае он работает безо всяких подготовок, просто с разбега фигачит по индексу, а дальше только разгребай результаты.
Хотя в общем случае считается так — если нужно найти одну запись в таблице по индексированным полям, то быстрее использовать нативный chain (чтение записи по значению ключа), а если множественная выборка — использовать SQL. Но бывают и исключения…
DrunkBear
То есть курсоры, обычно — один из самых медленных инструментов SQL — в AS используется как стандартный вариант при выборках?
Любопытная архитектура.
SpiderEkb
ну вообще здесь речь идет о SQLRPG — туда возможно засунуть любой SQL запрос.
Ну и никто не заставляет использовать именно SQL. Повторюсь — есть «нативные» функции для доступа к данным. Там вообще хитрая история (описана одним из «отцов-основателей» AS-ки Френком Солтисом в книга «Основы AS/400» — книга сама по себе занимательная т.к. там от истории эволюции System/3 — System/36 -System/38 — AS/400 до описания ее внутреннего мира, что как устроено и как работает) — было две команды, работающие над DB2/400. Одна разрабатывала концепцию DDS (Data Defenition Specifications) — язык описания данных, позволяющий достаточно единообразно описывать физические файлы (хранилища), логические файлы (способы доступа к хранилищам), дисплейные файлы (экранные формы) и принтерные файлы (формы для вывода на печать). Эта команда разработала т.н. «нативный» интерфейс позволяющий получать доступ к данным посредством функций типа read write update delete (в RPG несколько усеченный вариант, полный вариант содержится в RECIO — специфическое расширение C RTL для AS/400 — www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rtref/recioh.htm)
Вторая команда работала над SQL/DB2.
И о чем-то они не договорились. В результате сделали и то и это.
В каких-то случаях удобнее пользоваться SQL, в каких-то нативом, хотя там чтобы написать простенький запрос с парой join'ов, конечно, приходится написать прилично кода.
В ряде случаев натив оказывается быстрее и менее ресурсоемким, в каких-то наоборот.
В том случае, что описываю я, старое решение (на SQL, не прошедшее нагрузку) отрабатывало на тестовом юните за 21мс. А написанное мной нативное решение (хотя и более длинное по коду) там же и на тех же данных — 7мс.
Сейчас вот ждем что нагрузочники скажут. Сам не имею доступа к PEX (инструмент, позволяющий анализировать загрузку процессора).
khim
Понятие alfa, beta и прочее имели смысл, когда продукт нужно было распростналять на физических носителях и выпуск обновлений влетал в копеечку. Сегодня, когда релиз зачастую глючит не меньше, чем beta, но это никако не волнует, потому что всегда ж можно horfix выпустить… это просто ярлыки.
Jammarra
Ну если интересно, то рассказываю.
1) ты должен быть на ранке первым. Второй а тем более 3 и 4 уже никому не интересен, рынок к тому моменту будет занят и лезть туда бесполезно. Вот сейчас фейсбук ужасен и все это знают. Но никому не нужен хороший аналог фейсбука, ибо все уже сидят в нем.
Поэтому лучше выкинуть на рынок сырой продукт и потом допиливать напильником.
2) Время программ которые делались в гараже прошли. Сейчас надо несколько миллионов вложить что бы выпустить что то хорошее. И обычно это не про рубли речь. Значит нужны инвесторы. Инвесторам же не интересно что у тебя штат программистов там оптимизирует сортировку что бы на 0.5 секунд быстрее все работало пол года. Им нужен продукт который можно увидеть и который будет уже продвигаться на рынке.
3) Опять же речь про инвесторов. Разработка 2 года условно стоит 2 миллиона, 5 лет условно стоит 5 миллионов. Узнать же навярника стрельнет твой продукт или нет. Можно только выпустив его на рынок. Никто не захочет вложить 5 лямов что бы узнать что вы сделали никому не нужную фигню. Пусть и идеально. Предпочитают пальнуть за 2 и посмотреть есть или нет спрос.
4) IT мир и рынок быстро меняется. Лет 10-20 назад все пилили на монолит. Сейчас все пилят на микросервисы. Изменилось архитектура и т.д. Постоянно нужно дорабатывать.
Зачастую куда актуальнее, через 10 лет накопив критическую массу костылей выкинуть все что было написано до этого и сделать что то на более современных средствах. Чем тащить легси и искать программистов на условном делфи на рынке которые будут его поддерживать и дорабатывать.
5) Опять же про меняющийся рынок. Время жизни твоего продукта как концепта может просто составить всего несколько лет в IT. Потом кто то придумает что то более интересное и твоя компаний просто закроется.
Нужно просто понимать что по итогу наверное где то 80% всех продуктов на фиг не кому не нужны. И их делают не ради "движухи менеджмента" а ради проверки стрельнит или нет. Из ярких примеров куда вкинули тонну бабла, без выхлопа это например гугл плюс.
Да программисту как работнику не совсем прикольно что результат его трудов скорее всего пойдет на свалку через пару лет или будет переписан. Но такова жизнь
khim
И потому сейчас все пользуются для поиска AltaVista и Excite, редактируют текст в WordStar и WordPerfect, а бухгалетра считают зарплату в VisiCalc… ой, не так? Всё-таки пользуются даже не вторым, а 3-4м? А почему так?
Не нужен им продукт. Им хайп нужен. Чтобы на IPO выйти и денег срубить. Да — есть такое дело. Только даже им не нужна «движуха», когды вы что-то делаете за три дня, а не за месяц. Инвесторы с такими временными промежутками не работают.
Вот как раз если вы будете всё переворачивать с ног на голову каждые 2-3 дня — у вас и будет разработка длиться 5 лет. И получите вы в результате глючное дерьмо.
Вот кстати ещё один «никому не нужный продукт номер 3»: Chrome. И вышел на рынок позже всех (после Netscape, MS IE, и
снова NetscapeFirefox). И фичи пилятся месяцами (а некоторые и годами). И, тем не менее, сегодня — это браузер номер 1.Ну это уже движуха ради двужухи. Что вам и почему нужно «постоянно дорабатывать»? Вот прям так, что вы не можете план составить на полгода-год, а нужно всё в авральном порядке кромсать?
До-до-до. Вы много вообще таких примеров знаете? Назовите парочку, хотя бы. На каждый случай, когда этот «финт ушами» проходил приходятся десятки случаев, когда в момент, когда вы, наконец, решаете переписать всё «по феншую» — вас обходят конкуренты и вы либо становитесь номером два, либо вообще становитесь никем.
На эту тему есть много разных статей, самая разумная — пожалуй вот эта: иногда вы можете развивать новую версию как отдельный, успешный проект, который, через много лет, заменяет старый (классический пример — это переход от MS DOS к Windows NT через Windows 3.1, Windows 95 и вот это вот всё), но это — крайне сложное (и затратное мероприятие).
Попытка «срезать круг» и всё сделать в один шаг — приводит к катастроф (см. Windows Phone), а сделать всё правильно вам не дадут всё те же самые менеджеры, которым нужно показывать «движуху».
Вот как раз Delphi, Visual Basic и многие другие от этого феномена пострадали очень сильно. У них была развитая экосистема, но они попытались «сделать что то на более современных средствах». Результат — фактически полная катастрофа. Visual Basic .NET начал понемногу набирать популярность в последнее время — но для этого потребовалось в него вливать ресурсы больше десяти лет (то же самое с Firefox — компания, в результате, таки умерла, хотя браузер выжил).
А это — точно про «эффективных манагеров». Какая разница, что будет с компанией, с который вы уже все деньги выжали, «эффективность» показали и ушли в другую?
Я бы даже сказал 99% (если включить сюда не только «коробочные» продкты, но и всё то, что разрабывается для «внутреннего» потребления… а потом тихо выкидывается).
И вот как раз Google Wave, Google Plus, Google Hangouts и прочие продукты Гугла, которые в модном «молодёжном» стиле ежедневной движухи делали — провалились. А какой-нибудь Google Drive, который пилили буквально годами (вышел через пять лет после Dropbox) — вполне себе существует… потому что соотвествует ожиданиям.
Вся эта движуха по одному шаблону развивается: поднять кучу хайпа, получить от начальства бонусы (как вариант — вывести компанию на IPO и свалить), оставить всё вот это расхлёбывать кому-то другому.
Areso
А шанс?
Для простоты ситуации.
В Гугле открыта ровно 1 позиция, которая отдана аутсорсинговой компании Айтипиплы.
В местной компании ООО «Биллинговые решения для всех» открыта ровно 1 позиция, которая также отдана той же компании.
А теперь давайте прикинем, с каким шансом рекрутер из Айтипиплы сможет найти человека, который пойдет на собеседование, пройдет все этапы, получит оффер и выйдет на работу. И с каким шансом все тоже самое произойдет если рекрутер из Айтипиплы будет подбирать человека в ООО «Биллинговые решения», которым вот прямщас надо заменить ушедшего, по смешному совпадению, в Гугл ведущего программиста.
khim
Знаете, если бы HR умели в логику, то они бы писали программы (и зарабатывали бы куда больше денег), а не обрывали бы вам телефоны.
А так-то да, всё верно — Гугла именно потому и платит больше за вакансию, что закрыть её труднее.
maxwolf
Они, похоже, это просекли, и таки начали «писать программы»… Вот, из недавнего: AI «просматривает» по миллиону интервью за 90 дней, и, по сути, принимает решение, брать ли вас на работу
Gryphon88
Про это даже xkcd нарисовано.
whereispie
Недавно проходил тех резюме в Aliexpress на позицию разработчика, думал буду общаться с китайцем и будет очень "больно" в плане понимания китайско-английского)), в итоге общался с русским парнем, но интервью все тех вопросы были на английском (политика компании), после уже перешли на русский.
В общем главное не беспокоится в таких моментах. Всем удачи на интервью.
Офтоп P. S: Кому будет интересно, напишу список вопросов
Funky_Alex
Хотел бы добавить вариант собеседования в маленькой компании:
Главным вопросом может стать ваш знак зодиака :)
(из личного опыта)
Tunerok
Автор (несомненно автор), вы слишком (очень-очень) много (часто, а не редко) пишите в скобках (вот таких, даа). Стиль изложения (пишем когда) страдает от этого (ему очень-очень плохо:)) и читать такой (вот такой вот, как этот) текст :) неприятно (неприятно ведь). Особенно когда ещё и смайлики (смешные скобочки) :) вставлены :))
andyDufresne
У меня был интересный случай. Проходил собеседование по скайпу. Туда созвали 3х молодых чуваков меня собеседовать. С виду явно разработчики. В резюме соответсвенно указал, то с чем я работал как full stack разработчик с ASP.NET с MSSQL, ну и всякие Angular-ы. С самого начала заметил какую то ненависть в глазах ребят. Начали спрашивать у меня отличие кластерного индекса от не кластерного. У человека который работает с СУБД через различные прослойки типа Hibernate или Entity Framework подобные знания как то нахрен улетучиваются через 8 лет активной работы. Ну я ответил как смог. На что услышал фразу от одного из троих: «Так он XXX тысяч ЗП хочет и не знает что это такое?»
A114n
Это кстати тоже да.
И бывает не только с молодыми, которые просто ещё не столкнулись с собственным ростом опыта и забыванием всяких мелочей — но и от вполне опытных людей, которым просто жалко денег. Они смотрят на сумму, их немного начинает придавливать жаба и они принимаются задавать энциклопедические вопросы.
khim
Вы уж меня, конечно, извините, но если вы вообще работаете с базами данных — то должны понимать чем отличается кластерный индекс от некластерного.
Вот просто должны и всё.
Если вы вдруг не в курсе — я могу попробовать на пальцах объяснить. Предствьте себе, что у вас в базе данных хранятся не письма там или проводки, а внезапно, автомобили. То есть эта база данных — это такая куча гаражей, где стоят траки и легковушки, трактора и самосвалы… всё вперемешку.
Так вот можно — все самосвалы поместить в один гараж, а все легковушки — в другой. Это будет кластерный индекс «тип автомобиля». А можно, наоборот, собрать в одном гараже все авто синего цвета, а в другом — зелёного. Это кластерный индекс «цвет».
Это, собственно, основа вашей базы. Принципиальное решение, меняющее всё. Потому что если у вас кластеризация по типу автомобилей, то собрать стильную тройку из красного мотоцикла, красного самосвала и красного экскаватора — для вас будет проблемой. А вот зато пару экскаваторов разных цветов — вы «подгоните» легко.
Поскольку речь идёт о том, что мы физически гоняем машины из одного гаража в другой — то мы можем иметь только один кластерный индекс… и если мы его выбрали неверно, то у нас будут-таки проблемы. Зато если мы выбрали его хорошо — то может быть многократная экономия на серверах!
Поскольку у нас всё-таки в базах данных не авто — то в некоторых патологических случаях может оказаться полезным даже иметь две одинаковые базы с разными кластерными индексами. Ну, типа, закупить всех машин в двух экхемплярах — и поставить в один гараж разные экскаваторы, а в другой — всю технику красного цвета. Хотя это и не рекомедуется (если один экскаватор пропал, а другой остался — беда будет).
А вот что andyDufresne ответил на этот вопрос и как именно к нему придираются — сказать без подробностей нельзя. То ли он увяз в объяснениях того до какой степени разные базы готовы «копировать данные по диску», чтобы ускорить работу кластерного индекса, то ли он в принципе не смог объяснить чем кластерный от некластерного отличается… то он вообще всё правильно объяснил, просто использовал вместо слов «кластерный индекс» слова «первичный индекс» (в этом случае это уже точно придирки, так как практически случаев, когда их нужно различать, скорее вы не встретите).
andyDufresne
Здесь немного другие уровни абстракции. Обычный прикладной программист строит модель данных исходя из бизнес процессов которые эту модель затрагивают. Ему абсолютно монопинесуально, используется ли индексация физическая или вирутальная. Если в БД 10 таблиц. 5 из которых обычные справочники, то знания о том как эти справочники хранятся нужно только задротам. А для построения высоконагруженных БД есть отдельные специалисты, которых DBA зовут. И там модель Code First никто никогда не использует. А по поводу ответа на собеседовании, тогда я сказал, что для меня разница между типами индекса заключается лишь в том, что кластерный работает быстрее, но может быть только один — в общем ответил с практической точки зрения. На тот момент конечно напрочь забыл все определения.
khim
Далеко не всякая нагруженная база имаеет такие масштабы и далеко не каждая фирма имеет такой штат, чтобы выделенного DBA содержать. Очень многие хотили бы, чтобы сеньор — тоже мог в такое.
И да, сразу предупреждаю — я, например, не смогу. Последний раз базы оптимизировал много лет назад, почти сразу после универа… так что наверняка делал всё это неправильно и на подобную вакансию даже претендовать не стану.
Но про разницу между кластерным и некластерным до сих пор не забыл…
andyDufresne
Т.е. если человек создал оптимизированную БД, но при этом уже не помнит почему он так делает, по вашему ему не надо платить? По моему тут просто оценка знаний должна происходить, а не сопоставление этих знаний с запрошенной суммой. Это уже работа не технического интервьювера, а менеджера. Ну по крайней мере я так себе это представляю…
Ну да, все хотят сэкономить, но я то тут причем?
khim
Менеджер уже высказал всё, что было нужно до начала интервью: если вакансия на определённый набор навыков и определённую сумму открыта — то дальше чловек либо соотвествует ей, либо нет. Иногда открыты несколько вакансий и тогда может быть выбор — на какую из них человек подходит… но из вашего описания ну вот совершенно неясно — была ситуация такой или нет…
Ну как бы вы же на эту вакансию пытались устраиваться, не я… если вы предполагали, что схему базы будет разрабатывать DBA, а от вас ожидали, что это сделаете вы… то вы «не сошлись характерами» с вакансией, вот и всё.
DrunkBear
Может, стоит лечить где болит и сначала сделать слегка неоптимальную, но рабочую БД, а потом брать в руки профайлер и искать/лечить болевую точку?
Знаю пару компаний, в которых эти точки найдены и задокументированны, и могут ускорить производительность раз в 20.
Но пока лежат в виде документа: менеджмент решил, что сейчас заказчик доволен скоростью — пусть так и будет. А через годик-два база распухнет и заказчик перестанет быть довольным — тогда и стоит выкатывать фикс, всё ускорится и заказчик снова будет счастлив.
khim
Извините, но я даже не знаю чего от вашего рассказа убавить или чего прибавить.
Вы-то сами понимаете, что людей, выращенных в таких компаниях, в местах, в которых нужна работа с базой не для того, чтобы ублажать заказчика и тянуть из него деньги, а чтобы самим как-то использовать — стараются не подпускать в принципе?
Да, это отличная схема. Позволяет тяуть деньги из заказчиков, грубо говоря, вечно. Но если вы это делаете для себя… зачем оно вам?
mayorovp
Как за что? За код.
khim
Ну собственно в этот момент и возникает непонимание. Есть компании, где платят за решения задач. А есть те, где платят за код… и это разные компании.
Рассказ вашего коллеги вот буквально чуть выше — это же прекрасная иллюстрация…
mayorovp
Задачу решает отдел, а не один-единственный разработчик.
Thahr
Яндекс нельзя сравнивать с Google/Facebook/Amazon в плане интервью, я сейчас в процессе со всеми этими компания. В Я задачки только в начале, потом они хотят конкретных знаний. Все, с кем я общался, очень узкие спецы с очень узким кругозором и ожидают того же. Это куда ближе к ЕПАМ чем к Tier-1 (и даже не Tier-3) компаниям на западе.
Так же в Я мне встретились только 2 типа: или старые хардкорные динозавры с 10+ лет опыта (большую часть в том же Яндексе) или совсем молодые. Видимо все лучшие и активные уехали на запад или нашли лучше варианты в современых и более динамичных компаниях с лучшей компенсацией.
vortupin
Cerberuser
Любая из четырёх, в зависимости от патриотических чувств говорящего.
Thahr
Объективно Я и близко не стоит с другими компаниями в этом списке. Капитализация 15B против ~1T у ит-гигантов, количество и охват аудитории, технологии. Я был в 3х из 4х этих компаниях и субъективно Я так же совершенно другая лига ;-(
Просто их продукты на слуху для тех, кто живет в РФ и много лет формировался бренд, который засел у вас в головах. Но, по факту, это уровень EPAM, Dropbox, Cloudflare, Yelp (что, конечно, тоже круто).
vortupin
Это не патриотизм, а так называемый «квасной ура-патриотизм». Яндекс отнюдь не является ни «мировой», ни «крупнейшей» IT компанией. «Крупнейшей российской» — да. По меркам же мирового IT, Яндекс — это, максимум, средняя (по количеству персонала) компания с не слишком завидными финансовыми показателями, и практически не известная за пределами России.
Ну, и касательно остального содержимого данного опуса: наивный бред ни о чем «хаброюзера» с крайней ограниченным рабочим опытом. А бред потому, что практически все вышеизложенное не соответствует реальному положению дел, от слова «вообще» (могу абсолютно точно сказать касательно собеседований в одно из подразделений Amazon-а и Microsoft-а — да, все еще очень зависит от конкретного подразделения и команды, хотя есть определенные «корпоративно-стандартные» штуки).