Pull to refresh

Comments 302

Я не знаю почему в ваших глазах, заданные вопросы про:
  • yield
  • Как называется метод, который фильтрует все нилы в коллекции?
  • Что такое Enumerable? Назовите, какие там есть методы и кто его экстендит

вы видите как теоретические. По мне так это очень даже практические вопросы. Вещи которыми пользуешься каждый день.

Более теоретические (в моем понимании) это:
  • Чем отличается interface от mixin'а
  • Что такое функтор

и так далее

Вы тем самым показали, что не владеете инструментарием и скорее всего (из-за не знание основ) гавнокодите.
Вы тем самым показали

Я тем самым вообще ничего не показал, потому что на следующем собесе на эти вопросы ответил и в итоге получил оффер (правда не на 5к как рассчитывал а всего лишь на 4.5к :)))
4.5k гривен? Вас даже переоценили, с вашими то глубокими знаниями в руби. Видимо кадровый голод настолько сильный, что уже берут всех, кто хоть немного шарит в программировании и хочет программировать на руби.

А еще вы очень хорошо показали в статье что навык проходить собесы приходит с опытом :)
гривен

Беларусских рублей )))
У вас проблемы с логикой
Во-первых если тест имеет вероятность ложноположительного результата выше нуля, это еще не значит что тест плохой.
Во-вторых между собеседованиями вы провели обучение и закрыли какие-то пробелы в знаниях, а значит стали лучше, то есть вы не такой же как были на первом собесе.

Все потому и проводят по-разному интервью, что нет единого лучшего способа их проводить. Все методы имеют недостатки, их конечно можно на этом основании критиковать, но проводить то как-то надо) Вы наверно и сами согласитесь, что кандидат ответивший на 5 теоретических вопросов правильно, при прочих равных (или неизвестных) лучше кандидата который на них не ответил.
yield

Писал и пишу на Ruby с 2006 года, за всё время использовал эту фичу 3 раза. ЧЯДНТ?

У меня для вас плохие новости
Spoiler header
шутка :)


Ну по мне так, yield стал очень популярным. Концепт, который существует в других языках, как Python, C#, Scalа. И во всех этих языках это довольно популярная фича.

Не знаю насчет С#, но в Python и Scala yield — это разные вещи, я б не стал их сравнивать.

Как называется метод, который фильтрует все нилы в коллекции?

Вот конкретно такие вопросы — бессмысленные. Если кто-то зазубрит названия всех методов, это вовсе не будет значить, что он знает язык и хорошо кодит. Достаточно общего представления о возможностях (что так или примерно так можно, дальше уточнить в документации). На вскидку названия этого метода не припомню, но это ничуть не помешало использовать его не так давно.
Зависит от того, кто что использует.

Меня в JS бесит reduce-мания. Я на практике использовал reduce пару раз, поскольку не считаю, что reduce даёт читаемый код (часто проще обойтись map).

Но если я приду в контору у которой всё на reduce, то ессно буду выглядить бледно, потому что хоть знаю как работает reduce, но он у меня «не наработан».

Та же беда с SQL. Я не люблю joinы с использованием join, предпочитая джойниться в where. Для ребят у которых join на джойне, будет важно понимаю ли я чем отличается righ outer join от left inner. А я ведь с ходу не скажу ничего. Поскольку привык реализовывать это через exists и *= (в оракле).

Другое дело, что перестроится, что на reduce, что на join мне пробела особых на будет, но вот верит ли в это интервьюер? )))
. Я не люблю joinы с использованием join, предпочитая джойниться в where.

Я тоже, только в MySQL такой фокус не пройдет )))
Вот только условие в where может заменить лишь внутренне соединение (inner join) или внешнее, но только с проверкой ключа на is null. Все остальные варианты соединений на условие в where не способны заменяться в принципе. По крайней мере, за пределами Oracle. Кстати, left inner join не бывает.
Правда? Приведите пример, пожалуйста.

Я лет 10 занимался проектированием и программированием БД. И всегда хватало обычного where. Вложенные запросы с exists и in как правило решают проблему.

Все современные БД, умеют оптимизировать запросы с exists/in равно как и join'ы поэтому всё дело вкуса (и соглашения в текущей команде), имхо

Вот, держите:


select *
from foo
left join bar on foo.id = bar.fooid
Вы это… полегче с ними ))

На самом деле важное, я бы сказал в следующем:

SELECT 
     f.SomeField
    ,b.SomeOtherField
FROM foo as f
join bar as b on b.fooid = f.id


Мне, просто, всегда казалось что именно в этом основной смысл «join», а не в фильтрации )
select *
from foo
where not exists (select 1
from bar where foo.id = bar.fooid)


Единственная разница в том, что у в выборке не будет кучи пустых полей из bar. Для того, чтобы её получить надо более сильное колдунство

Ваш запрос вернет только те записи из foo, для которых не существует записей из bar — а надо-то все. Причём вместе с данными из bar!

Да, согласен. Перепутал join'ы, почему-то мне outer почудился, о чем ссно писал выше (что не готов с листа читать / писать join синтаксис)

Для выборки всего действительно «старый синтаксис» не подойдёт либо нужно будет делать извращения с union или агрегацией
outer вам не почудился, полное название left join — left outer join
Ок. Вы меня победили )))

Я же говорю, что join'ы это не моё. И время, чтобы в них въехать. И наша дискуссия это подтверждает. Практически уверен, что вы бы не взяли меня на работу.

Потому, что после того, как я так показательно сел в лужу, спрашивать, что собственно я делал такими кривыми руками, какие задачи решал, какие объёмы баз данных и насколько сложная там структура — смысла нет.

PS. На пред-предыдущеё работе за 5 лет работы с Oracle использовал =* (left join) два раза, на 40К+ строк PL/SQL. Но возможно мои задачи можно было решать и без него, где-то left join может осознанно и аргументированно использоваться очень активно
Потому, что после того, как я так показательно сел в лужу, спрашивать, что собственно я делал такими кривыми руками, какие задачи решал, какие объёмы баз данных и насколько сложная там структура — смысла нет.

Конечно же смысла нет, если вы знаете только Oracle, а в вакансии требуются MSSQL или Postgres...

select *
from foo, bar
where foo.id = bar.fooid(+)
Я же писал: за пределами Оракла
Не все, у Оракл перформанс часто проседает. Кроме того с джойнам проще писать базонезависимый код, там где это важно.
map и reduce это же принципиально разные инструменты, как это вы одним обходитесь?
Я использую lodash — там много инструментов)

Я про то, что часто достаточно использовать map или for in/of, а не гордится, что любую проблему можно, а поэтому нужно решать с помощью reduce
Я, видимо, чего-то не понимаю. Допустим, вам надо просуммировать числа в массиве. Логично использовать reduce. Допустим, вам надо возвести числа в в массиве в квадрат. Логично использовать map. Допустим, вам надо возвести числа в квадрат, а затем — просуммировать. Логично использовать map+reduce.
Тут нечем гордиться, это просто инструменты одного уровня. И точно так же глупо говорить
не считаю, что reduce даёт читаемый код (часто проще обойтись map).
map можно выразить через reduce. Но «обойтись map» действительно проще. В таком случае нет противоречия ¯\_(ツ)_/¯
С точки зрения скорости использовать reduce выгоднее. Но если у меня нет потребностей скрупулезно экономить ресурсы, то я напишу

mySum  = _.sum(_.map(arr, x => x *x ))

Для меня это гораздо лучше читается, чем

mySum = _.reduce(arr, (sum, x) => sum + x * x, 0)


Потому что в первом случае мы делаем две атомарные операции: (1) суммируем массив (2) квадратов исходного массива

В данном конкретном случае сложность чтения невысокая, но если нам надо например просуммировать квадраты всех чисел от двух и больше

_.sum(_.map(_.filter(arr, (x) => x >= 2 ), x => x * x))
// vs
_.reduce(arr, (sum, x) => sum + (x >= 2 ? x * x : 0) , 0)


Да оба примера выглядят грязно. Можно использовать chain запись — она тут читается идеально

_(arr)
  .filter(x => x >= 2)
  .map(x=> x * x)
  .sum()


Но, в плане улучшения читаемости кода, у нас есть возможность раскрыть часть функционального выражения через временную переменную (которую V8 на легко заоптимизирует)


const filtered = _.filter(arr, x=x => 2)
_.sum(_.map(filtered, x => x * x))


В reduce раскрытие кода хуже читается, потому на русском языке проще сказать — как написано выше: фильтруем всё что меньше 2, остальное возводим в квадрат и суммируем

_.reduce(arr, (sum, x) => {
   if (x >= 2) return sum + x*x;
   return sum
}, 0)


Так же у нас есть возможность использовать for


let sum = 0
for (const x of arr){
  if (x >=2) { sum += x *x }
}


PS. Написал lodash во всех случаях для простоты сравнения

PPS. Вообще меня в reduce бесит то, что инициализация — последний параметр. По мне было бы не в пример удобнее, если поменять инициализацию и функцию.

PPPS. Возможно я говорю глупо, но мне кажется, что я имею право на свою точку зрения? )
Вы, конечно, нормально упоролись, но сумма — это был просто пример. Я не пишу на js, я вообще про концепции говорил. Если у вас есть sum и reduce, и надо суммировать числа, то надо использовать sum. Только не надо при этом утверждать, что проще обходиться map.

Если нужна производительность, то можно трансдьюсеры юзать. Будет в один проход и читабельно.

Тут мне на днях кто-то на Хабре заявлял, что reduceRight допустимо использовать в качестве аналога forEach когда нужно обойти массив в обратном направлении…

Вот так и обходятся.
Не факт, что оптимизатор SQL переварит это и выдаст правильный план исполнения.
Но в этом году среди всех собеседований я не получил ни одного вопроса по шаблонам. Ruby-разработчиков, наверное еще можно понять, — они, наверное, про них ничего и не знают

Мой поиск работы длился 3 с половиной месяца, месяц удаленно по скайпу из НСК, и два с половиной уж в МСК. Язык PHP — почти все собеседования по паттернам и SOLID.

Так вот, одно из удаленных собеседований было на джуниора (почти остальные на мидла или что-то между джуном и мидлом), и мне задали вопрос по SOLID, погоняли по каждому принципу, привел даже примеры, погоняли по MySQL (тоже всегда гоняют пыхеров), по NoSQL сразу сказал, что вообще не работал ни с чем, в т.ч. с Эластиком и прочим...


Дали задание
В режиме шаринга экрана написать простой код с внедрением зависимости, походу дела усложнив до реализации контейнера зависимостей — конечно я его сделал, простенький… в ближайший понедельник мне заявили в сообщении, что я слабый джуниор и не возьмут меня. Было странное ощущение недоумения, тк более-менее есть адекватное понимание, кто и что должен знать :)

Хотя конечно на мидловых собеседованиях меня в лужу садили несколько раз так, что в затылке биение сердца чувствовал :)
В php вообще, судя по всему, творится ад и хаос.
Это стандартная фича языка ;)
Ну почему, мне, например, Laravel вполне даже приятен. Если приучить себя к особенностям синтаксиса PHP то становится почти как Rails.
Вообще ща пишу на yii2. Как понимаю, что-то родственное laravell. Но пыхе ща не хватает жесткой статической типизации — оттуда ад и хаос.
Зачем вам принципиально статическая нужна?
Вы сделали мой день ;)

Язык PHP — почти все собеседования по паттернам и SOLID


Интересно многие ли PHP команды это употребляют? Хотя, PHP как раз такой язык, что требует беспощадного насаждения культуры разработки.
Многие просто спрашивают на собеседовании, просто чтобы было что спросить.
На практике мало кто действительно использует и заморачивается. Иногда даже думают, что используют, но на самом деле — нет.
Думаю, сильно зависит от фреймворка.
Много, в топовых проектах много где Симфони (аналог Spring из языка Java)
github.com/symfony/symfony

Mail.ru (Delivery), Rambler, Lamoda, Forbes, Conde Nast, Skyeng… используют точно Симфони
И тысячи проектов пользуют похожие фреймворки, у некоторых есть огромнейшие минусы/плюсы, есть монолитные проекты, но во всех больших преоктах, сами понимаете, встает вопрос рефакторинга, поддержки и переиспользования кода… на что приходит нам на помощь неожиданно ООП.

Понимаю, для некоторых программистов очень удивительно слышать SOLID и PHP, недавно столкнулся с тимлидом на Java с 7 летним опытом, он очень был удивлен :):) просто про PHP он знал примерно то, о чем все обсуждают в ВК :)
«в ВК» — в компании при разработке одноименного сайта? :)
Я конечно ничего не понимаю в Java и Ruby, но по вопросам можно примерно представить уровень. Ну так вот не взяли вас в большинстве случаев совершенно правильно. Если вы не знаете синтаксиса языка, то зачем вы на те позиции шли? Можно не знать методов и библиотек, но синтаксис — святое.

Задачки на переворот строки дают чтобы не тратить время на совсем не программистов (вы не поверите сколько народу так отсеялось).

И ещё. Вы не прошли самый начальный уровень. Дальше были-бы вопросы сложнее. Потом ещё сложнее. И т.д. И так до предела возможностей или ваших или интервьювера. Это надо чтобы определить ваш уровень с одной стороны и предложить лучше позицию если случайно overqualified человек пришёл.
Ну так вот не взяли вас в большинстве случаев совершенно правильно.

Все верно, два раза не взяли, на третий раз взяли хотя я-до и я-после ничем не отличались по уровню. Между собесами прошло несколько дней. О чем это говорит? О том, что вопросы, которые мне задавали, совершенно ничего не показывают.
Если вы не знаете синтаксиса языка, то зачем вы на те позиции шли?

По фану ))) А еще на RoR я сделал несколько довольно серьезных коммерческих проектов и заработал прилично денег, поэтому уверен в своих способностях решать задачи бизнеса.

Понятие «говнокод» универсально для всех языков, я могу сходу определить что код плохой, будь он написан на Java/Ruby/Python/JS и так далее.
делал несколько довольно серьезных коммерческих проектов


Оно самое! Сейчас почему-то спрашивают какую-то хрень. По умным вопросам кажется, что проект будет гениальным, а потом окунают в махровый легаси уровня ПТУ.
UFO just landed and posted this here
Нефига себе — поделитесь историй успеха?
А еще он знает лично Илона Маска, помогал Лари Пейджу, и владеет солидным куском акций Apple и Amazon.

П-з-ть — не мешки ворочить!
UFO just landed and posted this here
Наличие успешных проектов ничего не говорит о компетентности.


Ну почему? Практический опыт о многом говорит.

К сожалению на интервью зачастую делают упор на незнание. А незнать можно боооольшое количество вещей. Начиная от сигнатуры метода и кончая какой-нибудь пятой нормальной формой. Обычно сам спрашивающий никогда не использовал эти знания на практике. Но если есть эквивалентные знания, то надо делать упор на них. Я например не знаю что такое «мок», но на самом деле это элеметарная вещь, которую просто хитро назвали. А тем временем спрашивающий наслаждается тайной властью.
Насчёт успешных проектов — как ни странно, это во многом так. Когда фрилансил, периодически приходилось что-то приделывать к коммерческим веб-приложениям (партнёрки, cms, и т.п.) — успешно продающимся на международном уровне. Код, как правило — тихий ужас. В мало-мальски крупной энтерпрайз-конторе такого бы не написали.
В больших конторах тоже бедлам. Я сейчас работаю в проекте со 150 программистами. Такого кода насмотрелся, от самого умного до самого тупого.
Все верно, два раза не взяли, на третий раз взяли хотя я-до и я-после ничем не отличались по уровню. Между собесами прошло несколько дней. О чем это говорит? О том, что вопросы, которые мне задавали, совершенно ничего не показывают.

Вы бы не подготовились за несколько дней, если бы не
А еще на RoR я сделал несколько довольно серьезных коммерческих проектов и заработал прилично денег, поэтому уверен в своих способностях решать задачи бизнеса.

Даже за месяц не факт, что подготовились бы.
Так что вполне возможно, что показывают. Да, вполне возможно, что на первых двух из трех ваших собеседованиях были ложно отрицательные результаты и Вы бы подошли на эти вакансии. Но вы же не знаете, какой в этих компаниях поток кандидатов. Может им не страшно не взять хорошего, но страшно взять плохого.

1) есть позиции, где умение программировать в целом важнее знания нюансов синтаксиса, а, тем более, сигнатур методов
2) в редко используемом (лично) языке трудно понять что в синтаксисе мастхэв, а что нюанс, который реально используется в паре низкоуровневых библиотек и введённый в язык их авторами. Кроме как сходить на собеседование других способов особо нет понять.

