Комментарии 342
Спасибо за то, что поделились опытом, и за ссылки на материалы.
Куда, если не секрет, получили оффер?
Куда, если не секрет, получили оффер?
Рада, что статья показалась полезной. Получила офферы в Amazon и Microsoft.
позиция какого уровня?
60 в Microsoft, SDE I в Amazon (вот здесь их удобно сравнивать). Вообще, они занижают уровни по сравнению с нынешней позицией и опытом. А Amazon еще и сбавил уровень из-за прохождения system design части, о которой я упоминала в статье.
НЛО прилетело и опубликовало эту надпись здесь
Вы про зарплату или грейды? Было бы интересно узнать реальные данные, если можете поделиться.
НЛО прилетело и опубликовало эту надпись здесь
В США часто используют «Total Compensation» (TC) в подобных сравнениях. Что-то вроде «годовая зарплата + стоимость опций\кол-во лет + sign-up бонус\кол-во лет + ежегодный рефрешер». В случае с FAANG — это может быть довольно серьезными суммами. Плюс на многие позиции компании готовы на контр-офферы, кандидат с офферами от Facebook и Snap может выйти за «обычные» рамки при некоторых обстоятельствах
НЛО прилетело и опубликовало эту надпись здесь
А какой у них план работы в связи с повсеместными карантинами? Удаленно или как-то перевозить будут?
НЛО прилетело и опубликовало эту надпись здесь
А в результате все это оказывается никому не нужным.
Во-первых, хорошо, что перестали спрашивать про теннисные мячи в автобусе, это все-таки уже ближе к реальности. И тенденция идет в сторону менее «красивых» и более прикладных задач. Во-вторых, некоторым эти алгоритмы все же нужны (например, вот). А в-третьих, мне кажется, нужно к этому относиться как к экзамену, там ведь тоже часто спрашивают абстрактные вещи. Эти компании нанимают людей без привязки к языку и технологиям, при этом они пытаются оценить кандидата.
А вот меня спрашивали про теннисные мячики, количество канализационных люков на определенной улице и также количество машин на отрезке дороги в час пик. Такие интервьюверы порой сами не далёкие люди, особенно когда с листка зачитывают, всю эту ересь.
В условных "ООО рога и копыта" верстальщику формочек — возможно это и не надо. А в FAANG такие алгоритмические задачи возникают в процессе работы. Вот, недавняя статья от яндекса приводит несколько примеров практически задач с собеседования, которые возникли в процессе нормальной обычной работы. Я сам в одной из FAANG компаний задаю на интервью именно ту задачу, которую решал во время работы. И там и про ассимптотику спросить можно и динамическое программирование написать в качестве хорошего решения.
Да, это происходит не каждый день, но когда оно происходит, то алгоритмические знания и умение решать алгоритмические задачи действительно нужны.
Добавьте к этому, что большим компаниям нужны стандартизованные, объективные критерии, как можно лучше коррелирующие с качеством нанимаемого программиста, которые можно оценить на интервью, и получится, что алгоритмические задачи — весьма неплохой вариант.
Какие есть альтернативы? Испытательный срок — дорого и не скейлится. Поговорить о жизни/что вы думаете по поводу технологии X — не формализуется и легко проходится теми у кого язык хорошо подвешан, даже если они писать код не могут вообще. Смотреть код с гитхаба — не у всех он есть, да и невозможно проверить, что этот код кандидат сможет воспроизвести. Тестовое задание — те же алгоритмические задачки, но тратит больше ресурсов и кандидата и компании, да и читерить на них могут запросто.
Но если кандидат решил алгоритмическую задачу, написал вменяемый код — значит он способен, во первых, вменяемый код писать, и писать достаточно быстро; он способен мыслить абстрактно и, когда сложная задача возникнет в процессе работы, он сможет ее решить, или хотя бы поймет, что тут не надо делать "пирамидку из for" и спросит помощи. В противном случае даже мысли не возникнет о том, что тут есть какое-то более элегантное, на порядки быстрее и короче решение.
Тестовое задание — те же алгоритмические задачки, но тратит больше ресурсов и кандидата и компании, да и читерить на них могут запросто.
Судя по этой статье, тестовое задание требует меньше ресурсов кандидата, чем алгоритмические задачи: на тестовое задание я могу убить неделю (вечерами после работы), если настроение будет, а решать leetcode по таймеру месяц я не буду.
Тут нельзя так однобоко считать. Leetcode вы один раз в жизни порешали месяц и потом перед каждым интервью один день повторили, а тестовое задание вам при каждом интервью придется делать неделю. 4 интервью — и вы уже суммарно больше времени на тестовые потратили.
Потом, это от человека зависит. Если computer science курс какой-то был, то месяц вам не понадобится — пару недель максимум.
тестовое задание вам при каждом интервью придется делать неделю
Тестовые бывают на полную рабочую неделю, но не так часто.
Насчёт сроков по Leetcode не соглашусь. Если не было опыта спортивного программирования, то за две недели подготовиться будет очень сложно. Подтверждение тому множество статей, подобные этой, а также истории кандидатов с Leetcode.
Leetcode вы один раз в жизни порешали месяц и потом перед каждым интервью один день повторили
Переносимость действительно работает и сухой остаток от решения задач есть, но без повторения уровень понемногу снижается.
Leetcode вы один раз в жизни порешали месяц и потом перед каждым интервью один день повторилиОдин раз в жизни. Ну, ну)
Может вы сможете сдать практически без подготовки ГОСы и любой экзамен, который сдавали в прошлом? Еще и с той же скоростью.
Людям свойственно забывать то, чем они не пользуются. Если на работе сложные алгоритмические задачи приходится решать реже раза в месяц, то перед собеседованием на новую работу снова придется месяц решать задачи из Leetcode.
Что касается поиска работы, то в идеале перед каждым новым поиском работы надо месяц порешать алгоритмы, месяц повторить и зазубрить теорию (вроде тонкостей языка, которые в работе не используешь), месяц поизучать то, что актуально на рынке, но что в работе ты не используешь, месяц походить на собеседования для тренировки, чтобы прокачать навык прохождения собеседований. После этого можно рассчитывать устроиться на ту же должность или выше в другую компанию. Итого, 4 месяца получилось. В итоге на новой работе большинство из изученного/повторенного окажется не нужным и через n лет при смене работы снова все это учить/повторять. Но можно сократить раза в 2 длительность подготовки, отсеяв 90% компаний, где собеседующий требует написать алгоритм на листочке, или перечислить, какие методы есть у стандартного класса Object, или спрашивающий, что выдаст [] + {}.
Насчет алгоритмов, добавлю еще, что программист первокурсник уделает по скорости решения алгоритмических задач практически любого программиста последнего курса. А тот уделает в этом практически любого сеньора. Т.к. все зависит от того, как часто приходится писать алгоритмы. Студенты, особенно на первых курсах, этим занимаются чаще.
В итоге на новой работе большинство из изученного/повторенного окажется не нужным и через n лет при смене работы снова все это учить/повторять.
И так почти на каждой работе. И я вот тоже не понимаю смысла в этом.
Да, я понимаю, если спрашивают то, с чем постоянно работаешь. Это нормально, это действительно понадобиться. На деле же много чего из спрашиваемого не нужно. Но мы же будем спрашивать и отсеивать тех, кто не знает.
первокурсник уделает по скорости решения алгоритмических задач практически любого программиста последнего курса. А тот уделает в этом практически любого сеньора.
Ну, если сеньор не может за 25 минут написать решение для "найдите длину наибольшего отрезка из единиц в массиве заполненном нулями и единицами", даже с подсказками, то грош цена такому сеньору.
Ну, вы почитайте саму статью, что привели и процитированные там комментарии с quora. Сам автор homebrew говорит, что его в твите не поняли, и наверно честно, что его не приняли в гугл. Там куча ответов вида, что чуваку надо было идти на PM, а не SWE.
Создание хоть и популярного и очень полезного продукта не говорит, что чувак крутой программист. У гугла реально возникает потребность инвертировать деревья или что-то подобное. А homebrew — не то что бы слишком сложный продукт.
НЛО прилетело и опубликовало эту надпись здесь
Этого, этого уровня сложности задачи. И некоторые «синьоры» не могут их решить, закапываются на краевых условиях, например. Это же те секции/сессии, на которых проверяют, что кандидат в принципе способен нормальный код писать.
НЛО прилетело и опубликовало эту надпись здесь
Можно и по другому решить: делается quicksort, при этом каждый раз отбирается та половина, где больше элементов. До тех пор пока в меньшей половине не останется 0 элементов.В этом случае, решение — в большей половине. Аппроксимационная сложность = O(2N).
Да, я не Бойер и не Мур.
Справедливости ради, приведенное решение, конечно, не такое элегантное и работает только если исходный массив можно менять
Да, я не Бойер и не Мур.
Справедливости ради, приведенное решение, конечно, не такое элегантное и работает только если исходный массив можно менять
НЛО прилетело и опубликовало эту надпись здесь
Нам не нужно сортировать весь массив, а только ту часть, где самый распространённый элемент. То есть в первый проход мы сделаем N сравнений, во второй — условно N/2, в третий — N/4 и т.д.
В условии не говорится, что массив нельзя менять
В условии не говорится, что массив нельзя менять
А как понять какой элемент самый распространённый (чтобы понять, какую половину сортировать), ведь задача и состоит в поиске этого элемента? Если я в курсе что это за элемент я и сортировать ничего не буду.
P.S.
Ничего умнее map<int,int> я не придумаю, да и в целом не буду. На моей памяти ни мне, ни кому-то из тех кого я знаю не потребовалось решать задач, в которых бы понадобились эти знания.
P.P.S.
Я очень рад за тех людей, которые встречаются с такими задачами. Мне обычно приходится решать какие-то более приземленные задачи.
Будет понятнее, если переформулировать решение. Этот самый распространенный элемент обязательно будет и медианой. Потому что в отсортированном массиве он будет занимать отрезок длиннее половины массива. Как этот отрезок не располагай, он будет пересекать середину. А дальше применяется более менее известный QuickSelect для поиска медианы — модификация QuickSort, которая может за O(n) в среднем выдать k-ый элемент.
Тут как в сортировке делается разбиение, а потом запускается рекурсия только в одной половине, в которой находится искомый элемент.
У Бойера-Мура конечно более изящное решение — не меняет входные данные и сложность стабильно O(N)
Мне, например, даже после прочтения этого алгоритма до конца непонятно, почему он работает.
О, я как раз про эту задачу писал хабрапост с подробным разбором алгоритма.
Ну так начинать то надо с чего либо?
Да собственно даже на простых задачах люди заваливаются. Да и у простой задачи обычно можно придумать усложнение.
Да собственно даже на простых задачах люди заваливаются. Да и у простой задачи обычно можно придумать усложнение.
Ну, если сеньор не может за 25 минут написать решение для "найдите длину наибольшего отрезка из единиц в массиве заполненном нулями и единицами", даже с подсказками, то грош цена такому сеньору.
Ну, я вот нашел эту задачу на leetcode, написал решение минуты за 3, работает за линейное время, тесты вроде проходит. Значит ли это, что я senior? Да ни разу, в Google меня, боюсь, не возьмут даже в качестве L3 (вообще, куда-то формошлепить под android меня, может быть, даже и взяли на позицию senior, но senior в такой конторке и senior в Google — это, как говорится, две большие разницы). Как минимум, потому что умения решать задачки уровня easy с leetcode для собеседования в Google недостаточно.
НЛО прилетело и опубликовало эту надпись здесь
распечатать 2000-ое число из упорядоченного естественным образом множества { 2i3j5k | i, j, k ∊ ℕ } с таким-то лимитом по временим
Перечитал несколько раз и всё равно нифига не понял задачу. :) 2i3j5k | i, j, k ∊ ℕ — это вот как понимать?
НЛО прилетело и опубликовало эту надпись здесь
Понятно. То есть, вся штука в том, что ряд чисел стандартного ряда таким множеством непредставимы, а потому 2000-е число не будет 2000. Верно?
Нет. Возмите все натуральные числа. Выкиньте все, что делятся на что-то кроме 2, 3 или 5. Из отсавшихся возмите 2000-ое число. Число 2000 там останется, но до него будет выкинуто много чисел (7, например). Т.ч. 2000-ое число точно больше 2000.
По-моему, это тоже самое, что я и написал. 7 непредставимо, 11, 13, 14 и так далее тоже непредставимы. В общем, смысл понятен.
А что если взять первое число — это 1, и дальше строить ряд, увеличивая на один степень 5 (как максимального числа) и добегая до неё степенями 3, а потом двойки, считая числа в порядке возрастания? Надо проверить, что получается.
А что если взять первое число — это 1, и дальше строить ряд, увеличивая на один степень 5 (как максимального числа) и добегая до неё степенями 3, а потом двойки, считая числа в порядке возрастания? Надо проверить, что получается.
Если определение верно, то что в этом ряду делает 1?
Видимо, ошибка в постановке задачи. Если там действительно i,j,k — натуральные числа, то ни 1, ни 2, ни 5 не содержатся в ответе, т.к. любое число должно делится хотя бы по разу и на 2, и на 3, и на 5. Очевидно, там имелось ввиду "неотрицательные целые числа".
НЛО прилетело и опубликовало эту надпись здесь
Я тоже считаю, что так было бы логичнее. Но, если мне не изменяет память, ноль в натуральных числах не значится.
Встречаются оба варианта. В России традиционно 0 не считается натуральным числом, но практически во всем остальном мире (включая стандарт ISO 80000-2) — считается. Если смотреть объективно то ни с чисто математической точки зрения ни даже с логической нет никаких поводов не включать ноль в натуральные числа. К примеру если рассматривать число как количество объектов (мощность множества) что является очень естественным подходом, то там никуда не деться от пустого множества. Короче счет от 1 — это еще одна «славная» советская традиция, ритуализированная но не имеющая особого смысла.
НЛО прилетело и опубликовало эту надпись здесь
Я когда писал комментарий специально поискал студенческие лекции в Интернете. Начинают с единицы, увы. РуВики дает ссылки например на такой учебник
Есть 2 решения. Одно попроще придумывается и принимается на хорошее знание алгоритмов. Если нет косяков с кодом, то это будет hire от меня. Второе быстрее и элегантнее, но его посложнее придумывать.
Первое решение такое:
Достаточно держать heap из потенциальных следующих элементов.
Изначально кладем туда 1 (видимо, в виде {0, 0, 0, log(2)*0+log(3)*0+log(5)*0}, чтобы bigint-ы не сравнивать и не считать).
Потом, пока не набралось n чисел, берем минимальное число из heap-а как следующее по порядку. Потом "умножем" его 2, 3, и 5 (на самом деле не умножем, а прибавляем 1 в нужное поле и нужный лог куда надо). Эти 3 числа, если они еще не были добавлены в heap туда суем. Тут можно использовать hash-set, чтобы несколько раз не добавлять число. Или можно добавлять число в любом случае, но тогда надо будет возможно одинаковые числа вытаскивать из начала хипа и там будет в 3 раза больше чисел.
Это решение за O(n log n) по времени и линейное по памяти (всего в хипе будет до 9*n чисел). При этом для экономии времени можно сказать "допустим у нас есть класс, который числа такого вида хранит и сравнивает быстро в виде тройки степеней и логрифма. Для не очень большого n точности double должно хаватать." Писать его не нужно, достаточно описать в каком виде он хранит и что делает. Для первого приближения можно вообще bigint использовать, но я обязательно подскажу, а нельзя ли тут как-то побыстрее сравнивать. Писать heap и hash set не надо! Можно знать про std::priority_queue и std::unordered_set или вообще сказать, что пусть у нас есть такие классы. Они точно есть в стандарте, но я точно не помню. Я за это "баллы" не снимаю (ведь на самой работе у вас будет интернет и ide).
Набросок кода
class Number; // Holds 2^a*3^b*5^c efficiently, can compare and multiply by 2,3, or 5.
Number GetNthNumber(size_t n) {
std::priority_queue<Number> next;
next.push_back(Number(2));
next.push_back(Number(3));
next.push_back(Number(5));
size_t processed = 1;
Number current = Number(1);
while (processed < n) {
Number next = next.pop_back();
if (current == next) continue;
next.push_back(next * 2);
next.push_back(next * 3);
next.push_back(next * 5);
current = next;
++processed;
}
return current;
}Второе решение линейное и по времени и по памяти. Нужно заметить, что любое число нужного вида можно получить из какого-то ранее известного числа умножением на 2, 3, и 5. Если мы сгенерим все числа до k-ого, и умножим из все на 2, 3 и 5 и смерджим все три списка, то точно сгенерим k+1-ое число. Эту операцию можно делать лениво. Это что-то типа того как ленивый haskell будет работать. Заведем список всех сгенеренных чисел и будем смотреть, какое минимальное число при умножении на 2, 3, и 5 в нем еще не содержится. Это такие 3 указателя. Каждый раз двигаем вперед один из указателей и дописываем новое число к концу списка.
код
class Number;
Number GetNthNumber(size_t n) {
std::vector<Number> numbers(n);
n[0] = Number(1);
int next2=0, next3=0, next5=0;
Number next2Number = Number(2);
Number next3Number = Number(3);
Number next5Number = Number(5);
for (size_t i = 1; i < n; ++i) {
if (next2Number < next3Number && next2Number < next5Number) {
numbers[i] = next2Number;
next2Number = numbers[++next2] * 2;
} else {
if (next3Number < next5Number) {
numbers[i] = next3Number;
next3Number = numbers[++next3] * 3;
} else {
numbers[i] = next5Number;
next5Number = numbers[++next5] * 5;
}
}
}
return numbers[n-1];
}Edit: исправил пару опечаток в коде. На интервью, я намекаю кандидату, если выижу опечатку вроде "в этой строчке похоже опечатка". Баллы за опечатки вида 3 вместо 5 в названии переменной не снимаются.
Эта задача, как оказывается, довольно широко известна в узких кругах. И решения для нее написаны на куче языков: Hamming numbers
Кстати эта отличная задача и порешать ее можно (с хорошими советами, если потребуются) самому тут, а потом обязательно посмотреть топовые решения. Многие изложенные тут в комментариях идеи неоптимальны, попробуйте сами!
программист первокурсник уделает по скорости решения алгоритмических задач практически любого программиста последнего курса. А тот уделает в этом практически любого сеньора.
Курсы в ВУЗах в основном теоретические и те люди, о которых вы говорите, могут взяться только из кружков по спортивному программированию. А у сеньоров есть преимущество на собеседовании по system design.
Ну, там хотя-бы немного лабораторных работ есть на первых курсах, где надо реализовать какие-то алгоритмы (работа с деревьями, алгоритмы поиска/сортировки, хэш-таблицы). Плюс программисты часто не только себе эти лабы делают, но и другим помогают.
А у сеньоров есть преимущество на собеседовании по system designЕсли вопросы на собеседовании дойдут до system design.
Ну, там хотя-бы немного лабораторных работ есть на первых курсах, где надо реализовать какие-то алгоритмы (работа с деревьями, алгоритмы поиска/сортировки, хэш-таблицы).
Да, только это надо сделать за 20 минут и еще успеть выбрать оптимальный подход к решению.
Если вопросы на собеседовании дойдут до system design.
Если пройти телефонное собеседование и system design предусмотрен, он обязательно будет.
Если пройти телефонное собеседование и system design предусмотрен, он обязательно будет.
Это зависит от компаний и тех, кто собеседует. Мы же сейчас говорим не про какие-то конкретные?
Некоторые могут собеседование прекратить после первых двух неудачных вопросов по «основам».
Это зависит от компаний и тех, кто собеседует. Мы же сейчас говорим не про какие-то конкретные?
Как минимум те четыре компании, которые я рассматриваю в статье. На очном этапе у них стандартный процесс, и они не могут прекратить его раньше времени.
Кстати, мне стало интересно. Если в таких компаниях прошел какой-то этап, но завалил следующий, и через какой-то промежуток времени пытаешься пройти снова, то нужно снова проходить с первого этапа? Или же достижение сохранено?)
Насколько я знаю, если завалил что-то на очном, то потом всё заново. Если со скрипом пройти телефонное с подсказками интервьюера — могут назначить повторное такое же. Но если однажды дойти до оффера, то появляется больше опций. Например, в Amazon оффер действует полгода, а после этого, если решишь снова собеседоваться, то попадёшь сразу на очный этап.
Я года 3 назад решал leetcode ради одного интервью. Интевью прошёл — работу получил и сразу же всё забыл. Абсолютно ненужная мне инфа выветривается из головы примерно за год.
Ну тут как сказать. Я вот из комментариев узнал про «Алгоритм большинства голосов Бойера — Мура» и точно могу сказать, что если эта задача передо мною встанет, то, даже если я не помню алгоритм, я уже знаю о его существовании. И смогу быстро найти инфо. Так же и с задачками. Алгоритмы, которые ты узнаешь при их решении — знание о них останется с тобой.
Собственно, олимпиадник детектед.
Умение решать на доске маркером за 10 минут без интернета?
О да, и как же компании проверяют, когда дают тестовое задание на дом? Там ведь тоже кто угодно сделать может. Дайте подумать, может задают вопросы по коду?
P.S: Я не против олимпиадников, просто подзадолбал неуместный элитизм некоторых представителей, которые могут написать на доске merge sort на С++ и при этом в реальных проектах пишут неподдерживаемый говнокод.
Да, это происходит не каждый день, но когда оно происходит, то алгоритмические знания и умение решать алгоритмические задачи действительно нужны.
Умение решать на доске маркером за 10 минут без интернета?
Смотреть код с гитхаба — не у всех он есть, да и невозможно проверить, что этот код кандидат сможет воспроизвести.
О да, и как же компании проверяют, когда дают тестовое задание на дом? Там ведь тоже кто угодно сделать может. Дайте подумать, может задают вопросы по коду?
P.S: Я не против олимпиадников, просто подзадолбал неуместный элитизм некоторых представителей, которые могут написать на доске merge sort на С++ и при этом в реальных проектах пишут неподдерживаемый говнокод.
Умение решать на доске маркером за 10 минут без интернета?
В гугле уже давно интервью проходят на ноутбуке. Задачи подбираются так, что 25 минут чистого кодирования должно хватать выше крыши. Да, без интернета, потому что проверяется способность кандидата решить проблему, если не удалось найти код на стекофервлоу, чтобы его скопипастить.
О да, и как же компании проверяют, когда дают тестовое задание на дом? Там ведь тоже кто угодно сделать может. Дайте подумать, может задают вопросы по коду?
Согласитесь, есть вариант взять старшего товарища, который решит вам тестовое и все объяснит. Это на порядок проще, чем самому писать. Желающих получить хорошую зарплату и все плюшки(а дальше, может и так справлюсь) — довольно много. Реально попадались люди, которые fizz buzz написать не могут, а на интервью подают (ну а вдруг?!). Еще была байка про китайца, который на интервью отправил похожего на себя друга, который интервью за него прошел, а сам вообще ничего сделать не мог.
Соответственно, будет далеко не нулевая доля кандидатов, которые могут решение понять и объяснить, но сами такой код написать не могут. Когда у вас тысячи нанимаемых людей в год, это выражается в ощутимом количестве новых работников, которые плохо справляются со своими задачами. А это большие потери для компании.
которые могут написать на доске merge sort на С++ и при этом в реальных проектах пишут неподдерживаемый говнокод.
На интервью даются подсказки и комментарии. Если условный олимпиадник пишет "олимпиадный", неподдерживаемый говнокод, ему это сразу же сообщается. Если кандидат так и не может написать читаемый код, даже если задача решена гениальным алгоритмом, в соответствующей графе записывается жирный минус. Если на всех 4-5 кодо-интервью будет говнокод, то вряд ли будет офер.
Да, без интернета, потому что проверяется способность кандидата решить проблему, если не удалось найти код на стекофервлоу, чтобы его скопипастить.
То есть надо не просто решить проблему, а сделать это с идиотскими ограничениями, которых никогда нет в реальных проектах. Часто от кандидатов ожидается зубрежка типовых решений типовых задач, которые легко гуглятся.
Реально попадались люди, которые fizz buzz написать не могут, а на интервью подают (ну а вдруг?!)
Это не новость для любого, кто проводил интервью в любой более-менее крупной конторе (далеко не уровня гугла).
Соответственно, будет далеко не нулевая доля кандидатов, которые могут решение понять и объяснить, но сами такой код написать не могут.
С чего вы взяли, что не могут? Если ты понимаешь решение, ты можешь его воспроизвести.
P.S. Обычно все это просто от неумения проводить интервью. Вроде тех знаменитых загадок в гугле про пианистов и канализационные люки.
То есть надо не просто решить проблему, а сделать это с идиотскими ограничениями, которых никогда нет в реальных проектах. Часто от кандидатов ожидается зубрежка типовых решений типовых задач, которые легко гуглятся.
Почему никогда нет?! Вы утверждаете, что решение любой задачи можно найти в интернете? Проверять именно вариант ненайденного решения имеет смысл, потому что копипастить код с stackoverflow может даже обезьяна. Интервью с интернетом или может отсеивать только полных идиотов, или тогда надо кандидату не решать задачу, а писать целые эссе на тему, какие решения найдены, чем они хороши, почему именно это выбрано и куча рассуждений, доказывающих, что кандидат понял решение, а не скопипастил первое попавшееся, где ключевые слова нашлись на странице. Но эти эссе проверять слишком долго. Или тогда обсуждать найденное решение надо несколько часов.
С чего вы взяли, что не могут? Если ты понимаешь решение, ты можешь его воспроизвести.
То же и с языком. Есть довольно широкий диапазон владения иностранным языком, когда читать и понимать можешь, а сказать — почти ни слова.
Тут то же самое.
Обычно все это просто от неумения проводить интервью.
Ну объясните тогда, как проводят интервью те, кто умеет?
Ну объясните тогда, как проводят интервью те, кто умеет?
Если нанимают мидл/сениор инженера, дают типичное задание. То есть если человеку надо разрабатывать API, дается тестовый проект и задание на минут 15-20, типа реализовать такой-то endpoint. Потом задаются вопросы и можно усложнять задание (посчитай еще вот это и верни в запросе). С сениорами еще поговорить про system design. Суть: посмотреть как кандидат справится с ежедневной работой.
То же и с языком. Есть довольно широкий диапазон владения иностранным языком, когда читать и понимать можешь, а сказать — почти ни слова.
Не надо сравнивать теплое с мягким. Если можешь читать то можешь и писать, разговорная речь это совсем другое. Аналогия так себе.
тогда надо кандидату не решать задачу, а писать целые эссе на тему, какие решения найдены, чем они хороши, почему именно это выбрано и куча рассуждений, доказывающих, что кандидат понял решение, а не скопипастил первое попавшееся, где ключевые слова нашлись на странице
Спросить не пробовали?
В гугле уже давно интервью проходят на ноутбуке.
Зависит от офиса, видимо.
Я в 2016 собеседовался в Цюрихе — были только доска и маркер.
По крайней мере после 2017-ого года в общей для всех инструкции написано спросить кандидата, хочет ли он писать на ноутбуке, который можно заранее взять там-то и там-то. Не вижу причин не делать это, потому что в этом случае код сразу готовый и его можно скопипастить в отчет — не надо фотографировать, парсить и перепечатывать доску.
Вот, недавняя статья от яндекса приводит несколько примеров практически задач с собеседования
Но это антипример практически. В качестве хардкорного примера тру-алгоритмических задач идёт… вымученый случай применить reduce на массиве.
Где то помню статья была от гугла, с признанием об отсутсвие кореляции качества сотрудника с качеством прохождения собеседования от слова совсем.
Интересно, на что еще способны пойти люди, лишь бы стать гайкой
Я ни на что особо не шла, мне нравилось решать задачи. Степень вклада в проект и свобода действий сильно зависит от будущей команды и компании. Например, даже в этих компаниях можно коммитить в опенсорс.
Гаечка
Гайка или нет — решает человек. Если для Вас это так — то старайтесь делать что-то иначе и добиваться своих результатов. Для кого-то, работа в таких компаниях — хорошая цель, в конце концов только усилиями многих людей делается что-то значимое, и IT гиганты только доказывают это своим существованием.
Я ни в коем случае не отговариваю или осуждаю.
и IT гиганты только доказывают это своим существованием.
что доказывают? профит от торговли рекламой?
Понятное дело, что это позор, что такие бабки вертятся в развлечениях, играх, торговле рекламой, и финансовых спекуляциях а не в, скажем, освоении дальнего космоса или хотя бы выведении всех людей на планете на приличный уровень жизни. Но это ж некоторые отвлеченные рассуждения. С точки зрения отдельного разраба, именно в FAANG проще всего познакомиться с мега-крутыми людьми и найти себе целую кучу комнат, в которых я буду самым тупым.
> это позор
Почему? Мне кажется это из той же оперы, что и «злиться на то, что ветер дует»? Мне кажется, что это результат довольно естественных решений социума, странно клеймить их позором. К слову, я с вами совершенно согласен — хочется уже воплотить мотивы Брэдберри, а не вот это вот все :)
Почему? Мне кажется это из той же оперы, что и «злиться на то, что ветер дует»? Мне кажется, что это результат довольно естественных решений социума, странно клеймить их позором. К слову, я с вами совершенно согласен — хочется уже воплотить мотивы Брэдберри, а не вот это вот все :)
То, что это закономерно и объективно и ничего с этим не поделать, не отменяет того, что это позор и живем мы с диком средневековье по сравнению с тем, как могли бы жить и как будем жить лет через 300.
по сравнению с тем, как могли бы жить и как будем жить лет через 300.
Да вы оптимист, я смотрю. Если через 300 лет не самовыпилимся совсем, то будет или глубокая антиутопия типа 1984, или самый мрачный киберпанк, где 99% населения будут практически рабами и править всем будут мегакорпорации, или буквально средневековье, в зависимости от того как третья мировая пройдет.
Боюсь что весь киберпанк закончится при наличии банального магнетрона достаточной мощности. Про ЭМ-бомбу (она, кстати, не так сложна, как может показаться и ядерного заряда не требует вовсе) я и говорить не буду. :) Вопрос только в том, нужно ли это будет уничтожать хоть кому-либо. Все почему-то ждут 1984, а пока всё же реализуется схема из «О, дивный новый мир!».
То что самовыпилимся — это да, тоже возможно. И средневековье тоже. А вот в 1984 не сильно верю, социальный прогресс в другую сторону идет.
А вот в 1984 не сильно верю, социальный прогресс в другую сторону идет.
Ну, китайцы уже обкатали на уйгурах вполне себе цифровой концлагерь. В москве потихоньку вводят похожего уровня ограничения и я не сомневаюсь, что "для вашей безопасности", эти пропуска оставят надолго.
Двоемыслие и переписывание прошлого уже практикуется политиками по всему миру (тот же Трамп, например, который может сегодня говорить полностью противоположное тому, что говорил вчера и отрицать, что он вообще вчера это говорил — и всем пофигу).
И вообще, случись глобальное потрясение, типа третьей мировой, или массового голода и переселения из-за климатической катастрофы — весь социальный прогресс сдует. А технологии останутся. И их будут применять не для улучшения уровня жизни а для сохранения власти и контроля.
Профит дело побочное, это усилиями менеджеров он сделан, а программисты делают сам продукт(многие помнят ламповый инет, когда уже многое было, а никак не монетизировалось). Вы вот наверняка ютуб смотрите тот же, а ведь это куча произошедших инноваций, год за годом. И то что на рекламе делаются основные деньги, а не на платной подписке — это альтернатива и значит это для потребителя лучше ее отсутствия. Бизнес на волонтерских началах не выживет.
Таким гайкам потом открыт путь в любую страну мира и на должности зачастую намного выше, а также многие такие гайки заводят свои дела и тем более гораздо с большей вероятностью получат инвестиции на свой бизнес как «бывший ведущий разработчик Amazon», чем программист Вася из ООО Биба и Боба
Мне показалось, что довольно лайтово автор готовилась, мне бы не хватило. Я вот подумываю о том, чтобы нанять себе менеджера-тренера-надсмотрщика, чтобы соблюдать режим подготовки. Чтобы с джирой, ежедневными митингами, отчетами, графиками, отчетными мини-экзаменами, mock interview'шками и всем таким. Ну, это помимо всего стандартного набора обучающих групп, платных и бесплатных сервисов и общения с экспертами по алгоритмике и по архитектуре. Но я планирую это мероприятие на полгодика, два месяца из которых — в отпуске. Получится что-то в итоге или нет — по-любому будет весело.
Будет интересно прочитать про ваш опыт. Я понимаю, что нет универсального количества времени на подготовку, например, там выше был комментарий, что я наоборот слишком долго готовилась.
Переусложняете, имхо. 2 недели leetcode, и попробуйте уже сходить на собеседование в ту из больших компаний, в которую будет меньше всего жалко провалить (Амазон, например). Дальше можете пол года ещё заниматься, но:
1) у вас уже будет опыт прохождения подобных собеседований
2) через пол года уже можно будет ещё раз пособеседоваться туда же
Чем больше собеседований посетите — тем проще будет проходить их.
1) у вас уже будет опыт прохождения подобных собеседований
2) через пол года уже можно будет ещё раз пособеседоваться туда же
Чем больше собеседований посетите — тем проще будет проходить их.
Мне кажется ваша тактика довольно рисковой, я бы через две недели попробовала пройти собеседование на какой-нибудь тестовой площадке или попросить об этом знакомого. Если результат понравится, то дальше уже идти на реальное собеседование.
Это если вас порекомендовали, иначе надо будет, чтобы о вас рекрутер вспомнил.
через пол года уже можно будет ещё раз пособеседоваться туда же
Это если вас порекомендовали, иначе надо будет, чтобы о вас рекрутер вспомнил.
чтобы нанять себе менеджера-тренера-надсмотрщика
А где такого можно найти? 0_о
Я видела репетиторов по спортивному программированию на сайте репетиторов, а ещё акселератор Outtalent, но последние хотят процент зарплаты после трудоустройства.
Вот и я пока что думаю. По идее, подойдет любой толковый менеджер, а то и просто virtual assistant. Ему даже не очень обязательно быть из области программирования, просто понимать управление процессами.
Спасибо за структурированную информацию и полезные ссылки. Желаю дальнейших успехов))
А еще не придумали соревнования по спортивному собеседованию?
Меня всегда во всех статьях про собеседования интригует уверенность кандидата в успешном дальнейшем развитии событий. То есть, никого не беспокоит, справится он с работой или нет? Для меня, например, это сверхприоритетно — я всегда не уверен, что я смогу и что моего уровня хватит. Но я смотрю, что всех волнует только пройдёт он собеседование или нет. Почему так?
Потому что на работе есть коллеги и инструкции, которые сильно помогают, плюс есть время на 'раскачку' чаще всего, никто сразу 100 процентов продуктивности не требует
Если бы это так просто работало, собеседования вообще не имели бы смысла — коллеги и инструкции доведут любого до нужных требований. Ан нет, чтобы это сработало нужно самому быть на уровне. А на уровне мы или нет для данной работы мы не знаем — мы же только собеседование прошли и только о нём и думали фактически. О работе-то мы ещё даже не беспокоились — я об этом и говорю, собственно.
Если бы это так просто работало, собеседования вообще не имели бы смысла
Это ещё почему? опыт не бинарное состояние есть/нет, и имеется огромная разница выход на 100% продуктивность через неделю две или года 2-3, вот на собеседовании и выбирают тех кто за минимальное время сможет выдать максимум продуктивности.
А на уровне мы или нет для данной работы мы не знаем
Обычно в вакансии круг требований указан и зачастую на собеседовании будущий начальник так же приходит, где и очерчивает круг обязанностей. При этом чем больше контора тем больше может быть зазор между имеющимися навыками и требуемыми, слишком много людей слишком нерасторопны бизнес процессы (даже здесь были отзыва где человеку неделю учётку заводили или забывали про целые отделы).
О работе-то мы ещё даже не беспокоились
Ну если требуемые навыки есть, что о ней беспокоиться то? Не потянете уволят, в крайнем случае, если уж прямо сильно обманули (а вот чтоб этого не было и проводят собеседования и спрашивают дипломы)
Это ещё почему?
Потому, что если это не так, то есть и повод беспокоиться, ибо «Потому что на работе есть коллеги и инструкции, которые сильно помогают, плюс есть время на 'раскачку' чаще всего, никто сразу 100 процентов продуктивности не требует» не гарантируют успешного выполнения работы. А я об этом, собственно, и говорил. Но если вы согласны, что возможность не справиться есть, тогда процитированное особо не поможет в этой ситуации.
выход на 100% продуктивность через неделю две или года 2-3,
А как быть, если всё, что вы напишете годится только в мусор (нет, не из-за стиля, а из-за недостатка опыта в применении некой технологии или концепции)? А чтобы годилось не в мусор, потребуется от вас серьёзное обучение и большой опыт именно узкой направленности (скажем, попробуйте написать драйвер — там очень непросто всё сделать правильно). И вполне можно не справиться.
Обычно в вакансии круг требований указан
Тут недавно кто-то писал, что у них в компании меняют как перчатки эти требования. Да я и сам видел — пришли на С++, но команда решила перейти на питон. Упс.
Ну если требуемые навыки есть, что о ней беспокоиться то?
Нет, ну если один-в-один совпадает с тем, что вы умеете, тогда да. Но обычно-то ведь не так. Точного совпадения нет.
Непонятно, почему вы так переживаете за работодателя. Собеседования — они для того и предназначены, чтобы на других посмотреть, да себя показать. Если уж вам сделали оффер — значит, готовы попробовать (и да, любой работодатель понимает, что найм — это риск). В самом худшем случае, если вы прям дико читанули на собеседовании и потом ещё долго отмазывались от работы — будете уволены с пометкой «обратно нанимать не хотели бы», но даже в этом случае компаний вокруг ещё много. Судя по вашим фразам, ничем подобным вы не страдаете, просто слишком строги к себе. Поэтому в вашем случае более реалистичен позитивный вариант: вы увидите, что и новые коллеги далеко не все гениальны, и сами подтянете свои скилы, заодно и уверенности в себе получите.
Непонятно, почему вы так переживаете за работодателя.
Я вас (и ещё двоих тут) не понимаю. При чём тут работодатель? Вы сами не боитесь не справиться и вылететь или угробить здоровье и силы, пытаясь соответствовать тому, чему вы на момент интервью не соответствуете? Работодатель-то найдёт другого, а вот вам придётся заново всё начинать.
вы увидите, что и новые коллеги далеко не все гениальны,
Это по-разному бывает.
Ну если интервью получилось успешно пройти, значит, более-менее соответствуем работе. Соображалка есть. А с конкретными технологиями опять же коллеги помогут, да и если голова работает, то "сейчас докурю и пойду сдавать" (с)
Так и вы тоже имеете право уволиться, если вам станет некомфортно работать, это же не крепостное право. А собеседоваться — не страшно.
Вы сами не боитесь не справиться и вылететь или угробить здоровье и силы, пытаясь соответствовать тому, чему вы на момент интервью не соответствуете?
Дык а что самое худшее произойдет? Поработаю месяц-два-пять и меня уволят? Ну-у-у, да, неприятно, придется потратить недельку-месяц на поиск нового места. Про угробить здоровье и силы — дык не надо гробить, просто чуток постарайтесь. Не хватит — ну значит не хватит, это ж не вопрос жизни и смерти.
Сомнения, конечно, есть. Но во-первых, можно запросить больше времени до выхода на работу — будет время изучить новый язык и/или технологию. А во-вторых, компания, принимая решение о найме, разделяет эту ответственность с сотрудником.
будет время изучить новый язык и/или технологию.
Изучить? За небольшое время? Завидую. Я вот за 20 лет С++ изучить не смог до современного уровня — я этот Си++ в не legacy стиле банально не понимаю как концепцию (куда уж до понимания граблей!).
C++ — это особый случай. В Google, например, style guide ограничивает функционал C++. Плюс к этому (и не только в Google) код обкладывается проверками анализаторов и тестами, а коллеги проводят ревью.
Так особых случаев очень-очень много. Скажем, мало кто может заниматься физикой твёрдого тела даже с соответствующим образованием. Да и математикой тоже не каждый овладеет на должном уровне. Ну или электроник тоже весьма непростыми навыкам научиться должен.
Только всё это не обязательно поможет вам быстро научиться требуемой концепции применения.
Плюс к этому (и не только в Google) код обкладывается проверками анализаторов и тестами, а коллеги проводят ревью.
Только всё это не обязательно поможет вам быстро научиться требуемой концепции применения.
НЛО прилетело и опубликовало эту надпись здесь
Научится работать легко.
Видимо, мне такого уровня не достичь. :)
Тем не менее, это нивелирует весь смысл собеседования. :)
Тем не менее, это нивелирует весь смысл собеседования. :)
Не совсем, ведь задача собеседования — минимизировать ложноположительные результаты. А минимизировать ложноотрицательные результаты — уже головная боль кандидата, а не компаний, поэтому и приходится готовиться к собеседованиям.
Такое ощущение, что вы никогда не проходили собеседования на разные работы, раз здесь в комментариях удивляетесь вполне себе обыденным вещам. Не думали никогда, что со стороны работодателя есть такая же мулька: «Справится/не справится, приживётся/не приживётся». Это всегда рулетка с обеих сторон.
что вы никогда не проходили собеседования на разные работы
Нет, не проходил.
Не думали никогда, что со стороны работодателя есть такая же мулька: «Справится/не справится, приживётся/не приживётся». Это всегда рулетка с обеих сторон.
Это логически никак не связанное утверждение с исходным моим вопросом. Там нет ни слова о стороне компании, там изначально вопрос задан со стороны работника. Проблемы компании я не рассматриваю, как можно увидеть.
НЛО прилетело и опубликовало эту надпись здесь
То есть, никого не беспокоит, справится он с работой или нет?
Риск фейла отдельно взятых сотрудников в достаточно крупной компании должен не беспокоить, а быть подсчитан и учтён в бизнес-процессах. А результаты собеседования как раз являются исходными данными для этого подсчёта.
Если же процессы в компании построены так, что фейл одного разработчика приведёт к
Понятно, что есть задачи, где цена ошибки одного человека может быть очень высокой, а возможности риск-менеджмента весьма ограниченными. Но туда и людей не по собеседованиям ищут.
В таких компания, обычно, есть onboarding — куча времени после выхода на работу для того, чтобы вьехать в тему (до 3х месяцев). За это время осла можно научить говорить. Кроме того, люди, прошедшие собес, не просто люди с улицы, а прошедшие тщательный отбор. Так что не нужно комплексовать. Если вы прошли собес — то и с работой справитесь (если захотите)
А вот пример того, о чём я и говорю. Как видите, не так-то всё и шоколадно бывает.
А зачем беспокоиться, справлюсь я с работой или нет? Я честно постараюсь сделать всё, что от меня зависит, чтобы справиться. Ну если нет — так нет. Если уволят — буду искать другую работу. Если нет — значит, следующую задачу дадут более соответствующую моему уровню. Главное, чтобы перед собой не было стыдно.
А зачем беспокоиться, справлюсь я с работой или нет?
Вот этого подхода я и не понимаю.
Я же в том же комментарии постарался объяснить...
Здесь фундаментальная разница в подходах. Я как-то не привык потратить уйму сил, чтобы пройти, а потом просто взять и уйти, потому что не справился. Мне этих сил как-то жалко. Я бы лучше их на что-то другое потратил. По этой же причине я бы не пошёл на работу, менее интересную, чем моя текущая. Собственно, я так собеседование проходил в чистую разработку ПО (с Qt), но отказывался от места с в 2 раза большей зарплатой именно потому, что я там не смогу заниматься ничем мне интересным, кроме этого самого Qt (на текущей работе, например, я могу инициировать разработку практически всего, чего мне потребуется (как аппаратную, так и программную части) в рамках проекта (к примеру, я инициировал разработку имитатора системы, потому что считаю его необходимым — и его я сделал (на PC), хотя аппаратную часть ещё пока не смог заставить начать проектировать — упираются.), могу легко выкроить время для своего собственного проекта, могу вообще заниматься тем, что только лишь может пригодиться в будущем (например, сейчас, играясь с платой ESP8266, мне пришла в голову мысль сделать списывание с вращающегося стенда через ESP8266 и WiFi вместо пучка проводов на вращающемся контакте — а пуркуа бы да не па? Скорости вроде как хватит. Я ещё подумаю над этой дивной мыслью. :) Прошлым летом я выкинул из процесса разработки ПО для отечественного аналога TMS320 глючный CodeComposer, требующий соединения с процессором в процессе работы и написал «запускатель» для запуска процесса компиляции всех файлов каталогов, который легко подключить к CodeBlocks, чем упростил всю процедуру сборки и разработки ПО для этого процессора. Так же летом просто играясь запустил (написал почти драйвер) в QNX6.3 плату CAN PCI7841 и заменил ей ISA-плату CAN527D на стендах (а то ISA-компьютеры дорогие нынче). ), могу подключиться к проектам в других группах; то есть, у меня очень широкая сейчас свобода в своих действиях — и я как бы это ценю и будет обидно такое променять на выполнение задач от и до по одной и той же тематике. Единственное но — работа нервная и плохоорганизованная — много воевать приходится с организаторами. Но я уже как бы привык.).
Понимаю. Вопрос в том, считать ли этот период времени (от подготовки к собесу до увольнения в случае неудачи на новой работе) потерянным. Вы получаете опыт, деньги за отработанное время, знакомства, расширяете кругозор.
А насчёт интереса к работе — пожалуй, полностью согласен. У всех свои требования к тому, чем они хотят заниматься. Грустно сидеть на нелюбимом месте. Ну разве что очень деньги нужны и другого выбора просто нет.
Мне кажется, вы взваливаете на себя обязанности работодателя. Задача выстроенной работодателем системы найма — отсеять подходящих кандидатов и распределить их по грейдам. Не отбирайте у людей хлеб, им лучше известно, сениор вы формошлеп или джуниор.
Ну почему же не волнует. Думаю многих волнует справятся ли они. Но, почти все, наедятся что все будет ок, что со всем справятся, если где-то не хватает уровня или знаний, то подтянут. Раз уж вы прошли собеседование, без читов, то вы, в большинстве случаев, способны справиться с задачами, на которые вас берут. На моем примере, я считаю, что невыполнимых задач не бывает, бывает только недостаток времени. Я когда менял последнее место работы, шел вообще в неизвестный мне стэк технологий, и считаю что я хорошо справился с изучением и применением того что узнал на практике, и соответственно хорошо справляюсь с работой и выполняю все что требуется. Если каждый раз так сильно переживать, то так можно всю жизнь просидеть на одном месте. Начальство тоже это видит и может все соки выжимать из такого сотрудника, с мыслью — да куда он уйдет, да кто его возьмет. Поэтому чуть больше уверенности в своих силах и все будет отлично. Как говорится, ну умеешь — научим, не хочешь заставим :)
Есть подозрение, что в том случае, если вы найдете у себя существенную нехватку знаний или опыта, пройдет уже столько времени, что компании будет выгоднее вас доучить, чем искать замену в команду через собеседования, давать новичку время на вникание в workflow и заново сводить группу с новым человеком в аспекте психологической совместимости. Даже при условии, что на их крыльце очереди стоят. Вы-то уже есть здесь и сейчас, знакомы с процессами, инструкциями, традициями. Важно ваше желание оставаться работать, если оно есть. Кроме того, не FAANG ли промотируют себя как райское место, где можно менять команды и проекты внутри компании?
Поздравляю вас! Это большое достижение.
Сколько всего у вас заняла подготовка (к примеру, N месяцев по M часов в день)?
Сколько всего у вас заняла подготовка (к примеру, N месяцев по M часов в день)?
Сколько проходила собеседований, везде спрашивают и про SOLID и про шаблоны проектирования. Но вот на практике увы — легаси код поддерживаешь в основном.
После «приятного» собеседования в майле, когда меня собеседовал только HR, и когда отказ дали из-за выбора в пользу того, кто знает нужный фреймворк. Хотя об этом заранее говорилось. Т.е. собеседование проводилось тупо для галочки. Вот после этого мне не хочется ни в майл, ни в яндекс.
Лучше работать в маленькой конторе, в которой проще провести изменения в сторону улучшения технологий. И вот там не будут просить решить логические задачи. Т.к. умение решать задачи — это ни о чем. Человека можно просто натаскать их решать, но вот в нужном месте он не сможет понять, что нужно сделать. Тут нужно не умение решать логические задачи, а опыт.
После «приятного» собеседования в майле, когда меня собеседовал только HR, и когда отказ дали из-за выбора в пользу того, кто знает нужный фреймворк. Хотя об этом заранее говорилось. Т.е. собеседование проводилось тупо для галочки. Вот после этого мне не хочется ни в майл, ни в яндекс.
Лучше работать в маленькой конторе, в которой проще провести изменения в сторону улучшения технологий. И вот там не будут просить решить логические задачи. Т.к. умение решать задачи — это ни о чем. Человека можно просто натаскать их решать, но вот в нужном месте он не сможет понять, что нужно сделать. Тут нужно не умение решать логические задачи, а опыт.
Т.е. собеседование проводилось тупо для галочки. Вот после этого мне не хочется ни в майл, ни в яндекс.
Такое бывает, но в случае Яндекса я с подобным не сталкивалась, хотя собеседовалась не один раз. Их собеседования очень похоже на те, что описаны в статье.
Лучше работать в маленькой конторе, в которой проще провести изменения в сторону улучшения технологий.
Это кому как повезёт. Как начальник будет реагировать на эти изменения. Из моего опыта, в крупных компаниях были гораздо лучше налажены процессы разработки, было строже ревью кода и технологии использовались новее. Кроме того, в крупных IT-компаниях стандартизирован формат собеседований, а в мелких никогда не знаешь, что будет. Сколько раз меня спрашивали про декрет, а один раз наняли в том числе потому, что подыскивали жену руководителю разработки.
И вот там не будут просить решить логические задачи.
От логических задач известные мне крупные IT-компании уже отказались.
Т.е. собеседование проводилось тупо для галочки. Вот после этого мне не хочется ни в майл, ни в яндекс.
В Яндексе по моему опыту прохождения собеседований делают упор на навыки программирования в общем и на system design. Отсутствие знаний по конкретному фреймворку еще не повод отказываться от кандидата, если конечно речь идет не о платформенных основах — типа понимания жизненного цикла Activity для Android разработчиков или многопоточности для Java-backend. А отсутствие знаний Spring или Dagger… Да фиг бы с ними, смотрите, он смог проверить строку на палиндром, надо брать!
Зато там те самые нелюбимые вами алгоритмические задачи, которые надо писать на листочке, доске или в текстовом редакторе.
P.S.: Мне проще задачки порешать, чем объяснять человеку, что в гробу я видел его вопросы про equals и hashcode.
А что насчет рассказывания крутых историй про опыт? С этим проблем не было или таких вопросов не встречается?
Такие вопросы, конечно, встречаются. Спрашивают, например, про самый сложный или самый интересный проект. Обычно это происходит на поведенческой части собеседования и там применимы методы, которые я упоминаю в этом разделе.
Этого полно на собесах — «расскажите мне о ситуации когда <случилось то-то и то-то>». К этому нужно готовиться, тк из головы это сложно связно рассказать и кандидатов, кто не готовился сразу видно. Да и просто это сложно и волнительно делать без подготовки.
Как относишься к такой особенности работы в гигантах типа FAANG, что своей работой ты лишь незначительно влияешь на продукт. Возможно, твоя работа и вовсе не заметна (не только в продукте, но и внутри компании). При этом бюрократия, грейды и внутренние интриги.
В стартапе же всё иначе: возможно, в будущем имя компании в CV ничего и не скажет, но ты непосредственно влияешь на продукт, который использует конечный пользователей, и этот продукт невероятно изменяется и эволюционирует у тебя на глазах. Ну, и «тот самый дух стартапа», и шанс, что он выстрелит (~ 10%).
Расскажи, проводила ли ты такие сравнения, делая выбор в пользу стабильности корпората, или никакого выбора не было, и ты всегда смотрела в сторону этих гигантов.
В стартапе же всё иначе: возможно, в будущем имя компании в CV ничего и не скажет, но ты непосредственно влияешь на продукт, который использует конечный пользователей, и этот продукт невероятно изменяется и эволюционирует у тебя на глазах. Ну, и «тот самый дух стартапа», и шанс, что он выстрелит (~ 10%).
Расскажи, проводила ли ты такие сравнения, делая выбор в пользу стабильности корпората, или никакого выбора не было, и ты всегда смотрела в сторону этих гигантов.
Я сравнивала и в данный момент смотрю больше в сторону корпораций. Во-первых, в стартапах сложнее найти позицию с релокацией, а во-вторых, мне кажется, стартапы чаще требуют опыт с определенным языком/технологиями, с которыми я в основном не пересекаюсь. И в-третьих, при желании, в некоторых больших компаниях можно найти подразделения с духом стартапа, например, DeepMind в Google. Для меня на самом деле важно влияние на продукт, и я пытаюсь выяснить это на этапе собеседования с командой.
Есть и крупные стартапы (типа Uber, Grab, Gojek, Revolut), где внутри уже настроены процессы, и есть релокация. Но там и от стартапов остается только то, что они всё ещё на инвестициях и работают в минус, хотя продукт и быстрее корпората развивается и больше шансов влиять на него. Зато для резюме уже жирная строчка.
В сторону Азии ты не смотрела?
Там тема IT стартапов бурлит!
В сторону Азии ты не смотрела?
Там тема IT стартапов бурлит!
У гигантов есть и подразделения, работающие на проектах с их клиентами. Там каждый проект — все разное и от тебя очень многое зависит.
Поздравляю с достижением цели!
Будет интересно почитать через, скажем, год — с чего начиналась непосредственно сама работа, где вы сейчас и к чему идете.
Успехов!
Будет интересно почитать через, скажем, год — с чего начиналась непосредственно сама работа, где вы сейчас и к чему идете.
Успехов!
Вот я так же к устройству в гугл готовился-готовился, на собеседовании ответил хорошо и взяли меня на позицию выше, чем я заслуживал. Чуть не выперли потом, еле выкарабкался.
Было бы очень интересно прочитать вашу историю.
Чуть не считается! Как раз и были на гране своих возможностей.
А вот между прочем про это было бы действительно интересно почитать. Огромное количество success story про то как «я два года готовился и получил оффер в гугл», но везде умалчивается а что было дальше.
Вот-вот, я об этом и спрашивал выше.
Потому что все посты о компании сотрудник обязан согласовывать с гугловым комитетом по цензуре — это достаточно долгая задача, на которую решаются немногие. Даже если я придумаю и напишу пост, то я не уверен, что у меня хватит терпения согласовать его.
Это не камень в вашу сторону, но все же прекрасно понимают что этот комитет существует исключительно ради того чтобы люди, которые хотят что-то написать обязательно от своего имени, не могли написать то чего не хочет компания. :) Для всех остальных есть анонимные сайты или throwaway аккаунты, где они могут написать все кроме той информации, которая поможет их идентифицировать.
Молю, напишите! Предвкушаю пост месяца!
0xd34df00d, прости =(
0xd34df00d, прости =(
Спасибо за информацию!
В ближайшее время она точно мне не понадобится, но для общего понимания — годно!
В ближайшее время она точно мне не понадобится, но для общего понимания — годно!
У меня вот такая мысль появилась. Что если алгоритмические собеседования — это просто Black Box-отсеивание? То бишь статистическая, корреляционная история, а не что-то с четким причинно-следственным обоснованием. Есть где-то метрика: среди тех, кто знает алгоритмы, процент хороших программистов больше. Ну там 60%, а в среднем по популяции всего лишь 30%. Почему? Да мы не знаем и нам не интересно, мы просто будем искать в той кучке, где их больше. При большом потоке кандидатов это довольно умное решение.
Ну, это возможно, но тут стоит помнить и такие корреляции:
Корреляция: как незаметно выстрелить себе в ногу
:D
Корреляция: как незаметно выстрелить себе в ногу
:D
Это гугл, у них очередь народа за строчкой резюме и релокацией стоит, потому они могут выбирать вообще по любому признаку. Хочешь гринку/блюкард: учись крутить деревьями и знать другие бесполезные вещи.
Необходимость подготовки к собеседованию опытному разрабу у меня вызывает недоумение. Это как если бы я покупал поддержанный авто, и перед тем, как его приехать посмотреть, позвонил бы владельцу и попросил его прогреть движок, коробку, залить присадочку, чтобы захотелось его купить.
Отвечаю Вам в той же аналогии. Выбираю я, значит, подержаный автомобиль, смотрю на объявления на сайте. Выберу ли я объявление с перекошенными фото, снятыми в полутьме, грязной машиной на фото с мусором в салоне и грубыми грамматическими ошибками в тексте? Может быть, но для этого объявление должно быть ооооочень вкусным. Во всех других случаях я пройду мимо, т.к. себе дороже копаться в шлаке. А нужно всего-то было убрать в машине, помыть всё внутри и снаружи, сделать нормальные фото с хорошим освещением и качеством и проверить объявление спеллчекером.
Так и здесь. Не думаю, что стоит доводить это до дрессировки с единственной целью — пройти любой ценой. Но освежить неиспользовавшиеся навыки и подготовиться к тому, что ожидает на собесе, может быть полезно, чтобы не проиграть в конкуренции вызубрившему всё джуну.
Так и здесь. Не думаю, что стоит доводить это до дрессировки с единственной целью — пройти любой ценой. Но освежить неиспользовавшиеся навыки и подготовиться к тому, что ожидает на собесе, может быть полезно, чтобы не проиграть в конкуренции вызубрившему всё джуну.
Но освежить неиспользовавшиеся навыки и подготовиться к тому, что ожидает на собесе, может быть полезно...В статье как раз про целенаправленно готовиться, а не освежить.
… чтобы не проиграть в конкуренции вызубрившему всё джуну.То есть опытный кандидат сравним с джуном? Получается вес опыта не велик?
То есть опытный кандидат сравним с джуном? Получается вес опыта не велик?
Смотря что вы хотите измерять. По умению решать хитровыдуманные задачки я бы с треском проиграл 20-летней версии самого себя. Но в моей сегодняшней работе 20-летняя версия была бы абсолютно бесполезна, а то и вредна, потому что думать именно в рамках рабочего процесса я тогда умел довольно плохо. Тем не менее, если я пойду менять работу, то большинство распрекрасных работодателей предложат мне именно хитрые задачки.
Смотря что вы хотите измерять.Я ничего не хочу измерять, я задал уточняющие вопросы предыдущему оратору.
С вами я согласен, но с хитрыми задачками у меня примерно одинаково, что сейчас, что 20 лет назад :) Последнее время меня гоняли по тонкостям C++, которые в реальной жизни я не использую, а после собеседований через некоторое время забуду.
Часто бывают тн «behavioral interviews» на которых достаточно сложно прямо из головы связно и структурированно (STAR) рассказать о ситуации про которую спрашивают.
Однажды я проходила собеседование, к которому долго и упорно готовилась. Я щёлкала задачи как орехи, быстро писала код и чувствовала воодушевление. Техническая часть показалась очень лёгкой, и я завершила звонок в полной уверенности моего прохождения: «Если я уж сейчас не пройду, то не знаю, что им ещё нужно». Не было человека счастливее меня, пока я не прокрутила своё решение ещё раз и не нашла ошибку.
На этой неделе проходила телефонное интервью. Очень похоже было, задача была несложная, но я сразу сказала, что изначально пишу brute-force версию. Потом мы поговорили про тест-кейсы, про некоторые оптимизации, я порассуждала о сложности решения, а затем времени не осталось. Интервьюер сказал, что задачу я решила, но решение принимает не он. В целом, как только оно закончилось, мне интервью очень понравилось.
Через 10 минут после интервью я поняла, что написала жесточайший костыль, и что очевиднейшую оптимизацию я упустила. И что тест-кейсов должно было быть больше. И что даже один из параметров в O-нотации не должен был быть больше другого, и можно было бы не тянуть второй.
На следующий день эти оптимизации мне даже снились.
Если по истечении времени задача не была сделана, я изучала решение, вносила её в список и возвращалась к ней через некоторое время.
Скажите, а что вы считали за «сделана»? Любой возможный способ, в том числе brute force, лишь бы задача принята и прошла все тесты? Или вы все-таки пытались получить хороший Time/Space Complexity?
Если задано ограничение по времени или в условии указаны определенные Time/Space Complexity, то пока я их не достигну — задача не сделана. Ещё даже после успешного решения смотрела разные подходы и если какой-то мне казался проще для запоминания/менее подверженным ошибкам/более оптимальным — тоже добавляла его в список и пробовала воспроизвести через какое-то время.
Мне кажется самое сложное — это привлечь внимание рекрутера. Ибо в это случае от тебя ничего не зависит.
Странно, что несмотря на 15 лет работы и солидный послужной список в линкедине, ни одна из вышеупомянутых компаний мне не нaписала.
В связи с чем есть вопрос: 100 connections это много или мало? А также: правда ли, что наличие фотки сильно влияет на шансы?
Странно, что несмотря на 15 лет работы и солидный послужной список в линкедине, ни одна из вышеупомянутых компаний мне не нaписала.
В связи с чем есть вопрос: 100 connections это много или мало? А также: правда ли, что наличие фотки сильно влияет на шансы?
100 connections это много или мало? — в LinkedIn? У меня там несколько тысяч… Думаю, что это не так важно. Скорее важна история работ, проектов, технологии, и так далее — всё должно быть упомянуто на профиле. И нужно проявлять активность там — я полагаю, это влияет на ранжирование профиля в поисковой выдаче.
100 connections это достаточно, вопрос только в том, кто среди них. Похоже, что сильно влияет социальный граф. Например, рекрутеры начинают стучаться к друзьям кандидата. Я добавляла некоторых людей и после этого просматриваемость моей страницы повышалась. Важно ещё подробно заполнить профиль и поддерживать активность: не просто добавить разом людей, а добавлять их регулярно, обновлять информацию, лайкать, репостить, подтверждать навыки, делать публикации.
100 connections это много или мало71 connections, 5 лет опыта, писали из Amazon, Facebook, и некоторых менее известных контор. Самый запомнившийся собеседник носил несколько неприличное имя (или это была фамилия?) и звал в Японию.
Особым послужным списком в Linked.in не обладаю. Фотография появилась недавно, но писали существенно до ее выставления.
В общем, это рандом дикий. Ну либо мой список какой то более послужной.
По моему опыту влияет:
— Кем вы подписаны в должности (Software Engineer лучше, чем реальная, но нестандартно называющаяся должность, где вы занимаетесь тем же самым);
— Есть ли у вас прикрепленные сертификаты;
— Какой уровень владения английским языком выставлен;
— Возможно, ваши навыки слишком сфокусированы на стеке, который им неинтересен.
Когда мне впервые написали из Amazon, у меня было что-то около 50 контактов.
— Кем вы подписаны в должности (Software Engineer лучше, чем реальная, но нестандартно называющаяся должность, где вы занимаетесь тем же самым);
— Есть ли у вас прикрепленные сертификаты;
— Какой уровень владения английским языком выставлен;
— Возможно, ваши навыки слишком сфокусированы на стеке, который им неинтересен.
Когда мне впервые написали из Amazon, у меня было что-то около 50 контактов.
— У меня в основном Senior Developer
— Сертификаты не прикреплены (фейсбук их реально смотрит?)
— Надо указывать английский? А зачем? Мне кажется 9 лет работы в англоязычной стране сам за себя говорит. Честно говоря, я вообще редко вижу чтобы язык кто-то указывал.
— Стек: backend и fullstack Java.
— Сертификаты не прикреплены (фейсбук их реально смотрит?)
— Надо указывать английский? А зачем? Мне кажется 9 лет работы в англоязычной стране сам за себя говорит. Честно говоря, я вообще редко вижу чтобы язык кто-то указывал.
— Стек: backend и fullstack Java.
Интересно. Я всегда указывала Software Engineer, у меня есть сертификаты и указан высокий уровень английского. Насчёт влияния Software Engineer не уверена, потому что мне пару раз предлагали Site Reliability Engineer.
Найдите своего знакомого в искомой конторе и попросите закинуть ваше резюме через internal referral
Спасибо за статью.
Откуда и куда Вы планируете релоцироваться?
Откуда и куда Вы планируете релоцироваться?
Спасибо за статью, интересно. Как вы учили и прокачивали английский? Думаю, высокий уровень языка один из больших плюсов.
Уровень английского к собеседованию я не прокачивала, только тренировалась объяснять задачи. Я прокачала английский несколько лет назад, когда готовилась к сдаче IELTS для учёбы по обмену. На входе после дополнительных занятий в институте у меня был B1: могла читать и переводить, были проблемы с говорением и аудированием. За 4 месяца очень интенсивных занятий я получила 7.0 IELTS (C1).
В то время я не могла потратиться на репетитора, поэтому занималась так: тренировалась с LinguaLeo каждый день по часу, читала научные статьи в Scientific American. Для прокачивания аудирования выбрала несложный сериал — я смотрела «Как я встретил вашу маму», подсматривала субтитры по минимуму и переводила их, после этого слушала подкасты BBC. Говорить ходила в разговорные клубы, а перед сдачей IELTS записалась на специальный курс. Сейчас использую английский на работе, немного ещё ходила на курсы и занималась в Skyeng.
Если бы я сейчас поднимала уровень английского к собеседованию, я бы поступила немного иначе, так как появилось много новых возможностей. Во-первых, пошла бы в Skyeng, там помимо занятий с репетитором есть бесплатные разговорные клубы. Во-вторых, помимо сериалов слушала бы подкасты про IT. В-третьих, попыталась бы найти специальный айтишный разговорный клуб: в идеале такой, где готовятся к собеседованиям (пример), но и просто за жизнь пойдет (пример). Мне кажется, для прохождения собеседования достаточно разговорного уровня B1-B2, главное знать специфику.
В то время я не могла потратиться на репетитора, поэтому занималась так: тренировалась с LinguaLeo каждый день по часу, читала научные статьи в Scientific American. Для прокачивания аудирования выбрала несложный сериал — я смотрела «Как я встретил вашу маму», подсматривала субтитры по минимуму и переводила их, после этого слушала подкасты BBC. Говорить ходила в разговорные клубы, а перед сдачей IELTS записалась на специальный курс. Сейчас использую английский на работе, немного ещё ходила на курсы и занималась в Skyeng.
Если бы я сейчас поднимала уровень английского к собеседованию, я бы поступила немного иначе, так как появилось много новых возможностей. Во-первых, пошла бы в Skyeng, там помимо занятий с репетитором есть бесплатные разговорные клубы. Во-вторых, помимо сериалов слушала бы подкасты про IT. В-третьих, попыталась бы найти специальный айтишный разговорный клуб: в идеале такой, где готовятся к собеседованиям (пример), но и просто за жизнь пойдет (пример). Мне кажется, для прохождения собеседования достаточно разговорного уровня B1-B2, главное знать специфику.
НЛО прилетело и опубликовало эту надпись здесь
Найти человека — не обязательно знакомого, можно просто постучаться в любой соцсети или мессенджере с просьбой порекомендовать. Если общаться с людьми даже так не хочется, то есть вариант стать финалистом какого-нибудь контеста, которые проводят эти компании, тогда можно сразу попасть на очный этап собеседования. Возможно, они также просматривают GitHub, StackOverflow, но не могу сказать, с какой вероятностью напишут.
НЛО прилетело и опубликовало эту надпись здесь
Только h1b сезон, к сожалению, только недавно закончился, так что до следующего придется ждать год. Ну и лоторея скорее всего будет. Поэтому если предложат в офис не-США — соглашайтесь, потом будет внутри шанс перевестись. Правда, скорее всего, только после промо до L5 (в случае Амазона), про майкрософт не знаю.
Пока не собираюсь в США, похоже из России туда сейчас очень сложно переехать. Слышала, что некоторые люди ждут визу более полутора лет.
Да нет, там особой разницы нет, откуда. Просто сама система иммиграции вероятностная. Главная виза h1b раздается раз в год в апреле, подающихся исторически больше чем квот, и поэтому проводится лоторея между желающими где должно повезти. Шансов выиграть немного, около 20%, по крайней мере последние несколько лет. Что будет в следующем году никто не знает конечно. В какую страну думаете переезжать тогда, если не секрет?
НЛО прилетело и опубликовало эту надпись здесь
На l1 нет лотореи, но вообще эта виза давно и регулярно абьюзится и если очень дотошно следовать духу закона, рядовых программистов по ней перевозить нельзя. Конечно, в случае европейских консульств проблем скорее всего быть не должно, но в Индии гайки закрутили очень сильно. Шанс получить l1 с Амазона в Хидерабаде или Бангалоре, по опыту знакомых — немногим больше чем выиграть h1b.
НЛО прилетело и опубликовало эту надпись здесь
l1a, по идее должна быть более «честной». Но l1b это specialized knowledge виза. Ее идея в том, что у сотрудника исключительно ценные знания, уникальные для конкретной компании. Просто знать С++ и ООП не достаточно, визовый офицер имеет право отказать сказав «У вас нет specialized knowledge, и вашу работу может делать любой американец знающий С++ и ООП». Это и есть причина №1 отказа подающихся из Индии. К счастью, в европейских широтах это большая редкость и эти визы штампуют без особых проблем. Даже больше, без семейных связей, гринкарт лоторей и доказываемых документально исключительных способностей, это, пожалуй, единственный реалистичный способ переехать в США для программистов.
НЛО прилетело и опубликовало эту надпись здесь
Как исполнительная ветка власти (в данном случае USCIS) интерпретирует текст законодательной — к сожалению, не точная наука. Specialized knowledge в законе определен именно как knowledge технологий компании, которые вы приобрели работая на нее, так что говорить офицеру про С++ — все-таки рисково. А про внутренню систему контроля версий и сброки — наверно да, на это лоеры и советуют упирать. Однако закон сильно рамзыт, и многое остается на усмотрение USCIS, которое в свою очередь идет от руководства и политического климата. «Закрутить гайки» можно в любой момент, как видно на примере Индии. Офицер (в теории) может сказать: «Я вот знаю что в Google/Amazon/Facebook есть on-boarding сотрудников, и систему контроля версий программисты осваиваивают за неделю, ваш knowledge не такой уж specialized и компания может нанять американца который сможет делать вашу работу. Я рекомендую вам подаваться по визе h1b». Я это кстати не придумываю — это почти слово-в-слово причина отказов многих l1 виз SDE II и даже III из Индийского Амазона в Сиэттл о которых я слышал. Отказывали даже программистам проработавшим много лет.
Читаю и зависть белая берёт, столько информации у программистов, сообщества различные и т.п.
А я вот, асушник, вообще ничего толком не могу (может не знаю, не умею) найти, ни форумов нормальных и живых, ни инфы по зарплатам, ни по собеседованиям.
Вот интересует меня вакансия в Амазоне европейском и что дальше, пробовать наобум…
А я вот, асушник, вообще ничего толком не могу (может не знаю, не умею) найти, ни форумов нормальных и живых, ни инфы по зарплатам, ни по собеседованиям.
Вот интересует меня вакансия в Амазоне европейском и что дальше, пробовать наобум…
> Так я поняла, что интервьюеры тоже ошибаются
Вообще, как работодатель могу сказать, что ошибку могли и заметить, но сознательно проигнорировать, т.к. все ошибаются. Если можно было бы просто брать на работу людей, которые не ошибаются, у нас бы не было ни автотестов, ни QA ручного, ни багов, ни проблем никогда и никаких. В идеальном мире наверное оно как-то так и устроено — ты просто берешь на работу тех, кто никогда не ошибается.
В реальном мире так не бывает и это приходится держать в уме. Конечно такие гиганты как Faceboogle могут себе позволить просто выкинуть кандидатов, которые ошиблись и брать на работу только тех, кто здесь и сейчас не ошибся. Но это не значит, что их программисты пукают бабочками, и свидетельства этому переодически вылезают наружу.
Удачи.
Вообще, как работодатель могу сказать, что ошибку могли и заметить, но сознательно проигнорировать, т.к. все ошибаются. Если можно было бы просто брать на работу людей, которые не ошибаются, у нас бы не было ни автотестов, ни QA ручного, ни багов, ни проблем никогда и никаких. В идеальном мире наверное оно как-то так и устроено — ты просто берешь на работу тех, кто никогда не ошибается.
В реальном мире так не бывает и это приходится держать в уме. Конечно такие гиганты как Faceboogle могут себе позволить просто выкинуть кандидатов, которые ошиблись и брать на работу только тех, кто здесь и сейчас не ошибся. Но это не значит, что их программисты пукают бабочками, и свидетельства этому переодически вылезают наружу.
Удачи.
Мне кажется, что это не был сознательный игнор. Там была концептуальная ошибка, на которую можно было бы натолкнуть при помощи тестового примера, обычно интервьюеры так и поступают. Задача была первая, времени хватало. В случае сомнений скорее всего назначили бы повторное собеседование, в FAANG тоже стараются не разбрасываться кандидатами.
Сигнатуры функций забываются, если использовать их достаточно редко…
Что уж говорить об алгоритмах, структурах, паттернах и умении вспоминать/воспроизводить/комбинировать их в условиях стресса на собеседовании?
Вот и получается: чтобы пройти собеседование, ты тренируешь себя в прохождении собеседований. Возможно, это вполне оправдано для таких IT-гигантов, им просто необходимо произвести качественный первичный отсев, чтобы не захлебнуться в нескончаемом потоке кандидатов. Но на деле, куда важнее уметь взаимодействовать с командой, адекватно эстимировать свои таски и отвечать пресловутым потребностям бизнеса.
В связи с этим, вопрос: зачем так мучить людей, если по итогу, большая часть их трудового ресурса всё равно будет утилизироваться на тривиальные, скучные, типичные задачи (будь то Google, MS или Amazon)? К тому же, не стоит забывать кучу прецедентов, когда кандидата апрувили, он попадал в компанию, а потом его с треском вышибали по «культурной несовместимости» (оказался чересчур расистом/сексистом или ещё как-то не угодил американскому просветлённому обществу).
Какой смысл тратить человеко/часы на подбор кандидата с обеих сторон, если успешно пройденный техсобес не даёт никаких гарантий получения нового члена команды, который станет крепкой ячейкой рабочего коллектива???
Что уж говорить об алгоритмах, структурах, паттернах и умении вспоминать/воспроизводить/комбинировать их в условиях стресса на собеседовании?
Вот и получается: чтобы пройти собеседование, ты тренируешь себя в прохождении собеседований. Возможно, это вполне оправдано для таких IT-гигантов, им просто необходимо произвести качественный первичный отсев, чтобы не захлебнуться в нескончаемом потоке кандидатов. Но на деле, куда важнее уметь взаимодействовать с командой, адекватно эстимировать свои таски и отвечать пресловутым потребностям бизнеса.
В связи с этим, вопрос: зачем так мучить людей, если по итогу, большая часть их трудового ресурса всё равно будет утилизироваться на тривиальные, скучные, типичные задачи (будь то Google, MS или Amazon)? К тому же, не стоит забывать кучу прецедентов, когда кандидата апрувили, он попадал в компанию, а потом его с треском вышибали по «культурной несовместимости» (оказался чересчур расистом/сексистом или ещё как-то не угодил американскому просветлённому обществу).
Какой смысл тратить человеко/часы на подбор кандидата с обеих сторон, если успешно пройденный техсобес не даёт никаких гарантий получения нового члена команды, который станет крепкой ячейкой рабочего коллектива???
Представьте себя на месте работодателя гиганта. Вы открываете позицию разработчика и к вам сваливаются 500 резюме в день, т.е. за условные 7 дней у вас 3500 резюме. Допустим вы как-то всех отфильтровали и у вас осталось 100 резюме, на каждое из которых вы можете потратить личное время. Вопрос, предложите способ выбрать лучшего из 100.
Как бы комично это не звучало в рамках данной статьи, но асимптотическая сложность данного алгоритма всё равно сводится к О(n) — в худшем случае, им придётся перебрать все 100 человек))
Поймите меня правильно, я ни в коем случае не хочу оскорбить автора. Более того — её упорство достойно уважения. Чтобы грокнуть всё это дело, действительно нужно потратить много времени.
Мой комментарий, скорее, крик души и скорбь по отсутствию реально действенного подхода к оценке кандидатов. Грустно осознавать, что компании-гиганты, которые кичатся своей «бирюзовостью» так и не придумали ничего более умного и по-настоящему действенного, кроме как делать упор на проверку абстрактных хард скилов.
Факт остаётся фактом: навык успешного прохождения собеседований — тренируемый и не имеет ничего общего с умением работать / не конфликтовать с коллегами / уровнем мотивации / лояльностью к компании / умением бороться с кучей проф деформаций.
В 2020 году уже все прекрасно понимают, что софт скиллы программиста первичнее его хард скиллов (которые подтягиваются по мере надобности на раз-два). Все же «гиганты» идут по проторенной дорожке, которую проложили ещё 30-40 лет назад, когда хорошим программистом считался человек, умеющий реализовать эффективный программный алгоритм на слабом железе.
Что не так с этим миром прогрессивных технологий 21 века, в котором от программного дизайнера высокоуровнего языка на входе требуется знание ассемблера?
Поймите меня правильно, я ни в коем случае не хочу оскорбить автора. Более того — её упорство достойно уважения. Чтобы грокнуть всё это дело, действительно нужно потратить много времени.
Мой комментарий, скорее, крик души и скорбь по отсутствию реально действенного подхода к оценке кандидатов. Грустно осознавать, что компании-гиганты, которые кичатся своей «бирюзовостью» так и не придумали ничего более умного и по-настоящему действенного, кроме как делать упор на проверку абстрактных хард скилов.
Факт остаётся фактом: навык успешного прохождения собеседований — тренируемый и не имеет ничего общего с умением работать / не конфликтовать с коллегами / уровнем мотивации / лояльностью к компании / умением бороться с кучей проф деформаций.
В 2020 году уже все прекрасно понимают, что софт скиллы программиста первичнее его хард скиллов (которые подтягиваются по мере надобности на раз-два). Все же «гиганты» идут по проторенной дорожке, которую проложили ещё 30-40 лет назад, когда хорошим программистом считался человек, умеющий реализовать эффективный программный алгоритм на слабом железе.
Что не так с этим миром прогрессивных технологий 21 века, в котором от программного дизайнера высокоуровнего языка на входе требуется знание ассемблера?
Согласитесь, что софт скилы невозможно проверить за 1 — 2 собеседования, да и даже за условную неделю работы, они тоже не всегда проявляются. Некоторые компании на онсайте просят не обойти дерево на доске, а поработать в команде 1 день, но мне кажется и тут будет все сводится к некоторой подготовке и все. Кстати можно привести аналогию с поступлением в институт, почему условный МГУ не берет всех, а только тех кто решает на 100 баллов? Ведь далеко не факт, что человек не забьёт на учебу в первый же семестр и будет до посинения играть в WoW или каким-то еще способом будет забивать на учебу и велетит, а человек, который набрал 98 баллов, может быть был бы в разы упорнее итд. Я это всё к тому, что на мой взгляд невозможно придумать такие правила отбора, которые бы устраивали всех. Мне нравится то, что хотя бы заранее известны правила игры, т.е. вы уверены, что с вами на собеседовании не будут особо за жизнь разговаривать, а будут спрашивать разного рода задачи. К чему и нужно готовиться.
Мне кажется, что когда кандидат тратит много времени на подготовку, а потом ещё правильно оформляет все документы и доезжает до точки назначения вовремя — это может косвенно свидетельствовать о его уровне мотивации и софт скиллах, плюс есть поведенческое собеседование. Часто бывает неформальное общение во время обеда в день собеседования, хотя компании утверждают, что оно ни на что не влияет. А лояльность эти компании пытаются заработать, выплачивая часть оклада акциями.
Ну будут в итоге люди не тренероватся писать алгоритмы и решать задачки, что хоть иногда может пригодится в работе (тема данной статьи, как раз этот факт), и точно коррелирует с абстрактным мышлением, которое программистам нужно. А будут люди учить наизусть истории о фейковом опыте конфликта в прошлой комманде, который они блестяще разрулили, будут платить за курсы ораторского искусства и учиться врать не краснея. Интервью в итоге будет отбирать самых хитрых и лицемерных и все.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ну… почти. У вас последний сегмент не обрабатывается. На строке "abbaaaa", для 'a' вернет 1 вместо 4.
НЛО прилетело и опубликовало эту надпись здесь
А group откуда? Из Data.List?
Почему? Не за количество же строк кода, слава богу, платят. По крайней мере в гугле.
Наоборот отличное решение. Только не специалисту в этом языке программирования вообще ничего непонятно. А еще неясно, как долго оно работает и сколько памяти дополнительной жрет (может у вас строчка в гигабайты?).
Ваще отвал башки. Помню когда изучал stl в плюсах, порой парсил одну строку кода час. А тут вроде даже что-то понятно, вон там group, вон max, да и &&& наверное погуглить можно. А можете написать объяснение, что тут и как, круто же?
«Мерседес у моего начальника видишь? Вот мои хард-скиллы!»
Я программированием зарабатываю 12 лет как (мое резюме). Начинал с расшифровки телеметрических данных баллистических ракет на плюсах, а последние лет пять во фронтэнде. ЧЕСТНО-ЧЕСТНО, мои системы работают, ими пользуются люди и за меня код никто не пишет. Эти системы частенько довольно сложны, но последние лет 7 без алгоритмики. С продажи этих систем мои начальник покупают себе яхты и мерседесы, да и мне на сырок «Дружба» хватает. Работал и маленьких, и в больших командах, мой код регулярно смотрят люди. Поставил эксперимент и начал решать вашу задачу, я ж сеньор в Швейцарии, а не клык моржовый.
Решил вашу задачу примерно за 40-50 минут чистого времени, используя песочницу кода, постоянно запуская код и иногда гугля вещи типа
Я из этого делаю следующие выводы:
Решил вашу задачу примерно за 40-50 минут чистого времени, используя песочницу кода, постоянно запуская код и иногда гугля вещи типа
hasOwnProperty и «чо там за функция преобразовывала строку в массив». Потом еще минут 10-15 приводил код в порядок. Мои наблюдения и переживания по этому поводу:- Блииин, во я лузер, не смог справиться с задачкой, чуть сложнее физзбазза.
- На белой доске, а не в песочнице мне понадобилось бы часа два. А может и три.
- Гмм, когда последний раз в моей работе мне удобнее было использовать
for, а неreduce? - Гмм, а почему
[...str]выдает в консоль не['b','b', 'b'], a простоbbb? (спустя 4 минуты) блин, похоже, это песочница так форматирует, все норм, это массив. Вроде. Ладно, вроде ж есть функцияsplit, которая стопудов дает массив. - В течение минут десяти была паника от того, что результат был неправильным. А он был неправильным потому что в самом начале у меня была якобы входная строка, а в свою функцию я ее не передавал как аргумент. В итоге эта якобы входная строка вообще была неиспользуемой переменной
- Я это все делал, лежа в тишине в постельке с ноутом на пузе и попивая вкусную сенчу, и с перерывом на завтрак, а не под пристальным взглядом какого-нить чувака, который презрительным взором пытается нащупать зачатки моих хард-скиллов.
- идею использовать currentSequenceLength и хранить в ней длину текущей последовательности подсказала мне жена, которая пару месяцев изучает C#, а до этого никакой алгоритмики в глаза не видела. У меня до этого был объект
champions, со структурой как у объектаresults, что было избыточно и усложняло код. - Если в строке будут эмодзи, все пойдет по рулю, ну да ладно.
Я из этого делаю следующие выводы:
- сама задача абсолютно не похожа на те, что я решаю восемь часов в день. То есть, какие-то хард-скиллы она проверяет, но не те, которые мне нужны для работы.
- к собесу, на котором есть даже самые хиленькие алгоритмические задачки вроде этой, надо готовиться отдельно и специально путем задрючивания leetcode'ов
- инструменты очень важны, и для решения подобных задач у вас они должны быть под рукой. А для этого вы должна готовиться к собеседованиям такого рода, ведь в вашей повседневной деятельности вы не решаете даже такие задачки.
Мой код. Публикую, обливаясь холодным потом и боясь, что вдруг оно все же не работает для каких-то случаев.
function getBiggestRepeatedSequenceLength(s) {
const result = {};
const strArray = s.split("");
let currentSequenceLength = 1;
for (let i = 1; i < strArray.length; i++) {
const curElement = strArray[i];
const prevElement = strArray[i - 1];
if (prevElement === curElement) {
currentSequenceLength++;
} else {
currentSequenceLength = 1;
}
const currentChampion = curElement in result ? result[curElement] : 0;
if (currentChampion < currentSequenceLength) {
result[curElement] = currentSequenceLength;
}
}
return result;
}
console.log(Date());
console.log(getBiggestRepeatedSequenceLength("aabbbccccaaaccccccca"));
console.log(getBiggestRepeatedSequenceLength(""));
console.log(getBiggestRepeatedSequenceLength("abababaccc"));
console.log(getBiggestRepeatedSequenceLength("cabccaabbcccaaabbb"));
console.log(getBiggestRepeatedSequenceLength("cabccaabbcccaaabbbcab"));справедливости ради — общую схему решения придумал минуты за три
Ваше решение не работает на тесте "abbb". Потому что у вас первый символ никогда не участвует в проверке на длину, а только для проверки на несовпадение со следующим символом. Исправить не сложно, на самом деле.
Во вторых, зачем вам s.split("")? У строки уже есть способ достать символ по индексу. Или s[i] или s.charAt(i), если верить справке (секция character access). Я на js не пишу и вообще его практически не знаю, но наличие такого метода было мне очевидно. Вы за 5 лет во фронтенде ни разу строки не использовали? Ни разу не надо было посмотреть i-ый символ?
Это могла бы быть попытка работать с юникодом, но тогда бы вы об этом наверняка сказали, да и в условии задачи это не надо. Кроме того split("") юникод все-равно поломает, когда как charAt() с юникодом работает (да, я это гуглил. На собеседовании я бы вам за эту попытку работы с юникодом, кстати, поставил бы жирный плюс. Рассмотрели интересный и важный случай, но забыли, как работает стандартная функция — черт с ней).
Я вам верю, что Вы умеете программировать, раз вас за 12 лет вас ни откуда не выгнали и на код ваш не жалуются. Но в гугл/яндекс вас не возьмут, потому что вы, скорее всего, будете работать сильно медленнее других кандидатов и допускать больше багов. По крайней мере не на сеньера точно. Потому что на эту тривиальную, на самом деле, задачу у вас ушел час времени, куча гуглежа и подсказка "коллеги". А звание синьер — не по выслуге лет дается. А за высокую производительность труда, высокое качество кода, лидерские качества и способность помогать команде.
Вы за 5 лет во фронтенде ни разу строки не использовали? Ни разу не надо было посмотреть i-ый символ?
Я вам клянусь, ни разу не нужно было. Обычно надо сделать что-то в духе toTitleCase или там trim или еще что-то в этом роде — все это есть в стандартной библиотеке и любая работа с индексами — это в 9 из 10 случаев говнокод. Если припрет и точно надо будет что-то реализовать — реализую, но вы видите, что обычно — надо было не настолько часто, чтобы быстро вспомнилось.
Но в гугл/яндекс вас не возьмут
Абсолютно согласен, что не возьмут, а если хочу, чтобы взяли — надо посидеть полгода-годик в leetcode. Но вот с тем, почему не возьмут — тут у меня большие вопросы. Что за такие удивительные задачи во фронтэнде Яндекса, что в других местах у меня не надо было брать [i]-тый символ в строке — а там надо?
Вы как-то берете за аксиому, что ваша задача имеет отношению к полезному, повседневному программированию. Я же вам оппонирую, говоря, что полным-полно программистов, к деятельности которых такая задача не имеет отношения — они не умеют их решать, а код в своих организация пишут хороший и полезный. Таким товарищам придется поступать как вот этому парню (между прочим гугловому вендору) — нарешивать сотнями задачки из литкода.
Я прошу прощения за эмоции, просто за живое задело и интересно докопаться до причин. Пока пришел к следующей гипотезе. В обычном промышленном фронтэнде мы собираем полезные системы из кусочков, в то время как в таких задачах упор идет на сборку кусочков из молекул. Мы наглядно видим, что моя ежедневная практика фронтэнда не помогла мне в решении задач на молекулы.
Ваше решение не работает на тесте «abbb».
Это при попытке причесать код бага появилась, нехорошо получилось. Сначала вот так было:
код
function getBiggestRepeatedSequenceLength(s) {
const result = {};
const strArray = s.split("");
let currentSequenceLength = 0;
for (let i = 0; i < strArray.length; i++) {
const curElement = strArray[i];
if (i===0) {
currentSequenceLength = 1;
} else {
const prevElement = strArray[i - 1];
if (prevElement === curElement) {
currentSequenceLength++;
} else {
currentSequenceLength = 1;
}
}
const currentChampion = (curElement in result) ? result[curElement] : 0;
if (currentChampion < currentSequenceLength) {
result[curElement] = currentSequenceLength;
}
}
return result;
}
console.log(Math.random());
console.log(getBiggestRepeatedSequenceLength("aabbbccccaaaccccccca"));
console.log(getBiggestRepeatedSequenceLength(""));
console.log(getBiggestRepeatedSequenceLength("abbb"));
console.log(getBiggestRepeatedSequenceLength("abababaccc"));
console.log(getBiggestRepeatedSequenceLength("cabccaabbcccaaabbb"));
console.log(getBiggestRepeatedSequenceLength("cabccaabbcccaaabbbcab"));
По крайней мере не на сеньера точно. Потому что на эту тривиальную, на самом деле, задачу у вас ушел час времени, куча гуглежа и подсказка «коллеги». А звание синьер — не по выслуге лет дается. А за высокую производительность труда, высокое качество кода, лидерские качества и способность помогать команде.Может, у автора коммента на его повседневных задачах как раз высокие производительность и качество кода и с командой он хорошо взаимодействует. Я бы не стал такие выводы делать по тому, как он решал эту несчастную задачку.
По вашему тону выходит, что он
Час на решение этой задачи? Серьезно? Я на дух не переношу алгоритмические задачки, но эта совсем элементарная. Псевдокодом на бумажке решается за минуту, я больше думал когда гуглил как строку в питоне итерировать, чем над решением
string = "aaaabccaab"
symbols = dict()
prev = None
count = 1
for i,c in enumerate(string):
if c != prev:
count = 1
else:
count = count + 1
symbols[c] = max(symbols.get(c, 1), count)
prev = c
print(symbols)Вы не ищете максимальный отрезок подряд идущих букв, а только последний. Например, на строке "aaaba", ваше решение вернет 1 для 'a', хотя должно быть 3. Потому что при обработке последнего символа вы перезапишете подсчитанное значение для 'a' на 1.
Да, я уже пофиксил. Думал успел исправить коммент пока никто не прочитал
НЛО прилетело и опубликовало эту надпись здесь
В реальной жизни на собесе(не в гугл) мне бы указали на ошибку, и я бы сходу её поправил. Не вижу тут реальной проблемы, затупить может каждый. Так или иначе, даже тут я ошибку нашел и исправил раньше, чем мне на нее указали (Ну или раньше чем я увидел комент).
А собес в гугл я и так знаю что не пройду, дрочить задачки месяцами у меня терпения не хватит.
А собес в гугл я и так знаю что не пройду, дрочить задачки месяцами у меня терпения не хватит.
НЛО прилетело и опубликовало эту надпись здесь
Вы сказали неправду про «минуту»;
С чего это? Время моих комментариев с решением и фиксом никак не коррелирует, мой комент висел на премодерации пару часов, а пока идет премодерация ни исправить\удалить комментарий, ни добавить еще один — нельзя. И когда пишешь псеводкод на бумажке нет накладных расходов на валидацию синтаксиса, запуск и проверку кода. Вы написали что потратили на все 10 минут, хотите сказать на само решение у вас ушло больше 1-2 минут?
поспешили им похвастаться
Такие тупые ошибки всегда случаются именно когда хвастаешься :)
полностью проигнорировали постановку задачи (рекомендую прочесть исходное сообщение еще раз).
Кто вам такое сказал?
Выведите максимальную длину подряд идущих символов для всех символов. Т.е. для aabccaaab, нужно выдать a: 3, b:1, c:2Для aabccaaab мое изначальное решение выдавало именно a: 3, b:1, c:2. Я достаточно тупой чтобы накосячить, но не такой тупой чтобы не понять задание.
Или вас смущает что я делаю просто print(symbols) вместо красивого форматированного вывода? Оно кстати выдает в таком формате {'a': 3, 'c': 2, 'b': 1}
все запощенные решения тут, включая моё — ошибочные, ни одно не проверяет исходную строку на null
Во-первых в современных языках есть non-nullable типы. Во-вторых далеко не во всех кейсах требуется проверка на null. Порой перфоманс важнее проверок, а порой функция приватная и проверка выполняется задолго до нее.
В третьих такие задачи дают на собесах чтобы проверить именно логику решения. Докопаться же в коде можно очень до многого. Помимо проверки null, тут никто (кроме растиста) не работает с utf8. Можно еще много чего найти. Но эти мелочи вообще не важны, важна именно логика решения. Странно что вы этого не понимаете.
Плохо если человек не может решить, плохо если решает задачу неадекватно долго, плохо если делает ошибки и при этом не может исправить.
Лично я бы не хотел видеть вас в своей команде, потому, что постоянно пришлось бы вас проверять и перепроверять, а потом фиксить ваши «косяки».
Вы попадаетесь на ту же ошибку, что и я с хвастовстом. Слишком уверенно делая диагноз по комментарию. Вы же меня в реальной работе не видели, всегда может оказаться так что это я буду за вами косяки подчищать, а не наоборот. Вы вон даже не понимаете зачем такие задачи на собеседованиях дают. Если действительно этих вещей еще не понимаете, собеседовать и принимать решения по подбору людей в команду вам рановато.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Интересно, отработает ли это на тех языках, где одна графема это несколько код пойнтов? Например, кхмерский или из простого чешский, где 'ch' — это одна буква?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Наверное потому что тут нет UTF-8?
НЛО прилетело и опубликовало эту надпись здесь
Вы на мои вопросы лучше ответьте, а не сьезжайте
НЛО прилетело и опубликовало эту надпись здесь
Пруфы косячности вашего кода, пруфы вашего незнания различий UTF-8/16/32 и незнания как устроен string в C# я привел всем, не только вам.
Наверное, на этом я общение с вами закончу: вы не любите критикуДавайте говорить правду: вы не хотите продолжать спор, потому что боитесь признать свою ошибку
P.S. Все-таки научитесь читать текстНечего ответить — докопайся до орфографии, классика
И, да. В языках где один символ — несколько кодпоинтов у вас работает не корректно
Юникодная консоль ваш тут не спасет
.NET 4.7.2 если что
CharSequenceCount("វឌ្ឍនននភាពពពពវវវវវវ");
CharSequenceCount("ទ្រ");ឌ: 1 ឍ: 1 ន: 3 ព: 4 ភ: 1 វ: 6 ា: 1 ្: 1
ទ: 1 រ: 1 ្: 1
Юникодная консоль ваш тут не спасет
.NET 4.7.2 если что
Справедливости ради.
Вот на такой строке не сработает
Надо использовать System.Globalization.StringInfo.
Вот на такой строке не сработает
CharSequenceCount("ȧȧȧȧȧȧȧ");Надо использовать System.Globalization.StringInfo.
НЛО прилетело и опубликовало эту надпись здесь
В моем нужно добавить один символ, for (int i = 0; i < s?.Length; i++))
И вы считаете это адекватным решением? Это сойдет для хотфикса, но в продакшен коде лучше сделать нормальную проверку на null в начале. Потому что завтра кто-то допишет еще одно обращение к s не заметив вопросик и все «упадет».
Как я сказал в коде(и в моем разумеется тоже) можно докопаться до очень многих вещей, но нужно ли?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ну товарищ, я за вас рад, вы гигант. Мне для подготовки нужно будет дрочить литкод полтора года, а вам — может быть, всего три месяца. Я так все откровенно расписал по важной причине. Меня настораживает тот факт, что мой опыт помогает зарабатывать бабки начальству (и чуток себе), но не помогает решать такого рода задачки. В чем тут разгадка?
- В гуглах другие повседневные задачи, нежели лично у меня?
- Во фронтэнде другие повседневные задачи, нежели у гуглов?
- Мне платят деньги по ошибке и фирма получает деньги от заказчиков зазря?
- Задачки на собесах вообще не должны быть как-то сильно связаны с тем, над чем ты работал?
Во фронтэнде другие повседневные задачи, нежели у гуглов?
Разгадка простая — фронтенд это не программирование, а формошлепство. Дизайн интерфейса и UX в разы более интеллектуально насыщенная деятельность. Формошлепство же при каком-никаком опыте не требует напряжения мозга, просто клепаешь на автомате.
Задачки на собесах вообще не должны быть как-то сильно связаны с тем, над чем ты работал?
Лично я откровенно хейчу гугловский подход к собесам с дрочерскими задачками, особенно зная качество кода их продуктов. Как раз за то что они проверяют навыки вообще не связанные с работой программиста. Да и людей знаю, которые собесы в гуглы проходят, а программировать не умеют. Опыт подсказывает что автор поста как раз к таким людям относится.
Но конкретно эта задачка вообще детская и проверяет базовое умение программировать вообще. Даже в рамках формошлепства, такая раз в месяц попадается.
Разгадка простая — фронтенд это не программирование, а формошлепство.
Не ну это тоже ответ, который можно обсуждать. Но ведь мы говорили о переходе из фронтенда вне гуглов во фронтенд же — в гуглах.
Мне при переходе из плюсов в бэк (джава, джанго, пых), а потом во фронт (angular) становилось проще и веселее, поскольку характер повседневных задач становился ближе к тому, что я люблю. В итоге я пришел к тому, что самое приятное — это что-то на стыке фронтэнда, UX и продакт-менеджмента: тесно общаешься с юзерами, горячо обсуждаешь приоритеты в фичах, наблюдаешь за тем, как они юзают систему и как можно сделать так, чтобы система угадывала их мысли. Потом смотришь как они радуются и сам радуешься. Параллельно стараешься кодить так, чтобы всем вокруг было как можно понятнее и радуешься, что все остальные быстро въезжают в твой код.
Так это правда, че ее обсжудать.
Не, мы говорили о том, почему ваш опыт фронтенда не помогает вам решить задачу про aabccaab.
Это все не имеет отношения к программированию.
Поэтому и не помогает. Опыт покраски стен не поможет построить здание.
Это кстати меня удивляет. Потому что ваш код из примеров плохочитаем, и чрезмерно длинные названия этому только мешают. Вы бы хоть отступы между строчками расставляли.
Но ведь мы говорили о переходе из фронтенда вне гуглов во фронтенд же — в гуглах.
Не, мы говорили о том, почему ваш опыт фронтенда не помогает вам решить задачу про aabccaab.
В итоге я пришел к тому, что самое приятное — это что-то на стыке фронтэнда, UX и продакт-менеджмента: тесно общаешься с юзерами, горячо обсуждаешь приоритеты в фичах, наблюдаешь за тем, как они юзают систему
Это все не имеет отношения к программированию.
Поэтому и не помогает. Опыт покраски стен не поможет построить здание.
все остальные быстро въезжают в твой код.
Это кстати меня удивляет. Потому что ваш код из примеров плохочитаем, и чрезмерно длинные названия этому только мешают. Вы бы хоть отступы между строчками расставляли.
Если все это не имеет отношения к программированию, чем получается я занимаюсь и что мне нравится? Вопрос без подтекста, просто полезно знать, вдруг у этого есть название и надо искать себя в другой области.
По поводу длинных названий — критику принимаю, думаю опыт работы с джавашниками в энтерпрайзе сказывается. Там выше было решение товарища (кстати на джаве), в котором совсем мало строчек, и коротенькие имена, а читается легче. Опять-таки, если задаться целью, то за полгодика уж точно должно поправиться.
Опять-таки, если задаться целью, то за полгодика уж точно должно поправиться.
Весмя странно имея большой опыт, не уметь на автомате писать более-менее чисто.
Обычно это нарабатывается в первые пару лет программирования, даже без участия более опытных товарищией. Просто через месяц смотришь на свой код, сходу не можешь понять и понимаешь что надо почище писать.
Это не критика, просто меня это удивляет
По поводу названий не соглашусь. Для собеседования, скорее всего, будет рациональнее сократить, но для рабочего кода длинные читаемые названия будут лучше коротких. Код читается гораздо чаще, чем пишется, не стоит на этом экономить. Тем более, сейчас многие работают с IDE и названия можно автозаполнять.
Мне тоже показалось, что зависит от класса задач, языка и принятых в нем церемоний. У нас вот молятся на книжку Clean Code, плюс много джавы — и там и там названия довольно длинные (QueryBuilderMappingStrategy), привыкаешь быстро. На код-ревью часто названия переменных обсуждаются. В алгоритмике и в Сях иногда не западло назвать переменную просто сtr, buf (ну counter и buffer), а то и вообще c и a (количество и аккумулятор) плюс широко используются сокращения слов до согласных букв. Питонисты, как мне показалось любят одно-два слова в названии. Приходишь в чужой храм — быстренько почитай устав и делай как все.
но для рабочего кода длинные читаемые названия будут лучше коротких
Ключевое слово — читаемые. Я критиковал именно нечитаемые.
У человека есть значительные ограничения на восприятие, название из двух слов вопсринимается легко, название из длинных 4-5 слов — не воспринримается вообще. Писать непонятными сокращениями плохо, писать длиннющие названия тоже плохо.
Лично я откровенно хейчу гугловский подход к собесам с дрочерскими задачками, особенно зная качество кода их продуктов. Как раз за то что они проверяют навыки вообще не связанные с работой программиста. Да и людей знаю, которые собесы в гуглы проходят, а программировать не умеют. Опыт подсказывает что автор поста как раз к таким людям относится.
Какие ваши доказательства, что я не умею программировать? А также не могли бы вы поделиться своим резюме и примерами кода как образцом для подражания? Рекомендую, правда, заранее его протестировать, чтобы не было как с задачей про строки.
Какие ваши доказательства, что я не умею программировать?Никаких, равно и доказательств что умеете. Только интуиция, я же написал.
А также не могли бы вы поделиться своим резюме и примерами кода как образцом для подражания?
Не, ну так не честно. Одно дело — мы с вами, под настоящими именами, со ссылками на профили, с репутацией и осознающие, что все, что мы тут понапишем сохранится навсегда, а другое дело — троллящие дети под одноразовыми аккаунтами. Нельзя их к такому принуждать.
НЛО прилетело и опубликовало эту надпись здесь
Мне на ум приходит следующее:
- В том, как организовать асинхронные потоки и потоки управления так, чтобы все легко читалось и занимало мало строчек кода. Реактивность и вот это все.
- В том, как выстроить простую архитектуру, в которую сможешь въехать миддл или джун за минимальное время
- В том, как убедить заказчика не делать эту фичу, которая будет нам стоить 2 месяца, а вместо этого сделать вот эту фичу, которая нам будет стоить три дня, а задача заказчика будет решена и в первом и во втором случае. Это вот самое важное, на мой взгляд. Кодить — вредно и затратно.
- В том, как как обмазать это все гайдлайнами, документацией, тестами (оставив важные и убрав идиотские), чтобы в отсутствие тебя это все не поросло чертополохом и не вызывало баги.
НЛО прилетело и опубликовало эту надпись здесь
Так это уже алгоритмика.
Гм, не думал об этом. наверное, да — алгоритмика, просто непривычная. Составными элементами являются не индексы и даже не filter'ы с map'ами и reduc'ами, а жуткое количество операторов rx-a, а объекты оптимизации — не столько сложные структуры данных, сколько сложные взаимодействия во времени и «кто на что должен реагировать».
Спроектировать систему — значит составить такую систему уравнений, которая удовлетворит всем требованиям. А придумать алгоритм это очень похожий, но всетаки немного иной и более линейный навык. В системе каждая ее часть влияет на другие части, в алгоритме же все линейно — каждый пункт влияет только на последующие. В хорошей системе алгоритмы взаимодействия ее частей простые, уж явно проще всяких дрочерских алгоритмов сортировок.
Но решения алгоритмических задачек, тем более под собесы — это не умение придумывать алгоритмы, это подмена этого умения заучиванием разных готовых алгоритмов. Это как учить паттерны проектирования, вместо того чтобы учиться проектировать.
Да, и сложную систему может сделать любой дебил. Настоящая сложность в том чтобы сделать ее простой.
Но решения алгоритмических задачек, тем более под собесы — это не умение придумывать алгоритмы, это подмена этого умения заучиванием разных готовых алгоритмов. Это как учить паттерны проектирования, вместо того чтобы учиться проектировать.
Да, и сложную систему может сделать любой дебил. Настоящая сложность в том чтобы сделать ее простой.
Ой, вот еще. Бывают системы, которые сложные с методологической точки зрения. Я как-то работал над системой, в которой надо было максимизировать конструктивность дискуссии и стимулировать консенсус сообщества редакторов.
Ну типа есть у нас выдвинутый кем-то законопроект о сипульках, и есть 300 экспертов-сипулёлогов с научными степенями. Надо чтобы они посмотрели на законопроект и сказали, что в нем плохо, а что хорошо, и как надо, если что-то плохо. Если дать им в качестве инструмента экспертизы почту — будет совсем плохо. Дать гугл-док или вики, и пусть себе редактируют — передерутся и прав будет не самый конструктивный, а тот, кто сделал последнюю правку. Поместить на бложик или дать обсудить на форуме — засрут все комментариями и фиг ты потом поймешь, а что не так-то.
Тут методологическая часть настолько сложная, что капец, а реализовано все может быть на простейшей структуре БД, простом фреймворке и реально несложных алгоритмах.
Ну типа есть у нас выдвинутый кем-то законопроект о сипульках, и есть 300 экспертов-сипулёлогов с научными степенями. Надо чтобы они посмотрели на законопроект и сказали, что в нем плохо, а что хорошо, и как надо, если что-то плохо. Если дать им в качестве инструмента экспертизы почту — будет совсем плохо. Дать гугл-док или вики, и пусть себе редактируют — передерутся и прав будет не самый конструктивный, а тот, кто сделал последнюю правку. Поместить на бложик или дать обсудить на форуме — засрут все комментариями и фиг ты потом поймешь, а что не так-то.
Тут методологическая часть настолько сложная, что капец, а реализовано все может быть на простейшей структуре БД, простом фреймворке и реально несложных алгоритмах.
В чём сложность системы, если не в алгоритме?
Сложность в том, чтобы всё правильно сделать. Представьте, что вам дали некое устройство, например, плату приёма-передачи. Расписали регистры и принцип работы. Итак, ваша задача запустить плату и обеспечить приём и передачу данных. Вы начинаете эту задачу решать. Так, буфер платы всего 64 сообщения на приём и 8 на передачу. Клиент может не забирать данные и хотеть передавать много. Ладно, ставим кольцевой буфер. Обработка буфера должна быть в отдельном потоке, чтобы не задерживать клиента. Поток будем синхронизировать мютексом, а запускать с помощью posix. Для удобства вкатаем RAII на мютекс. (Да, std::thread в систему не завезли — gcc2.95 (ну или 3 какой-то там ещё можно выбрать) и обновить пока у меня не вышло — система QNX 6.3). Кстати, я и не пользуюсь, потому не знаю про std::thread, он вообще позволяет делать настройку потока? Диспетчеризацию выбирать? Наследование приоритета? В общем, всё то, что позволяет posix create_thread. Я что-то не нашёл такого.). Назначим средний приоритет потоку. Далее, вспомним, что читаем мы регистры платы через адресное пространство шины PCI (попутно научимся поиску устройства и вообще работе с этой шиной). Попутно вспомним про барьеры памяти — поставим и их на операциях доступа к шине. Ах да, плата генерирует прерывание при приходу данных. Делаем обработчик в отдельном потоке, так как непосредственно занимать прерывание не стоит и упасть в обработчике будет очень-очень грустно. Запускаем. Всё работает. Ура!!! Проходит год. Однажды, на какой-либо системе вдруг вся программа резко зависает намертво. Что за хрень? Выясняется странное:
Сегодня попался компьютер (на i3), на котором программа весело зависает намертво вместе с системой при завершении программы по сигналу или при вызове функции Init повторно. Ни на одном другом компьютере такого не было никогда! В попытках понять, что происходит, удалось обнаружить, что зависание возникает при вызове функции StopThread. Но вся штука в том, что зависает захват мютекса в классе RAII для работы с мютексом. Я в полном недоумении. Если пропустить настройку каналов в инициализации, то зависания не происходит. Что от этого меняется-то? Прерывания не приходят? Но я полностью отключал поток обработки прерываний (вместе с InterruptAttachEvent) — зависает также на ура. И главное, я не понимаю, чем занимается в это время процессор. Такое впечатление, что система застревает в каком-то своём ISR (моего-то нет — InterruptAttachEvent), откуда не выходит. Странно ещё и то, что если убрать InterruptUnmask, то намертво отваливается USB-клавиатура, но мышка PS/2 живёт, как и вся остальная система. Уж не поделила ли QNX линию прерывания платы с другими устройствами и что-то работает неверно, вот и виснет?
Но нет, всё банальнее:
Интересная штука. Оказывается, всё дело в этих самых прерываниях. Плате обязательно нужно их запретить до завершения работы с ней и шиной PCI. Похоже, если у неё не сбросить флаг прерывания, считав регистр прерываний, она начинает генерировать прерывания непрерывно, чем загоняет QNX до зависания. А не натыкался я на такое, потому что система работала как запрос-ответ и сама формировала запрос. Как только я стал ловить приходящий траффик, тут всё и повисало намертво.
Итак, у нас получился модуль работы с платой. Пользователю этого мало. Он желает писать данные на диск с частотой 32 Гц (при этом вспомним, что дисковые операции могут занять 100 мс и выше, что провалит цикл, то есть, писать в основном потоке синхронными операциями нельзя, а асинхронные всё равно потребуют буферизации, так что выносим синхронные дисковые операции в отдельный поток). Дальше, пользователю надо обеспечить протокол обмена и выполнение цепочек команд к устройству, причём, эти команды хотят использовать принятые данные от устройства (которое может не отвечать на нужный момент — зависло или линия накрылась). Так, это сделали. Простые команды не интересно, нужны команды, состоящие из сложной последовательности действий: получить вектор гироскопа, сравнить с вектором требуемым, совпадает с погрешностью — завершить работу, отключив токи в катушках, иначе передать контроллеру разгона какие токи выставить в катушках, чтобы вектор дошёл до нужных (гироскоп идёт перпендикулярно приложенной силе, плюс перекосы магнитного поля, так что тут подстройка на регуляторе), повторить. Ну и это ещё не всё — ещё надо добиться стабильности цикла, определить механизм обмена (посылаем — ждём ответа или посылаем всем, ждём N-мс и смотрим, что пришло и надеемся, что шина CAN всё сама разберёт в последовательности передач), нарисовать годограф, если пользователь этого желает с перемасштабированием. :)
Формально, всё это алгоритмы, как последовательности действий. Но это не те алгоритмы, которые понимаются под алгоритмами, когда заходит о них разговор.
НЛО прилетело и опубликовало эту надпись здесь
Ну вот моё решение, кое-как обрабатывающее Unicode. Точно время не засекал, но в 15 минут вроде уложился. Я прошёл?
НЛО прилетело и опубликовало эту надпись здесь
То что sumanai забыл обработать последнюю последовательность всё равно бы считалось что ок, кодить умеет.
Смотря в какую компанию. Например, в Google сложилось впечатление, что это будет ок, только если самому успеть найти ошибку.
Это снизит вероятность strong hire. Но если кандидат с подсказками вида "Вы уверены, что у вас все крайние случаи обрабатываются? Что если строка очень короткая? Очень-очень короткая?" находит ошибку, то это hire. Да, если в такой простой задаче кандидат будет искать ошибку 10 минут после 30 минут кодирования, то это будет не рекомендация от меня.
Наконец-то добрался до компа: было смутное ощущение, что можно обойтись чисто LINQ, но ReverseSplit пришлось писать вручную.
Интересно, что я тоже сходу накосячил с «abbaaaa», как и sumanai, при том что решения визуально не очень-то и похожи :)
Код
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApp2
{
static class Program
{
static void Main(string[] args)
{
CountSequences("aabccaaab");
CountSequences("abbaaaa");
CountSequences("aabbbccccaaaccccccca");
CountSequences("");
CountSequences("abababaccc");
CountSequences("cabccaabbcccaaabbb");
CountSequences("cabccaabbcccaaabbbcab");
Console.ReadKey();
}
private static void CountSequences(string input)
{
var result = input
.Distinct()
.Select(x =>
new KeyValuePair<char, int>(
x,
input.ReverseSplit(x).Max(y => y.Length)));
var formatted = result.Select(x => $"{x.Key} - {x.Value}");
Console.WriteLine($"{input}: {string.Join(", ", formatted)}");
}
public static List<string> ReverseSplit(this string input, char nonSeparator)
{
var result = new List<string>();
var sb = new StringBuilder();
void FinalizeSequence()
{
if (sb.Length > 0)
{
result.Add(sb.ToString());
sb.Clear();
}
};
var i = 0;
while (i < input.Length)
{
if (input[i] == nonSeparator)
{
sb.Append(nonSeparator);
}
else
{
FinalizeSequence();
}
i++;
}
FinalizeSequence();
return result;
}
}
}Интересно, что я тоже сходу накосячил с «abbaaaa», как и sumanai, при том что решения визуально не очень-то и похожи :)
Что думаете о вот таком методе подготовки? Меня этот товарищ удивил своей методичностью.
На мой взгляд, хороший метод. Единственное, что смутило:
Мне кажется, достаточно один раз написать задачу без подсветки синтаксиса. Автор пытается после этого заново написать компилируемый код, но это оверкилл для собеседования: опечатки и не совсем верные названия функций допускаются.
Перебиваем код в любимую IDE, при этом не смотрим в бумажку. Таким образом, мы повторяем решение два раза.
Мне кажется, достаточно один раз написать задачу без подсветки синтаксиса. Автор пытается после этого заново написать компилируемый код, но это оверкилл для собеседования: опечатки и не совсем верные названия функций допускаются.
Интересный гайд получился и круто структурировано. Спасибо!
Я для прохождения интервью и общего развития рекомендую www.educative.io/courses/grokking-the-coding-interview Этот курс рассказывает про паттерны которые чаще всего используются для решения задач на интервью.
Этот курс есть у меня в ссылках, стоит заметить, что он платный (бесплатно несколько частей). Есть бесплатная статья от его автора, где расписаны эти паттерны, на русском и английском. Среди плюсов: хороший подбор задач, разбивка по темам, подробное объяснение. Недостатки: встречаются ошибки в предложенных решениях, и всё очень плохо с тестами, их буквально 2-3 на задачу и откровенно неправильные решения могут их пройти. Приходилось искать похожую задачу на Leetcode и прогонять решение там.
Пользуясь случаем, хочу спросить у информированных людей: я из академического и спортивного интереса написал компрессор LZ77 типа для работы в реальном времени (можно сказать, на лету). Он по соотношению скорость/коэфф. сжатия/разжатия заметно превосходит аналогичные программки известных спецов (blzpack, например) и приближается к известной zstd Яна Коллета (с ключами -1 и -2). Коэфф. сжатия на лету — оставляет 40% от enwik8 (самого известного файла для пузомерки). Хочется узнать, как можно заработать на алгоритме/исходниках этой программки: кто-то ведь этим интересуется (студенты, напр.) и могут купить? Распространять, как шареваре, по-моему бесперспективно, да и алгоритм своруют…
Мне кажется, вам просто можно написать статью в реферируемый журнал для начала, сюда например или сюда. В обоих журналах публиковался Дональд Кнут. Если алгоритм толковый и полезный, вас опубликуют и, может быть, когда-нибудь, мы будем читать о вас в Искусстве программирования.
Спасибо, запишу ссылки. Можно публиковать только в одном каком-то журнале? Обычно разработчики создают проект на Гитхаб аналогично LZ4 и zstd Яна Колле (который получает з/п в Фейсбуке, сжимая короткие сообщения) и/или свой сайт, как автор LZO, на котором отдают исходники какой-нибудь мини-версии и продают коммерческую версию в виде архиватора.
Но если вдруг кто-то из компрессорщиков годами раньше уже додумался до некоторых моих находок, то может произойти что-то нехорошее…
Но если вдруг кто-то из компрессорщиков годами раньше уже додумался до некоторых моих находок, то может произойти что-то нехорошее…
Хочется узнать, как можно заработать на алгоритме/исходниках этой программки: кто-то ведь этим интересуется (студенты, напр.) и могут купить? Распространять, как шареваре, по-моему бесперспективно, да и алгоритм своруют…
Заработать на алгоритме — никак. Можно попробовать на основе этого алгоритма сделать какое-то решение которое потом продать, но сам алгоритм — практически без шансов.
Большое спасибо за интересную статью!
Вопрос: можно ли по опыту поиска работы в гигантах FAANG понять, имеет ли для них значение возраст соискателя или только опыт?
Вопрос: можно ли по опыту поиска работы в гигантах FAANG понять, имеет ли для них значение возраст соискателя или только опыт?
Я не сталкивалась с эйджизмом и не слышала об этом от знакомых. Теоретически, возраст не должен влиять, и компании всячески поощряют его не указывать в резюме, например. Но практически все не так хорошо.
При приеме на работу дискриминация по возрасту запрещена законом и это строго соблюдается (по крайней мере, формально). У вас никогда не спросят про возраст, религию, ориентацию, семейное полложение и тд. А если говорить о среднем возрасте сотрудников, то сильно зависит от подразделения. Видел команды (в основном занимающиеся системными вещами) где средний возраст был хорошо за 40. В целом, по моим наблюдениям, эйджизм если и есть, то намного менее выражен, чем в России.
greenEkatherine Поздравляю с оффером! Особенно в виду текущей ситуации в мире.
По части design interview, кое-что интересное есть у Tushar Roy: 1, 2, 3, 4. Так же, у Success in Tech довольно занимательные видео по теме. Плюс InfoQ и другие тематические конференции.
Для тех, кому интересны финансы — levels.fyi. И да, эти цифры не имеют никакого значения без понимания системы налогообложения и стоимости жизни в соответствующей локации.
По части design interview, кое-что интересное есть у Tushar Roy: 1, 2, 3, 4. Так же, у Success in Tech довольно занимательные видео по теме. Плюс InfoQ и другие тематические конференции.
Для тех, кому интересны финансы — levels.fyi. И да, эти цифры не имеют никакого значения без понимания системы налогообложения и стоимости жизни в соответствующей локации.
Спасибо за поздравление и полезные ссылки. Стоимость жизни можно примерно сравнить здесь
Что думаете насчет Hackerrank? Я думаю, что вы по любому рассматривали его как альтернативу Leetcode.
Я использовала Hackerrank до того, как перешла на Leetcode. Ушла с Hackerrank в первую очередь потому, что там не осталось соревнований, а хотелось потренироваться в боевых условиях. Ещё, насколько я помню, там было неудобно смотреть чужие решения — нельзя было за них проголосовать или обсудить. Мне нравится что на Leetcode активное коммьюнити, много обсуждений, решений, описания опыта подготовки и прохождения собеседований. Можно искать прямо по компаниям, как в постах пользователей, так и в тэгах задач — это тоже очень удобно, когда готовишься в конкретную компанию.
Это даже не статья, а пошаговый план подготовки для любого разработчика.
Подготовка к собеседованиям в IT-гиганты: как я преодолела проклятье алгоритмического собеседования