Комментарии 140
Я разработчик с 6 годами опыта работы
25 компаний, 54 этапа, 2 оффера
Тоже сейчас ищу работу, от этих цифр страшно.
Понял что на мои 4 "отлично поговорили, мы вам перезвоним" за неделю уповать не стоит, открыл hh, и начал "спамить" (ну, в хорошем смысле) откликами.
большинство из них даже не стягивало проект с гита, а те, кто заходил, дальше первой страницы не уходили.
Из моих собесов только половина hr с резюме ознакомилась (держа распечатанный листок на столе), что становится понятно в ходе беседы
Удачи с поиском, у вас обязательно все получиться!
Из моих собесов только половина hr с резюме ознакомилась (держа распечатанный листок на столе), что становится понятно в ходе беседы
О, да.
Сначала "Мы очень внимательно ознакомились с Вашим резюме и нам очень понравился Ваш опыт, не могли бы вы написать в телеграм %randomUser%, чтобы продолжить общение?".
А потом: "У меня осталось пара вопросов:
1. На каком языке вы пишите?
2. Ваш пол, возраст, место жительства?"
Классика.
А еще очень обижаются:
Как вы не знаете что мы за компания? Вы могли бы подготовится и прочитать про нас в интернете!
Мы, вообще то, входим в тысячу крупнейших производителей пластиковой посуды юго-восточной Африки.
Не стоит к этому слишком серьезно относиться. Этот ответ просто шаблон, читай как "ну да, давай поговорим".
"отлично поговорили, мы вам перезвоним"
Да тут и так понятно что уповать не стоит. Но вот что даже фраза "мы готовы предложить вам работу, только нужна подпись гендиректора" ещё не означает оффера...
@latooИзвините, я не туда нажал и случайно отклонил ваш комментарий (а может быть и не ваш, я уже сам не уверен))) Там было что-то вроде "почему я хочу работать в больших компаниях, а не одиночкой" насколько я успел запонить. В целом я и в том и в другом варианте вижу для себя плюсы. Каждый из них приносит свой опыт и развивает меня в какую-то новую сторону. В большой корпорации ты видишь кухню изнутри и это неплохо, чтобы потом построить свою кухню, взяв у них лучшее. К тому же в больших компаниях ты редко урабатываешься до потери пульса. С другой стороны, в маленькой компании, у тебя развязаны руки - ты сам определяешь вектор развития проекта и нужный стек. Ты не просто муравей исполнитель, но автор и творец и это здорово. У меня нет предвзятости, я могу быть и тем и другим, если компании хорошо платит
Не хватает очень опции автоматически принимать все комментарии под статьей. Я когда первые статьи писал даже не знал, что некоторые нужно в ручную принимать.
Так в итоге сколько из этапов заключалось в решении задачек из егэ по информатике и финальный оффер вам тоже дали за задачки?
Задачки спрашивали в Яндексе, Озоне, Exness, Tango me и Avito. Большинство по моему опыту обходятся без них. Компания, в которую я пошел задачек не давала. Лучшие из проверяющих по моему опыту стараются заставить кандидата говорить и думать, проектировать что-то новое, не связанное с их целевым продуктом (!). Это действительно важно, потому как в итоге думают оба и получается диалог. Средней руки интервьюеры предлагают спроектировать часть их собственного продукта, что на мой взгляд не честно, ведь они имеют преимущество в своем продукте и заранее знают, если не единственно правильный, то один из лучших ответов. В таком случае кандидат всегда стоит на ступеньку ниже и должен угадать, какое же решение авторы придумали? Задачки, положа руку на сердце, я считаю рудиментом - они никак не показывают уровень разработчика, если его работа не писать алгоритмы. С таким же успехом мы могли бы играть в шахматы или шашки: человек с МС уделывал бы всех любителей, только потому что он потратил 10 тысяч часов на свое хобби (тут должен быть смайлик, разводящий руками). Кому-то алгоритмы нравится, кто-то с них торчит, я к ним совершенно холоден. Задачки я решил во всех фирмах, в Яндексе правда со второго раза.
Спасибо, интересный опыт.
никак не показывают уровень разработчика, если его работа не писать алгоритмы.
какое удивительное высказывание. А в чем же, по-вашему, состоит работа разработчика, как не в написании алгоритмов решения задач на подходящем алгоритмическом (хм, снова это слово - может быть оно здесь неспроста?) языке программирования?
Нет, ну, положим, джун действительно в некоторых случаях может просто кодировать чужие алгоритмы, но слышать такое от сеньора по меньшей мере странно.
И давно последний раз приходилось бинарное дерево переворачивать? Реализовывать приоритетную очередь или сортировку кучей? Кратчайший путь в графе находить?
Людей бомбит не от алгоритмов, а от тех алгоритмических задачек, что обычно спрашивают на собеседованиях, позаимствованных из около олимпиадного программирования. И часто имеющих довольно мало отношения к тому, чем приходится заниматься. (перекладывать джейсоны)
Тем более, что их еще и приходится решать на время, что очень далеко от реальности, даже сложной алгоритмической или математической разработки.
Проблема даже не в алгоритмах в целом - а в конкретных задачах. Мне, например, нравятся задачки про различные операции с массивами, вроде изи-левела собеса в ФААНГ, они позволяют послушать рассуждения, мысли, пути оптимизации. Иными словами, что кандидат не просто вызубрил литкод, а способен осмысленно решать различные задачи. Но самое главное - эти задачи должны быть решаемы без предварительного знания ответа. Чтобы кандидат мог их сам понять, без сложных абстракций и глубоких знаний ответа, иначе это ничем не отличается от того, чтобы просто на собеседовании спрашивать матмодель квантового компьютера, цитаты Ницше, характеристики автотрасс - не зная ответа, тут и рассуждать нечего.
И давно последний раз приходилось бинарное дерево переворачивать? Реализовывать приоритетную очередь или сортировку кучей?
Такие простые только на собеседованиях. Алгоритмы большинства моих бизнес-задач существенно сложнее, их реализация занимает тысячи строк кода.
Кратчайший путь в графе находить?
Такое было частью одной из задач. Самой простой её частью.
Людей бомбит не от алгоритмов
А вы прочли то на что я отвечал? А я повторю, мне не трудно, - "никак не показывают уровень разработчика, если его работа не писать алгоритмы." если работа разработчика не в том, чтобы писать алгоритмы, значит он кодер чужих алгоритмов. Это абсолютно нормально, но это означает, что ему не стоит браться за работу, которой он не хочет либо не умеет заниматься. Я не умею танцевать балет и меня совершенно не расстраивает, что на собеседованиях артистов балета просят сделать что-то для меня запредельное.
а от тех алгоритмических задачек, что обычно спрашивают на собеседованиях
Если кандидат не в состоянии написать бинарный поиск или сортировку пузырьком, стоит ли от него ждать способности решить реальную бизнес-проблему?
Тем более, что их еще и приходится решать на время
Да, бросьте, реализация пузырьковой сортировки - три строки. Бинарного поиска - пять.
перекладывать джейсоны
Да, про джунов я тоже специально упоминул. Но пассажир же позиционирует себя сеньором.
спрашивают на собеседованиях
Это самое адекватное что спрашивают на собеседованиях. Гораздо более непонятно зачем на всех собеседованиях спрашивают работу гарбадж коллектора (ну, у меня был ЕДИНСТВЕННЫЙ раз когда это знание было действительно полезно для последующей работы и тогда заранее предупредили об этом). Или вот ещё очень "актуальный" вопрос - какие есть методы у класса Object? Помните, что там есть такой - finalize()? А когда-нибудь использовали его? :) Вооот! А вот алгоритмы я каждый день "пишу". Именно в этом и состоит моя работа разработчика.
Если кандидат вдруг ни с того ни с сего выдаёт бинарный поиск или сортровку пузырьком
Не знаю что вы подразумеваете под "вдруг ни с того ни с сего выдаёт", но если кандидат за пол часа не может написать трёх строк кода по заданному алгоритму, то зачем вам такой нелепый "пограммист"? Нет, ну, правда, зачем?
значит кандидат просто подготовился
Не представляю зачем заучивать реализации настолько простейших алгоритмов, но предположим, так и случилось. Ну, и что? Собеседование на этом только началось - дальше спросите как перекладывать эти ваши жысоны, если считаете подобную способность релевантной. Но если "не щмогла" и в пузырёк, то ведь дальнейший разговор не имеет смысла? Зачем тратить своё и чужое время?
А протестировать всё, а предусмотреть все edge-cases?
В алгоритмических интервью на это очень пристально смотрят.
И реализовать их отработку системно, а не россыпью if-костылей
Да! Качество кода — основной сигнал качества программиста. Его же берут код писать! Что может быль лучше, чем посмотреть, как кандидат пишет код? Но давать что-то большое нецелесообразно — больше времени кандидата тратится, дольше проверять, сложнее выдумывать задания. Вот были бы какие-нибудь небольшие задания, требующие кандидата писать 10-15 строк не тривиального broilerplate кода… А погодите ка, это и есть easy-medium задачки с литкода.
Нормальный здоровый человек не напишет всё это за полчаса, кроме случаев когда он уже недавно делал это.
Есть проблема волнения и стресса на интервью, ну с это неизбежное зло. А дальше, если кандидат не может за пол часа воспроизвести тривиальный алгоритм, то он вряд ли хороший программист (никто не просит писать сортировку пузырьком. Просят в правильной последовательности вызвать встроенный в язык sort и как-то пройтись по массиву)
Нет, не эффективнее. Это очень сложно из Жиры выделить что-то самодостаточное, чтобы кандидат смог 10-15 строк кода с нуля по этому набросать. Ибо там в основном тикеты вида "Когда пользователь делает вот так, вон в той подсистеме что-то не так работает". Или "Надо протянуть вот это вот значение из вон той подсистемы вон в эту через N уровней абстракции, и там на него реагировать". Или что-то более высокого уровня вроде "запилите вот такую вот фичу". И там такое количество контекста что вы его будете кандидату два часа только рассказывать.
А те куски-функции, которые можно выделить — они чаще всего уровня FizzBuzz. Опять же, если у вас десятки кандидатов на место, оно не работает. А если у вас откликов на вакансию итак нет, то испытательный срок — лучший вариант (после любого тривиального интервью, чтобы уж совсем неадекватов отсеить). А если можно из жиры выделить что-то посложнее, то это те же самые Алгоритмические Задачки и получаются. Хорошо, когда они из вашего проекта и растут. Я такую задачу на интервью и задаю, кстати. Но редко когда можно что-то настолько абстрагировать и упростить, чтобы в интервью влезть и чтобы оно при этом не стало точно таким же "не практичным" как произвольная задача с литкода.
не эффективнее ли спросить у кандидата на этих реальных тасках - какие варианты решения он видит и что ему НЕ хватает для этого самого решения.
p.s. потенциально тимлид походу
россыпью if-костылей
вспомнил, как переделывал за предшественником кусочек с 20+ вложениями такого вида
if company == 'ООО «Ромашки»':
company = 'ООО Ромашки'
Если кандидат не в состоянии написать бинарный поиск или сортировку пузырьком, стоит ли от него ждать способности решить реальную бизнес-проблему?
Свидетели святого литкодинга забывают такой нюанс, что никто не решает реальные бизнес-проблемы под стрессом перед незнакомыми типами в незнакомом редакторе и на время. Вы сравниваете несравнимое.
никто не решает реальные бизнес-проблемы под стрессом
Ой ли? :)
Вы сравниваете несравнимое.
Это вы натягиваете сову на глобус. Никто не говорит про или-или. Лайвкодинг никак не связан с проверкой способности решать бизнес-проблемы. Он проверяет способность кандидата кодировать простейшие задачки. Про решение бизнес-проблем будут последующие вопросы. Но к ним нет смысла приступать, если кандидат не способен написать кода из трёх строк. Нет смысла спрашивать про интегралы, если персонаж не владеет умножением и теорией пределов. Что-то зазубренное он может рассказать, но толку от этой зубрёжки как от козла молока.
Написание кода из трёх строк — это про FizzBuzz, а не про поиск кратчайшего пути в графе.
И говорю как человек способный этот самый поиск написать: проще всего его именно что зазубрить чем на ходу придумать. По крайней мере, лучшие олимпиадники все алгоритмы именно что зубрили (да, думать на олимпиадах тоже надо — но если ты начал думать над базовым алгоритмом, ты уже проиграл).
Так зачем вы проверяете способность кандидатов зубрить алгоритмы, если сами же говорите что толку от зубрёжки нет?
И говорю как человек способный этот самый поиск написать: проще всего его именно что зазубрить чем на ходу придумать.
зачем? у нас на факультете была одна барышня, которая на первом семестре считала, что проще заучить полугодовой курс матана, чем понять, как всё устроено. Очень упорная барышня - с 12го раза сдала. Но поняла, что разобраться и выводить доказательства куда проще, чем их заучивать. Зачем учить реализацию, если быстрее её реализовать?
По крайней мере, лучшие олимпиадники все алгоритмы именно что зубрили (да, думать на олимпиадах тоже надо — но если ты начал думать над базовым алгоритмом, ты уже проиграл).
Мы же не на олимпиаде, нам не нужна скорость. Олимпиадники, кстати, в большинстве не особо хороши в разработке. По крайней мере те, что мне встречались. Но один, впрочем, был очень хорош!
Так зачем вы проверяете способность кандидатов зубрить алгоритмы
Я? И где я такое предлагал? Я предлагал проверять как кандидат пишет реализацию по готовому алгоритму. Но если он настолько тупой, что выучил только реализации, а не то, как их писать, то в последующем разговоре он посыпется. Достаточно попросить модифицировать его программу под немного другие условия. Это же стандартная практика интервью: быстро написал (заученный) бинарный поиск - ок, молодец, а что если нам нужно найти не заданное число, а третье бОльшее после него? А если на вход подали предпоследнее? О! Пришла пора написать дополнительный юнит тест, правда? А может не один - в массиве может быть всего два элемента? Задача же не в том, чтобы непременно взять на работу тех, кто написал реализацию по готовому алгоритму. Задача обратная и состоит в том, чтобы ещё на раннем этапе отсеять тех, кто даже этого не осилил. Зачем тратить время на бессмыслицу?
задам встречный вопрос - в чём вы видите проблему написать реализацию по заданному алгоритму? Речь ведь только о реализации. Я НИГДЕ и НИКОГДА не говорил о выводе самого алгоритма. Перечитайте.
А если я задам встречный вопрос - найдите наибольшее число в списке, пополняемом параллельным потоком, lock-free?
"Я не знаком с этим алгоритмом, напомните мне его пожалуйста."
Вы нанимаете прокачанных алгоритмистов?
Синьор девелоперов. Которые умеют писать код.
Нет, тех, кто не умеет писать код мв не нанимаем. А вы нанимаете? А зачем?
Или тех кому по факту надо сджойнить пару таблиц?
"На сегодня приём джунов закрыт, вы ошиблись вакансией, не будем тратить ваше и своё время, возможно, когда вы научитесь писать код мы сможем побеседовать подольше."
Но к ним нет смысла приступать, если кандидат не способен написать кода из трёх строк
Ну а другой скажет, что нет смысла приступать, если теория event loop от зубов не отскакивает. Чем ваше кунг-фу лучше вот этого кунг-фу? Тем, что самомнение пухлее?
Вы пытаетесь оценить комплексное качество - скилл - простым измерением. Это типа как линейкой мерить и длину, и температуру, и давление. Я, к слову, не против кодинга на собесах. На наших собесах и кодинг, и ревью, и теория, и систем дизайн. И я смотрю на человека в комплексе и раньше времени желтую звезду ему на грудь не вешаю.
Ну а другой скажет, что нет смысла приступать, если теория event loop от зубов не отскакивает.
А что в этом плохого? Если его работа подразумевает плотную работу с/в event loop, то работник должен разбираться в этом.
Чем ваше кунг-фу лучше вот этого кунг-фу?
Ничем не лучше. Мне знание ивент лупов ни к чему, я спрошу что-нибудь другое, что используем мы. После того, как кандидат покажет свою способность к написанию кода. До этого просто нет смысла.
Тем, что самомнение пухлее?
Самомнение состоит в том, чтобы узнать способен ли будущий разработчик писать код по готовому алгоритму? Гм, не знал, что это настолько выдающийся скил, что не часто встречается у "синьор девелопер". А вам правда нужны синьор девелоперы не способные писать код? А зачем, позвольте поинтересоваться?
Вы пытаетесь оценить комплексное качество - скилл - простым измерением.
Ни в коем разе. Я пытаюсь сэконономить своё время и не пытаться принять на работу "девелопера" не способного к написанию кода. Входной фильтр. Про условия необходимые и достаточные вы же знаете? Это - необходимое. Но с чего вы взяли, что достаточное?
И я смотрю на человека в комплексе и раньше времени желтую звезду ему на грудь не вешаю.
Всё пытаюсь понять, зачем вам нужен разработчик у которого огромные скилы в ревью, теории и систем дизайн, но которые не способен писать код. Вы его поставите в парадный угол и будете на него любоваться? Стирать с него пыль и спрашивать теорию? Или у вас есть позиция выделенного ревьюера, который не пишет код, а только его ревьюит? - ну, если условия позволяют, то это годный вариант, но это не позиция синьор девелопер, это другая позиция.
Вы сами придумали что "литкодить на скорость" == "писать боевой код" и теперь размахиваете этим тезисом с великим восторгом. Заявление уровня "не служил - не мужик", короче. А для меня это не абсолютная истина, а так, частный случай. Можно хорошо литкодить и плохо писать боевой код. А можно плохо литкодить и хорошо писать боевой код. И остальные 2 комбинации тоже бывают. Так что выдохните уже.
Вы сами придумали что "литкодить на скорость" == "писать боевой код" и теперь размахиваете этим тезисом с великим восторгом
А давайте вы, для начала, приведёте цитату, где я утверждал, что "литкодить на скорость" == "писать боевой код"? А то как-то неловко получается - вы знаете где я это сказал, а я нет. У меня РОВНО противоположная позиция - если человек не может написать "программу" в три-пять строк по ЗАДАННОМУ алгоритму, то мне не о чем с ним разговаривать.
"если работа разработчика не в том, чтобы писать алгоритмы, значит он кодер чужих алгоритмов" не все разработчики придумывают/кодируют алгоритмы. Есть много других способов потратить рабочее время. У меня, к примеру, большую часть времени занимает раскопка недр Хромиума, и чуть-чуть времени на поправить необходимое. Кто-то пишет гуй. Кто-то сети. Кто-то системным программированием занимается. Кто-то, внезапно, дистрибутивы кодирует. Скрипты на питоне. SQL запросы.
Алгоритмы - это лишь малая часть айти.
Речь шла про алгоритмы в вакууме, а не про алгоритмизацию в целом. Тебя спрашивают по учебнику, но это нафиг не нужно на практике, т.к. никто не пишет свою сортировку и т.п.
я не знаю что такое "алгоритмы в вакууме". Моё мнение простое - если некто не может написать даже трёхстроковый "пузырёк по известной спецификации, значит ничего более сложного у него нет смысла спрашивать. На практике нужно писать код. Если кандидат не умеет этого делать мне он не нужен. А вам такой нужен? Позвольте спросить зачем?
По известной ли? Если дают описание алгоритма и говорят его написать — тут вопросов у меня нет, в качестве базовой проверки вменяемости сойдёт (хотя есть риск нанять кодера вместо программиста).
Но, насколько я понял, обычно задание звучит так: "отсортируйте массив пузырьком, гуглить нельзя". То есть кандидат должен знать этот вредный на практике алгоритм и уметь написать его по памяти.
я говорю об известной. Каждый раз это упоминаю на всякий случай, у меня уже мозоль. Меня не интересует как обычно звучит задание. У яндекса есть алгоритмические секции, там, да, гуглить нельзя (но даже там подсказки спрашивать можно). Но я говорю не о алго-секциях яндекса, а о проверке способности писать код и только о ней.
ЗЫ. Если кандидат не может придумать алгоритм пузырька, да хоть за пол-часа, я бы тоже с сомнением на него смотрел.
Но вы сами начали писать про "пузырёк". Устроит ли вас ситуация, когда кандидат напишет другой алгоритм сортировки?
Если нет, то какого фига?
Если да, то с чем вы тут спорите и кого защищаете?
В смысле, я дам ему описание алгоритма пузырька, а он напишет не по заданному, алгоритму, а по иному? Хмммм. Это вызовет подозрение в зубрёжке и даст повод поразбираться глубже. Но, в принципе, я и сам могу сказать - пузырёк сильно простой, давайте я напишу что-нибудь другое :). Лично мне вообще не важно, что там будет писать кандидат, главное, чтобы умел писать.
Но отказ следовать спецификации потребуется обосновать, да.
А в чём проблема с реализацией трёх строк? Почему написание трёх строк вызывает священный ужас "сеньоров".
никак не связанной с предыдущим бэкграундом и будущими обязанностями
Да, это фильтр имеено от таких. Если у кандидата в бэкграунде не было кодинга, зачем мне его нанимать? А вы нанимаете разработчиков, не умеющих кодировать? А для чего?
Есть сомнения что всё написанное в резюме правда?
Да. Вы не поверите... :)
Давайте подискутируем.
Давайте. Вот простейший алгоритм, напишите его реализацию.
вы просто боитесь произвести на кандидата впечатление некомпетентого?
Некомпетентного в чём? В domain knowledge кандидата? Да я и заранее могу сказать, что я ничего не смыслю ни в ядерной физике, ни в бухгалтерском учёте, ни в ставках на скачки, ни в ритейле и ещё много в чём. А кандидат, скорее всего в моём domain knowledge. Тут разговор вообще бессмысленен. А вот в области разработки у нас, да, есть общие темы и это именно те знания и умения, которые потребуется для дальнейшей работы. Я могу многого порассказывать про океанские течения. Или про лазерную физику. Но нахрена это работодателю, которому нужен разработчик для работы с FIX протоколом и он готов мириться с тем, что я пока не знаю протокола, но могу закодировать его хотелки?
Тогда да, формат "марш кодить что я заранее точно знаю" - ваше спасение.
Когда мне нужен разработчик я ищу разработчика и проверяю его умения в разработке начиная с простейшего кодирования. В области физики лазеров ничего не спрашиваю, хотя легко могу большинству кандидатов сформировать комплекс неполноценности на несколько лет психологических консультаций.
Но никак не могу понять как вы нанимаете разработчиков без проверки их навыков?
А зачем мне проверять его навыки алгоритмов сортировки?
Навыки написания кода. Алгоритм рояли не играет. Можете кодировать свой любимый. Это, кстати, ещё любопытнее.
А раз в теме, значит всё это работало, значит как-то кодировал он всё это.
Ви таки не поверите!
Навык обсуждения сказок и навык кодирования - это совершенно разные навыки.
Мне не совсем понятно, мы о найме сеньйоров, или кого? Человек, значит, 5-10 лет кружочки и квадратики на бумажке рисовал чтоли? Такое бывает?
То, что человек утверждает, что он сеньор, вовсе не означает, что он таковым является. Одной из задач собеседования и является таковых отсеять.
Насочинять убедительный сеньйорский опыт и вести диалог на равных как специалист со специалистом, этого читер просто не сможет.
скопировать чужое резюме много ума не надо. А вести разговор с читером, чтобы выводить его на чистую воду... ну, оно вам надо? Мне - нет.
Не поверю!
Ну, вот, синьор-топикстартер утверждает, что занимается реализацией алгоритмов не чаще раза в году. Мне сложно предположить что он делает всё остальное время и я, честно, не особо горю желанием это выяснять. А вам нужен "сеньор", который код пишет не чаще раза в год? :)
Не знаю, про какого топик стартера речь, но интереса ради решил попробовать ответить на вопрос, чем можно заниматься на работе, чтобы при этом не заниматься реализацией алгоритмов: разбираться, как регистрируются COM-объекты; разбираться, как сделать в них elevation; разбираться, как можно схитрить и переименовать .exe файл, пока он работает; разобраться, откуда берутся иконки, которые отображаются в таскбаре; разобраться, как устроены дистрибутивы, написать самодельный msi; поковырять локализацию продукта; разобраться, как устроен список установленных программ в винде, и где он хранится; ковырять хитрую проблему с помощью process explorer, process dump, grep, ...; ковырять git, python, ssh, чёрта в ступе.
В общем, ни одного алгоритма. Но 40 часов в неделю стабильно куда-то исчезают.
Это всё зашибись, но выхлоп-то какой? Вот, приходит к вам бизнес и говорит, - ну, как, сделали приложеньку? А вы такие, - ну, мы поковыряли в гите, разобрались как устроен список, узнали откуда берутся иконки и переименовали экзешник. - Бизнес такой, - ой, какие вы молодцы, вот вам премия! В следующий квартал разберитесь с грепом, почитайте как устроен хэшмап, переименуйте экзешник обратно и закопайте уже ком-объекты. Вин-вин. Многие верят. ;)
Ты не понял. Выхлоп как раз в том, что в результате приложение заработало, иконка правильная, обновление проходит. И иконка правильная, потому что в rc файле найдено правильное место для неё, а обновление проходит, потому что выбран правильный winapi метод. Ну или потому, что добавлен внешний процесс, который тупо состоит из двух winapi вызовов: WaitForSingleObject + rename. Есть там алгоритмы? Да как бы нет. Ну, если не считать за алгоритм тот факт, что две команды языка программирования, написанные друг за дружкой, будут выполнены именно друг за дружкой. Где тут алгоритмы??
И бизнес действительно говорит "ой какие вы молодцы, пользователи перестали нас пинать в техподдержку, потому что у них теперь всё работает".
И иконка правильная, потому что в rc файле найдено правильное место для неё, а обновление проходит, потому что выбран правильный winapi метод. Ну или потому, что добавлен внешний процесс, который тупо состоит из двух winapi вызовов: WaitForSingleObject + rename.
Гм, ну, это деятельность девопса или инженера какой-то там линии техподдержки или SRE (на самом деле не знаю как это правильно в десктопом мире называется, я больше по бэкенду, буду условно называть девопсом). Так-то нормально, но...
Есть там алгоритмы? Да как бы нет.
Так кажется, девопсов и не тестируют на алгосекциях.
И бизнес действительно говорит "ой какие вы молодцы
Ну, это, наверное, хорошо, если бизнес настолько богат, что на позициях девопсов или поддержки легаси держит разработчиков, но это, скорее, исключение, чем правило. Из 10+ мест где я работал, разработчики 90% времени разрабатывают, а девопсят, ну, разве что в очень некоторых местах в рамках дежурств, если так принято. Искать иконку 40 часов - это явно не работа разработчика.
Девопсы вообще не этим занимаются, как и инженеры техподдержки. Перечисленные задачи всегда были обязанностью программистов, а не кого-то ещё.
Перечисленные задачи всегда были обязанностью программистов
Любой бухгалтер большинства советсроссийских предприятий абсолютно точно знает, что задача замены картриджа в принтере и поиск клавиши "эни" всегда были обязанностью программистов. Так что да, я не удивлён.
Слава небесам, что мне за 30+ лет программистской деятелности не пришлось работать ни в одной из подобных контор (наоборот, однажды в должности слесаря писал программы для бухов, используя, о божечки, стррррашные алгоритмы!).
Но я же говорю, если бизнес считает нужным нанимать на такие должности программистов за программистские зарплаты, значит дела у него идут неплохо и это, наверное, хорошо. И да, конечно, спрашивать у программиста по замене картриджей и поиску иконок какие-то там алгоритмы действительно чрезвычайно глупо.
Что общего между заменой картриджей и отображением иконки в трее?
Тем, что большинство программистов сделает и то и другое, но ни в том ни в другом не состоит работа разработчика. Назвать-то эникея пограммистом можно, но станет ли он от этого таковым?
Работа разработчика не заключается в написании программ?
Ну, я-то как раз уверен, что заключается именно в написании программ. Которые, как завещал великий Никлаус Вирт, суть алгоритмы + структуры данных. А вот товарищ считает, что нет. Достаточно неделями искать иконки, переименовывать файлы, собирать дистрибутивы и грепать конфиги. У нас этим админы занимаются. Но если тамошний бизнес это устраивает, то кто я такой, чтобы их учить? И, да, я согласен, что у таких "пограммистов" нет смысла спрашивать за какие-то там "алгорифмы". Равно как и у эникеев, меняющих картриджи.
Иконку искать не нужно, иконка уже есть. Её нужно показать пользователю. Причём не вручную показать, как вы могли бы подумать, пользователь должен увидеть иконку в определённом месте при запуске программы.
Чтобы это сделать, нужно написать в исходном коде программы в определённом месте вызов определённый функции с правильными параметрами.
С каких пор исходный код программы должны редактировать девопс и админ?
С каких пор чтение документации по используемой библиотеке стало чем-то, не относящимся к работе программиста?
Причём не вручную показать, как вы могли бы подумать, пользователь должен увидеть иконку в определённом месте при запуске программы.
Чтобы это сделать, нужно написать в исходном коде программы в определённом месте вызов определённый функции с правильными параметрами.
Вы это серьёзно? Сначала пишите, что это не вручную делается, а потом пишите как это делать зачем-то вручную? Я последний раз под венду 3.11 программировал и уже тогда не требовалось писать "в исходном коде программы в определённом месте вызов определённый функции с правильными параметрами". Собственно, мой собеседник этого и не делает - он же написал об этом прямо. Иконку уже лет 30 просто указывают в файле ресурсов. Но сначала, конечно, нужно её найти. И это тяжкий пограммерский труд, требующий квалификации сеньора!
С каких пор исходный код программы должны редактировать девопс и админ?
См выше. А против грепанья конфигов и собирания дистров у вас возражений нет, я так понял?
С каких пор чтение документации по используемой библиотеке стало чем-то, не относящимся к работе программиста?
С каких пор чтение документации стало ВСЕЙ работой "пограммиста"? Вы же видели - человек из недели в неделю по 40 стандартных часов читает документацию и грепает гиты. А предыдущий сеньор-собеседник писал, что пишет код не чаще одного раза в год. Таким гражданам определённо бессмысленно задавать вопросы про алгоритмы. Равно, как и "программисту" заправляющему картриджи в бухгалтерии.
Собственно, мой собеседник этого и не делает - он же написал об этом прямо. Иконку уже лет 30 просто указывают в файле ресурсов.
А в трее-то она окажется сама? Чушь.
Кстати, редактирует файл ресурсов у вас девопс?
Но сначала, конечно, нужно её найти. И это тяжкий пограммерский труд, требующий квалификации сеньора!
Хватит перевирать собеседников. Искать 40 часов саму иконку тут предлагали лишь вы.
Но, насколько я понял, обычно задание звучит так: "отсортируйте массив пузырьком, гуглить нельзя".
Нет, обычно вопрос вида: разложите числа в таком порядке, чтобы сумма частичных сумм была минимальна (общее время ожидания в очереди при данных временах обработки каждой заявки). Или что-то вроде: найдите k максимальных чисел в массиве. Писать сортировку никто не просит. Вызов стандартной sort() всех устроит. Сортировки учат в теории только как удобный пример задачи, где можно показать многие приемы построения алгоритмов. На интервью их писать не просят! Максимум, просят допереть, что вот тут надо посортировать или применить приоритетную очередь.
Дада, потом оллимпиадники в продуктовом коде в качестве хэша используют содержимое файла завёрнутое в base64, и в качестве значения путь до файла.
На мой субъективный взгляд хорошо проверить задачкой можно только джуна - он все равно ничего не знает, а понять как он мыслить с помощью задачки можно. Другое дело когда вы задаете эту же задачку сеньеру. Я вот пишу алгоритмы 1-2 раза в год - они редкость в андроиде. Но т.к. некоторые компании требуют их на собесе, приходится тратить свое время на "натаскивание". Куда грамотнее было бы проверить сеньера по его знаниям и умениям проектировать. Достаточно попросить его решить практическую задачу, чтобы понять хороший он программист или нет (даже если описание будет устным). Казалось бы и первый и второй вариант дает один результат, но нет: любой джун может натаскаться на задачках, набить руку на собесах и пройти в крупных бигтех мидлом, приписав себе 2 года опыта работы. С проверкой на проектирование так сделать не получится. Когда у Яндекса случилась утечка кода, мы все увидели немалое кол-во велосипедов, а ведь они проверяют всех алгоритмами. Получается, авторы этих костылей хорошо решают задачки, но плохо выполняют свою работу, значит умение решать задачки != хороший программист
На мой субъективный взгляд хорошо проверить задачкой можно только джуна — он все равно ничего не знает
В случае ФААНГА все кандидаты — как "джуны": там своя кухня, свои технологии. Их на стороне не знают толком. Только по основам языка и можно гонять кандидатов — это грустное занятие. На мидлов-сеньеров ФААНГ проводит дополнительные интервью (system design, domain-specific knowledge).
Достаточно попросить его решить практическую задачу
Практическую задачу практически очень редко можно впихнуть в рамки интервью. Максимум получится поболтать на тему архитектуры и это и проверяют в design interview.
Это интервью смогут проводить только опытные сеньеры, ибо там гораздо больше субъективности. Если у вас пол кандидата на место, то вы можете пожертвовать их временем. Если, как в ФААНГе, десятки человек на место, то уже приходится привлекать к интервью мидлов и давать задачки всем.
На мой субъективный взгляд хорошо проверить задачкой можно только джуна
Вы смотрите со стороны кандидата. Со стороны нанимателя несложная задачка позволяет дёшево отфильтровать негодных кандидатов. Которых немало и среди ведущих (по должности) разработчиков. Естественно задача должна быть такая, решение к которой реально придумать за время интервью. Быстрая сортировка или перебалансировка красно-чёрного дерева не подойдёт.
Когда у Яндекса случилась утечка кода, мы все увидели немалое кол-во велосипедов, а ведь они проверяют всех алгоритмами. Получается, авторы этих костылей хорошо решают задачки, но плохо выполняют свою работу, значит умение решать задачки != хороший программист
Как-будто, если бы они не проверяли всех алгоритмами, то код был бы идеально вылизан. Генезис костылей и велосипедов в большой и хорошо выдержанной кодовой базе несколько сложнее.
Как-будто, если бы они не проверяли всех алгоритмами, то код был бы идеально вылизан.
Скажем там, если бы давали хоть что-то, кроме алгоритмов, то результат мог быть другой. Недавняя история с 6 задачками на 3 собесах в Небиус (экс-Яндекс) это же чисто буффонада.
Скажем там, если бы давали хоть что-то, кроме алгоритмов, то результат мог быть другой
Не мог. Во-первых, никакая методика найма не даёт 100%-го результата. Во-вторых, костыли и велосипеды появляются на стыке бизнеса и архитектуры при их развитии. Например: сегодня мы создали архитектуру из бизнес-требований и запилили решение. Через год, развитие приложения больше не финансируется, но надо поддерживать текущих клиентов. При этом инфраструктура плывёт, а клиентам иногда всё-таки удаётся пробить новые возможности. По уму приложение надо переписать, но ресурсов на это нет. По-этому команда выкручивается как может. То есть ставит костыли и строит велосипеды. Хороший разработчик тут поставит крепкий костыль и напишет большой комментарий: "ОСТОРОЖНО!!! Это костыль. Сделали, потому что иначе нельзя. У самих сердце кровью обливается." Плохой разработчик поставит хлипкий костыль и не оставит комментария.
А в чем же, по-вашему, состоит работа разработчика, как не в написании алгоритмов решения задач на подходящем алгоритмическом (хм, снова это слово - может быть оно здесь неспроста?) языке программирования?
Оптимальные алгоритмы хорошо изучены и давно эффективно реализованы на всех языках. Кроме того, необходимые и достаточные условия применения этих алгоритмов также хорошо исследованы, что позволяет реализовывать гибридные оптимальные алгоритмы (и структуры данных тоже). Любой самописный алгоритм, скорее всего, будет точечным.
В результате имеем, что разработчик должен не заниматься высшей математикой, а грамотно применять алгоритмические библиотеки в различных кейсах.
Но главная задача разработчика, что и отличает сеньора от джуна - решать проблемы бизнеса.
В результате имеем, что разработчик должен не заниматься высшей математикой, а грамотно применять алгоритмические библиотеки в различных кейсах.
Алгоритмы - это не высшая математика. Разработчик не должен будет руками сортировать массивы и балансировать деревья, но в большинстве случаев делать штуки вроде "выбрать клиентов, которые сделали не больше двух заказов в течении последнего года, добавить им персональную скидку 5% и отправить каждому рекламное сообщение" он будет должен. А это тоже очень даже алгоритмы, и ни в каких библиотеках их нет.
Не всегда и не везде всю логику можно засунуть в базу данных. Потом, если уж говорить про ФААНГ, то там эти самые базы данных часто и разрабатывают.
Например, это не клиенты, а какие-то события. И разговор идет о телеметрии в программе. Если какое-то событие произошло 2 раза за определенный промежуток вермени, то это аномалия и надо послать impression на сервер. Крутить на клиенте базу данных только для того, чтобы решать эту задачу через SQL запрос — очень неэффективное решение.
Типовая повседневная бизнес-задача, которая уже 20-30 лет назад просто и эффективно решалась.
Сейчас 2023-й год, многие задачи, которые решались эффективно, сейчас решаются не эффективно. Например, у вас там может быть NoSQL СУБД :)
Возможно, и задачи тогда следует давать про штуки вроде вашей, а не про big data алгоритмы и структуры из говна и палок?
Буквально сегодня подумывал, а что же лучше: практиковаться в алгоритмах на leetcode или развиваться, делая свой pet проект?
Как я вижу уже из второй статьи, реальность такова, что навыки решения задач с leetcode гораздо важнее. С ними как-то уверенней в завтрашний день смотришь.
Навык прохождения собесов почти никак не связан с навыками, которые нужны в работе. А вот пет-проект полезен и для Вашего собственного развития, причём задачи в нём обычно приходится решать более близкие к реальной работе, чем алгоритмические задачи с литкода. Вот если это не ради собесов, а с целью подтянуть собственные знания алгоритмов - тогда другое дело.
Кроме того, у автора свой опыт как соискателя, а у меня свой как собеседующего: и я лично всегда прошу кандидатов показать пример кода (в идеале - на гитхабе), всегда выделяю полчаса перед собесом на изучение этого кода, и на собесе мы обсуждаем в т.ч. отдельные места в этом коде под углом "почему сделано так а не иначе" и "в какой ситуации эта часть корректно работать не будет", плюс читая код я выявляю потенциально слабые места в знаниях и задаю по ним дополнительные вопросы, чтобы понять причину (если это просто невнимательность то норм если такого не очень много, если чего-то конкретного не знает то вообще не проблема, а вот если это фундаментальное недопонимание природы вещей то стоит разобраться насколько случай запущенный). А если своего кода нет - тогда я обычно выдаю тестовое задание, чтобы всё-таки получить пример кода (при этом не всегда критично, особенно если это позиция джуна, чтобы тестовое было корректно и полно реализовано, мне важнее чтобы был пример любого кода чем корректное решение). Всё это позволяет на порядок корректнее оценить квалификацию соискателя, чем любые другие известные мне подходы.
А как соискатель я отправляю ссылки на свой гитхаб и хабр, после чего обычно тупых вопросов ко мне на собесе уже нет, разговариваем за жизнь/архитектуру. А если кто-то начинает задавать такие вопросы, в частности показывая что мой гитхаб смотреть поленились - ну, это их проблема, на собесе не только они меня оценивают но и я их, так что это сильный довод в пользу того, чтобы в эту компанию не идти.
Честно говоря, мне кажется странной статистика автора. Возможно дело в том, что он немного переоценивает свою квалификацию как лида и сениора. Или в том, что искал работу в крайне неудачный период для разработчиков уехавших из РФ. Или в том, что у него были собственные завышенные требования к компаниям. Ну или ситуация на рынке действительно изменилась в последний год, и найти работу среднему сениору стало намного труднее.
Лично у меня за всю жизнь (а код я пишу уже 34 года) именно "заваленных" собесов было… не хочу соврать, может и был один, не помню точно. Более того, на то, чтобы получить работу у меня в среднем уходило заметно меньше 2-х собесов, причём если не складывалось то обычно отказывался я, причём с мотивацией "уже устроился в другое место". Лайвкодинг на собесе я попробовал один раз из любопытства, и нет, мне не понравилось (субъективно я бы сказал, что я его завалил, но это был "бонусный" раунд собеса чисто из любопытства, обратную связь по нему мне не дали, и он не помешал моему найму в ту компанию), так что повторять этот опыт я не буду - кому нужен мой код пусть смотрят на гитхабе, а если им лень, то я не нужен им а они - мне.
При всём этом я спокойно мог и полгода сидеть без работы, лениво ожидая пока работа найдёт меня сама, занимаясь в это время своими проектами на гитхабе или написанием статей на хабр. Меня такое времяпровождение между проектами всегда полностью устраивало, потому что во время работы найти на всё это время довольно сложно, а своими личными проектами заниматься тоже хочется.
Я смотрю на вас снизу вверх) У вас в 6 раз больше опыта чем у меня и конечно же вы не испытываете тех трудностей, что испытываем мы, свежевыкошенные сеньеры. в моем понимание сеньер - это разработчик, способный качественно и самостоятельно выполнять большой объем работы без лишнего контроля и проверок. Я этими качествами обладаю, но я не знаю всего и не успел попробовать и пытакать все технологии, что must have на текущий день в android (опять же rxjava и kmm). При этом я принимаю правилы игры и постоянно закрываю такие пробелы - в июне я самостоятельно разорбрался с MVI, вывел для себя оптимальную формулу и отладил ее на пет-проекте. У компаний в РФ на мой взгляд - с одной стороны дефицит кадров, а с другой стороны завышенные ожидания при низкой зарплате. Я просил у всех компаний в РФ зп от 350к, что вполне соответствует сеньерской позиции. У компаний зарубежом я просил от 6k$. И та и другая цена на мой взгляд довольно справедлива.
Не надо на меня так смотреть - я таким опытным не родился и когда-то и у меня тоже было 6 лет опыта. :) Правда, и собесы в те времена были другие, сложно сравнивать.
По деньгам в РФ если в среднем - да, у меня такое же впечатление, но это вполне ожидаемо после ухода и западных заказчиков и западных компаний (нет необходимости конкурировать с их зарплатами), но это коснулось далеко не всех компаний.
Тем не менее, для джуна такая статистика собесов ещё понятна, я бы не удивился такой и для миддла через пару лет (ChatGPT не дремлет!), но сейчас и для сениора по востребованной технологии, к тому же не ограничивающего себя компаниями только в одной стране - ну не знаю, на мой взгляд это всё-таки странно. Очень интересно понять, это Вы такой особенный, или это сейчас такая ситуация на рынке стала.
в моем понимание сеньер - это разработчик, способный качественно и
самостоятельно выполнять большой объем работы без лишнего контроля и
проверок.
Хм, хм. Это никак не тянет на сеньера. В серьезных конторах - это миддл разработчик. Сеньер это не просто чувак что много и качественно работает, это еще и тот кто улучшает процессы, учит других разработчиков, умеет говорить с бизнесом и т.д. и т.п.
По-моему, это вы путаете сеньера с лидом - сеньеру нет дела до остальных, он не должен никого учить и думать за всех. Его цель - тот фронт работы, что ему выделила команда. Там он предлагает, думает и решать, а как дела у всего проекта и всей команды - ему по-большому счету всеравно. Для этого есть тим-лиды и тех-лиды. В конце-концов, что получится за хаос, где 30 человек лезут со своими идеями и новшествами ко всем где надо и не надо? Звучит неправдоподобно
Это вы мидла описали.
В большистве компаний сеньйор имеет как минимум код ревью и менторство.
В моем понимании всегда грейды выглядят примерно так:
Лид - организует работу команды. Вместе с командой определяет дальнейшее развитие проекта. Несет ответственность за выбранный путь.
Сеньер - самостоятельная единица, способная выполнять задачи любого уровня сложности.
Мидл - разраб с опытом, но не достаточной силы. Способен решать большинство задач, к архитектуре обычно не допускается или допускается с оглядкой. В случае чего может запросить SOS у коллег, и те ему помогут. Нуждается в наблюдении.
Джун - талантливый, трудолюбивый, что-то умеет, знает недостаточно для самостоятельной работы. Нуждается в постоянном контроле/менторстве
Ревью - это касается всех вне зависимости от грейда. В нашей команде оно было круговым - каждый поверял каждого по кругу. Менторство опционально - если сотрудник имеет к этому предрасположенность и желание, он может быть ментором
В крупных компаниях обычно нет такого чувака как лид. Есть что-то вроде Senior -> Staff -> Principal -> Distinguished -> Fellow. И обычно уже с сеньера ожидается куча работы вне своей команды, менторство, ревью, комьюнити проекты и пр.
Хорошо, спасибо) Переосмыслю)
Ну кто-то же должен заниматься оперативным управлением техническими специалистами. Я видел подход, что это модификатор для разработчика.То есть есть условный мидлосиньёр и на него ещё вешается роль лида и часть рабочего времени, вплоть до 100%, у него начинает именно на управление командой уходить.
По нашему грейду ваш мидл - подвид джуна)
Если человек требует "допуска с оглядкой" — он джун, извините.
Мидл самостоятельноа единица.
Архитектура в нормальных компаниях выбирается на митинге всех девов, и в большистве случаев уже выбрана к моменту вашего прихода. Куча мелких тасков с нуля — нетипичная картина
Я бы все таки вниз сместил. Стажер — тот кто у вас джун. Джун — тот кто у вас мидл, и т.д.
или развиваться, делая свой pet проект?
Для общего развития - почему бы и нет. Но если вы рассчитываете, что наличие пет-проекта на гитхабе как-то избавит от ряда вопросов на собеседовании, то это с высокой вероятностью сработает, только если пет-проект достаточно известен. В остальных случаях собеседующих, которые имеют время и желание сколь-нибудь серьёзно ковыряться в вашем коде перед собеседованием, немного, и обычно это сравнительно молодые ребята, которые ещё не особо часто собеседовали. Ну потому что оценивать человека по совершенно незнакомому коду, это занимает много времени, плюс, все равно надо и вживую увидеть, и вопросы позадавать, поэтому нет смысла вместо "провести собеседование" делать "смотреть гитхаб, а потом все равно провести собеседование".
Мне кажется, что задачки во время собеседование - это скорее стресс тест. Да еще и рулетка. Знает ли кандидат ответ на этот конкретный вопрос сразу. Типичные вопросы на таких собеседования - это как спрашивать таблицу логарифмов, а не сам принцип логарифмической функции, например.
Мне всегда проще оценивать кандидатов именно по его коду. Что такого в том, что бы посмотреть код и сразу понять общий стиль. Многие концептуальные ошибки/проблемы ну просто сами в глаза бросаются.
Ну и опять же.. мне потом в его коде уже на работе разбираться. Лучше я сразу оценю ряшливость/неряшливость, понятность кода, что комментирует в коде и пр.
Если попрограммировать во время собеседования, все равно же интернет под рукой есть, можно посмотреть, если не знаешь/забыл. По-большому счёту, не так уж важно, насколько там у человека код неряшливый в пет-проектах. Всё это исправляется, к тому же лдно дело, когда ты пишешь сам для себя, другое дело, когда для других и по принятому в команде стандарту. Вот увидеть, умеет ли человек и думать головой, и искать информацию - это как раз важно.
По-большому счёту, не так уж важно, насколько там у человека код неряшливый в пет-проектах.
Важно. Так не бывает. Что бы щелк и переключалось в голове "я тут дома пишу/я тут на работе".
Вот увидеть, умеет ли человек и думать головой, и искать информацию - это как раз важно.
Во время интервью?! В жутком стрессе (для большинства).
Я вот терпеть не могу, когда кто то просто за плечом стоит и т.п. когда я работаю.
Зачем я буду отсеивать кандидатов в свой отдел по критерию "он не может быстро писать код и тупит в условия стресса". Потому что представлю как я сам будут чувствовать в таких условиях.
Ситуации "ой все сломалось, срочно найди ошибку по логам и что бы пач вышел через 15 минут" бывают регулярно. Но они мне очень не нравятся.
Если кому то нужны разработчик, который как фильмах про хакерах быстро быстро "долбять" по клавиатуре взламывая сайт "пентагона" когда у них за спиной стреляют из пулемета - ну пусть устраивают стресс тесты с решением алгоритмических задач типа "сортировка извращенным пузырьком наоборот" за 5 минут в блокноте.
А мне нужно что бы мои подчиненные могли:
Написать код не 5 минут дистанции, а на 3-5 дней на промежуточный/окончательный вариант.
Я мог легко разобраться (читаемый код C++/Java/ReactJs/python) в проблеме и внести мелкие исправления, в случае "в отпуске сотрудник и пр." или перепоручить это кому то, не беспокоясь что это вызовет проблемы "что за хрень тут написана"
Для всего этого лично мне лучше оценивать по примерам кода, а не по идиотским задачам, которые к жизни/работе разраба, как правило, прямого отношения не имеют.
Важно. Так не бывает. Что бы щелк и переключалось в голове "я тут дома пишу/я тут на работе".
"Щелк" происходит обычно после первого-второго неудачного кодеревью естественным образом. В моей истории был только один обратный случай, и это реально исключение. Обычно, если человек вообще научился программировать и ему меньше этак 60 лет, он достаточно компетентен, чтобы следовать гайдлайну, который ему покажут. Пусть даже если ему это и не нравится.
Во время интервью?! В жутком стрессе (для большинства).
Ну да. Не знаю насчёт жуткого стресса для большинства, обычно, если это не первое-второе в жизни интервью, оно проходит всё-таки безболезненно для большинства.
Зачем я буду отсеивать кандидатов в свой отдел по критерию "он не может быстро писать код и тупит в условия стресса"
Так вы же сами ответили на свой вопрос:
Ситуации "ой все сломалось, срочно найди ошибку по логам и что бы пач вышел через 15 минут" бывают регулярно
Вот как раз за этим. Если у вас бывают аварии, требующие срочных фиксов, зачем вам разработчик, который не сможет это сделать?
что же лучше: практиковаться в алгоритмах на leetcode или развиваться, делая свой pet проект?
Смотря куда Вы устраиваетесь. Где-то и до задач можно не дойти, если нет своего проекта на гитхабе или хотя бы коммитов в чужой опенсорс.
Солидарен в этом вопросе с @powerman: задачки для интервью, пет проект для души и свободной практики
Выражаю личную поддержку, но статья написано косноязычно.
Занялся бизнесом, и? Опыт 6 лет, не мог тех собес пройти? Ты мобильный разработчик и было тестовое на перегонку wav в mp3, зачем ты вообще взялся? Кто в здравом уме вообще полезет смотреть код кандидата на Гите?
Складывается впечатление что ты неорганизованный человек.
Очень интересный опыт. Побольше бы такого на Хабре)
У меня по вашему конспекту создалось впечатление(возможно очень ошибочное), что вы слишком сильно рассчитывали, что при вашем резюме и гитхабе спрашивать вас теорию в принципе никому в голову не придет, а разговор сразу пойдет за системный дизайн или алгоритмы, а если вдруг, то вы сходу ответите. Лично мне он чем-то мои первые наброски напомнил, когда я 1.5 года назад в ит вкатывался при 0 коммерческого опыта. Недели 2 назад начал потихоньку к собесам готовиться, поднимать старые доки и что-то такое промотал до конца и снес - просто потому, что 90% инфы оттуда за 1.5 года кодинга уже в подкорку въелось, по крайней мере на уровне начальных формулировок.
Спасибо за столь подробное изложение, в некоторые компании сам когда-то проходил собесы, очень похожее впечатление от них) Будет интересно почитать, как всё сложится в ОАЭ.
Мой богатый опыт наблюдения за собой помогает мне предсказать "выгорание" заранее. За год или типа того. Поэтому я начинаю разбрасываться резюме заранее, и проходить 1-2 собеса в месяц, отказываться от неинтересного, не сильно обращая внимание на "нужду".
По итогу, опыт собеседований примерно такой же, но он растянут по времени и не так сильно бьет по настроению. А кроме того, наступающее "выгорание" переносится легче. Когда тебя уже задолбало происходящее вокруг, но ты видишь какое-то светлое будущее: оферы, которые кажутся лучше окружающей действительности, но пока еще недостаточно лучше.
Сдать паспорт в начале февраля - это вот реально про "не повезло" :( Но хорошо то, что хорошо заканчивается! Удачи на новом месте!
У автора похоже есть гражданство иной, более "удобной" страны,вместе с соответсвующим загранпаспортом, так что можно за него порадоваться.
Если человек получал гражданство России, то он должен был сдать казахстанский паспорт; за обратное предусмотрена нехилая ответственность.
в начале февраля 2022 сдал паспорт РК
что человек и сделал.
По закону РК, человек получивший гражданство другой страны, лишается прав на гражданство Республики Казахстан.
да ладно, бывает)) Спасибо)
А чего ваша Галя всё не замужем?
Да дюже разборчивая она.
Два варианта. Автор слишком много хочет или преувеличивает свои компетенции. Но я бы как наниматель с таким не стал связываться.
Рынок мобильных приложений уже не так растет, поэтому понятно,что теперь критерии выше и нет такой острой потребности
Что-то какая-то жесть с собесами на Андроид. Когда я искал первую работу на Java, я посоветовался с опытным товарищем и он сказал: на Java не найдёшь, требования высокие, народу много. Я подумал: да, наверно и попробовал поучить Котлин и Андроид, но мне вообще не зашло. В итоге устроился таки на Java. И такой жести не было ни поначалу, ни через год когда я решил сходить на рынок вакансий. Правда, я, конечно, на джуна подавался....
В списке компаний значительная часть - кипрские. Можно узнать в каких источниках Вы искали вакансии? Для себя, чтобы понимать где есть много кипрских вакансий, и ещё интересно почему такое распределение проектов в списке в статье.
Добрый день! В начале февраля я собрал резюме на linkedin и стал рассылать резюме. Кипрские компании писали сами, я их даже не искал. Я основном кидал заявки в Германию (бабка была немкой и мне казалось логично, что если не Россия, так Германия). Всего по планете я разослал около 200 заявок, что довольно много. Треть из них ответила вежливым отказом, 2/3 не ответили совсем. Из этого я делаю вывод, что рынок кандидатов перегрет чудовищно за рубежом. Т.ч. лучше не повторять моих ошибок и бросать работу, раньше чем у вас появится хороший, более-менее надежный план ;)
Собеседовался в кипрскую компанию с релокейтом, на финальном общении с командой оказалось что они больше не релоциют, а HR просто забыла об этом. Мы все так глупо выглядели :).
Кстати вопрос, так уж плохо что в сегодняшней ситуацию многие ждут от компании в первую очередь релокейт и зп не в рублях, работа же почти всегда в первую очередь была возможностью жить лучше чем до неё.
Спасибо за такое подробное описание! Должно воодушевить тех, кто пока не может найти работу. Я последний раз тоже искал работу довольно долго - два месяца примерно. Прошел около 10 интервью. Где-то прощались после интервью с HR, где-то после технического. В Yandex тоже собеседовался, но показал себя не очень хорошо. Хотя, не скажу что собеседование было адекватным.
В общем, согласен с выводом что надо не опускать руки и продолжать проходить собеседования - обязательно найдете свою работу.
Начала читать внимательно, потом перестала, так как нет какой-то конкретной привязки к датам-срокам. В итоге непонятно сколько в общей сложности искал работу, сколько собесов в неделю и тп более четкие параметры.
Про деградацию скилов согласен абсолютно, я системный аналитик, прошлой весной активно качался по SQL - прошёл несколько курсов и на онлайн тренажёре SQL academy неплохой рейтинг заимел, после в конце мая устроился в компанию нынешнюю, тут Dbeaver открываю раз в 2-3 месяца и навык реально подрстерял, щас просматриваю на рынок, пролжая там работать, прошёл 2 этапа собеседований, всё хорошо - дали тестовое по SQL, где надо было 10 задач решить за 30 минут - из них я только 3 успел?♂️
В итоге получил отказ?♂️
Ой, как же я Вас понимаю! За 22й год откликнулся на более 100 заявок за рубежом, после 80й подавал уже исключительно на ближайшее зарубежье. 101-я вакансия была из Великобритании, и я подумал: "100 отказов или 101 - это не важно, я все равно попробую!" И, наконец, спустя 5 этапов собеседования и долгого процесса получения визы я оказался в прекрасной Шотландии!
Что порой кроется за «успехом»