Насчет «синтаксис — святое» не соглашусь. Если пишешь проект на нескольких языках разом, в моем случае Ruby, JS и Kotlin, то легко перепутать и написать метод или конструкцию не того языка сдуру. Да, перед собеседованием не грех и повторить азы, чтоб не смущать собеседущего. Но так вот радикально, не помнишь синтаксис — вон из сеньоров, это напрасно.
Знакомые ощущения, после собеседований уровня «переверни-ка мне дерево» и чем X структура отличается от У (при условии, что У нигде на практике не используется) и резюмирования «у вас пробелы в базовых знаниях», наступает некоторая апатия, даже объяснять интервьюерам/рекрутерам ничего не хочется.

Тут важно понимать, что есть много вещей, которые вы знаете, но не знает тот (собеседующий), кто знает, то, что вы не знаете/путаетесь.

после собеседований уровня «переверни-ка мне дерево» и чем X структура отличается от У (при условии, что У нигде на практике не используется)

Я рассуждаю так — если работа вам нужна, то нужно просто выучить все эти алгоритмы и уметь решать их с закрытыми глазами. Было много историй о собесах в FAANGи где люди месяцами сидели учили Cracking Coding Interview и LeetCode чтобы пройти собесы. Если рынок требует — значит надо соответствовать. Иначе снижается количество мест, куда можно попасть, зачем себя ограничивать в потенциальных возможностях. Если бы на собесах требовали писать о себе эссе на 10 страниц — пришлось бы писать, что поделать.

Я ходил на собесы по фану, поэтому не готовился ваще и поставил себе челлендж получить максимум офферов на $5k, на любые позиции, на любые технологии, отвечал на все запросы рекрутеров. Конечно, если бы я более серьезно подошел к делу, то результат был бы лучше, но и времени мне пришлось бы потратить больше (учитывая что новая работа мне ваще-т не нужна была). Я бы конечно хотел повторить этот опыт, только уже не для локальных аутсорс конторок, а FAANG, но как только представлю, сколько времени нужно будет потратить на подготовку, чтобы получть хоть один оффер из 10 попыток, всякое желание отпадает. Тем более что работать там я все равно не хочу.
Вы, конечно, правильные минусы выделили у собеседований, но если бы вы вместе со своим резюме скинули бы мне ещё и эту статью, то я бы вас к себе не взял. И даже не стал бы интервью проводить. Не из-за пробелов в знаниях, а именно из-за вашего отношения. Вы знали, на какую позицию идёте, при этом даже не удосужились подтянуть свои знания.

«Смогу выучить за пару месяцев» и подобные вещи — аргумент, но вот контр-аргументом будет то, что перед собеседованиями у вас было время это выучить, но вместо этого вы решили выехать на опыте, а потом уже как-нибудь доучить. Ведь далеко не все вопросы были ненужными и многие были достаточно фундаментальными по языку.

А уж имея такие пробелы и надеясь выехать на опыте, вдвойне удивительно, что вы даже не пытались сами показать то, что вы умеете, вместо этого в статье только и слышно, что не те вопросы вам задавали.

Просто с таким отношением есть высокая вероятность, что ваши интересы будут перпендикулярны интересам проекта и в долгосрочной перспективе не факт, что ваш вклад вообще будет со знаком плюс. И страдать от этого всего будет не только сама компания, но и люди, с которыми вам придётся работать.
Не из-за пробелов в знаниях, а именно из-за вашего отношения.

Я ходил на собесы по фану, и чтобы статьи потом написать (зацените предыдущие две).

Вы знали, на какую позицию идёте, при этом даже не удосужились подтянуть свои знания.

Ну че, на третий раз подтянул и оффер получил. Ez.

вместо этого в статье только и слышно, что не те вопросы вам задавали

Отличные вопросы мне задавали на позицию java техлида (я об этом написал), так шо нет, таки были хорошие собеседующие. Ruby ребята чот не порадовали, не барское это дело, на вопросы о синтаксисе отвечать, ну и ладно.

Просто с таким отношением есть высокая вероятность

Это уже менеджерское дело выяснять ))) Но любой человек при желании может давать социально приемлемые ответы и эту линию обороны тоже на изичах проскочить.

Вот я собеседовался на позицию Group Manager и там меня раскусили и не дали оффер )

Это если предполагать, что человек в активном поиске на конкретный стэк. А если просто откликается на прямые предложения или всё равно какой стэк, то подготовить теорию по всем возможным проблематично.

можно увидеть решение задачки each_slice по первому собеседованию? и что там с индексами в итераторах — где прочитать про это?
можно увидеть решение задачки each_slice по первому собеседованию?

Собес был еще в октябре (полгода назад), кодерпад я потерял, да и код там тривиальный.

и что там с индексами в итераторах — где прочитать про это?

Не знаю, наверное в учебнике ))) Я просто запустил код в repl и протестировал как он работает. Что-то вроде

for i in 0..5
   puts "Value of local variable is #{i}"
   i = i + 1
end


Выведет не 0, 2, 4 а 1, 2, 3, 4, 5

Школьный вопрос какой-то на самом деле )))
UFO just landed and posted this here
Чтобы подвинуть «окно» итерации для each_slice. Надо было через while делать но я затупил, вот и все.

Это не переменная цикла, а item в массиве.
И вроде в большинстве языков с for each его модифицировать нельзя.
P.S.: На ruby никогда не писал.
Жалко, что C — style for не существует во многих языках. Приходится разбираться, как выполнять элементарные операции, типа получить текущий индекс или перезаписать элемент массива.

за пару лет разработки на Ruby как-то и не вспомню, когда приходилось использовать for и приходилось ли вообще. А уже переменную менять…
Да наверное и реализацию each_slice или другого тривиального метода тоже нечасто нужно делать )))

Тут дело даже не в мутабельности. :)

Собеседования «на доске» очень полезны. Лично я, когда провожу собеседования, обязательно даю задачу, которую надо написать «без гугла». Желательно — на листке бумаги. Потому что когда человек пишет рукой на листке бумаги — у него нет возможности что-то легко поправить, где-то вставить строчку кода. Большинство это понимают сразу и сначала планируют решение, а потом уже его пишут. Я таким образом проверяю не способность кандидата (например) развернуть список, а оцениваю опыт написания кода в целом. Опытный разраб для простых задач сразу знает, сколько ему нужно переменных, какие циклы будут и т.п. — у него во время написания кода уже в голове цельная картинка и он её просто переносит на бумагу. А вот джун такой картинки не имеет — он по ходу додумывает решение, где-то что-то подправляет. Иногда джун даже не может удержать всё решение в голове (а это крайне важное умение для того, чтобы писать код без багов — иначе всегда будут пропущенные корнер-кейсы). К слову, для решения задач на бумаге я никогда не даю что-то «головоломистое» — только базовые вещи, чтобы senior писал «от руки» решение за пару минут.
Представляю сколько толковых кандидатов вы из-за этого потеряли!
Если честно, не очень понимаю — каким образом? Это не риторический вопрос, мне действительно интересно мнение.
На мой взгляд — толковый кандидат легко напишет на бумаге нужный код. Или я что-то упускаю?
Я лично знаю жестких типов (отличных разработчиков), которые после предложения написать код на бумажке просто встанут и уйдут :)
и это кстати очень хорошо. они и свое время таким образом сэкономят, и время команды интервьюеров. еще лучше было бы, если бы эти мега-парни еще у рекрутера догадались спросить о формате интервью и вообще не приходили бы.

Почему бы не написать об этом в вакансии и сэкономить время всем сторонам, включая рекрутера?

Это говорит об их невоспитанности, а не о профессионализме. Неужели так неожиданно, что при собеседовании на должность программиста просят написать программу?

Насколько я понимаю, этим жёстким типам никогда не хотелось попасть в такие организации, как Microsoft, Google, Яндекс и т.п. (если речь идёт про SWE).
Неужели так неожиданно, что при собеседовании на должность программиста просят написать программу?

Ваще-т да, у нас как-то уже давно такое не практикуют. Да и все собесы почти проходят по скайпу, там есть repl.it/coderpad/шаринг экрана

Microsoft, Google, Яндекс

Да, у нас в Украине тухло с этими конторами ((( Только тупой аутсорс, только галеры.
Это говорит об их невоспитанности, а не о профессионализме. Неужели так неожиданно, что при собеседовании на должность программиста просят написать программу?

Просить писать программу на листочке — это хамство. В том, чтобы встать и уйти, если тебе нахамили — ничего невоспитанного нет.

И много ли вы раз так вставали и уходили с интервью в мировых организациях?
чтобы встать и уйти с интервью «в мировых организациях», как вы их назвали, надо, чтобы на это интервью сначала позвали.
Ровно об этом я и подумал, но решил не писать, т.к. прозвучало бы слишком резко, а я и так вон уже минусов нахватал =)
А так — да, судя по всему многие «комментаторы» не дотягивают по уровню, оттого и не понимают, зачем всё это нужно.

А какая разница, мировая или не мировая? Если тебя оскорбляет представитель мировой компании — то он типа "право имеет" или как?

в чем оскорбление заключается? в том, что они хотят какие-то вещи проверить перед приемом на работу? есть стандартный процесс собеседования в эти «мировые» компании, который всех там работающих не оскорбляет, а вас почему-то оскорбляет.
в чем оскорбление заключается?

Человек пришел устраиваться программистом, а ему предлагают заниматься цирковыми номерами.


есть стандартный процесс собеседования в эти «мировые» компании

Но ведь в этом стандартном процессе никаких задач на листочках нет.

что значит нет? почитайте, как устроено интервью в топ 5 мировых софтверных компаний. не на листочке, а на доске. но суть та же. в последнее время некоторые по желанию стали давать компьютер, где писать надо в ноутпэде (если повезет, с подсветкой синтаксиса).
встать и уйти


Если есть возражения против такой формы собеседования, вежливо скажите об этом интервьюверу. Вставать в позу или обижаться — это не серьезно и просто не профессионально. Более непрофессионально, чем попросить написать программу на листочке.

Так одному кандидату не понравилось, что попросили написать SQL запрос на листочке — он «встал и ушел». Второму не понравилось, что спросили теорию, он встал и ушел. Третьему не понравилось, что спросили, чем не нравится текущее место работы — он встал и ушел.

Завтра этому же кандидату уже на рабочем месте что-то не понравится и он, вместо того, чтобы объяснить свою позицию, «встанет и уйдет».
Завтра этому же кандидату уже на рабочем месте что-то не понравится и он, вместо того, чтобы объяснить свою позицию, «встанет и уйдет».

Что же он, по-вашему, должен делать, если настолько не нравится? Сидеть там до пенсии, которой не будет, или умных жизни учить?
Есть мнение, что лучше сначала говорить, что не нравится, а уходить только когда ожидаемой реакции нет за разумное время.
И вы остались без работников.

Слышал такое мнение: Если человек хорошо пишет на листочке, то это либо студент, либо профессиональный ходок по собеседованиям.

Со студентами-олимпиадниками есть отдельная проблема: они очень хорошо пишут код на листочке, решают алгоритмические задачки на раз и вообще влёт проходят типичные «гугл-фейсбук-эппл»-собеседования. Для таких товарищей есть секции по архитектуре и проектированию. Жаль, не во всех организациях при приёме эти секции проводят (я не про отдельную встречу на час-два, а хотя бы рассуждения минут на 15).

Ну и студентов настолько больше, чем молодых senior-разрабов, что обычно если видишь молодого парня, бодро пишущего код от руки, то вывод (изредка неверный) сам напрашивается, это да.
мы недавно взяли такого олимпиадника. причем, не просто олимпиадника, а тренера одной из азиатских олимпийских команд. но взяли на entry-level позицию. и вроде как и с настоящей работой справляется. секции на дизайн и архитектуру проводят в зависимости от уровня, на который кандидата рассматривают. чем выше уровень, тем больше внимания этому уделяется. на начальные позиции легко можно пройти, просто умея решать задачи.
Вопрос в том, что ожидается увидеть. Если готовое рабочее решение — то да, именно так. А если базу, от которой можно потом говорить, дорисовывать и так далее, то уже не важно что написано на листочке вначале, важно куда это всё придёт.
Ожидается увидеть то, как человек подходит к написанию кода. Ни разу ещё не было такого, чтобы опытный разработчик после прослушивания задачи сразу начал её писать. Обычно идёт несколько вопросов, размышление/обсуждение, строится решение, продумываются корнер-кейсы и после этого быстро пишется код на бумаге. У джунов (и некоторых мидлов) обычно происходит иначе.
на самом деле часто встречается такое, что у людей совсем без знания алгоритмов на ровном месте появляется лишняя квадратная асимптотика, которая всплывает только ближе к проду. Плюс людям без знания алгоритмов сильно сложнее объяснить в чем именно тут проблема. Даже в примере, который привел автор, он решил задачу какими-то вложенными циклами (уже скорее всего квадрат), хотя она решается одним проходом со словарем всех встреченных значений и их индексов
Даже в примере, который привел автор, он решил задачу какими-то вложенными циклами (уже скорее всего квадрат), хотя она решается одним проходом со словарем всех встреченных значений и их индексов

Без озвучивания ограничений ваше «даже» абсолютно бессмысленно. Вы экономите циклы, расходуя память — что, очевидно, возможно только тогда, когда у вас есть память, которую можно потратить.
в задачах конечно можно давать ограничения, но в том и дело, что в реальной жизни эти ограничения часто обнаруживаются поздно (конечно хорошо, когда программист знает ограничения предметной области и они не собираются меняться) и нужно сразу писать более менее оптимально (в разумных пределах и не особо ухудшая код). Ну и да, экономим циклы, расходуя память, но
1) память также расходуется линейно, а не квадратично
2) в подавляющем большинстве случаев, память дешевле вычислительной мощности и легче масштабируется
Вы экономите циклы, расходуя память

Нет, словарь всех встреченных индексов занимает примерно столько же, сколько строка с промежуточным найденным значением у автора.
И память можно оценить — сколько там символов в юникоде? Случай, когда сотни килобайт нет но есть секунды а то и минуты на исполнение, ИМХО, не совсем типичен.
Толковый разработчик в спокойном состоянии может писать хороший код. Во время интервью большинство людей испытывают стресс, то есть уже не так продуктивны как могли бы быть. Помимо этого сам ход интервью может выбить из колеи. Да и в отличии от IDE на бумаге вставлять.

Очень сложно писать код без привычных инструментов, с сильным стрессом, без права на ошибку. Хороший девелопер может не написать код, а может и написать. Разве нужна эта лотерея? Давать для вайт боард кодинг можно лишь простейшие задачи(fuzz bizz, проверка строки на палиндром) для проверки, а умеет ли кандидат вообще писать код, в принципе?
Хороший девелопер может не написать код, а может и написать. Разве нужна эта лотерея?

Дак если бы был способ надёжно, без лотереи, узнать уровень кандидата — все бы им пользовались.

Давать для вайт боард кодинг можно лишь простейшие задачи(fuzz bizz, проверка строки на палиндром) для проверки, а умеет ли кандидат вообще писать код, в принципе?

Согласен, именно о таких задачах я и писал. У меня личный критерий отсечения «сложных» задачи — попросить коллегу-мидла на обеденном перерыве накатать решение. В спокойных условиях, за чашечкой чая. Если за 10 минут не вышло — задача плохая, т.к. при стрессе вперемешку с обсуждениями и мыслями вслух, кандидат будет писать её минут 40.
Такой способ есть — поговорить про прошлый опыт, про то, какие задачи решал, чем пользовался и так далее. Если со слов опыт релевантный — брать на испытательный. Это лучший вариант узнать, подходит ли тебе кандидат. Другое дело, что далеко не все конторы до этого додумались, более того — это лишняя нагрузка на отдел кадров, но имхо это лучше, чем набрать черти кого по задачам на листочке, а потом думать что с ними вообще делать.
Вообще программиста берут на работу не разговаривать, а программы писать. :) Поговорить — это софт-скилл, важный но недостаточный.
То есть вы правда считаете, что программист с большей вероятностью напишет код на листочке под прессингом интервьюеров, чем расскажет о том, чем занимался на прошлой работе? Рассказать про опыт — это не софт-скилл даже близко.
Я считаю, что способность написать код на листочке под прессингом интервьюеров больше коррелирует со способностью писать код в IDE под прессингом начальства/команды/сроков и т. п., чем способность рассказать о своём (предположительно, но не факт) опыте под тем же прессингом.

Это навык самопрезентации — главный, пожалуй, из софт-скиллов на собеседованиях, аттестациях и прочих разговорах об условиях сотрудничества. Сильно вам поможет «Чем занимался? Задачи делал. Какие? Разные. На каком стеке? В резюме написано. Что сложного было? Ну за неделю до годового релиза пришли новые требования, из-за которых пришлось неделю по 16 часов всё переписывать»

