Comments 68
Каждый вопрос - доклад минут 20-40.
Крутая статья!
Теперь у вас появятся много разработчиков, кто знают ответы на все ваши вопросы ?
Если правда знают - можно брать.
Так тут как раз ответов нет. А вопросов так много, что либо это учишь долго, либо почти всё забудется перед собеседованием. Так что тот, кто будет знать ответы на эти вопросы, скорее всего нормальный специалист :)
Поверь, все равно не появятся)))) есть куча ресурсов, где учи - не хочу, как говорится)) но никто это не делает)) а жаль)
Зачем про управление памятью на уровне ОС? Никогда не слышал таких дискуссий у бэкендеров!
Память нерезиновая, многи разрабы часто вообще не думают о том что есть "железо" на котором запускается их творчество и что оно стоит денег и меет пределы.
Очередной маньячило из прошлого века. 99% мидов завалит на собесе. При том что для работы, особенно на бэкэнде многое вовсе не нужно в подавляющем большинстве кейсов. Удивлен, как он сюда еще остальные языки бэкэнда в обязалово не напихал.
Приведу еще один вариант «плохого» вопроса. Например, мы собеседуем разработчика на Go и просим его рассказать, как сделать семафор с помощью канала.
— Семафоры и мьютексы: как имплементировать семафор с помощью канала?
Вся правда по МТС в одном вопросе?)
Автор здесь: да, поймали меня. Так вышло потому, что сначала был список вопросов, который пополнялся. Он и сейчас есть, на гитхабе, на английском правда. Статья была дописана сверху него, как бы. Таким образом, здесь нет противоречия. Да, такой вопрос есть. И да, я считаю что это плохой вопрос. Как говорил Ларри Уолл - "1 - я всегда прав, 2 - я могу изменить свое мнение".
Там же написано, что цель статьи - не дать вам чеклист готовый! Она как раз об этом. Я поражен сколько много комментов, и, пользуясь случаем хочу ответить тем, кто удивляется тем что вопросы какие-то может не нужны, или неуместны..... Друзья! Эта статья - мой личный опыт (история рассказанная за пивом), вкупе с некоторой моей личной шпаргалкой. И как и всякую не свою шпаргалку, использовать все это буквально точно не надо.
Скорее, это про определенную мысль, которая пронизывает статью от начала до конца, о отношении к самому действу под названием собес. Что это? Для чего он? А список вопросов, вы если что, и сами напишите. Этот список - просто пример, рассматривайте его так, и не более чем так.
И еще. Да, у нас в МТС высокий уровень. И да, мы считаем что разработчик бэка должен отличать L2 и L3. И точно должен знать про память.
Кто-то писал, что "а что я могу почерпнуть отсюда". Окей, если вы прочитали, это заставило вас задуматься - вы уже что-то почерпнули.
Желаю всем хорошего и продуктивного 2022 года!
Еще раз, чтобы не было разночтений:
- список вопросов который всем так не понравился - моя личная шпаргалка.
- Вам, при использовании моей шпаргалки, возможно не надо пользоваться ей буквально.
- список не является "официальным чеклистом для приема на работу" куда либо - это моя личная шпаргалка.
- Эта шпаргалка - прежде всего не для тех кто ищет работу, но прежде всего для тех кто проводит собеседования. Материал для вдохновления, чтобы написать свою. Возможно даже, для другого языка (!). Смотрите шире и более обще.
- Несмотря на критику, под каждым словом подписываюсь, так что не надо тут "накидывать косвенно" на МТС. Не согласы - пишите мне лично "ты написал дичь", и (!) содержательно аргументируйте почему.
- И САМОЕ ГЛАВНОЕ: лучший способ пройти любое интервью - по чесноку знать то, на что претендуете. Тогда не придется ничего заучивать.
"по чесноку знать то, на что претендуете" - а вот это смешно было, учитывая сколько и чего требует средняя компания в описании вакансии и сколько из этого реально нужно.
Ээээ... Там много что пишут. Когда вы идете устраиваться на работу, вы матчите то что там написано, с тем что вы сами про себя считаете. И то что порой в требованиях пишут рандомный набор - это же все знают, что об этом говорить-то? Это просто так есть.
Вы должны сами для себя прежде всего понимать кто вы есть в этом мире, что вы умеете, какую ценность несете.
Таким образом слова "то на что претендуете" - это не про список требований в вакансии. Это - про то что вы сами про себя считаете и вслух говорите.
Например - вы приходите на вакансию Питон-программиста. Или 1С. Или любого другого. Или стоматолога. Или менеджера. Сам факт что вы пришли - манифестация вами утверждения что вы в этом профессионал, вы декларируете "вот я, я пришел, я знаю Питон".
И если вы и правда его знаете - вам не страшны никакие опросы и вопросы. Если вы его правда знаете. А если не знаете - вряд ли заучивание поможет.
Если востребованы знания столь низкого уровня, наверно речь идет о высоконагружаемых и высоконадежных проектах с неограниченным временем разработки и тестирования. Однако в большинстве случаев нужно было все сдать уже вчера, и слайс используется в отличие от массива только потому что он расширяется. Возможно лучше будет например способность найти оптимальное количество абстракций проекта под задачи бизнеса? Или исходя из перспектив тип фреймворка, ORM или RAW SQL, форматы обмена по шинам и т.п.? Вопросы вроде на синьора, но для синьора на мой взгляд важнее, что я написал. А подход к собеседованию самый адекватный из тех что я видел!
Раньше когда сам только ходил на собеседования не понимал зачем задают такие простые вопросы. С недавних пор сам начал собеседовать и понял - 80% не знает и минимума, хотя опыта якобы несколько лет. До вопросов со звёздочкой или философских вопросов ещё не доходил - не было такого, чтобы кандидат отвечал на вопросы так быстро и ясно, что хотелось ему позадавать более "сложные". Правда и собеседовал на джунов и мидлов. Хотя, казалось бы, основы у них должны от зубов отлетать.
Все читал и думал - а это точно про МТС? А потом когда дело дошло до списка вопросов и чек листа после прохожденя которого якобы человек попадает в МТС понял что точно не про МТС.
Половина вопросов теоретические. Далеко не каждый день сидишь и копаешь процессы, потоки ос и решаешь задачи/проблемы виртуализации и системного администрирования.
Чаще всего перекладываешь json в базу и обратно. И раскапываешь доку на внешний сервис, с которым тебе надо интегрироваться. Периодически возникают проблемы производительности. Но никакое управление памятью потоками и процессами оказывается не причем. А тупо в семафор случайно передают ноль в качестве периода срабатывания, что и грузит проц на 99%.
Так что все сводится к повторению теории перед собеседованием. В надежде угадать какие именно вопросы будут спрашивать именно на этом собесе.
IP адреса, маски, DNS?
VPN и бриджевание L2 или L3 — в чем разница?
Что такое ARP-запрос?
А зачем это знать бекендщику ?
Аналогично. В свое время приняли на работу по остаточному принципу. Зато мессия собеседований того дня потом сидел на работе безвылазно, т.к. дошло до последнего китайского, а я приходил к обеду и периодически на живую исправлял косяки тех, кто приходил во время.
И вообще собесы для меня полная катастрофа, а отпускать так же не хотели.
Статья как раз о том, что возможно НЕ НАДО спрашивать про определение транзакции, или про труктуру пакета. Вы, для себя, для своего проекта, должны определить что точно и без вариантов должен кандидат знать. На все остальное можно закрыть глаза.
Важно ли для вашего проекта знание структуры пакета? Да или нет? Если нет - это не попадает в список. Если да - тогда да. И так по каждой позиции.
Данный список - моя личная шпаргалка, чтобы самому уже не путаться (т.к. когда проведешь два собеса в день, (а и так было), то уже не помнишь что спрашивал что нет), и это не официальный список МТС. Более того, наверняка многие коллеги со мной бы поспорили, по этому списку.
Эх, вот уж этот список
Вы человека прямо на конкретный проект нанимаете и точно знаете, что ему в нем понадобится, а что нет?
Важно ли для вашего проекта знание структуры пакета? Да или нет? Если нет - это не попадает в список. Если да - тогда да. И так по каждой позиции
итого: человек работал в компании с другим акцентом, например на жирную бизнесуху или еще что-то, умен и алгоритмы круто делает, а вот сетевые штуки слегка заплесневели в его багаже... вы определили, что сеть — ниважнейший из акцентов, человек не угадал с подготовкой, но умен
Fail
Двойной: человек провалился, вы упустили умного кандидата
Интересно, сколько должно длиться интервью, чтобы успеть обсудить все эти вопросы. Или это работает по-другому - вы просто задаете несколько рандомных вопросов из этого списка, и если кандидат на них ответил - значит он знает ответы на все остальные и "профпригоден"?
В любом случае, было бы интересно узнать, какой процент действующих разрабов МТС сможет ответить на весь этот список и почему они все еще работают в МТС
Ну этот список вопросов, кстати, никак не копирует гугл и нетфликс, в отличии от яндекс и тинькофф, там все таки литкод, а здесь просто слишком хардкорный и длинный (для такой компании) список вопросов, который возможно и может оценить кандидата лучше, чем проверка задачек на алгоритмы
Вообще-то, это мой личный список вопросов. Моя личная шпаргалка. Ну а поскольку я работаю в МТС, то если вы придете к нам на работу устраиваться, и вам "повезет" что собеседовать буду я, то я задам эти вопросы... или не эти, или другие. Но это точно не копирование кого-то. Если у кого-то так же (а мне уже говорили об этом, как комплимент), ну значит крутяк, я мыслю похожим образом, и для вас дорогие читатели выше вероятность что это валидный подход.
90 минут достаточно. Если на вопросы есть корректные ответы. Если нет - 30 минут вежливости. Ну час.
Читайте внимательнее :) все вопросы не надо задавать. Это не чеклист. Это шпаргалка.
Хорошая и логичная статья, кроме списка вопросов в самом конце. Похоже что автор сам себе противоречит.
Только что мы разговаривали про нагрузочное и интеграционное тестирование, и, оказывается, он не знаем что такое стек, или структура данных, или… Да, я реально разговаривал с людьми, которые не знают, что такое рекурсия и стек!
Потом столкнулись с таким во второй раз. Было очень больно.
Если мне два кандидата, покажут свои домашние проекты, на одном авто-тесты с 90+% покрытием и CI/CD, но он не знает всего вышеперечисленного, а у другого нет авто-тестов, но в теории он прям все знает - я выберу первого.
На практике самое сложное - это добиться того, чтобы даже простой код на проде работал и не ломался. Не смотря на постоянные обновления и расширения функционала. Не смотря на смену программистов.
Теория это все здорово, но она не всегда конвертируется в надежный код. Более того, замечаю такой интересный феномен, что если программист работает много лет, но так и не дошел до написания тестов - то дальше он скорее всего их никогда и не будет писать. Видимо у человека появляется корона на голове, и писать "скучные" тесты это ниже его достоинства.
P.S. Конечно, в программировании много специфичных сфер. Но в веб-бекенде, где под капотом по микросервисам гоняются json-чики - самой сложной задачей оказываются элементарные вещи: чтобы API возвращало то, что написано в документации, чтобы отправленные данные, пройдя через 10 микросервисов, не сломались по дороге. Казалось бы, ничего сложного - просто внимательно пишите авто-тесты, просто настройте CI/CD, просто не ленитесь обновлять тесты под изменившуюся логику, но... 90% команд этого не могут. И получаем бесконечные баги-баги-баги...
На коммерческих проектах бизнес решает оплачивать написание тестов или не оплачивать. Хороший код может быть с тестами и без, также как плохой код. Не всегда процент покрытия тестами говорит о качестве кода.
На коммерческих проектах бизнес решает оплачивать написание тестов или не оплачивать
Вы лишь доказали, то, что я написал)
Нет, ну серьезно, ниужели вы не слышали хотя бы истории строителей, когда они делали не так, как надо, а так как хотел заказчик, и что ничего хорошего из этого не получалось? При чем выноватым всегда остается тот, кто делал, он же специалист.
Бизнес нужно спрашивать что ему нужно, а вот как делать - решают программисты.
Не всегда процент покрытия тестами говорит о качестве кода.
Как там говорят - кто борется, может проиграть, кто не борется, тот уже проиграл.
страшный миф
"бизнес не платит за тесты" можно превратить в:
"бизнес не платит за понятные переменные"
"не платит за соблюдение архитектуры"
"не платит за документацию"
"не платит за разбиение программы по файлам"
"не платит за программу, которая не течет"
"не платит за то, чтобы удобно работало"...
спиосок вечный
причем тут бизнес, ваш контракт работает или нет после рефакторинга или к концу программирования? Докажи, что да! (себе докажи, конечно — да, придется написать тест :)
А как вы отличите "плохой" код от "хорошего" без тестов? Я понимаю, что есть какая-то насмотернность и знание кодовой базы проекта, но как вы без тестов узнаете соотвествует код техническому заданию или нет. :)
С чего вы взяли что чел не скопирастил этот проект и зарефачил названия классов чтобы сложнее было гуглить оригинал
Любой домашний проект преследует какую-то цель и рассматривать его разумно только в рамках достижения этой цели.
И тесты, не гороворя уже о CI/CD, могут быть не нужны. Код дает нужный результат, если что-то не так автор отравит все в помойку и начнет заново. От автора не требуется ни поддержка ни забота о будущих поколениях.
Так что судить о навыках по такому источнику может быть как минимум неэффективно.
Исключением может быть случай если это популярная библиотека или что-то подобное, здесь да информации много и ее разумно использовать.
Просто есть люди, которые пишут нормальный код, а есть пишущие 100500 видов тестов вместо кода
Особенно требовать 90% покрытия и CI/CD в петах смешно. Человек, по вашему, пет пишет, чтобы те же 90% времени потратить на тесты, или, чтобы научиться с чем-то новым работать, что-то интересное ему освоить и сделать (что подразумевает написание кода)?
Я имел ввиду то, что не надо вестись на красивые рассказы. В том кокретном случае не было "если кандидат покажет", а было "кандидат рассказывает". Так-то если покажет - то я согласен, и сам являюсь сторонником того что лучший определитель кто он - это что он сделал. Покажи что ты сделал - я скажу кто ты.
А у вас есть показать, что вы сделали? У меня - есть. Но есть не у всех.
Этот разговор, о том как понять вообще профпригоден кандидат или нет. Например, я убежден, что человек пришедший из PHP, и не понимающий что есть стек и поток (а эти вопросы именно после общения с адептами PHP, не хочу никого задеть, честно), на бэке не может работать, на высоконагруженных проектах. Статья о том, как отсеять.
Если у вас есть знакомый, который может показать свои проекты, с тестами и CI/CD, то может и тратить время вот на это все и не надо. Но таких знакомых на пересчет пальцев, обычно.
из PHP, и не понимающий что есть стек и поток, на бэке не может работать, на высоконагруженных проектах
то есть к вам приходят люди, которые умудрялись держать нагрузки без многопоточности из коробки, но в силу природы языка еще не до конца втянулись в теорию... вы их отсеете? :) интересный у вас, конечно, подход
Строки в Го
И задача на понимание юникода: как сравнить 2 строки?
А статья-продолжение будет?
Просто, не понял: зачем лом гнуть?!!
В целом все верно. Более того, даже незнание паттернов ни о чем не говорит. Здравомыслящий человек приходит к этому сам и там где это нужно. Зато полно случаев когда эти паттерны пихают без повода и творят лютую дичь.
Вопросы в конце - дичь.
Какой то диссонанс между названием статьи и списком в конце. И много таких, кто прошёл все уровни этого списка?
По опыту, разработчики зачастую IP от порта отличить не могут, какая там модель osi? Может мне конечно так везет.
Мне приходилось несколько раз проводить технические собеседования, никогда не понимал вот таких бесед по часу-два с кандидатами.
Если кандидат "идиот", это будет понятно сразу. То же работает в другую сторону - если человек разбирается в теме и его можно садить писать код, это тоже сразу видно. 10 минут достаточно, чтобы ответить кадровику по поводу оффера и примерной зарплаты.
А вот эти все "напишете мне сортировку пузырьком маркером на доске" - это вопросы ради вопросов.
Вроде текста много, основная мысль понятна, но что я могу почерпнуть и применить я так и не понял.
И что, каждый разработчик должен все это знать и выдать на собеседовании? И вы реально к вопросам начального уровня отнесли знания ядра OS и алгоритмы работы менеджера памяти OS?
Секция 8 озаглавлена как программы, но вопросы там по разновидностям деревьев. Опять таки - если вы не разработчик систем управления данными, то зачем вам это?
Поймал себя на мысли, что без подготовки ответил примерно на половину этих вопросов. Наверное, в вашей классификации я даже на Джуниора не тяну )
У меня возник только один вопрос что такого плохого если кандидат будет знать заранее какие конструкции языка и алгоритнмы наиболее востребованы для конкретных вакансий?
Разместить ссылки со списками рядом с вакансиями, пусть кто вспомнит, а кто выучит. И задавать на собеседовании задачки про наиболее характерные ситуации полученные по анализу ревью кода.
Ведь тот же теорминимум состоял из вполне конкретного списка тем, про них знали и могли готовиться. И никого это не смущало.
Собеседование - начальный фильтр (он у каждой компании свой и правильнее правильного), не более, для того, чтобы немного понять уровень разработчика и уровень компании существует испытательный срок.
А у вас Phone Screening не принято делать? Многие простые вопросы мог бы задать рекрутер и не тащить неподходящих кандидатов на собесы.
За список спасибо - не со всем согласен, но много интересных вопросов чтобы освежить знания и копнуть глубже
"Как найти профпригодного сотрудника"... позволю себе усомниться и усмотреть противоречие. С одной стороны, ищем того, кто сможет работать прямо сейчас, с другой стороны, ещё и сами себе строим абстракцию профпригодности. А ведь нужно решить конкретную задачу. Именно её. Может быть, даже именно сейчас. Её. А не "найти проф.. пригодного". Проф. Это ещё что? К дискуссии что есть проф что не проф ? :( Пригодного к чему? Надо найти того, кто умеет решать эту задачу!!!!
Предположим, у Вас болит зуб. Это проблема, в смысле задача. Ее надо решить.
Правильное решение - найти стоматолога. Профессионального, который с оборудованием, принимает в кабинете, а еще некоторые люди отзывы смотрят прежде чем к нему идти.
Ваш вариант - есть проблема здесь и сейчас - незачем искать стоматолога, подойдет любой прохожий с пассатижами?
Будем конкретны. В МТС проблема, и очень большая. Т.н. "цифровая экосистема" -. андроид-приложение МТС - не работает. Настолько, что просто позор, ведь это фасад якобы большой авторитетной влиятельной организации. (в скобках - м.б. это совсем не проблема и МТС это не нужно. Но снаружи выглядит вот так.). Выглядит это таким образом, что МТС не имеет никакого морального права кого-либо экзаменовать по вопросам програмирования, пока не приведет в порядок фасад своего дома. Поэтому, с моей т зр программиста, разумно было бы: 1) так и написать в обьявлении: требуется привести в порядок приложение МТС для показа баланса и смены тарифа. Ссылка. Цена указана, чтоб её не выпытывать у посредников. Указан срок. 2) Ход кандидата. Приложение вот оно. Если канд. имеет соотв опыт, он по внешнему виду или по содержимому APK файла поймёт, "на чём" это сделано. Проблема это или просто можно откусить пассатижами? ответ может быть получен уже сейчас. Вдруг разработчики наступили на типичные "грабли" использованного инструмента. Если не повезло и причина срециалисту сходу не известна, он оценит с точностью до 500% цену и срок и свои возможности и решит, стоит ли идти на беседу. Допустим, решил,что может и стоит. Ход МТС. 3) Первый главный и единственный вопрос: "Каковы, по Вашему опыту, могут быть непосредственные программные причины такого состояния программы?" 4) если удовлетворительный ответ получен, бесенда продолжается и кандидат выясняет общую архитектуру билинга на предмет того, дело только в несчастной программульке на 170 Мб, либо то, что видим, тянет за собой дейставительно много смежных проблем. Отсюда и цена и торг. Умничать же в абстрактном плане может кто угодно, только не МТС
Т.н. "цифровая экосистема" -. андроид-приложение МТС — не работает.
Но оно работает. И я это пишу как человек, не шибко-то довольный МТСом. Да, работает кривенько, но всё, что я в нем делал (от смен тарифа до всяких там отчетов по расходам) — работало.
Я его почти всегда давлю системой, не дождавшись ответа. И это на суперкомпьютере - совр смартфоне. 170 Мб. Вот квадрик летает. Это - работает. Представим, что он летал бы так, как "это" или любой браузер:) нет - ничего из вышеперечисленного и в основном тестке и комментах НЕ работает. Мы сознаём это?
Спасибо за статью, интересно было почитать.
Мы используем еще один способ, направленный как раз на то, чтобы перейти от экзамена к равноправному диалогу. Мы сначала рассказываем про проекты и команды и предоставляем слово кандидату, чтобы он мог задать любые интересующие его вопросы. И только после этого, если кандидат всё еще заинтересован в вакансии, переходим к проверке скиллов
Хорошая статья! по своему опыту могу добавить: один вопрос за интервью может быть сложным (таким, на которых кандидат не знает ответа) чтобы посмотреть как он поведёт себя в такой ситуации (честно скажет "я не знаю", задаст наводящие вопросы, или как в вашем примере - повесит трубку), ведь работа в ситуации неопределённости это пожалуй одно из важнейших качеств крутого специалиста.
Мой опыт технического собеседования: как не превратить его в экзамен и найти профпригодного сотрудника