Comments 22
Спойлер - готовиться нужно.
Готовиться к собеседованиям - это всё равно, что принимать антибиотики перед анализами. Если единственная задача как угодно попасть хоть куда-то, то смысл в подготовке есть, но в норме собеседование - это не экзамен, а подбор сотрудника с подходящими навыками с одной стороны и подбор компании с подходящими задачами с другой.
Скорость обновления технологий в ИТ очень высокая.
Может быть на фронте и в мобильной разработке, а вообще всё самое важное в ИТ придумали лет 50 назад. На бэкенде только какие-нибудь дурачки, у которых лучше не работать, будут спрашивать мелкие нюансы последней версии модного фреймворка.
Сегодня технология на хайпе, но к тому моменту, когда ты выйдешь на рынок труда, она может благополучно исчезнуть.
Смотрим предыдущий пункт. Самые жирные деньги в нормальной разработке приносят фундаментальные знания, которые были 50 лет назад и будут ещё через 50 лет.
Раз мир “охоты за головами” устроен именно так, кандидату остается готовиться к техническим собеседованиям.
Мир нужно менять к лучшему, а не подыгрывать плохим практикам. Сейчас рынок кандидата, что даёт нам возможность диктовать условия проведения собеседований.
Готовиться к собеседованиям - это всё равно, что принимать антибиотики перед анализами.
Лучше и не скажешь. При чем даже в этом случае что грамотный диагност, что толковый представитель работодателя враз раскусит примененную хитрость и это будет скорее очень жирным минусом в лучшем случае. В худшем поломает тот самый SoftSkill, который "быть, а не казаться"
Мир нужно менять к лучшему, а не подыгрывать плохим практикам.
В общем это тоже правильно. Но, как всегда есть нюансы...
К счастью мир IT довольно большой. Там найдется место и готовящимся к техническим собеседованиям любителям самых хайповых технологий, уходящих работать в откровенно "пузырные" темы, и серьезным математикам-фундаменталистам, и людям с инженерным подходом, производящим то, что реально продается. Главное для себя определиться кто ж ты таков на самом деле.
...что даёт нам возможность диктовать условия проведения собеседований.
Не знаю. Мне не дает. Да я и сам не беру. Более того, уже сколько лет наблюдаю - как только двухуровневое собеседование (HR, затем техника) так совершенно без шансов. А когда люди, с которыми работал, приводят непосредственно к руководителю и разговор с ним - оффер в кармане. Правда тут приходится думать что с ним делать - ибо в большинстве случаев меняешь шило на мыло. Условия везде примерно одинаковые, а бросать свои многолетние проекты и доказывать в новом месте что ты не верблюд, и в состоянии заниматься разработкой, а не просто затыкать дыры - ну то еще удовольствие.
Ну и вопрос денег... Они там, где хайп и очередной пузырь. Где реальное дело деньги всегда с оборота. Не то, чтоб их не было, но их всегда кратно меньше. За то не надо раз в три года работу менять. Эта история, как правило, на долго.
Готовиться к собеседованиям - это всё равно, что принимать антибиотики перед анализами.
Смысл есть, так как собеседование не идеально. И даже близко не идельно. Вот если вас сразу на испытательный берут, где вы уж точно себя покажете - тогда да, тут не подготовишься. Собеседование - это все таки экзамен, где себя надо показать здесь и сейчас. И глупо будет, если окажется что ты его завалил, если забыл банальную вещь. Причем ее можно знать, пользоваться, но даже банально забыть, а как оно называется :)
Как минимум, стоит изучить компанию, хоть приблизительно. Также требования к вакансии. Там много подсказок, на что стоит обратить внимание. Просто опять же, простой тест.
Я работодатель, опубликовал описание вакансии. Приходит кандидат и оказывается он его не смотрел. Вопрос - а почему тогда он будет более внимательно читать тех. задание, описание таски в Jira и т.д.? Не, может связи и нет, но вероятность наличия пренебрежительного отношения к входящей инфе стала выше, что не играет на руку кандидату
Может быть на фронте и в мобильной разработке, а вообще всё самое важное в ИТ придумали лет 50 назад.
Я тоже как бы пионерский галстук носит, и начинал с паскалей, С и 286. Но не совсем. Хотим мы или нет, но вот банальный ORM. Я бы не сказал, что в эпоху двух-слойных приложений такая концепция была реально массовой, хотя допускаю, что можно найти что вот мистер "Х" ее применил.
Ну и если от человека ожидается, что он будет выдавать продукцию, желательно знание того, что использует команда. Либо явно будет видно, что кандидат реально прошареный тип и освоит очень быстро
Мир нужно менять к лучшему, а не подыгрывать плохим практикам. Сейчас рынок кандидата, что даёт нам возможность диктовать условия проведения собеседований.
Это не означает, что можно на собеседовании класть ноги на стол. Да, вас хантят, меня хантят. Но не факт, что возьмут. Потому что хантят многих, и вот именно туда, куда бы стоило попасть - могут и не взять
И глупо будет, если окажется что ты его завалил, если забыл банальную вещь.
Ничего зазорного нет в том, чтобы что-то не помнить. В далёком 2016 году, я будучи инженером-системотехником, самостоятельно выучил основы веб-разработки и решил "войти в IT". В одной из контор меня попросили написать алгоритм пузырьковой сортировки, а я не знал как. Я так и сказал "вы же видите в резюме, что я по образованию инженер по приборостроению и мне такие штуки в универе не рассказывали, а то, что рассказывали в школе, я забыл. Но если мне надо будет отсортировать массив, то я знаю, что в php есть целая куча функций для сортировки по значению, по ключу, по пользовательской функции, всё это с сохранением ключей или без сохранения. Но я даже не помню названия всех этих функций, потому что когда будет нужно, я открою документацию на php.net и посмотрю там в разделе о массивах, какая функция сортировки подойдёт мне." В итоге получил оффер. Но я не пошёл туда работать, потому что кроме этого у меня было ещё три других оффера, и я пошёл туда, где больше понравилось. Кстати, ни к одному из собеседований я не готовился.
Как минимум, стоит изучить компанию, хоть приблизительно. Также требования к вакансии.
Весьма удручает тот факт, что приходится давать такие советы. Я всегда изучал всю доступную информацию о компании, прежде чем откликаться на вакансию. И никогда не откликался на то, что мне не подходит или не нравится. Я думал, что это нечто само собой разумеющееся, и что у всех так. Но увы, реальность показывает, что люди сейчас кликают на всё подряд, не глядя. Иначе откуда эти истории, как джун сделал более 1000 откликов впустую. Я не верю, что в природе существует такое количество вакансий, подходящих для одного человека.
Собеседование - это все таки экзамен, где себя надо показать здесь и сейчас. И глупо будет, если окажется что ты его завалил, если забыл банальную вещь. Причем ее можно знать, пользоваться, но даже банально забыть, а как оно называется
Экзамен, да. Для нанимателя. Если он меня не возьмёт из-за того, что я забыл как что-то называется, ну он сам себе плохо и сделал.
Боюсь не стоит так высоко о себе думать :)
Нанимателям? Возможно. Как минимум тем, которые хантят. Контора, в которую все хотят попасть хантить не будет.
Ну оно ж не совсем так работает.
Допустим крутая контора "Х" открыла вакансию для хорошего спеца и ждет :) Мы ж не хантим. Что дальше?
Нежданчик первый. Все заняты. Дело в том, что люди в целом трудоустроены. Даже если взять страну в целом, то процент безработицы обычно 5-10%. Но это в целом. Хорошие спецы обычно показывают куда лучший результат. Поэтому сразу оказывается, что из 100 кандидатов, которые бы точно подошли, без работы сидит 2, и то - это не точно. Понятно, что среди 98 работающих еще есть пара-тройка, которым не очень на их рабочем месте и они тоже ищут, куда б свалить. Итого потенциальный улов на 3-5 на 100. Но они еще должны увидеть эту вакансию, они им должна подойти ... вообщем статистика пришла и почти победила с первого захода
Нежданчик второй. Все хотят попасть. Поэтому присылать свои резюме будут все, кто увидел вакансию. И тут компания "Х" получит условно еще 100 резюме на одного спеца, который ей бы подошел. Так как по резюме не сразу видно, подходит кандидат или нет - надо либо собеседовать, либо еще как-то фильтровать.
В общем получается, что при наличии потенциальный 100 кандидатов, который можно переманить, компания старательно перелопачивает тонные "пустой" породы в поисках своей крупинки золота. Не самое отпимальное решение :)
Поэтому что делается. Ищутся спецы по "прямым" каналам, и не важно, они ищут работу или нет. Найденым спецам прямо предлагается вакансия. Кто-то откажется, кто-то нет. Но легко поверить, что те же 3-5 кандидатов найдуться. пусть даже два.
Такая стратегия выгодно отличатся от первой, так как ищется та крупинка золота, которая окажется доступной.
Но вот фишин, и есть условно два кандидата. И из надо сравнить методом собеседования.
И тут рынок сразу переворачивается и становится рынком работодателя. И чтобы не вышло, что взяли когото другого - лучше подготовиться
На бэкенде только какие-нибудь дурачки, у которых лучше не работать, будут спрашивать мелкие нюансы последней версии модного фреймворка
Как раз отсеивают других дурачков, которые, не разобравшись, грохнут сервер, допустят утечку сокетов или вообще дедлок, или еще круче, начнут постранично отдавать то, что можно отдать потоком
всё самое важное в ИТ придумали лет 50 назад
Консенсус меньше 30 лет назад придумали, асинхронный ввод/вывод в линуксе 20 лет назад появился, rcu в ядре столько же, докер и контейнеры ок 10 лет назад, map/reduce лет 15, сейчас тот же flink года по-моему 4 назад появился и предлагает потоковую обработку больших данных и концепцию dynamic table
Короче, на технологиях 50 летней давности вы не выедете, если только не писали на cobol все эти 50 лет
map/reduce лет 15
map и foldl были уже реализованы в Haskell версии 1.0 - 1990 год. В lisp/scheme, я думаю, были и раньше.
Консенсус меньше 30 лет назад придумали
Тётя вика указывает 78-ой, как формальный год рождения византийских генералов.
асинхронный ввод/вывод в линуксе 20 лет назад
речь была про самое важное. Алгоритмы, подходы, парадигмы. Асинхронный ввод/вывод, да ещё и именно в Линуксе трудно отнести к этой категории.
докер и контейнеры ок 10 лет назад
Та же тётя Вика относит день рождения LXC к 2008-му году. По важности — там же где aio
map/reduce лет 15,
В целом я скорее согласен с вами по поводу важности данной технологии для индустрии. Однако, именно её новаторство спорно. Реализация облаков — намного больший прорыв на мой взгляд. Однако, для разработчиков от этого не очень много поменялось, по-моему.
Короче, на технологиях 50 летней давности вы не выедете, если только не писали на cobol все эти 50 лет
вы путаете концепции и фреймворки. Изучение нового фреймворка занимает две недели, если вы знакомы с концепциями на которых он основан. Переезд с С на Хаскель может вообще не получится.
78-ой, как формальный год рождения византийских генералов
я вообще Paxos имел в виду, год публикации 1998, отсюда есть и пошли распределенные системы, всякие там bigtable, hdfs, hbase... Византийские генералы, ну не знаю, давайте еще обедающих философов вспомним, довольно отвлеченная задача
речь была про самое важное. Алгоритмы, подходы, парадигмы
вообще, асинхронный ввод/вывод - это и подход, и немного парадигма даже. Было: апач с его process/thread-per-connection, стало - Nginx с его C10K
Докер дал дешевую виртуализацию, а также подход к решению проблемы dependency hell, в общем.
вы путаете концепции и фреймворки
фреймворк иногда бывает реализацией концепции
Переезд с С на Хаскель может вообще не получится
я переезжал с C++ на Scala с ФП) 8 лет, полет нормальный
я вообще Paxos имел в виду, год публикации 1998
The Paxos protocol was first submitted in 1989. Придумал его, кстати, тот же Лесли Лампорт, который предложил решение вышеупомянутой проблемы генералов за 10 лет до того.
я переезжал с C++ на Scala с ФП)
вы молодец.
асинхронный ввод/вывод в линуксе 20 лет назад появился
Это он в Linux так поздно появился. А в других ОС он был и раньше. Например, у DEC, в VMS и даже в RSX-11, которая аж с 1972 выпускалась: запуск асинхронной операции через QIO и уведомление через AST (по-нынешнему это - callback) по факту завершения операции.
Кстати, поскольку Windows NT (которая является предком нынешних версий Windows) делала команда как раз из DEC, то в нее асинхронный ввод-вывод был заложен изначально (но это было сравнительно недавно: NT вышла всего 30 лет назад). Собственно, синхронный ввод/вывод в NT вообще не был первичным, а эмулировался асинхронным запуском операции и ожииданием ее завершения на описателе файла (в NT это - тоже объект синхронизации).
А ещё мне смутно припоминается, что какой-то механизм асинхронного ввода/вывода и обратного вызова по его завершению был и в IBM OS/360 (аппаратура ввода-вывда там точно работала совершенно асинхронно - этим занимались т.н. каналы) - а это вообще 60-е, но за это уже не уверен.
То есть, концепция асинхронного ввода/вывода - это тоже старая концепция.
Ну, а за все остальное, вроде как, уже написали.
Расскажите это людям, которые годами готовятся к собеседованиям в FAANG и в итоге это даёт свои плоды.
Из своего опыта, готовиться к собеседованию нужно, хотя бы внимательно ознакомиться с вакансией и компанией. Далее всё индивидуально, кто-то может быть уверен в себе на все 100, и ему необходимо лишь восполнить какие-то небольшие пробелы, а кому-то действительно понадобится как минимум пару дней. Не знаю как у разрабов, но у тех же DevOps 70% вопросов практически всегда одинаковые, поэтому при поиске работы чем чаще ходишь на собеседования, тем больше откладывается в голове. Самое печальное, что даже на сегодняшний день у многих компаний собеседование до сих пор проводят как экзамен.
Вот мой чеклист с учётом того, что большинство собеседований сейчас проходят удалённо:
Выбрать или подготовить место, где удобно сидеть, и на фоне нет ничего стрёмного. Блюрить или заменять фон нежелательно, т.к. многие ценят открытость.
Надеть нормальную майку или рубашку. Тут вроде всё понятно.
Обязательно (!!!) надеть штаны! Хоть их и не видно, но в процессе собеседования может произойти ситуация, когда придётся срочно встать из-за стола, например, кот что-нибудь учудит или какой-то другой форс-мажор. Кстати, по-моему, тут на Хабре кто-то писал, что его на собеседовании попросили встать.
Привести себя в порядок: причесаться, если есть волосы, достать из бороды остатки недавнего приёма пищи, если есть борода, и т. д.
Предупредить окружающих, чтобы не отвлекали.
со стороны интервьюера вижу тоже палку о двух концах. начинаю собеседование всегда с предоставления слова кандидату и прошу рассказать об интересных с технической точки зрения кейсах из практики, попутно уточняя детали. но... т.к. умение рассказывать это тоже умение и оно есть далеко не у всех, то зачастую рассказ кандидата выглядит как "делал задачки из jira" или "у меня nda". в таких случаях уже переходим на разбор моих кейсов - это обычно ревью заготовленного кода или архитектуры - из текущего проекта с долей упрощения, разумеется. да, я готовлюсь к собеседованию, и кейсы мне дает реальная практика с проектов. надо просто оправданий лени не искать. и зачастую очень любопытные и непринуждённые беседы выходят.
Без подготовки в IT теперь не пройти ни одно собеседование. Да и с подготовкой тоже. Меня однажды спросили, какую ассемблерную инструкцию сгенерирует компилятор Go для инкремента. Жабьескриптерам дают выражение с нагромождением скобок и требуют предсказать результат, попутно объяснив его. А чтобы его объяснить, надо знать такие кишки интерпретатора, что упасть не встать. Какой человек, если у него здорова психика, будет засорять себе мозг всем этим хламом?
Как выглядит техсобес в современном мире и нужно ли к нему готовиться?