Ох, да ну вы серьезно? Часто над вами стоит ваш начальник и менеджер и смотрит что вы там делаете, когда вы пишете код? Если да, и вы все еще работаете в этом месте — то это какая-то ваша личная профдеформация, так быть не должно.
Прессинг не только в виде пристального взгляда может быть.
Может быть, а может и не быть. Взгляда, или не взгляда. А на «бумажном» интервью он будет точно, и это точно будет взгляд. Чуете разницу?
Человек может не уметь хорошо работать в стрессе, это нормальная ситуация. А вот если в компании столько этих стрессовых ситуаций, что нужно проверять работоспособность кандидата в стрессе — это вот уже как раз совсем не нормально.
Ну пару раз мне давали занятия на бумаге, оставив одного и объяснив правила типа «названия функций/методов не бойся написать неправильно, если уж совсем не помнишь, то просто дай название, синтаксис тоже поскольку постольку, считай вообще что псевдокод пишешь». Так что тоже может быть, а может не быть.
Сильно вам поможет «Чем занимался? Задачи делал. Какие? Разные. На каком стеке? В резюме написано. Что сложного было? Ну за неделю до годового релиза пришли новые требования, из-за которых пришлось неделю по 16 часов всё переписывать»

Уточняем по одной (наиболее запомнившейся) задаче, и поехали дальше вглубь до примененных решений, а там и до уровня кода можно в отдельных местах копнуть? Не?
Про жизненные случаи и то, как писался или не писался код — кандидат и сам очень даже расскажет, если его немного «разговорить» перед этим.

Или у вас вызывает сопротивление то, что в этом случае вы остаётесь без бинарного результата (написал код на бумажке / не написал)? Так вы не экзаменатором должны работать, а собеседующим. Экзаменаторство прокатит в школе и в ВУЗе (и по этим же причинам оно более-менее сгодится для джунов без опыта).
вы остаетесь вообще без понимания того, как кандидат подходит к написанию кода — все в кучу или разбито на функции, использует ли синхронизационный примитив или влепит спин-лок, как и в каком порядке подойдет к решению составляющих частей (начнет ли с самых важных кусков, обозначив утилити-функции только названиями или станет ковыряться в малозначащих вещах), как он подойдет к поиску ошибок, которые с большой вероятностью будут в коде. результат далеко не бинарный, результат дает множество данных о способностях кандидата.
Код или схема на бумажке для меня как раз предмет обсуждений (с обеих сторон баррикад), а не бинарный результат.
Другое дело, что далеко не все конторы до этого додумались

Когда у вас поток по 2-3 кандидата в неделю, то оказывается, что дело не в «конторы не додумались». В крупных организациях на 1000+ разрабов поток бывает и по 10 кандидатов в неделю.
Меня бы это сбило с толку хотя бы потому, что у меня жуткий почерк и я со школы ничего не пишу от руки. Это примерно как выполнить задание, стоя на голове.
Меня бы это сбило с толку хотя бы потому, что у меня жуткий почерк и я со школы ничего не пишу от руки.

Почерк практически у всех плохой — это норма. Если что-то написано непонятно — интервьюер уточнит (а что ему ещё остаётся).

Это примерно как выполнить задание, стоя на голове.

Интересное сравнение, надо бы запомнить.
Не писал кода на бумажке лет эдак 20 и не планирую начинать.
Последний раз это был ассемблер для ZX Spectrum. Там это было оправдано необходимостью получения на той же бумажке соответствующего списка машинных кодов для прямого вбивания в память в отсутствии подходящих высокоуровневых инструментов.

Было бы здорово, если бы Вы включали Ваши предпочтения по вайтбордингу и бумажкам в описание вакансии. Сэкономили бы кучу времени себе и таким противникам извращений как я.
Было бы здорово, если бы Вы включали Ваши предпочтения по вайтбордингу и бумажкам в описание вакансии. Сэкономили бы кучу времени себе и таким противникам извращений как я.

В описании вакансии этому не место, но рекрутер всегда предупреждает потенциальных кандидатов об этом.
Как раз таки место, просто вы понимаете, что после этого к вам никто не придет на чудесное собеседование, поэтому и тяните до последнего. Если бы это было круто и правильно — об этом говорили бы сразу, но вы прекрасно понимаете, что с этим «что-то не так».
Как раз таки место

В тексте вакансии я хочу узнать о самой работе, о функциях, обязанностях и т.п., а не о процессе найма.

просто вы понимаете, что после этого к вам никто не придет на чудесное собеседование

Каким же тогда, по-вашему, образом в Google и Facebook работают тысячи программистов, если «никто не хочет на такие собеседования ходить»? Может проблема в ваших представлениях о том, что должен уметь скилловый разраб?

поэтому и тяните до последнего

Вы намеренно проигнорировали слова о том, что рекрутер всегда предупреждает человека?
В тексте вакансии я хочу узнать о самой работе, о функциях, обязанностях и т.п., а не о процессе найма.

А процесс найма это тоже «о компании».

Каким же тогда, по-вашему, образом в Google и Facebook работают тысячи программистов

Собеседовался в гугл и яндекс — писал код клавиатурой. Большие компании инертны и дольше переходят на нормальные способы. Ваше «думание перед тем как написать на листочке» от создателей «писать реферат от руки чтобы запомнилось» — это пережиток прошлого, в этом нет ни романтики, ни смысла. Гипербола — заставляйте писать код на бересте — там цена ошибки выше.

Вы намеренно проигнорировали слова о том, что рекрутер всегда предупреждает человека?

Я был бы рад, если бы информация о процессе собеседования была в вакансии, это просто личная хотелка, посыл был совсем не в этом предложении.
«писать на листочке» — это обобщающее определение, означающее, что IDE использовать не дадут. это может быть доска, листочек, простенький текстовый редактор. гугл дает на выбор редактор с подсветкой синтаксиса (без возможности запустить код) или доску. многие дают сейчас такой выбор. некоторые уже даже позволяют запускать IDE (но не из top 10 компаний), хотя все еще есть места, где предпочитают маркер и доску.
zuko3d:
Лично я, когда провожу собеседования, обязательно даю задачу, которую надо написать «без гугла». Желательно — на листке бумаги. Потому что когда человек пишет рукой на листке бумаги — у него нет возможности что-то легко поправить, где-то вставить строчку кода.

Так в том-то и дело, что человек не про обобщение говорит, а про прям листочек, именно к этому притензия.
Пока что я увидел фразу «пережиток прошлого» и ни одного конструктивного аргумента против. О том, что нет смысла — я уже написал, какой в этом смысл и эта практика даёт плоды.

Буду рад прочитать конструктивные аргументы против такого подхода.
Хотите конструктива, его есть у меня:
1. Например, я хочу сперва решить основную задачу, а потом сосредоточиться на деталях. Что я делаю в редакторе?
def spam():
    pass

def egg():
    pass

def solve():
    ...
    spam()
    ...
    egg()


И после того как разберусь с solve(), я вернусь к spam() и egg(). Как реализовать это подход на листочке? Оставлять место? Продумывать заранее?

2. Мне нравится итеративный подход, я «думаю кодом», я использую редактор как буфер мыслей, постоянного меняю код, выделяю методы если вижу в них необходимость и т. д., тут ваш листочек тоже не позволит это сделать, извольте сразу писать правильно.

3. Меня на собеседованиях иногда просили модифицировать решение, добавить А или Б фичи, с листочком вы тоже лишаете себя этой возможности.

4. Когда человек пишет решение в редакторе под присмотром интервьюера, второй может наблюдать за ходом мысли, как и что он исправляет и меняет, что вы увидите в случае листочка? Правильно, как человек сидит и смотрит в одну точку.

5. Писать код от руки непривычно, человек уже под стрессом и в неудобной обстановке, так вы еще добавляете один фактор, который мешает, не получая преимуществ кроме вымышленных «думает, перед тем как написать» (wat?).

Итого: собеседование на листочке подходит только для эгоистичных интервьюеров, которые рассматривают собеседования как проверку кандидата на прочность в экстренных условиях, в которых ему не придется работать, а не как равный диалог о будущем кандидата в компании.
Как реализовать это подход на листочке? Оставлять место? Продумывать заранее?

Писать spam и egg после solve :-)

Немножко демагогия, но ладно.
Во-первых, если мы про Python, то это синтаксически неправильно.
Во-вторых, во время работы над solve я хочу видеть сигнатуру методов, при этом писать их после solve я не могу, потому что не знаю какой длины будет solve.
В любом случае, посыл не про это :)
А почему неправильно-то?

С сигнатурой сложнее, но можно сделать так: написать заглушку, использовать её, потом зачеркнуть заглушку и написать реализацию.
А почему неправильно-то?

Ну потому что методы должны быть объявлены до использования, иначе «name 'egg' is not defined»

но можно сделать так

А можно взять редактор и не делать людям мозг -_-

Вот только использование происходит когда основная функция выполняется, а не когда она объявляется.


Если взять вот такой код:


def foo(): #1
    bar() #4

def bar(): #2
    pass #5

foo() #3

То окажется, что сроки кода выполняются в порядке 1-2-3-4-5, а функция bar используется строго после своего объявления.

Согласен, но в вашем примере будет
def solve():
    egg()
    spam()

def spam():
    pass
def egg():
    pass

Что работать не будет.

Блин, ну возьмите и проверьте уже!


Вот чем ваш пример от моего отличается? Тем, что функций две вместо одной? Или именами? Вы уверены, что это что-то меняет?

Я немного запарился, извиняйте, у вас все норм, но еще раз, я говорил совсем не про это, я говорил про удобство редактирования.
P.S. я говорил про такой вариант.
Спасибо, конструктив понравился! Если есть ещё — пишите.

И после того как разберусь с solve(), я вернусь к spam() и egg(). Как реализовать это подход на листочке? Оставлять место? Продумывать заранее?

Я в таких случаях просил дополнительные листы бумаги и на каждом отдельном листе писал конкретную функцию. В случае с доской это сложнее — обычно делил её на несколько частей.

2. Мне нравится итеративный подход, я «думаю кодом», я использую редактор как буфер мыслей, постоянного меняю код, выделяю методы если вижу в них необходимость и т. д., тут ваш листочек тоже не позволит это сделать, извольте сразу писать правильно.

Хочется проверить размер этого буфера. Я почти уверен, что вы в голове не одну строчку держите, а некий блок кода. И чем больше этот блок — тем лучше. Сначала я даю задачу типа «найти максимальный элемент». Кстати, даже с этой задачей уже не все кандидаты справляются (это было для меня открытием). Ну и потом по нарастающей. Есть кандидаты, которые BFS пишут с ходу (не олимпиадники).

3. Меня на собеседованиях иногда просили модифицировать решение, добавить А или Б фичи, с листочком вы тоже лишаете себя этой возможности.

Да, согласен. За всё приходится платить =) Но, если честно, у меня обычно не возникает желание модифицировать задачу по ходу.

4. Когда человек пишет решение в редакторе под присмотром интервьюера, второй может наблюдать за ходом мысли, как и что он исправляет и меняет, что вы увидите в случае листочка? Правильно, как человек сидит и смотрит в одну точку.

Это только в теории. На практике происходит иначе: начиная с мидлов — люди общаются и обсуждают своё решение. По крайней мере, на моём опыте именно так бывает. Если человек сидит и смотрит в точку — либо что-то идёт не так и надо задавать наводящие вопросы, либо человек в раздумьях и он так же сидел бы перед IDE.
С джунами чуть сложнее (они не привыкли проговаривать вслух ход мыслей), но там обычно нет смысла человека мурыжить задачами, достаточно просто пообщаться, т.к. у джуна всё равно опыта особого нет — важно чтобы хотел обучаться и работать.

5. Писать код от руки непривычно, человек уже под стрессом и в неудобной обстановке, так вы еще добавляете один фактор, который мешает, не получая преимуществ кроме вымышленных «думает, перед тем как написать» (wat?).

Так, писать от руки непривычно — согласен, это действительно проблема. А какой фактор добавляю? Не понял.

Итого: собеседование на листочке подходит только для эгоистичных интервьюеров, которые рассматривают собеседования как проверку кандидата на прочность в экстренных условиях, в которых ему не придется работать, а не как равный диалог о будущем кандидата в компании.

Не-не-не, никакой проверки на прочность. Интервью это стресс в любом случае, согласен. Но при чём тут эгоизм? Обычно у меня с кандидатом равный и достаточно свободный диалог (люди порой могут посмеяться над чем-то, или порассуждать на отвлечённые темы — это расслабляет), да и почти все собеседования, в которых мне надо было писать код на бумаге/доске тоже проходили вполне комфортно и я не чувствовал, что со мной общаются «свысока».

а не как равный диалог о будущем кандидата в компании.

Всё же техническое интервью — это не диалог о будущем, а проверка знаний и калибровка уровня кандидата. Диалог о будущем — это к HR'ам.
Сначала хотел ответить по пунктам, но мне уже лень, извиняйте =)
Коротко:
1. Заставлять писать кандидата на листочке — неуважение к нему, я не хочу работать в компании, которая изначально меня не уважает.

2.
проверка знаний и калибровка уровня кандидата

Вот здесь у нас главное отличие, именно этой фразой вы ставите себя как компанию выше кандидата, это не калибровка кандидата, это взаимная проверка соответствия, двусторонняя, а не опыты над обезьянкой. И именно в этой позиции эгоизм, вы не обращаете внимание на то, как удобней будет кандидату.

3. Чем листочек лучше редактора с подсветкой? Хоть одна «конструктивная» причина?

P.S. А по поводу вашего «сужу по опыту» у вас нет бОльшей части картины мира, поэтому выводы делать не очень дальновидно. Если бы провели 10000 интервью и половина из них была с листочком, а половина нормальных и вы могли бы снять все метрики — тогда да, ваш опыт что-либо значил, а пока вы выдаете желаемое за действительное, опираясь на дисбалансные данные и личные ощущения, а тут «здравствуйте» систематической ошибке выжившего, ложной корреляции и другим классным штукам.
Вот вы считаете, что неуважение, а другие не считают. И могут считать, что кандидату так должно быть проще, чем дать IDE, но тогда и требовать работающий код.
Этот разговор начинает затягиваться по непонятным для меня причинам.

В основе моей позиции простейший постулат и я искренне не понимаю как можно считать по-другому:
Программист работает на клавиатуре, не на листочке, значит, и проверять его надо на клавиатуре, на привычным инструменте, а не заставлять забивать гвозди дрелью. Здесь не противопоставление листочек — IDE, здесь противопоставление ручка — клавиатура.
Смотря что проверять. Далеко не всегда целью этапа «напиши код на бумажке» является проверка способности писать код на клавиатуре. Или является, но не единственной целью.
Извините, но я не совсем понимаю, о чем вы.
Вы, похоже, исходите из предпослыки, что целью задания «напиши код на бумажке» является проверка способности работать на клавиатуре. Но это не всегда так.

С другой стороны, по личному опыту было несколько собеседований, которые я провалили, потому что требовали писать на клавиатуре.

Вроде норм, да? Но я это счёл тестом на стрессоустойчивость: дали ноутбук с незнакомой клавиатурой (кажется отсутствовали клавиши Ctrl и Alt), незнакомой ОС, незнакомой IDE и, как добивающий, без мыши.
Я не исхожу из этой предпосылки, я лишь говорю, что проверка программиста на клавиатуре более репрезентативна, чем на листочке.
Собеседование на программиста не должно быть тестом на стрессоустойчивость, оно должно быть собеседованием на программиста =)
Если работа предполагает стрессы, то проверка на стрессоустойчивость должна входить в собеседование. С одной стороны. С другой, предоставить привычное окружение программисту не всегда возможно за разумное время, а в непривычном это может быть стресс посильнее «бумажки».
В тексте вакансии я хочу узнать о самой работе, о функциях, обязанностях и т.п., а не о процессе найма.

Одно другому не мешает же, просто одна дополнительная строчка. Про тестовые задания в вакансии часто пишут, а это процесс найма. Вакансия сама по себе часть процесса найма.

А вы программист?
Если нет то, то я поясню как сейчас пишется программа.
В IDE начинаешь писать «for» затем выбираешь из списка подсказки оператор/функцию/переменную…
затем IDE за тебя добавляет нужные скобки, кавычки, точки и т.д.
Откуда у программиста детальное знание синтаксиса? а главное зачем оно ему? Интервью проходить?

У сеньеров в голове 10-20 языков, причем многие похожи.
Лично я не помню синтаксис создания классов и даже енумов. И не парюсь по этому поводу — это меньше 1% кода? причем стандартного и ошибиться там нельзя — IDE подскажет. Так зачем мне это помнить?

>то крайне важное умение для того, чтобы писать код без багов
Может для уровня джюниор?

На уровне сеньера баги совсем совсем другие:
Не верно продумал архитектуру базовых классов, из-за этого при сотом изменении ТЗ приходится делать костыли.
Не так срабатывает удаление объектов, так как по мере разработки сильно поменялась их передача и создание. А «умные» подсказки про shared_ptr вызывают улыбку.
И т.д.
А вы программист?

Да, программист. Опыт более 10 лет, успел поработать в нескольких крупных (5000+) айтишных организациях, сейчас я Senior SWE в одной из них.

Откуда у программиста детальное знание синтаксиса?

Вы же каждый (рабочий) день код пишете — как иначе?

У сеньеров в голове 10-20 языков, причем многие похожи.

На кой чёрт нужно в одном проекте 10 языков? Это же зоопарк технологий, который нереально поддерживать. На своём опыте в успешных проектах видел не болоее трёх языков одновременно. При этом ни разу не было такого, чтобы один разраб коммитил сразу на всех трёх языках.

Так зачем мне это помнить?

И правда — зачем?.. Я, кажется, писал о том, что придираться к запятым и потерянным скобкам — глупость, мы таким не занимаемся.

На уровне сеньера баги совсем совсем другие:
Не верно продумал архитектуру базовых классов

Согласен, что баги другие. Но как, по-вашему, человек продумает архитектуру сложного объекта, если он даже не может в голове удержать простую программу? Или вы считаете, что каким-то волшебным образом можно решать сложные задачи не умея решать простые?
На своём опыте в успешных проектах видел не болоее трёх языков одновременно. При этом ни разу не было такого, чтобы один разраб коммитил сразу на всех трёх языках.

У меня прямо щас проект где ехал микросервис через лямбду и там используется Java, Python, Node.js, горы скриптов на баше и немного Ruby, на фронте реакт. Я коммичу во все места )))

И есть еще один где PHP, Java, Ruby, лямбды на node.js и работа с OpenCV на питоне. Тоже коммичу во все )))
Ваш проект приносит много денег? Стабильно ли он работает, легко ли проходят релизы? И при этом он уже много лет на рынке?
Кажется, на большинство вопросов ответ будет «нет».
Ваш проект приносит много денег?

достаточно, чтобы спонсировать дальнейшую разработку

Стабильно ли он работает

конечно

легко ли проходят релизы

ваще изи, вы наверное не слышали про такую штуку как CI/CD, да?)))

И при этом он уже много лет на рынке?

define много? Три года — много или мало?

Кажется, на большинство вопросов ответ будет «нет».

Когда кажется, сами знаете, что надо делать. Не стоит натягивать привычную вам картину на весь остальной мир.

То, что вы не работали с чем-то, или не видели чего-то, не значит, что другие не работают с этим или не делают. Если вы не видели больше 3х экосистем в рамках одного проекта — это значит лишь то, что вы просто не принимали участия в таких проектах, но не значит что таких проектов нет вообще, или они какие-то плохие.
> На кой чёрт нужно в одном проекте 10 языков?

У многих нет одного-единственного проекта на всю жизнь.

> При этом ни разу не было такого, чтобы один разраб коммитил сразу на всех трёх языках.

Если SQL, HTML и CSS считать за языки, то и 6+ на одного может легко набраться на одном проекте.
Если SQL, HTML и CSS считать за языки, то и 6+ на одного может легко набраться на одном проекте.

Кстати да! А еще есть серверный js и клиентский ))) Тогда у меня легко десяточка будет )))
Или клиентский ts и серверный js :)
В IDE начинаешь писать «for» затем выбираешь из списка подсказки оператор/функцию/переменную…

А на JavaScript IDE напишет for..in или for..of? :)
Вообще я с Вами в целом согласен, просто забавно. Тут скорее не очень удачное решение, сделать два очень похожих иногда разных варианта цикла.
Детальное знание синтаксиса нужно хотя бы для того, чтобы быстро и полностью понимать чужой код.

Это ложное утверждение. Языки похожи, и чтобы понимать код, надо знать основные концепции, а каким синтаксисом они записываются в конкретной версии языка не имеет значения. Кроме того, этот код уже написан и синтаксис у него заведомо правильный. Поискать в документации, что означает вот этот оператор, не составляет никакой проблемы.


Нет, серьезно, вы правда считаете, что никто не сможет понять, что означает "x = a + b", если в языке, которым он обычно пользуется, в конце надо ставить точку с запятой? Или что "fun powerOf(number: Int, exponent: Int) { ... }" объявляет функцию?

Так кажется тем, кто привык к простым языкам, вроде Java или Python. Мне как-то на собеседовании дали несколько задач на наследование C++, и я почти все их решил неправильно. Хотя написал десятки тысяч строк объектного кода на C++. Просто не знал ряда семантических нюансов, ведь современная ANSI спецификация C++ — это около 3000 страниц. Если бы такие конструкции попались мне в код ревью, я бы не смог его сделать как следует.
Мне как-то на собеседовании дали несколько задач на наследование C++

Мне кажется, такие задачи в реальном коде решаются просто запуском кода. Запустили и проверили, что вызывается.


"Детальное знание синтаксиса нужно" и "спецификация C++ — это около 3000 страниц" это сильно разные вещи. Возможно, для код-ревью именно на C++ надо знать чуть больше синтаксиса, чем в других языках, но принципиально это ничего не меняет.

Предлагаю рассказать, что делает вот этот (между прочим, очень полезный и важный) класс и привести аналогичный пример из питона, джавы или что там нынче популярно:

template<typename Ret, typename ...Args>
class Function<Ret(Args...)>
{
    using FunctionPointerType = Ret (*) (Storage, Args...);
public:
    template<typename Callable>
    Function (Callable callable) noexcept
    {
        m_func_ptr = &trampoline<Callable>;
        new(reinterpret_cast<Callable *>(m_data)) Callable(callable);
    }

    Ret operator() (Args ...args) const
    {
        return (*m_func_ptr)(m_storage, std::forward<Args>(args)...);
    }

private:
    template<typename Callable>
    static Ret trampoline (Storage storage, Args ...args)
    {
        Callable const *c = reinterpret_cast<Callable const *>(m_data);
        return (*c)(std::forward<Args>(args)...);
    }

    FunctionPointerType m_func_ptr;
    alignas(alignof(std::max_align_t)) char m_data[FunctionStorageSize];
};


В этих 30 строках кода используется сразу несколько редких фич языка, и без них этот код не стал бы рабочим и полезным.

Некая обертка для вызова функций. Желательно конечно пример использования посмотреть, в реальном коде это можно сделать.


... означает список аргументов неопределеной длины, это понятно даже по названию типа.
new(m_data) видимо присваивание, раз выполняется в конструкторе.
alignas() скорее всего связано с платформозависимым выравниванием данных.
std::forward() видимо какая-то оптимизация, связанная с особенностями C++, это уже не синтаксис, а стандартная библиотека.


Чтобы просто понять, что делает код, достаточно базовых знаний синтаксиса C++ — указатели, шаблоны.
Для более детального понимания, например с целью изменить код чтобы он работал по-другому, надо поискать описание конструкций ..., reinterpret_cast, new(), std::forward(). Также надо знать про UB и как их избегать, это тоже уже не совсем синтаксис.
Конечно, джуниора на этот код нельзя ставить без присмотра, но разобраться и использовать, и даже изменить чтобы работало хотя бы в debug-режиме он сможет. Остальное подскажут на код-ревью, он запомнит, и в следующий раз сразу так будет делать.


Не знаю, как в Java или Python, в PHP это будет примерно так:


$func = [$this, 'someMethod'];
$args = [1, 2, 3, 4];
call_user_func_array($func, $args);
Проблема понимания чужого кода находится на уровень выше чем синтаксис.
А для того что бы понимать, что это строка объявление класса или енума, Детальное знание синтаксиса ненужно.
В целом, имел похожее представление о подобных задачах. Но недавно был на собеседовании в одну компанию, которая любит 4 часа писать код на доске и бумаге, и как-то резко поменял своё отношение к таким собеседованиям.
Из четырёх людей трое докапывались чуть ли не до запятой. Из часа, выделенного на общение с каждым, минут 35-40 я тупо писал и правил код без IDE, подсветки синтаксиса и даже возможности запустить творение.
Задачи, может быть, и интересный способ оценки, но в варианте «объяснить решение на пальцах». Если человек может объяснить решение — написать его в тепличных условиях ему не составит труда. А написание кода на бумаге тупо тратит время и повышает градус неадекватности.
Тоже встречался с таким (в качестве кандидата). В таких историях есть сильные косяки от интервьюеров:

Из четырёх людей трое докапывались чуть ли не до запятой

Я и мои коллеги-интервьюеры никогда не считаем это проблемой, т.к. ясное дело, что если человек пропустил точку-с-запятой в конце строки, то это либо от концентрации на самой задаче, либо от волнения. И то, и другое — вполне ожидаемо на собеседовании, так что лично я просто указываю кандидату, мол «запятую потеряли» — и даже не успеваю сказать где именно, а человек уже исправил. Если же интервьюер просто говорил «у вас программа работает некорректно» и ждёт исправления запятой — это косяк скорее интервьюера, нежели кандидата, т.к. таким образом ничего полезного не выясняется, а время (и нервы) тратятся.

минут 35-40 я тупо писал и правил код

Это вообще треш. Если решение занимает несколько листов А4 (ну или несколько исписанных досок) — это крайне плохая задача для собеседования. Вариант, что «кандидат настолько плох, что не догадался до короткого решения» я откидываю, т.к. головоломки с коротким и элегантным решением ничего полезного не проверяют. У задачи должно быть изначально видно либо короткое, либо эффективное решение.

Если человек может объяснить решение — написать его в тепличных условиях ему не составит труда.

А вот тут я не согласен. На личном очень неприятном опыте убедился, что есть люди, которые могут объяснить решение, но не способны написать рабочий код. То баги сажают, то не компилируется под какие-то платформы, то просто пишут код, который делает совсем другое. Давно (ещё когда не было опыта собеседования) по ошибке брал таких людей (мол, главное чтоб соображал, а код написать кто угодно сможет) и для организации это выходило очень дорого.
Я и мои коллеги-интервьюеры никогда не считаем это проблемой

Ну вот вы не считаете, а у большинства собеседуемых впечатление об упражнениях с бумажкой может быть именно таким, потому что им на пути всегда попадались «неправильные» собеседующие, а «правильных» днем с огнем не сыщешь. Поэтому у людей и горит от кода на бумажке.
в моей практике тоже не встречалось случаев, когда придирались к запятым. при этом я сам прошел десятки интервью и гораздо больше их провел. мы даем на выбор — писать или на доске, или на компьютере (не в IDE, но в редакторе с подсветкой синтаксиса). и примерно половина кандидатов-таки выбирает доску.

Если человек может объяснить решение — написать его в тепличных условиях ему не составит труда

почти в половине случаев люди, которые очень хорошо рассказывают про решение, не могли его вменяемо написать.
А на что ещё указываете? Синтаксис, названия классов, функций/методов и т. п.? В общем указываете, что код просто не запустится нормально не из-за алгоритмических ошибок?
Я не указываю, вообще пофиг. Лишь бы алгоритм был правильный.

Не понимаю, зачем бахвалиться незнанием основ языка? Я не специалист в Руби, но знать, как работает вызов метода, конечно надо. Как вы иначе поймете, что в каком случае вызывается?


Что касается "service objects", опять же странно недоумение автора. как можно не понимать таких элементарных вещей? Модель в RoR это обычно объект, соответствующий строчке в БД. Но часто нам нужно писать код, не работающий с БД вообще (условно, рассылающий письма, работающий с API итд), или код, работающий с несколькими разными моделями. Куда еще его помещать? В контроллер, может быть?


Статический анализатор не обнаружит нарушение принципов SOLID.


То есть автор каким-то образом ранее прошел собеседование, пролез без особых знаний, ничего нового не приобрел за время работы и винит в этом других.


Другой пример: если человек не понимает, например, как работает ActiveRecord и связи, то он может написать неэффективный код, слишком медленно работающий или создающий нагрузку на БД, с грубыми ошибками именно из-за незнания.


Наконец, про то, что вопросы не совпадают с тем, что приходится делать на работе. Чтобы давать "реальные" задачи, вас надо ознакомить с кодом проекта. Но он является коммерческой тайной, плюс вы вряд ли захотите тратить на это несколько дней, плюс у нас может не быть хорошей документации (так как ваши коллеги аналогично вам думают, что их код настолько гениален, что не требует пояснений). И сами рабочие задачи тоже могут быть длительными по времени, никто не захочет их решать. И более того, умение решать рабочие задачи мы увидим на испытательном сроке. Потому на собеседовании мы просто пытаемся из пришедших кандидатов отобрать самых ярких, с самым широким кругозором или хотя бы превышающих определенную планку.


И кстати, у многих кандидатов, даже с большим опытом, есть серьезные пробелы в знаниях. Банально: один толком не разбирается в нормализации или индексах в БД, другой не может описать примеры популярных уязвимостей в веб-приложениях, третий не понимает HTTP, и почти каждый 9 из 10 не пишет комментарии. Как вас вообще допускают код писать, ау?


Будь моя воля — я бы всех "вкатывальщиков" выкатил обратно — учить основы. Водителя не пускают на дорогу без сдачи экзамена по правилам безопасного вождения. Почему программистов без знания правил безопасного написания кода надо допускать на рабочее место? По-вашему, старший разработчик должен за вами бегать, перечитывать код и исправлять ошибки?


(если вы читаете эти строки, попробуйте мысленно без запинки и "ну… это когда..." рассказать про 5 самых популярных уязвимостей и объяснить механизм их возникновения. Если не можете — вы не годны)

зачем бахвалиться незнанием основ языка

Разжигать в комментариях! ))) Реакция публики очевидна — «ах как он посмел не знать синтаксиса, анафема!» и ожидаема. Статья получает больше просмотров, больше дискуссии, всем профит!

Кроме того, заметьте, что в итоге я всем советую заучить теорию и типовые вопросы чтобы не попадать в такие ситуации как я. Однако это не отменяет моего мнения что знание теории по большому счету ничего не значит.

То есть автор каким-то образом ранее прошел собеседование, пролез без особых знаний, ничего нового не приобрел за время работы и винит в этом других.

Ерунду написали :D И я никого не обвиняю.

Что касается «service objects», опять же странно недоумение автора. как можно не понимать таких элементарных вещей?

Я имел ввиду не концепцию а название. Концепцию я использую (хотя может быть и не совсем в таком виде каким ее видят авторы, когда модель остается вообще чистой, как в стандартных Java Spring/Hibernate приложухах), понятное дело, а то что оно так называется — не знал.

Я не специалист в Руби, но знать, как работает вызов метода, конечно надо.

Лол зачем? Это нужно раз в год, когда ты достаточно неаккуратен для того, чтобы назвать метод в классе словом send и потом удивляться, почему у тебя мистические баги вылазят.
Знать нужно не порядок вызова методов, а, например, порядок срабатывания хуков ActiveRecord, или хотя бы просто иметь представление о том, что это такое.

если человек не понимает, например, как работает ActiveRecord и связи, то он может написать неэффективный код, слишком медленно работающий или создающий нагрузку на БД, с грубыми ошибками именно из-за незнания.

Все верно, вот это — пример хорошего вопроса и постоянно возникающей рабочей ситуации. Но почему-то никто меня про это не спрашивал ))) А могли бы спросить, например чем отличается joins от includes, когда что использовать, как делать вложенные includes, как правильно писать валидации, что такое скоупы и так далее. Но чот никто не хотел (((

Если не можете — вы не годны)

Негоден для чего? Для вашей работы? Ну ок, пойду на соседнюю улицу оффера получать, там такой ерундой как секурити не заморачиваются ))) Годность или негодность определяет строго рынок а не комментаторы. Если рынку не нужны разрабы со знаниями тонкостей работы GC — никто не будет заморачиваться чтобы это учить просто так.

Вот, кстати, мне еще и показалось, что у вас требования по з/п высокие. Вы, как я понимаю, живете в Украине и там, может быть, другая экономическая ситуация, но у нас в России, на мой взгляд странно платить особо не выдающемуся знаниями или заслугами веб-программисту 5 000 долларов. За 2500-3000, если подольше поискать, как мне кажется, вполне можно найти специалиста, который хорошо знает и теорию и перечисленные выше в моем комментарии вопросы. Непонятно, зачем ему предлагать 5 000 :) Мы же не в Калифорнии, у нас тут минимальная зарплата вообще 11500 рублей (ок, в Москве побольше — 19 000). На 5 000 долларов, мне кажется, это должен быть уникум из команды Вконтакте или крутой специалист из Яндекса со знанием всего, что можно. Разве я не прав?


Ну и, конечно, хочется подбирать людей не с тягой к деньгам, а тягой к знаниям и любовью к решению сложных задач.


Вот еще ниже спрашивают про комментарии. Они должны быть не на доске, а в тестовом задании или в примерах своего кода, которые демонстрирует кандидат. Как без комментариев-то в вашем коду будут разбираться коллеги? Или вы об этом не задумывались? Не приспособлены к работе в команде?


как правильно писать валидации, что такое скоупы

Ну это же какие-то очевидные вещи, которые наверно описаны в мануале по фреймворку. На 5 000 наверно нужны навыки получше, чем умение пересказывать мануал.


Ну ок, пойду на соседнюю улицу оффера получать, там такой ерундой как секурити не заморачиваются

Ну вот мы еще и выяснили, что вас не беспокоит качество получающегося продукта.

Вот еще ниже спрашивают про комментарии. Они должны быть не на доске, а в тестовом задании или в примерах своего кода, которые демонстрирует кандидат. Как без комментариев-то в вашем коду будут разбираться коллеги? Или вы об этом не задумывались? Не приспособлены к работе в команде?

Есть красивая теория, о том, что хорошо написанный код в комментариях не нуждается. Теория эта вдребезги разбивается о реальную жизнь, однако многие в нее все же верят.
Есть красивая теория, о том, что хорошо написанный код в комментариях не нуждается.

Есть не менее замечательная теория о том, что комментарии — всемогущее средство, если код непонятен. Увы, по опыту, это только теория. Комментарии обычно живут в отрыве от кода и при его изменении их часто просто забывают поправить. В итоге комментарий описывает не то, что уже представляет код, и является, скорее, вредным, чем полезным. Хорошо написанный код и правда не нуждается в комментариях. На моей практике было очень мало реальных случаев, когда без комментариев прям совсем не обойтись. А если хочется написать комментарий к коду, который непонятен, то тут 2 варианта. Первый — код просто нуждается в рефакторинге и тут комментарий, ИТ как мёртвому припарка. Второй — сложная бизнес-логика, которую иначе не описать, кроме как снабдив сопровождающими описаниями. Заметьте, я сейчас не про докстринги, описывающие сигнатуры методов, а именно про комментарии в непонятном коде.

простой код, как правило, в комментариях не нуждается. а вот сложный код — как раз наоборот. как пример, комментарий нужен для предостережения следующего инженера от упрощения какого-то куска кода — с детальным описанием, почему не сделано просто. иначе может быть очень дорого чинить инцидент в проде, потому что кто-то улучшил какой-то кусок. кодбэйз гугла, например, полон комментариев. разумеется, нужна дисциплина, поддерживать комментарии в актуальном состоянии. но не пользоваться каким-то инструментом с объяснением «мы все равно им пользуемся неправильно» мне кажется странным.
> а вот сложный код — как раз наоборот.

Я об этом и написал, это как раз 1 случай, когда код нуждается в рефакторинге.

> как пример, комментарий нужен для предостережения следующего инженера от упрощения какого-то куска кода — с детальным описанием, почему не сделано просто.

Такие случаи конечно имеют место быть и там комментарии необходимы. Но если ваш код сплошь и рядом состоит из таких кусков кода, то это либо какой-то специфический проект, в котором иначе никак, и без комментариев вообще непонятно, как оно работает, либо вы реально что-то делаете не так, если ваш код сплошь настолько сложный, что без комментариев в нем не разобраться.

> кодбэйз гугла, например, полон комментариев. разумеется, нужна дисциплина, поддерживать комментарии в актуальном состоянии.

Кодбейз гугла разрабатывается уже не первый десяток лет, разрабатывают его инженеры с разным уровнем опыта и скорее всего там достаточно легаси, закладок на обратную совместимость, нестандартную оптимизацию и прочее. Никто не спорит, что если такие вещи явно не описать комментариями, то там все легко сломать.
Но мы ж про простой код говорим) И про среднестатистические проекты, где таких мест, как правило, не очень много. Я хочу быть понятым правильно, я не против комментариев там, где без них реально не обойтись. Я против комментариев, которые представляются, как возможность описать код, который нужно переписать. Если код нельзя переписать, конечно пишите комментарий. Но, повторюсь, в моей практике таких случаев было не так уж и много, хотя они и были.
В итоге комментарий описывает не то, что уже представляет код, и является, скорее, вредным, чем полезным.

Вот ни разу не было, чтобы устаревший комментарий оказался вредным. А вот когда он помогал разобраться в текущем коде, было.

Не видел, значит не бывает?) Ну а у меня было) Ну и опять же, это ни о чем не говорит. На моём опыте так же было, что раз можно написать комментарии к каждому блоку, чё не запихнуть все эти блоки в одну большую функцию. Зато всё ясно и понятно, да и в одни месте. Так что в некоторых случаях вместо декомпозиции и рефакторинга предпочитают комментарии

Да нет, это скорее о вероятностях)
Есть красивая теория, о том, что хорошо написанный код в комментариях не нуждается.

Есть красивая теория, что код описывает, что надо делать, а комментарии — почему это надо делать.


Например:


def call_partner_api(params)
  # Если в API нашего партнёра передавать больше 8 знаков
  # после запятой, то у него что-то внутрях падает, поэтому
  # принудительно урежем точность.
  params[:blah] = params[:blah].round(8)
  send_request_to_api(params)
end
у нас в России, на мой взгляд странно платить особо не выдающемуся знаниями или заслугами веб-программисту 5 000 долларов.

На мой взгляд куда страннее собеседовать человека на позицию из окрестности 5000 баксов, и при этом спрашивать у него синтаксис языка или тривиальные алгоритмические задачки. Но вот почему-то спрашивают.
а что, по-вашему, у него надо спрашивать? просто поговорить о высоких материях? а если он 10К попросит? а если 20К? Вообще без собеседования брать? Высокая зарплата не должна освобождать от требования уметь и понимать то, что умеет и понимает типичный мидл. Высокая позиция предполагает, что в дополнение ко всему тому у вас еще и отличное понимание архитектуры, организации процессов и еще чего-то там есть.
а что, по-вашему, у него надо спрашивать?

Давать норм тестовое задание (на час-два, а не на два дня), вопросы по дизайну, по архитектуре, про общение в команде, про взаимодействие с бизнесом.

И у меня действительно спрашивали эти вопросы, но на позиции java-техлида или архитекта. Руби парни не спрашивали, хотя запросы по зп были одинаковыми и там и там.
Судя по вашим ответам тут, спрашивать вас по архитектуре и дизайну достаточно бесполезно, ибо если вы не удосужились ответить на простейшие вещи, то уж и на более глубокие вряд ли сможете. И да, я ознакомился с вашим профилем в Линкедине. Но ваши слова здесь и стиль общения сведетельствуют скорее о том, что в Линкедине — пурга.

На самом деле, я диву даюсь, насколько перегрета отрасль, что готовы предлагать зарплаты по 5к любым синьорам с 2мя годами опыта работы. (Если что, это не конкретно к вам относится)
просто поговорить о высоких материях?

Именно. Только не «просто» поговорить, а предметно. Что решалось, как решалось, проблемы какие были, и так далее. Естественно, собеседовать должен человек с соответствующей квалификацией, чтоб можно было распознать чистую пургу.

Высокая зарплата не должна освобождать от требования уметь и понимать то, что умеет и понимает типичный мидл.

Нет, ни в коем случае. Просто это требование не будет основополагающим. При прочих равных (которые в случае сеньоров скорее всего не возникнут, но вот в теории) конечно же лучше взять того, кто на уровне мидла шибче. Но если собеседовать только по уровню мидла, то — … собственно, кого нанимаем-то? Мидла на 5К?
про «только» разговора не было. был о том, что надо, чтобы и высокие материи знал, и руками работать мог. если он все это делал настолько давно, что теперь может только о высоких материях, то он для нас сильно неидеален.
был о том, что надо, чтобы и высокие материи знал, и руками работать мог.

Ага. И собеседовали про работу руками, оставляя высокие материи где-то на закуску. Опять же, вопрос о том, кого нанимаем: того, кто за 5К будет в первую очередь руками работать? Или нет?
почему на закуску? архитектурные интервью так же важны как и интервью на кодинг. на них надо выделять отдельные секции, где эти навыки и оценивать. человек высокого уровня будет скорее всего заниматься больше не ручным трудом, но он должен быть способен помочь застрявшему мидлу, к примеру, если понадобится. а как он это будет делать, если он ничего этого не может?

пару месяцев назад я интервьюировался на позиции, эквивалентные гугловому Staff Engineer в несколько других компаний. и решать алгоритмические задачи (где на доске, где на компьютере) приходилось везде. так же приходилось решать high scale system design задачи, проходить behavioral секции и много чего еще. но при этом никому почему-то был не нужен человек, который может говорить о высоких материях, и при этом не может решить алгоритмическую задачу (при условии, что он претендует на техническую позицию, а не позицию менеджера людей).

К сожалению, есть полно кандидатов, вообще не дотягивающих по квалификации, но отправляющих CV, хорошенько преукрашенное, везде куда могут, на авось.


Поэтому имеет смысл спрашивать и про синтаксис. Правда, лучше, чтобы это был телефонный скриннинг выполняемый не специалистом с простыми впросами и ответами на бумажке.

мне еще и показалось, что у вас требования по з/п высокие

Это не у меня высокие, это у вас — низкие )))

На 5 000 долларов, мне кажется, это должен быть уникум из команды Вконтакте или крутой специалист из Яндекса со знанием всего, что можно. Разве я не прав?

Может в РФ это и так, но у нас 5k — это норм зарплата для норм спеца. Не каждый конечно такие деньги получает, но это и незаоблачные или недосягаемые вещи, в чем я убедился на собственном опыте. В итоге я получил несколько офферов на эти деньги без особых трудностей (наверное мог даже больше просить), ну вот кроме разве что позиции руби разраба где мне дали только 4.5 потому что я «плохо синтаксис знал». Ах да, 5k это на руки, после вычета налогов. Про зарплаты я писал у себя в телеге — вот можете почитать — https://t.me/full_of_hatred/19
И нет, я не вру и не хвастаюсь.

Яндекс платит ниже рынка, это известно даже мне.

И да, Вастрик например писал что в МСК можно косить примерно такое же бабло без особых напрягов.

Можете еще первую статью перечитать, там написано кто я ваще такой и какой у меня бэкграунд, может со стороны показаться что я какой-то вайтишник-понторез, но это не так. Можете вот еще линкедин посмотреть — https://www.linkedin.com/in/rozhok/

Они должны быть не на доске, а в тестовом задании или в примерах своего кода, которые демонстрирует кандидат. Как без комментариев-то в вашем коду будут разбираться коллеги?

Не очень понял кому вообще вопрос, у меня в секции про тестовое задание написано что я писал джавадоки.

Ну это же какие-то очевидные вещи

Но ведь надо же знать про их существование, нет? Как по мне, это такая же важная штука как и eager/includes/join. Впрочем кому я вру, у меня на трех или четырех рейлс проектах не написано ни одной валидации — не нужно было )))

Ну вот мы еще и выяснили, что вас не беспокоит качество получающегося продукта.

А мы выяснили что у вас отсутствует детектор сарказма/юмора.
> у нас в России, на мой взгляд странно платить особо не выдающемуся знаниями или заслугами веб-программисту 5 000 долларов

Насколько я понимаю, украинские (и белорусские) зп действительно в разы выше российских сейчас, и происходит это из-за разного уровня налогов.
и происходит это из-за разного уровня налогов.

Я бы сказал из-за экспортоориентированности украинских и беларусских компаний. Налоги тут второстепенный вопрос (хотя и их мы платим намного меньше).

В Украине почти нет компаний, которые работают на внутренний рынок, в отличие от РФ, где есть яндексы, вк, мейл.ру, одноклассники и прочие ребята, которые, естественно, получают выручку в рублях.

А у нас все получают выручку в твердых долларах и евро, поэтому когда курс обвалился то российские программисты стали получать меньше денег в долларах, а украинские/беларусские — остались на месте.

Вот и вся арифметика.
Курс рубля все-таки не в два раза обвалился. И потом, в России немало «экспортирующих» компаний тоже — тот же Luxoft или как он там.

А зарплаты все равно в два раза меньше.
Курс рубля все-таки не в два раза обвалился.

Как это не в два? В РФ был по 30 стал по 60.
В Украине был по 8 стал по 27.

И потом, в России немало «экспортирующих» компаний тоже — тот же Luxoft или как он там.

Да, но все равно на рынке сложилась ситуация когда крупные игроки фиксируют зарплаты в рублях. У нас (в Украине) такого никогда не было. Люди просто не пойдут работать в компанию, где фиксируют зп в гривнах.

А зарплаты все равно в два раза меньше.

Я че-то в этом вообще не уверен. Особенно в МСК — там точно зп сравнимы с киевскими. В общем хотите косить бабло и не платить сотни денег за аренду однушки в ново-медведково — приезжайте к нам )))
Да, но все равно на рынке сложилась ситуация когда крупные игроки фиксируют зарплаты в рублях. У нас (в Украине) такого никогда не было. Люди просто не пойдут работать в компанию, где фиксируют зп в гривнах.


Это очень интересный момент, потому что в России тоже так было, в 90х повсеместно, и потом сохранялось даже какое-то время в 2000х. А потом прошло, интересно почему. Я помню, как одна моя подработка, стабильно платившая мне долларами в конверте, в 2009 году вдруг заявила, что теперь рубли и баста, а то их всех посадят. Рубли предлагались все в том же конверте.

Нам тогда пришлось расстаться, потому что мы не договорились.
С вики: С 15 июня 2004 года в России действуют положения Федерального закона «О валютном регулировании и валютном контроле» от 10 декабря 2003 года № 173-ФЗ. Пунктом 1 статьи 9 установлен общий запрет на осуществление валютных операций между резидентами.
Сениорская зарплата в Москве — 200-300т.р. или от 3-4.5 тыс долларов на руки чистыми. При лобовом сравнении по ХХ разница у Москвы и Киева процентов 15%, где вы там в два раза нашли, я не знаю.
Спасибо за цифры! Я давно живу во Франции и, может быть, неправильно сужу со стороны.

Мои впечатления основаны вот на этой статистике moikrug, согласно которой зп больше 220тр (=3300 долларов) имеют меньше 3%. А медиана так и вовсе 90тр (=1300 долларов).

А вот статистика по Украине, которая дает 2000 долларов как медиану зп разработчика и суммы порядка 4000 долларов как медиану зп сеньора.

У меня сложилось впечатление, что в среднем зп в два раза выше.

Вы сразу стали обсуждать сеньоров, но по вашим цифрам и по статистике moikrug получается, что вы сразу отбросили 97% и обсуждаете оставшиеся 3%.
Что вы думаете насчет зарплат в среднем?
Я честно говоря не в курсе как они считают среднюю ЗП на DOA. Я просто открыл там список зарплат в Киеве для Java разработчиков. Возможно просто поиск на ДОА сделан херово (мне пришлось подгружать список до конца искать поиском по странице значка доллара), но там с указанием ЗП нашлось 15 вакансий. Из них с верхней планкой выше $3K — 3 штуки. Как они по такой выборке среднюю считают, я не знаю.
Еще мне показалось, но это субъективно, в РФ существенно больше джуновых и недомидловых вакансий.
Виджет зарплат — результат опросов.
Может где-то столько и получают, но публичных вакансий с таким уровнем мало, да и когда рекрутеры стучатся сами, обычно о меньших суммах речь идёт.
Если именно про зарплату по КЗоТ/ТК говорить, то уровень налогов в Украине как бы не выше российского. Но очень многие программисты и прочие ИТ-специалисты в Украине работают как независимые контракторы, юридически как ФОП (ИП по-российски) по упрощенке с 5% на доход.
Не совсем понятно как эта ЗП считается, потому что в РФ для ИП отпуск не положен, как и 13-я ЗП, и вроде бы как и праздники. Потому что в средней московской фирме вы вместо 12 месяцев вы работаете 10.5 месяцев в году. А зарплату получите в обычной фирме за 13 месяцев, а в каком-нибудь Сбере минимум за 14. В этом случае $4k белыми примерно равны $5k для ИП. $4k*13 = $52k, а $5k*10.5 = $52.5k. Как с этим в Украине — понятия не имею.
Вот честно, когда обсуждал вакансии в Москве, то только одна заикнулась за 13-ю зарплату и выставляла это как явное преимущество перед другими конторами. У других максимум невнятное «премия по результатам года».

Отпуска у ИП нет, да, поскольку нет трудовых отношений, но минимум на 20 рабочих дней вынужденного бездействия в году рассчитывать можно.
Как с этим в Украине — понятия не имею.

Так же как и с КзОТовцами, в контракте все прописывается. Де-юре вы конечно не защищены, потому что отношения не трудовые, но де-факто все работают так же как и в обычных конторах. Никто не замечен в злоупотреблении формальным отсутствием трудовых отношений.
«Увольняют» иногда без отработки, просто оплачивают две недели и свободен :)
А в чём преимущество отработки перед «оплатили и свободен»? Или КзОТ гарантирует право работать без оплаты?
Кстати, вариант «оплатили и свободен» применяют во всём мире, к ИП это никак не относится. Иногда это вообще единственный возможный вариант увольнения.
По ТК РФ уволить человека по желанию работодателя нельзя. Можно сократить, выплатив зарплату за два, если не ошибаюсь полных месяца. Еще и на эту должность потом нанять никого нельзя в течение вроде бы года. Со мной некоторое время рядом работали люди, которых забыли уволить на испытательном сроке. Слава Богу не на одном проекте работали, а просто рядом сидели.
В США насколько я знаю это регламентируется контрактом. В ЕС вроде работника не на срочном контракте тоже хер уволишь.
На моем опыте в РФ в IT это в основном мешает нормальным компаниям увольнять тупых работников. Слышал в красном банке одного придурка так год увольняли. Зато не мешает всяким говнокомпаниям увольнять целые отделы тупо закрывая одно из своих семнадцати ООО.
Мне показалось (может не так прочитал), что в комменте Выше человек считает злоупотреблением вариант увольнения без отработок. Я же полагаю, что с точки зрения работника важно иметь оплату (которую по ИП выплачивали честно), и только хорошо если при этом не надо работать.
По ТК РФ — лично я не считаю эту норму правильной. Но именно на это я и намекал — в некоторых странах «по желанию работодателя» можно уволить только формулировкой «завтра на работу не выходишь, деньги на счет мы перевели».
Я не помню уже, какие были выплаты при увольнении ИП (и не знаю что изменилось за 7 лет) — пожалуй таки 2 недели. Правда в реалиях Украины по ИП это была реальная зарплата, по нормальному найму часть обычно была премиями и серыми.
Насколько я помню, КЗоТ не допускает увольнение по собственному без фактической отработки, но выплатой денег за отработку как будто она была.
Вы сейчас про «по собственному желанию» кого? По желанию работника — да, обязан отработать, иначе это уже «по согласованию». По инициативе работодателя (по сокращению, или любой допустимой причине" — не знаю, но если КзОТ требует обеспечить возможность работнику находиться на рабочем месте при том, что деньги ему уже в полном объеме выплачены — это странное требование.
Да и бССР мир не ограничивается — в некоторых странах и сценариях «сократить» фирма может только в один день, выход работника на рабочее место после этого отменяет сокращение.
Ну вот, а вмире ИП вполне возможно, что уведомляешь о намерении расторгнуть контракт за 2 недели, а тебе расторгают сразу, выплачивая «выходное пособие» за эти две недели.
Хорошо, а проблема то в чём? Уведомляешь за две недели, деньги получаешь за две недели. Вроде всё прекрасно.
В чём проблема для работника, если ему подарили 2 недели оплаченного отпуска?
В моём посте выше «обязан отработать» следует читать как «по требованию работодателя обязан». Я буду крайне удивлён, если КзОТ обязывает работодателя обеспечить работника работой.
в США, к примеру, могут быть интересные последствия такого подаренного оплаченного отпуска. например, медицинская страховка работодателя может перестать действовать в день фактического прекращения трудоустройства. это не всегда так — зависит и от штата, и от работодателя, но такое может произойти. если в эти две недели вдруг заболеть, может выйти дорого.
Тем, что это будет отпуск, а не увольнение, то есть устроиться в другую компанию до истечения этих двух недель нельзя официально. Опять же есть сомнения, что компания может официально подарить отпуск.
компания не дарит отпуск — в большинстве случаев это-таки увольнение сразу. просто деньги выплатят за 2 недели работы, хотя работать уже будет не надо.
Я вот сомневаюсь, что КЗоТ и белая бухгалтерия такую выплату позволят провести (дополнительно к компенсации неиспользованного отпуска).
Обычно процесс найма не настолько быстр, чтобы это на что-то влияло. В крупных компаниях это обычно месяцы.
Классическая ситуация: пришёл с оффером просить повышения, отказали — написал заявление. А тебя через 2 недели только увольняют. Даже если в отпуск отправили, трудовую дадут после него. Или могут пойти навстречу и дать трудовую на руки, но там будет дата увольнения из будущего.
Никогда так не делал — не могу прокоментировать.
Мне на прошлой работе пытались подсунуть контракт, где они уольняли чуть ли не одним днем, а я должен был аж за 3 недели уведомить. Когда ткнул носом внезапно оказалось «ой, это ошибка, мы не заметили» и в итоге сошлись на неделе в обе стороны (что мне оказалось весьма кстати впоследствие)
В СевАмерике всегда так, если увольнение не по твоей инициативе.

Комментарии? Их что прямо на собеседовании надо писать на доске или бумажке?
В реальных проектах лучше бы код писали понятный без комментариев, а то я видел устаревших комментариев больше чем реально полезных.

// todo: fix this hack

Самый главный коммент )))
#  @fixme because of shit

наше всё
нет ни одного надежного способа достоверно определить, будет ли кандидат хорошим работником или нет. умение решать задачи на алгоритмы на доске показывает хотя бы то, что кандидат способен за разумное время разобрать эти алгоритмы и набить руку на решение таких задач. то есть он обучаем, мотивирован, и в целом соображает. на интервью на синиор инженера ожидать, что на интервью придется писать только круды, немного странно.
будет ли кандидат хорошим работником или нет

Есть — это совместная работа в течение короткого периода времени (день-два парного программирования). Но такое не все могут позволить, а галерам/большим конторам это просто не нужно, потому что у них потоковая работа и цена ошибки (найма плохого человека) довольно низкая.

Таким образом, например, на работу берет такая контора как Basecamp (это кстати они придумали Rails).

на интервью на синиор инженера ожидать, что на интервью придется писать только круды

Я ожидал какие-то вопросы по дизайну и архитектуре, но их получил только на Java собесах. Ruby ребята спрашивали дичь для джунов.
пара дней совместной работы тоже никакой гарантии не дает. вы, похоже, путаете «будет» и «может быть». кандидат вполне может оказаться хорошим разработчиком, способным быть хорошим работником, однако это не значит, что он таковым будет. через пару дней вашего короткого периода и получения офера все может и закончиться. способа определить, будет он хорошим работником или нет, не существует.

ну и по поводу подхода в целом: для какого-нибудь условного джуниора пару дней наблюдения за тем, как он пишет круды (или, как говорят в гуглах, двигает протобафы), может и подойдет. а вот у синиоров на такое обычно времени нет. а если вдруг есть, то ему на эти два дня надо вполне себе широкий спектр интересных задач найти (при этом таких, чтобы их еще и закончить можно было), чтобы можно было какие-то выводы сделать.

самый надежный на сегодняшний день индикатор — это личная рекомендация от людей, мнению которых доверяешь, и у которых есть личный опыт работы с человеком. это тоже не 100% гарантия, но уже сильно ближе. жаль только, что крайне редко такой индикатор доступен.
Есть несколько причин давать алгоритмические задачи на собеседовании:
1. Они короткие.
2. Они интересны кандидатам.
3. Это Common Sense, применимый к любой технологии. И без привязки к технологии, просто проверка что у человека мозги на месте.
4. Они позволяют увидеть, как человек пишет код. на абстрактной задаче, реальный код.
5. Показывают подход к решеню проблем.

И не особо в пользу задач, но как факт многие так делают:
6. они позволяют формально отранжировать кандидатов и выбрать одного. То есть задачу «обоснованно самого полезного из [имеющихся кандидатов]» сводят к «обоснованно одного из».

Во многом Ваша статья сводится к тому, что многие не умеют собеседовать. Прекрасный пример тут:
«Ок, задачу сделаю, но у меня вопрос: у вас в работе понадобятся эти знания, вам нужно решать похожие вещи?». На что получаю феноменальный ответ…
я позволил себе немного высказаться по поводу бессмысленности таких собеседований. Интервьюер со мной согласился

То есть интервьюер изначально не видит смысла в том методе собеседования, который он применяет. Тут проблема именно в этом, а не в задачах.

За 15 лет работы у меня не было ни одного проекта, где не было алгоритмических задач. Даже в самом «кровавом энтерпрайзе». Просто иногда эти задачи замечаю только тогда, когда в коде вместо понятных 3 строчек написано непонятных 50. Ведь иногда действительно важно вовремя подумать про время исполнения.

Задача с многопоточным API для записи данных в файл на диске — это отличная задача. Но не факт, что в той фирме таки такое пишут каждый день. Или хоть раз.

По теории — во-первых я тоже заметил, что западноевропейские фирмы уделяют этому куда меньше внимания, чем в России и Украине. Не знаю почему.
Во-вторых, иногда это просто попытки свести кандидатов к каким-то сравнимым метрикам.

Ну и главное из моего опыта — процесс очень по-разному выглядит со стороны собеседующего и собеседуемого. И, конечно, с обеих сторон бывают ошибки.
За 15 лет работы у меня не было ни одного проекта, где не было алгоритмических задач.

А у меня за 12 не было ни одного, где они бы были, кроме проекта, где вовсю использовались деревья и графы. Но даже там базовые вещи вроде траверса-вставки-балансировки и тд писались один раз и потом реюзались всеми годами.
Вообще говоря в любом куске кода есть какой-то алгоритм :)
Понятно, что чистое первозданное «отбалансировать дерево» встречается редко. Скорее бывает что-то вроде «убрать перекрывающиеся интервалы из списка», что совсем не похоже на известные алгоритмы, но при этом к ним сводится. Человек, который об алгоритмах не думает, выдаёт код «в лоб», который 2 минуты из базы данные выгребает. Или пишет 200 строк кода вместо 10.
Хотел бы я посмотреть на человека, который будет давать на собеседованиях задачу на динамическое программирование, серьезно.

Вбейте в поиске "сотрудник Гугла, фото", смотрите на здоровье. :)
В гугле, яндексе и других крупных международных компаниях очень часто дают задачи и на динамическое программирование. Хотя чаще встречаются просто на знание структур данных.


Штука с динамическим программированием, что ты не знаешь, когда оно понадобится. И если разработчик его не знает, он(а) будет писать какой-нибудь полный перебор и даже не задумается, что задачу можно решить лучше. Да, есть области, где это крайне маловероятно — какие-нибудь embedded разработчики, где тупо нет памяти и регистров, чтобы что-то нетривиальное сделать, или рисовальщики формочек например, где все задачи тривиальны по своей сути. Если же в продукте есть хоть какая-то обработка данных, ДП может когда-нибудь да вылезти.


Читаемость кода и лучшие практики можно натренировать у почти любого программиста за пару месяцев код-ревью (а в перечисленных фирмах ревью есть всегда). Динамическое программирование же — понять суждено не всем.


Так что, если есть поток кандидатов, то нанимающий может позволить себе отсеивать тех. кто не знает ДП, например. Не потому, что это абсолютно необходимое знание — нет, но потому что это хороший бонус.


Как уже написали выше, все собеседования — это нелепая попытка измерить за n минут то, что можно хотя бы примерно оценить только за несколько месяцев работы. Но нанимать всех на испытательный срок в, скажем, 6 месяцев физически невозможно.

ДП на интервью — это в последнее время редкость. в гугле уже не рекомендуют давать задачи на ДП, хотя изредка их все же можно встретить. это раньше давали достаточно часто. в других местах тоже не так чтобы часто попадалось. три месяца назад я сходил на интервью в пяток компаний — в среднем по 6 секций в каждой — и из всех этих 30 секций ДП было только на одной, и то — это была запасная задача, потому что решение основной я знал, и интервьюеру пришлось что-то еще срочно выдумывать.
потому что решение основной я знал, и интервьюеру пришлось что-то еще срочно выдумывать

Ахаха, вся суть этих задач ))) У меня тоже был такой случай, но очень давно, в начале десятых годов, там тоже так оказалось что ребята дали мне задачу типа почему люки круглые а я сразу и ответил. Тогда такие вопросы были в моде )))
Вбейте в поиске «сотрудник Гугла, фото», смотрите на здоровье. :)

Я имел ввиду наши реалии. Ну нет у наших аутсорсеров и аутстафферов реально сложных задач требующих вот этого всего. Все проекты — веб-формошлепство, кровавый ентерпрайз и прочая дичь, требующая умения не решать алгоритмические задачи, а выдавать нужный бизнесу код с приемлемой скоростью и приемлемым качеством.

Но если вдруг есть — то я только за. Главное предупредите, что у вас хардкорные разработки и надо шарить деревья, сортировки тима и быстро подстроки искать. Тогда я подготовлюсь, приду, и буду потеть над этими задачами понимая, зачем я это делаю. А не просто дать задачу потому что все дают а потом посадить меня круды делать.

Про FAANG и так все понятно — сотни постов и тысячи комментов в западной блогосфере написаны на тему сломанности их техинтервью, но ситуацию это не меняет. Что забавно, они тоже пишут что даже там в работе эти алгоритмы реально не нужны.
Про FAANG и так все понятно — сотни постов и тысячи комментов в западной блогосфере написаны на тему сломанности их техинтервью, но ситуацию это не меняет. Что забавно, они тоже пишут что даже там в работе эти алгоритмы реально не нужны.

нужны они в FAANG. не каждый день, но достаточно часто. какой-нибудь reservoir sampling, к примеру, мне пригодился для шардинга ки-спэйса для распределенной обработки не так давно. задачи на многопоточность — так вообще каждодневно нужны. изредка что-то из графов пригождается. ну и в целом — даже если в большинстве случаев это будет двиганье протобафов, иногда будет появляться что-то, где желательно уметь рассмотреть возможность оптимизации (иногда на порядки). а без знания того, что какой-то алгоритм или структура существует и каким-то образом может быть применен(а), шанс на то, что эта оптимизация произойдет, достаточно низкий.
Добавлю к этому, что понимание алгоритмов обычно говорит о любознательности и эрудиции, и коррелирует с умением эффективно работать.
Если вас интересует любознательность и эрудиция, то вы можете поговорить далеко не только об алгоритмах. :) Скажем, спросить, знает ли собеседник, как работает магнетрон, сможет ли он объяснить эффект Доплера, рассказать, как работает лазер, объяснить угол Брюстера и что такое поляризация ЭМ волны вообще, что такое дифференциальный и инструментальный усилители, гиратор и для чего все они нужны, объяснить, что такое устойчивость следящей системы и как её определить, ну и какие типы регуляторов знает собеседуемый, а вот уже потом, вернувшись к ПО, можно попросить рассказать о построении софтверных 3D движков (соответствующая статья про движок уровня Wolf 3D тут недавно была очень востребована, что говорит о слабом освещении этой темы для большого количества разработчиков).
Вот только после таких диалогов может вдруг оказаться, что при наличии данного вида любознательности и эрудиции (если собеседник смог ответить на вопросы), собеседник не вспомнит алгоритм Дейкстры и балансировку дерева. Потому что либо не знал, либо не использовал. Ну так это лечится открыванием книжки/статей. В конце-концов, над алгоритмами люди их придумавшие думали совсем не один день.
А причина всего этого одна — область знаний огромна. Просто огромна. И вместить её всю человеку невозможно. И совсем не обязательно, это должны быть стандартные алгоритмы. :)

P.S. Когда нам читали численные методы, там были круги Гершгорина (я давно забыл, что это и для чего применялись — 18 лет прошло). Они тоже были в одном алгоритме про вычисление чего-то. Но я очень сомневаюсь, что много кто про этого Гершгорина слышал, кроме специфических математиков. И таких малоизвестных алгоритмов тьма.
А причина всего этого одна — область знаний огромна. И вместить её всю человеку невозможно. И совсем не обязательно, это должны быть стандартные алгоритмы. :)

Если Вы идёте работать в институт физики, то я сложно представляю себе кандидата, не знающего про эффект Доплера.
А вот если Вы хотите быть программистом, то ту маленькую часть области знаний, которая относится к программированию, желательно немного знать. И да, я не говорю об алгоритмах как о заученных решениях конкретных задач. Скорее об алгоритмизации в принципе, об умении придумать и написать какой-то алгоритм в принципе. И знание какиех-то основных принципов.
То же динамическое программирование, это не какой-то конкретный алгоритм, а мкорее принцип, хотя бы о том, что вложенные циклы работают медленно, и их можно иногда заменить затратами памяти.
Если конкретнее, я никогда не спрашиваю на собеседовании алгоритм Дейкстры. Не вижу смысла заучивать алгоритмы по абстрактным названиям (да и сам только что подсмотрел в Вики, хоть и писал его много раз). А вполне могу дать простую задачу, и посмотрю что:
а) кандидат в принципе решит её хоть как нибудь. ну ведь очевидно, что задача решаема.
б) кандидат понимает, что его решение неоптимально, и может подумать в сторону оптимизации. Да хотя бы просто задумывается о сложности и прожорливости.
в) кандидат догадывается, что могут сушествовать готовые решения, и примерно понимает где их искать.
Если Вы идёте работать в институт физики, то я сложно представляю себе кандидата, не знающего про эффект Доплера.


А совершенно напрасно. Если у вас есть знакомые физики, попробуйте поспрашивать их по учебнику для 1-2 курса вузов. Найдёте великое множество пробелов, непонимания и ошибочных суждений. Даже у докторов наук и академиков РАН. Потому что можно хорошо и досконально знать только крохотную область. А всё вместе в голову просто не влезет из-за моря нюансов.
Но мы ведь говорили про эрудицию и любознательность, как общее мерило кандидата. Смотрите, какой охват вопросов — от математики к физике и электронике и потом к ПО. Можно ещё и школьную химию вспомнить: скажем, не скажет ли кандидат, что такое электроотрицательность, валентность, степень окисления, стехиометрические и нестехиометрические соединения. Не знает ли он, почему при понижении температуры реакции обычно замедляются и не назовёт ли с объяснением работы пример реакции, которая ускоряется при охлаждении? Помнит ли что такое белки, жиры и углеводы? Можно физхимию вспомнить: что такое энергия Гиббса и энтропия и энтальпия, например. Ну и диаграмму плавкости пусть объяснит — где там эвтектика и перитектика, а так же ликвидус и солидус. Ну и так далее. Много чего можно вспомнить, коль интересны эрудиция и любознательность кандидата. А то всё компьютер, да компьютер… На нём свет клином не сошёлся. Кстати, можно предложить построить на бумажке простейший процессор (это если кандидат вспомнит синтез автоматов) — но это уже особый навык.

Скорее об алгоритмизации в принципе, об умении придумать и написать какой-то алгоритм в принципе.


Разумеется. Вот только это может занять массу времени и не гарантирует результата. Вот, скажем, я только через 15 лет понял, как сделать при выводе 3D экранный портал. До этого просто не сообразил. Бывает. А так, массу хитрых алгоритмов хорошо придумывают математики — у них мышление в этом плане удачнее идёт.
Вот вы тот же алгоритм Дейкстры смогли бы вывести, не зная его вообще? Вряд ли. Значит, вперёд выходит память (как и везде, кстати). Но сейчас память можно заменить поиском в соответствующей литературе. Так все специальности делают! Только программистам, почему-то, нельзя.

кандидат понимает, что его решение неоптимально, и может подумать в сторону оптимизации. Да хотя бы просто задумывается о сложности и прожорливости.


Весь вопрос в том, что не все задачи следует оптимизировать хитрыми способами. Может оказаться, что это на самом деле не нужно — вызывается очень-очень редко и вполне можно немножко подождать.
Ещё раз, про эрудицию и любознательность — я говорил про IT, а не вообще во всём. И вроде как повторил в своём ответе ещё раз. Зачем опять писать про физику?
Если уж про физику
Из того, что Вы написали, если отбросить терминологию (которую можно только заучить но не понять), я почти всё немного знаю. Неглубоко, но имею представление. И мне кажется, что любой более-менее адекватный человек тоже. Конечно, можно сказать что к IT это отношения не имеет, но что-то мне не встречался грамотный программист, который не слышал про эффект Доплера. И уж тем более из моих знакомых физиков — правда, ни одного.
И да, из личного опыта, обычно те, кому интересно как работает процессор и как найти путь в графе, пишут код куда лучше, чем те кому это не интересно.

Но сейчас память можно заменить поиском в соответствующей литературе. Так все специальности делают! Только программистам, почему-то, нельзя.

МОЖНО! Именно этому меня учила учительница химии и профессор теории вероятностей. На экзамене у последнего можно было пользоваться любой литературой. Но почему то не все в группе сдавали с первого раза, я не говорю даже о пятёрках.
Почему? Потому что чтобы найти в литературе алгоритм Дейкстры, надо во-первых понять что перед вами граф, во-вторых что по нему надо найти путь, и в третьих что для этого бывает алгоритм. А уже заметив это, можно вбивать запрос на StackOverflow. А вот «специалист», который получив задачу будет вбивать полный её текст в гугл и ждать чуда, мне вряд ли нужен.
Весь вопрос в том, что не все задачи следует оптимизировать хитрыми способами. Может оказаться, что это на самом деле не нужно — вызывается очень-очень редко и вполне можно немножко подождать.

100% согласен. Я нанимаю человека именно для принятия таких решений. И мне предпочтительнее тот, кто это решение примет, вместо того, кто даже не подумает проверить производительность очевидно неоптимально написаного кода.
Ещё раз, про эрудицию и любознательность — я говорил про IT, а не вообще во всём.


Ну, допустим. А математика к IT у вас будет относиться? А когда игру надо написать, физику игры можно делать без знания механики? Вряд ли. А есть ещё задачи моделирования, там без той же физики никуда. Получается, для ряда направлений требуется знать ещё что-то кроме IT. Или хотя бы знать, что оно есть.

Неглубоко, но имею представление.


Нет, так это не работает. Представления, обычно, это «что-то слышал, но детально не знаю». То есть, начнёте применять такое представление — будете изумляться «а чего оно не работает-то?». Знаете, сколько на форумах таких вопросов? :) Типа «помогите настроить ПИД-регулятор! Не получается!». Или «Соединил у операционника входы, а он почему-то на выходе не выдаёт нуля». Это всё от вездесущего «что-то слышал». Опасная вещь, этот «что-то слышал». Хорошо хоть книжки есть, где можно детально найти с нюансами. И то вспотеешь, разбираясь.

но что-то мне не встречался грамотный программист, который не слышал про эффект Доплера.


Слышал или может объяснить, почему он возникает и как вывести формулу? Кстати, звук продольная или поперечная волна? :) А свет? А почему и там и там тогда эффект Доплера возникает, коль волны разные? :)

МОЖНО!


Да где же? В какую тему про собеседования ни зайди, сплошные задачи из книжки «математическая смекалка». И никакого поиска в гугле не дают. Решить надо «здесь и сейчас без всяких справочников». При этом в реальной работе решение растягивается на дни раздумий, оценок и поиска подобных решений.

Но почему то не все в группе сдавали с первого раза, я не говорю даже о пятёрках.


А вот в этом как раз ничего удивительного нет: редкий случай, чтобы студент не пытался заучить, а понять. Более того, осознать.
Получается, для ряда направлений требуется знать ещё что-то кроме IT.

Нет, как человек, писавший диссертацию про моделирование физиологии, работавший в банке, с букмекерами и т.д. я уверен, что программисту чтобы быть эффективным, надо разобраться в бизнес-домене.
А знать должен специалист: у меня в команде был учёный-физиолог, трейдер, букмекер. Их задача знать очень глубоко. Попытка сделать что угодно из этих задач командой чисто программистов была бы обречена на провал. Но и те, кто не хотел хоть немного понять как это работает, были сильно неэффективны.
Слышал или может объяснить, почему он возникает и как вывести формулу?

Лично я могу, за других не скажу.
Но алгоритмы — это чистое программирование, вот и ожидается, что знать их будет программист, а не кто-то другой. Хотя бы на уровне мид или синьор. Джуниоры конечно могут не знать и тупо кодить то, что им сказали.
В какую тему про собеседования ни зайди, сплошные задачи из книжки «математическая смекалка». И никакого поиска в гугле не дают.

Ещё раз — те задачи, что я считаю правильным давать на собеседовании, довольно простые. Если на каждый мелкий баг разработчик будет устраивать «дни раздумий», мне такой в команде не нужен.
я уверен, что программисту чтобы быть эффективным, надо разобраться в бизнес-домене.


Если так, тогда зачем вы требуете от программиста знания алгоритмов? Алгоритмист и программист («кодер») — это разная специализация. Так раньше и было.

Но алгоритмы — это чистое программирование,


В том-то и дело, что алгоритмы с их теорией это несколько другое:
«Программирование — процесс создания компьютерных программ. В узком смысле (так называемое кодирование) под программированием понимается написание инструкций (программ) на конкретном языке программирования (часто по уже имеющемуся алгоритму — плану, методу решения поставленной задачи). Соответственно, люди, которые этим занимаются, называются программистами (на профессиональном жаргоне — кодерами), а те, кто разрабатывают алгоритмы — алгоритмистами, специалистами предметной области математиками.»


Ещё раз — те задачи, что я считаю правильным давать на собеседовании, довольно простые.


Ну, ваши-то задачи мы не обсуждаем — я их не знаю. Я говорю о предлагаемых задачах вообще. Тут есть определённая проблема:

— В одной из моих увлекательных магловских книг, — холодно начал Гарри, — описано исследование: люди, притворяясь умниками, задавали вопросы, на которые только они знали ответы. И ни один наблюдатель не смог их раскусить.


Очень много предлагаемых задач требуют просто знания ответов и метода решения.
Если так, тогда зачем вы требуете от программиста знания алгоритмов? Алгоритмист и программист («кодер») — это разная специализация. Так раньше и было.

Раньше — это когда, во времена перфокарт? Скажите честно, у Вас в команде есть выделенный алгоритмист?
Напомню название статьи, которую мы обсуждаем: «Senior Engineer в поисках работы...» — Вы полагаете, на этой должности человек должен заниматься «кодированием по уже имеющемуся алгоритму»?
Раньше — это когда, во времена перфокарт? Скажите честно, у Вас в команде есть выделенный алгоритмист?


Раньше — это в 80-е. У меня в команде есть несколько математиков по модели ухода гироскопа и они придумывают, как бы им центр годографа вытащить из кривых данных. Иными словами, тот же алгоритм. Только я в НИИ, а не в бизнес-IT.

Вот есть интересные комментарии на тему, нужно ли знать эти алгоритмы на отличном уровне или достаточно просто знать, что они есть:
habr.com/ru/post/279453/#comment_8808147
habr.com/ru/post/279453/#comment_8808689
habr.com/ru/post/279453/#comment_8807955

И я с этими комментариями согласен.
Немного поясню, в чём камень преткновения.
Вот вы сказали, что программисту для создания ПО требуется только лишь разобраться в проблематике, решаемой этим ПО. Знать уже должен специалист. Но дело в том, что алгоритмика так же удел специалистов-математиков. Программисту в этом случае достаточно просто быть уверенным, что алгоритм наверняка есть и просто найти и реализовать его (если нет алгоритмиста в штате. Ах да, давайте всё же не считать любую программу алгоритмом — это конечно, не верно, но сейчас, говоря об алгоритмах, имеют в виду методы решения неких относительно сложных задач). Но такого программиста почему-то не считают серьёзным — дескать, это кодер. Но тут кроется ошибка: если я предложу вам написать драйвер USB-устройства, вы не используете ни одного алгоритма. Но драйвер не напишете (нет, если вы умеете писать драйвера — напишете. А вот так сходу — нет. А книжка на эту тему для Windows толстенная — там много нюансов). Потому что не знаете, как это делать, что вообще для этого нужно, что нужно учесть и из чего вообще состоит драйвер. Вот программист и должен всё подобное знать. В этом его работа и заключается. И так оно и есть — вот тут вам писали, что за 12 лет с алгоритмами не столкнулись ни разу. У меня точно такая же ситуация — ну правда, вот задача: сделать опрос трёх гироблоков по CAN, отработать аварийные ситуации, сохранить данные в файлы, обеспечить оператору интерфейс управления этими гироблоками в ручном и автоматическом режимах (с цепочкой действий по заданной процедуре работы типа включения/отключения и слежения с отработкой аварийных ситуаций), подать данные на модель гироблока и получить результат. Всё это вывести на экран и сохранить в файл. Ну вот где здесь могут появиться деревья, хэши, строки и прочее? Да нигде. И точно так же у разработчиков под микроконтроллеры — у них алгоритмы всплывают очень редко. А когда они нужны, они просто ищутся или придумываются за некоторое время (может даже большое).

те задачи, что я считаю правильным давать на собеседовании


Кстати, а что вы обычно спрашиваете? Просто хочу оценить — я-то в алгоритмике не искушённый, так что взгляд будет достаточно свежий. А то тут задачи часто попадаются такие, что ни в жизнь не догадался бы так решать.
Потому что не знаете, как это делать, что вообще для этого нужно, что нужно учесть и из чего вообще состоит драйвер. Вот программист и должен всё подобное знать.

Не обязательно. Знать подобное должен программист драйверов или микроконтроллеров — вот я, например, не знаю. Наверное, я бы не прошёл собеседование, как и отлично пишущий драйвера, возможно, не пройдёт собеседование ко мне.
Кстати, а что вы обычно спрашиваете?

Лично я уже весьма давно собеседую в основном по скайпу, потому без задач. Что «считаю правильным» — например, уже упоминавшееся «развернуть строку», или «для набора иногда пересекающихся интервалов дат, найти покрывающие их непересекающиеся интервалы». Когда-то давно просил написать свою реализацию HashTable (а с требованием многопоточности хорошо работало как домашнее задание).
За ссылку на задачи спасибо, интересно просмотреть и порешать. Они забавные, но лично я для своего проекта не вижу смысла их спрашивать, то есть не совсем представляю, как умение их решать связано с нашими задачами. Возможно, ребята в Гугле что-то знают на этот счёт. Возможно, у них другие критерии и требования.
Не обязательно.


Речь не о драйверах, как таковых. Знать как написать программу — вот что должен программист.
А вот ответ на «эффект Доплера» и IT. Как видите, даже такой простейший вопрос здесь имеет все шансы на преодоление отметки в 50 лайков. Собственно, этим всё и сказано более чем (голосуют ведь люди с публикациями и кармой больше 4 (редкие люди без публикаций и с достаточной кармой (уж не знаю, как так вышло) погоды не сделают)).
Там скорее люди с кармой больше 4, которые отлично знают разницу между кВтч и кВт, плюсуют человека который наконец-то расписал для тех, кто не знает но и минусовать не может :)
Куда показательнее использование кВт как единицы энергии в статьях с 50 лайками, а такое, к счастью, только в виде опечаток видел.
Блажен кто верует. :) Сами-то лайкнули? ;)
Лайки обсуждать не принято :) Но да, лайкнул, потому что когда-то тоже зацепило и пробовал объяснить это же в комментах.
Про FAANG и так все понятно — сотни постов и тысячи комментов в западной блогосфере написаны на тему сломанности их техинтервью, но ситуацию это не меняет. Что забавно, они тоже пишут что даже там в работе эти алгоритмы реально не нужны.

Нужны. В дополнение к словам senya_z, я cам писал ДП в пакетизации видео данных с разбиениями. И всякие задачи с собеседований, типа максимума в двигающемся окне, тоже приходилось писать. Линейная регрессия, еще, например. Т.е. даже математика бывает нужна, хотя какзалось бы, проект — фактически обертка над видео кодеком, даже не сам кодек.


Да, они нужны не 95% и даже не 10% времени. Но когда они нужны — они реально нужны. Что, в этом случае — иметь в комманде отдельного алгоритмиста-гуру? Во первых, проблема в том, что не имея знаний в алгоритмах, программист даже не будет подозревать, что этот кусок вместо 100 строк рекурсивного мессива полного перебора можно заменить на 20 строк с двумя вложенными циклами и коротким комментарием. Во вторых, простой, вроде бы код, никто кроме этого гуру понимать не будет.

Когда я проводил такие собеседования, то я просто копипастил условия задачи в редактор кода, чтобы у кандидата не оставалось никаких вопросов.

"Не оставалось", говорите? Challenge accepted. Вопросы, их есть у меня.

Зачастую интервьюер действительно хочет посмотреть, какие вопросы задаст кандидат.
да. практически всегда хочет. часто задача формулируется так, чтобы кандидату надо было задавать вопросы, чтобы прийти к решению. вопросы, ход мыслей, процесс решения и общий подход к проблеме часто важнее правильного результата.
Я хоть и не программирую на работе каждый день, но тоже начал в последнее время разбираться с алгоритмами (с универа многое заржавело уже, а многого у нас и не преподавали). А то конторы повадились их давать даже на инженерные позиции, не связанные с разработкой кода непосредственно.
Service Objects это очень удобно. Так у нас получаются тонкие модели, тонкие контроллеры и толстые сервисы, в которые уходит вся логика получения и обработки данных.
Service objects не усложняют архитектуру и позволяют разгрузить модели и контроллеры.

Тег "цiкавi дослiди" — это пять! :)
А что до


«Какой есть недостаток в использовании прокси-AOP по сравнению с AspectJ в Spring?»

это весьма сложно звучащая вещь, но она очень просто проявляется в виде граблей в повседневной жизни обыденных задачах.

но она очень просто проявляется в виде граблей

Если не знаешь этого то можно легко полдня-денёк на дебаг потратить — лично такое наблюдал.
Ага ))) Что интересно — в итоге оффер таки сделали )))
Ну к слову сказать, чтобы девопсить, знать что такое маска подсети не обязательно, действительно.
Ну такое на самом деле, не уверен что это будет хороший девопс учитывая например что в любом мало-мальски большом проекте который хостится в облаке есть публичные и приватные подсети, разнесенные по AZ.

Я-то знал что такое маска подсети (и вообще что такое подсети), но не смог внятно дать определение.
Интересно, что уже довольно большой стек статей про то как везде всё плохо с собеседованиями. Причем в каждой упор на недостатки, а не способы их устранения. Увидим тут когда-нибудь ли мы квинтэссенцию идеального собеседования, хоть сколько нибудь приближенной к реальности?

У меня про паттерны спрашивают постоянно, даже те, кто, по моим ощущениям, сам не очень понимает (тут хватает упоминания аббревиатур без расшифровки :)). Правда, я претендовал на миддла, возможно, собеседующие считают, что senior по умолчанию обязан знать основы проектирования.
Найти максимально длинную последовательность из уникальных символов в заданной строке


Кстати, как вы это решали? Есть какой-то быстрый алгоритм типа подобного?
Кстати, как вы это решали?

В лоб конечно же — иду по строке, сохраняю в буфере текущую подстроку, проверяю, есть ли там уже такой символ, если нет — добавляю его в буфер и двигаюсь дальше по строке, если есть — проверяю длиннее ли эта подстрока текущего максимума и при необходимости заменяю его, и иду дальше начиная с того места, на котором закончил, как-то так.

По этому решению интервьюер не смог меня ничего спросить, так как его вопросы были заточены именно под длину подстроки, её действительно можно решить проще и быстрее.

По моему решению он вроде как согласился что особо тут ничего не соптимизируешь. Да и не стояло у нас такой задачи.

Я предварительно не готовился и не знал, есть ли быстрые решения. Да и сейчас мне это не особо интересно — хотя наверняка что-то можно придумать.
и иду дальше начиная с того места, на котором закончил, как-то так.

Можно тут поподробнее немного? У вас то же, что я описал в этом комментарии, или нет?


По этому решению интервьюер не смог меня ничего спросить, так как его вопросы были заточены именно под длину подстроки, её действительно можно решить проще и быстрее

А как длину можно найти проще и быстрее, чем саму подстроку?

Можно тут поподробнее немного? У вас то же, что я описал в этом комментарии, или нет?

Если я правильно понял, то нет — использовался буфер, который надо проходить заново каждый раз для «проверяю, есть ли там уже такой символ». Именно здесь напрашивается оптимизация вроде хешсета (или как в Вашем решении, с массивом ещё лучше).
В данном случае скорее всего интервьюеру не только сказали дать такую задачу (в чём он явно признался), но и рассказали как свести к вопросу о хешсете, потому что сам он не понимает. Иначе бы он понял, что тут можно прийти ровно к тем же вопросам.
А как длину можно найти проще и быстрее, чем саму подстроку?

На один шаг проще и быстрее, потому что надо сделать то же самое, но не копировать строку. Насколько я понимаю, самый эффективный вариант найти подстроку это найти сначала длину (плюс место), а потом взять там подстроку.

Нет, тут никакие z-функции или префикс функции не помогут. Нужен только массив на 256 элементов/хешмап для обобщенных символов.


Не самое лучшее, но умнее наивного за куб, решение за квадрат примерно такое: Для каждого возможного начала подстроки, жадно удленняем ее, пока не встретим символ, который уже видели. Для отслеживания этого просто считаем в массиве/хешмапе сколько каждых символов уже видели. Когда патаемся добавить новый символ, если уже такой видели — останавливаемся.


Быстрое решение за линию почти такое же. Только не начинаем для каждого начала подстроки считать символы заново. Вместо этого продолжаем с последнего символа для предыдущего начала. Ведь эта новая, на один символ короче строка точно иммет уникальные символы.


Вот примерный код

Можно заменить counts на bool, вместо счетчиков.


size_t LongestUniqueCharsSubstring(const string &s) {
  vector<int> counts(256, 0);
  size_t ans = 0;
  size_t end = 0;
  for (size_t beg = 0; beg < s.length(); ++beg) {
    while (end < s.length() && counts[static_cast<int>(s[end])] == 0) {
      ++counts[static_cast<int>(s[end])];
      ++end;
    }
    if (end - beg > ans) {
      ans = end - beg;
    }
    --counts[static_cast<int>(s[beg])];
  }
  return ans;
}
Линейное решение даже проще:
size_t LongestUniqueCharsSubstring(const string &s) {
  vector<size_t> last(256, -1);
  size_t ans = 0;
  size_t beg = -1;
  for (size_t end = 0; end < s.length(); ++end) {
    int c = static_cast<int>(s[end]);
    if (last[c] > beg) {
      beg = last[c];
    }
    last[c] = end;
    if (end - beg> ans) {
      ans = end - beg;
    }
  }
  return ans;
}
Линейное решение даже проще:

Это субъективная оценка. Ваше решение на 1 строчку длиннее, например, но, по хорошему, я бы тоже должен был сохранить static_cast(end). Какое из двух проще — не очевидно. Мое логически выводится из наивного за кадрат, и поэтому я предпочитаю его.

Я бы сказал, что это 2 одинаково простых решения с разными подходами =)

del. Понял, в чём моя ошибка. Символ с beg выводить не нужно.

(Ну и size_t беззнаковый, его на long надо заменить, раз у вас -1 используется. )
А, ну да. Только тогда уж на какой-нибудь ptrdiff_t или intptr_t…

Там, кстати, ещё и со знаковым char будут проблемы.
Нужен только массив на 256 элементов


Отличный вариант, но тут есть проблема — а вдруг предполагается строка абстрактная. И возможно, скажем, utf-16 или даже utf-32. Но это надо отдельно оговаривать, наверное.

Я этот вариант описал сразу за указанной цитатой: "хешмап для обобщенных символов."

И можно закапываться дальше в собеседование с вопросами «что лучше». Ведь в некоторых случаях массив всё равно лучше.
У вас за линию, как и r0zh0k проблемы с алгоритмом. Например вот такой набор символов даст не правильный результат — абвгдвежз.
Public string GetMaxUniqueSubstring(string toCheck)
{
  var checkingSubStringQueue = new Queue<char>();
  var checkingSubStringSet = new Hashset<char>();
  String result =string.Empty;
  for (int i=0;i<toCheck.Length;i++)
  {
    Char pointer =toCheck[i];
    if (checkingSubStringSet.Contains(pointer))
    {
      String testStr = new String(checkingSubStringQueue.ToArray());
      if (testStr.Length>result.Length)
      {
         result=testStr;
      }
      Bool end = false;
      while(!end)
      {
        Char test = checkingSubStringQueue.Dequeue();
        checkingSubStringSet.Remove(test);
        if (test==pointer)
        {
          checkingSubStringQueue.Enqueue(pointer);
          checkingSubStringSet.Add(pointer);
          end=true;
         }
      }
    }
    else
    {
      checkingSubStringQueue.Enqueue(pointer);
      checkingSubStringSet.Add(pointer);
    }
  }
  return result;
}

У вас за линию, как и r0zh0k проблемы с алгоритмом. Например вот такой набор символов даст не правильный результат — абвгдвежз.

Не согласен.


Мое решение при beg==0 увеличит end до 5, где остновится по условию
counts[static_cast(s[end])] == 0. Запомнит как возможный ответ "абвгд". При beg==1 или 2, end по той же причине не сдвинется. При beg=3, end сдвинется до конца и мое решение найдет "гдвежз" в качестве ответа.

Ваше же решение, во первых, за квадрат, потому что вы делаете checkingSubStringQueue.ToArray() каждый раз и на тесте "abcdefghijabcdefghij" оно выполнится n/2 раз, при этом состоя из n/2 символов (Формально, в случае ограниченного алфавита, ваше решение не квадрат, а O(An), вместо O(n), как у меня). Во вторых, если его вылизать, будет в почти то же самое, что и у r0zh0k (хоть это и не совсем очевидно).


Вместо очереди вам надо хранить только индексы beg и end, ведь очередь у вас всегда содержит подряд идущие символы. Тогда и toString() никакой вызывать не надо, можно вместо .Length() взять end-beg (вот и соптимизировали до нормалной линии).


Добавление символа в хешсет и очередь у вас всегда происходит в обеих ветках if/else, его можно вынести в конец, после if.


В итоге получится, как у r0zh0k, внешний цикл по end, а внутри, вместо прыжка сразу куда надо, Вы по одному символу, как у меня, удаляете их из хешсета, пока не освободите место для s[end].

Только не начинаем для каждого начала подстроки считать символы заново. Вместо этого продолжаем с последнего символа для предыдущего начала
Прокомментировал вот это текстовое описание алгоритма(у меня начало из 2го предложения проассоциировалось с началом подстроки из первого), каюсь, код не смотрел.
Посмотрел — согласен с Вами.
Что касается моего кода:
Писал ночью… в блокноте… на планшете… там еще если все символы уникальны не сработает…
Если верить microsoft то квадрата в этом месте не будет.
Засада в другом — checkingSubStringQueue.Enqueue(pointer)

Нет, имено тут засада: в toArray методе идет копирование массива в новый. А потом еще раз, когда вы над ним строку делаете (но тут я не уверен).


У разработчиков .net, похоже, есть достаточно здравого смысла, что бы эта Queue также как и c++ vector удлинялась в 2 раза, если надо. Поэтому суммарно все удлинения займут линейное время. Так что с Enqueue проблем нет (кроме ненужности очереди, как таковой).

Статью обсуждать не буду, меня заинтересовал вот этот момент:
Java Developer

«Найти максимально длинную последовательность из уникальных символов в заданной строке»


Кто как прокомментирует такое решение:
for(String a: new String[] {"abc*de**ffasd***dsa", "*", "", null}) {
      if(a != null) {
        System.out.println(Arrays.stream(a.split("[^*]"))
          .max(Comparator.comparingInt(String::length))
          .orElse("")
          .length());
      } else {
        System.out.println("Null!");
      }
    }
?
А звездочки зачем? ))) Причем тут split?
И найти надо не длину последовательности, а саму последовательность.
Звёздочки — потому что неверно задание понял, решил что искать надо последовательность определенных, а не уникальных символов. Тогда, конечно, решение неверное, хорошо ещё что я потратил на него меньше минуты.
Сейчас пилю проект где серверная часть на Python (flask, asyncio, sqlalchemy, jinja2), база на PostgreSQL, для кеширования и как брокер сообщений Redis, клиентская браузерная часть html5, CSS3, JavaScript (vue), клиентская мобильная часть Kotlin (rxjava, retrofit), используется паттерн MVVM. Все это взаимодействует через API (json-rpc) и WebSocket, периодически данные выгружаются из 1С (используя HTTP-сервисы 1с). Все это располагается на Linux VDS сервере (Nginx). Кроме этого всего, за годы программирования было изучено огромное количество других языков таких как C#, C++, PHP и т.д. НО! Как только я начитаю читать такие статьи, я понимаю, что меня не взяли бы даже на позицию джуниора. Хорошо грузчикам: не пьет – принят :)
И еще проблемы такие детские типа один метод, плоховато работает)) Когда у тебя сто тыщ строк кода написаны через жопу и работают вкривь и вкось, чуть что тронешь все разваливается, то починить один метод, который неээфективно сумму скобок считает — да это в радость))))
А как же вывод, что нытиков никто не любит?
Выскажусь на тему собеседований — ещё до собеседования интересуйтесь, каким образом компания ищет человека: берет сразу, как найдёт нужного, или выбирает. Это крайне важно для понимания дальнейшей работы в этой компании. Компания, которая выбирает из кандидатов, точно не знает, кто ей нужен и берет людей по принципу «нравится». В такой компании и команде каши не сваришь. Не тратьте свое время на собеседования с ними
Выбирают обычно компании, у которых одна негорящая вакансия и большой поток формально подходящих кандидатов. И «нравится» не последнюю роль играет — совместная работа, как минимум, негативных эмоций не должна приносить.
Как-то сомнительно идти на работу, где ты не очень то и нужен (негорящая вакансия). Вдруг тебе со временем и не очень то платить захотят
Я бы сказал наоборот, стрёмно идти на горящую вакансию. Это значит, что фирма не смогла хорошо распланировать и готова брать кого угодно. Как раз со временем планы могут поменяться и окажется что этот «кто угодно» им не нужен.
С нормальным планированием и отбором надёжнее. Иногда.
Есть компании, которые постоянно набирают подходящих им кандидатов, у них одна вакансия может висеть годами (обновляясь, конечно) и десятки людей по ней берут, особо не торопясь, выбирая только тех, кто не только обладает нужными техническими знаниями, но и хорошо впишется в коллектив.

А вот с горящими как раз риски выше. Сейчас они тебе готовы заплатить на 30% выше рынка, а потом не спеша найдут ещё одного и тебя уволят, ну или понизят зп. Или годами повышать не будут.
Смысл проходить интервью с «тупыми» вопросами? мне не интересно работать с людьми которые ни чего интересного спросить не могут. Всегда плыву на вопросах по теории и по практике :) потому что тоже писал на тысяче и одном языке, и что там где как ни когда не помню, гугл всегда поможет.
Когда сам провожу собеседования, то просто смотрю на код тестового и мы обсуждаем его, считаю этого достаточно.
Смысл проходить интервью с «тупыми» вопросами?

Кто ж знает наперед что они «тупые»? Все это выясняется уже когда поздно…
я к тому что бы не парить себе мозг штудированием ответов на стандартные вопросы, и на самом собеседовании не обломаться сказать «я не в курсе но я умею читать доки и меня не забанили в гугле»
на самом собеседовании не обломаться сказать «я не в курсе но я умею читать доки и меня не забанили в гугле»

Я так говорил, но это не прокатывало. Особенно смешно было с тем самым методом compact, который фильтрует нилы в коллекции.
главное не расстраиваться. у меня было овер дофига собеседований гдеменя из-за подобных вещей не брали, но я ни окгда об этом не жалел
когда на большую часть вопросов кандидат отвечает «меня не забанили в гугле», то шансов мало. когда он знает, в какую сторону копать, но не помнит каких-то деталей, то ответ про гугл принимается. например, решает задачу поиска пути конем на шахматной доске через BFS, при этом говорит, что она может быть улучшена через A*, но он не помнит, как это сделать — в реальной жизни нагуглил бы за 5 минут.
В реальной жизни он с вероятностью 0% будет решать «задачу поиска пути конем на шахматной доске» и с вероятностью -0% будет самостоятельно велосипедить для этого алгоритм. Иначе — только соболезнования.

Одним из наиболее интересных вопросов, полученных мною на собеседованиях (и который я сам теперь иногда задаю, не очень часто, и только матёрым кандидатам), был вопрос вида:

«Есть некая техническая проблема, вот тебе распечатки свежих статей, как люди её решают, выбери оптимальный способ по минимизации заданных параметров X и Y и набросай основу алгоритма, потом поговорим. Гуглить дополнительную информацию можно, реализацию, исходники — нельзя. Экран ноута пишется, проверяется только использование Интернета, на мыкания в редакторе внимания не обращаем.»
У меня в универе преподавательница на первом курсе вынуждала писать код на С++ на бумажке. И ладно бы простые циклы/условия/переменные в стеке.
Едва ли не на уровне битовых операций писать заставляла.
На втором поменялся преподаватель — зная, что лабу я сдаю на Java (RESTful микросервис с каким-либо фронтом, «абы было, на красоту мне все равно»), несколько человек пишут на Django, ещё несколько вообще десктопное приложение на C# и WPF пишут, все ещё требовал учить на экзамен какие-то базовые приколы С++ типа зачем обнулять указатели, что такое битовые поля, специфика наследования в С++ (это джависту, питонщикам и дотнетовцам!).
Завалился я на вопросе «в чем отличие struct от class», потому что в моём любимом языке нет нет таких заморочек, а к экзамену я такого вопроса не готовил :))

Многопоточности к слову не было, её тихо отрицали, как явление :(

Это я к чему. Всё эти собеседования бесконечно близки к экзаменам в универе — без бумажки сходу назвать какие-то методы, которые гуглятся в две секунды (один клик в официальную документацию — профит). Я проходил два собеседования по JS на должность «ближе к джуну, но вообще ищем миддла», на одном из них мне показали реальный код ошибки в консоли Хрома, на другом — я решал алгоритмическую задачу в духе «перевернуть массив с повторяющимися элементами».
Если первое — вполне себе вменяемо, потому что с консолью фронтэндщику нужно каждый день работать, то второе просто ??? А зачем мне вообще переворачивать массивы руками? Если я буду писать на Python, я сделаю [::-1], на JS — myArray.reverse() и ничего не потеряю в скорости работы + я не думаю, что писать велосипеды на реальной работе — гуд.

На собеседовании по QA мне дали несложную логическую задачку, посмотреть на ход мышления. И мне это понравилось больше, чем извращаться с алгоритмами, 99% из которых реализованы в стандартных библиотеках, а 1% мне понадобится писать на должности сеньйора, до которого ещё дожить нужно.

P.S.
Собеседования проходил давно, алгоритмические задачи люблю, но не считаю, что умение построить красно-чёрное дерево/написать свою реализаю хэш-мапы/реализовать свой класс динамического массива — задача, которую будешь делать в реальной жизни каждый день.
«перевернуть массив с повторяющимися элементами»…
на JS — myArray.reverse() и ничего не потеряю в скорости работы + я не думаю, что писать велосипеды на реальной работе — гуд

И это ИМХО отличный правильный ответ.
После которого неплохо бы написать хоть какой-то алгоритм именно для «посмотреть на ход мышления». На таком примитивном примере видно, насколько человек дружит с математикой и логикой. Хотя бы то немногое, что можно проверить на собеседовании.
У меня в универе преподавательница на первом курсе вынуждала писать код на С++ на бумажке. И ладно бы простые циклы/условия/переменные в стеке.


У меня на первом курсе пришёл дядя с кафедры высшей математики и изнасиловал нас Derive, Mathlab и численными методами. :) Что характерно, он всё доказывал, но часто ошибался и доказательство не получалось. «Ну исправите, там очевидно», говорил он. :) Как бы не так.

Articles