Комментарии 128
Рынком сейчас правят разработчики, и они устанавливают уровень зарплаты, за которую готовы работать. Ни как не HR'ы. Сейчас.
Ну в целом есть такое, правда много крутых ребят, которые скромные и много просить побаиваются что ли.
Сейчас на Рынке Синьор джава стоит 300К - 400К. Понятно кто-то до 250К даст, кто-то и 450К, но это редкость.
И я бы советовал ребятам не скромничать по ЗП, т.к. недвижка выросла в 1.5 раза за 3 года (в Москве точно), еда, одежда и прочее тоже растет будь здоров. 200К в том году это уже не те же 200К сегодня.
Если не хочется париться то ставьте 300К, если есть время и желание собеситься, то 350К-400К.
Да, в основном уже есть постоянная стабильная работа за сумму N, или опыт.
Я про Sr. уровень. Предложения N+20% - не интересно.
Скромничать не стоит, конечно, если вы уже востребованы. А вот этого надо добиться.
всегда удивляло, почему у вас, если зп в рублях, то она хорошо меньше зп в usd/eur
например 450К RUB - это прямо редкость, если 10К USD - обычная зп
цифры для USD взяты со слов знакомых, которые недавно нанимали SJD
За бугром ЗП выше, но и жизнь подороже )
+ за границей всегда говорят до вычета налогов, а в РФ - после.
я говорил про наём в вашей стране, а не сравниваю разные страны
10K USD это тоже зп в европейской части россии
10K USD зп в европейской части России за Java Senior Dev - это редкость. Ну прямо совсем редкость.
Таких ЗП очень мало, это раз. И два - если написано до 10К usd вообще не гарант что после собеса Вам дадут именно 10К.
Т.е. это ЗП для уникальных разработчиков, если вы сможете их удивить стрельнув лазером из глаз.
Мне кажется, что все как-то однобоко. Крутые ребята оказались те, кто спрашивают архитектуру, GC и solid. Но это что-то, что можно вытащить просто на разговорном уровне без скилов, прочитав пару статей. Как будто ты совершенно отбрасывается техническая часть собеседований.
А потом окажется, что как создать свой сервер и роутинг они не знают, потому что запускали всегда приложение из idea по зелёному треугольнику и приходили на готовый проект. Делают вложенные циклы или многоуровневые условия, делают циклами запросы в базу или вообще используют пробелы вместо табов😅
Я к тому, что кажется, что все таки лучше, когда как-то разумно совмещены все эти типы
Я не говорил, что роутинг нужен без фреймворка. Зачем сервер? Скорее это я их своей специфики, что мне java нужна для бэкенда, то есть для написания серверной части. И в данном случае я говорю о том, что как-то нужно написать на джаве сервер, который будет отвечать на запросы клиента, ну и запустить его в терминале через команду, а не с помощью ide. Но я не говорил, что нужно написать свой Apache или nginx
а для сервера iis и apache
cервером будет Tomcat/Jetty/etc
для reverse proxy - nginx (для кубов ingress через nginx и его форки)
после предложения использовать "iis и apache" можно сразу заканчивать собеседование
когда я собеседовал SJD из москвы/питера (с опытом 10+ лет) то половина из них просто не знала как работает AtomicLong и что такое ForkJoinPool
так что да, могут не только лишь все
Я бы совместил 4 + 5 . И +3 (по алгоритмам) - только если реально, это нужно на проекте.
Золотая середина - всегда хорошо )
У нас в компании приняты пробелы вместо табов в обязательном порядке, это прям боль, к которой я несколько месяцев привыкал(
А в чем проблема тут вообще? Любой нормальный текстовый редактор это прозрачно поддерживает, а про ide вообще молчу.
Тут надо посмотреть серию Кремниевую Долину: https://www.youtube.com/watch?v=SsoOG6ZeyUI. Это действительно боль....
А чем плохо нажать кнопку tab и получить 4 пробела? Шифт + таб их уберёт. Число можно настроить, конечно. Справедливо для идеи и пайчарма.
наверное в том, что потом передвижение стрелками не даёт такого же быстрого движения - приходится хоткеи использовать для прыжков по словам.
ЗЫ: я вообще предпочитаю Tab + SmartTabs, то есть гибридное использование Tab и пробелов
Камень в огород стандартов где "таб" - 2 пробела. Читать такое сложнее.
Шутка конечно, но:
4 пробела - это больше одного таба на 3 байта. В итоге примерно четверть кода исходников - это пробелы
В последнее время больше всего напрягает то, что если позиция по java, то значит и по дефолту и по спринг ты должен иметь опыт. Абсурд.
Спринг - стандарт де-факто для промышленной разработки. Нравится это кому-то или нет. Микронавт, гусь и велосипеды - это доли процента. Кроме того, если вы не знаете конкретно спринг, но знакомы с паттерном DI, рефлексией и общими принципами конфигурирования приложений, то тоже никаких проблем быть не должно.
Потому что сейчас вся джава разработка на спринге.
Это оборотная сторона другого абсурда - проблема освоить самый популярный инструмент на рынке из мире джавы?
эээм, если вы идете на синьера, то вы не только спринг и прочие хибернейты с мавенами должны знать, но еще и докеры с куберами, какие-то пайтоны или баши, да и фронтом было б неплохо не брезговать. Другое дело, что все это дополнительное - не до уровня реализации и подводных камней, но представлять о чем речь, чтоб не обделаться ненароком при встрече.
Можно весь список сократить до тех, кому пофигу, и тех, кому нет.
Как по мне, первые 4 пункта - это ребята, которым пофигу. Компании нужен человек под конкретные задачи с конкретным набором скиллов. Если об этих задачах и об этом наборе скиллов на собесе речь не идет, то значит интервьюеру пофигу, что там компании нужно. Он или самоутверждается за счет накидывания всяких олимпиадных задач и вопросов на знание справочной информации, или просто тянет лямку обязанности провести собес.
Ну так уж получилось )))
В целом скепсис вполне уместен, дыры в знаниях есть )
Но в целом тут скорее отталкиваться от задач и проекта, тогда твой опыт в одном месте может быть Синьор, в другом Мидл )
Тогда стоит начать с самого понятия Синьор, именно в Вашем понимании.
Иначе это все равно, что говорить об авто, но один представит серебристую теслу, а второй Порше кайен шоколадного цвета.
Хотя предмет статьи - это все таки собеседования, а не то что я себя считаю таким классным разработчиком. И я много встречал людей, которые превосходят меня по разным вопросам в разы...
Вот еще неплохая статья про Синьорство https://habr.com/ru/post/460901/
Проблематика в расплывчатости и высокой субъективности классификации разработчиков.
Вообще собеседования - очень субъективная вещь )
выбить бабки из работодателя "как у сеньёра" - хорошо для вас, но сеньёром автоматом вы после этого не стали, в тех же США синьорами не просто так становятся. в первую очередь это человек, который может решить задачу от начала (дизайна) и до конца (тестов), попутно обсудив всё с заказчиком (убедить его если требуется), который ещё и другим таски раздать может и вообще понимает как примерно нужно всё делать, без помощи гугла. человек, который прочитал например "высоконагруженные приложения", просмотрел сотни разных видео лекций с конференций, да и который может сам сесть и с некоторой подготовкой запилить чёткое видео как и что он делает. + софт скилс и понимание лидерства. т.е. это очень зубастый разработчик, а не тот, который примерно "слышал про то и это". дыры в знаниях - это мидл, страшного ничего нет, главное чтобы было желание учиться.
вообще как по мне самый страшный грех любого работника (не только айти) это не отсутствие занией, а иллюзия их наличия, если не знаешь - спросишь, найдёшь, а если тебе кажется что ты знаешь, вот тогда можно наделать дел
Давайте так, если посмотреть объективно, то Вы просто впились в классификацию Синьора, вот и всё )
Мне по большому счету параллельно как называется должность Синьор, Мидл, Страший, Средний или младший разработчик... Если я получаю то вознаграждение, которое я хотел ) А я его получаю.
Статья не про меня и про то считаю ли я себя синьором (это же глупо, подумайте сами). Я проходил собесы на позицию Синьор в компаниях - всё, точка )
В собеседовании вообще важно только одно: подходите Вы компании или нет.
дыры в знаниях - это мидл
Если я проработаю еще лет 5, одни дыры закроются - другие откроются.
Я вообще не верю в то, что можно абсолютно все узнать.
Сократ: "Я знаю только то, что я ничего не знаю"
Если Вы будите спорить с этим, то я уже даже участвовать в этом не буду, тут будет всё ясно и так )))
очень странно себя ведёте, ещё раз, вас берут не просто на работу в компанию, а на определённую роль. у работодателя в принципе могут быть свои причины платить вам как сеньору или как мидлу когда вы сеньор, это ни разу не критерий. в общем поработайте больше и тогда вы сами сможете на глаз отличать мидла от сеньора, повторять остальное из написанного выше не буду.
Такая же мысль. Хотя, я работал с людьми, которые больше 10 лет программисты, но застряли конкретно. И да, согласен про опыт, я 18 лет работаю, но самомнение лет 15 назад было гораздо выше. Чем больше знаю, тем больше понимаю, что есть куда расти.
— А кто вообще такой этот Джеймс Гослинг?
— Да, ты что! Это разработчик Java.
— Как наш Вася?
— Нет, наш Вася – старший разработчик.
А я для себя взял за правило - хотя бы один вопрос на простейший алгоритм нужен. Сначала 5 минут про основы, потом какой-то алгоритм: количество слов в строке, кратчайший путь, - что-то буквально на десяток строк, потом уже к хардкору.
Ну уж если мидл/сеньор, то какие-то основы алгоритмизации должны быть, иначе просто не комфортно работать - как будто на разных языках говоришь.
Минутка статистики. 2,5 года Senior, >100 собесов по этой позиции. Т.е. раз в 1-2 недели по собесу.
На этой планете существует очень ограниченное количество мест, где за 2,5 года человек может стать senior developer. Может, это ваш случай, но обладая столь интересным и всесторонним опытом, вряд ли бы вы опустились до обсуждения и классификации типов интервьюеров. Во-первых, это всецело дело компании, как вести процесс найма, и у нас нет морального права это подвергать насмешками. Это все равно, что прийти к кому-то домой в гости и возмущаться, что вас, например, просят одеть тапочки. Да, в России очень любят хейтить в IT, в теме собеседований. Но в конечном итоге, если не нравится - не идите в эту компанию, интервью - хорошая возможность познакомиться с компанией, ещё не поработав в ней. Во-вторых, в зависимости от задач, упор может быть на совершенно разные аспекты. И да, в некоторых компаниях действительно нужно понимание алгоритмов , это не просто faang мода. В третьих, как говорится, «не бывает скучных лекций, бывают скучные лекторы». В данном случае, дело не в том, что вас начали спрашивать про алгоритмы, или про какие-то технические тонкости фреймворка. Дело в том, как, и для чего. Одно дело, сухо озвучить условие задачи и в напряженной тишине ждать «единственно правильного» ответа, другое - быть в диалоге, по шагам идти к решению, попутно раскрывая много интересных моментов.
Думаю, что ваши первые 4 пункта - это попытка найти несколько причин, почему интервью плохое. При этом, в хорошем интервью, на самом деле будут эти же вещи, те же пункты 2, 3, 4, в некоторой пропорции, с перекосом в какие-то из них.
Как то немного негативный комментарий )
Про то как нанимать - дело компании: ну правильно говорите, их право просить хоть знание всех систем исчисления и решение задачек на эту тему... каждый тут может изощряться. Вопрос в статье - нужно ли так делать?
Про насмешки: не было такой цели - высмеять кого то, лишь указать на проблематику.
Про алгоритмы: я написал, что где они нужны - велком, но не надо циклиться на этом.
И конечно же, извиняюсь, если задел лично.
Даже, наверное, не немного, прошу прощения. Но посмотрите чужими глазами на свой текст: добрую часть его вы раскладываете по полочкам плохих интервьюеров. Это как-то совсем не вяжется с опытом в сотню собеседований. Совсем немного людей в мире проходят столько за всю жизнь. Вы получили колоссальный опыт, могли бы рассказать не о негативе, а о чём-то полезном. Советы, тонкости - про этому вас один абзац.
Ну насчет того, что "немного людей в мире проходят столько за всю жизнь" - ну это скорее вопрос желания и терпения, это могут все )
Сейчас вообще нет проблем проходить собеседования прямо пачками (если активно ищешь и хочешь уйти), у меня доходило до 4 в день... это дико выматывало, но опыт интересный )
Можно как раз в неотгуленные дни прямо плотненько пособеситься )
В целом, Вы правы, конечно, много минусов описал, нежели плюсов.
Однако, по каждому минусу можно логически прийти к плюсу.
В этом, наверное, основная суть статьи - не дать решение, а натолкнуть на размышления в эту сторону )
А зачем? Ну в смысле, вот я попробовал вспомнить, сколько собеседований я прошел скажем с 2004 года, до которого я фрилансил — и не смог назвать больше 20. То есть, было пять компаний за примерно 15 лет, и примерно три-четыре собеседования перед каждой. Не более. Это по своей инициативе, так сказать. Ну еще штук 20 вакансий минимум мне обычно прибегает за год с линкедин, например. Не все они подходят обычно, но на какие-то можно было бы и сходить.
И если вот сейчас вдруг будет нужно — я не смогу назвать 100 компаний (для определенности скажем в Москве), куда я планировал бы пойти собеседоваться. Более того, с ходу я их и пять не смогу назвать, пожалуй. А уж 100 — откуда такое количество вообще взялось, интересно? Ну если взять всех, кто предлагает похожие вакансии, и сходить со всеми пообщаться — ну да, 100 наберется, но опять же — а смысл? Вы совсем их что-ли заранее не отбираете?
Дорогой друг, давно ты на рынок труда не захаживал )
Зачем?
Ну как же зачем... надоело тебе на одном месте, стало скучно, хочется что-то поменять. Это логично )
Или ещё... устроился ты на свои 220К, сидишь года 3, тебе докинули до 250К и ты вроде как доволен - вот он рост (оценили по достоинству), а ты на рынке уже 350 стоишь.
Вопрос: "На 100К в месяц больше стоит того чтобы походить по собесам или нет?". Тут сам себе отвечай, нужно ли оно тебе или нет )
И если вот сейчас вдруг будет нужно — я не смогу назвать 100 компаний ...
Ну как то олдскульно так искать работу, самому искать конторы.
Просто открываешь резюме на hh и тебя бомбят каждый день рекрутеры.
Ты соглашаешься на собесы, ходишь (удаленно), кто -то по деньгам не подходит, где-то легаси много, где-то лид не понравился, где-то проект не зацепил, где -то ты не понравился )
И таким образом ходишь не на одно собеседование и сразу бежишь к ним устраиваться, а выбираешь самый сок )
В целом советую периодически похаживать, узнаешь и цену свою, и точки роста )
Не, вы немного не на тот вопрос отвечаете. Ну ок, надоело, или что-то поменялось, стало плохо, в это все я верю разумеется. Но зачем 100 собеседований? Где вы нашли те 100 фирм, куда вам хочется пойти поработать? Ну выберите те 5, ну 10, куда вам интересно, вы же опять же, их что, совсем не отсеиваете что-ли предварительно?
>Просто открываешь резюме на hh и тебя бомбят каждый день рекрутеры.
Меня и так время от времени бомбят. Это совершенно не означает, что я будут реагировать хотя бы на 10 процентов предложений и пытаться сходить туда побеседовать. Тупо потому, что они мне не нравятся сразу. Ну вот вы открыли резюме человека, и вы иногда сразу видите, что он вам не подойдет? Вот точно так же и с предложениями рекрутеров. Те же яйца, только в профиль. Тем более мир же тесен, я поработал с людьми, которые в свою очередь поработали на множество компаний — и я кое-что про них про многих знаю заранее, еще до их предложения. Ну да, где-то тут есть разница в опыте, очевидно.
>кто -то по деньгам не подходит
Так зачем для всего этого ходить по собеседованиям, если большую часть ответов можно получить от HR?
100 фирм искать не надо - они сами находят вас... тут без комментов.
Из шаблонных описаний типа:
Мы ООО "Газ и Тормоз" делаем классный транспортно-логистический продукт. У нас современный стек (стандартный на 90%, как и везде), классная команда (ну а как же), корпоративы (куда без них), гибкое начало дня (ну прям удивили), ДМС (стандарт практически) - приходи к нам работать.
Что из этого убедило Вас отсеять или принять приглашение от такой компании?
Второй момент: что вам толкового скажет hr?
Ну что вы узнаете про то как и кем ставятся задачи? Специфика проекта? Сколько легаси? Где границы разработчика - от взятия задачи, до отдачи (кто-то сам подготавливает релиз и сам выкатывает, где то только ветку релизную подготовить) ? Как осуществляется поддержка прода и кем (где то есть выделенные люди где-то SRE хотят из разработчика)?
Находят. Так я и говорю, что выбрасываю в корзину сразу 90% предложений рекрутеров. Я не знаю, может это моя особенность резюме какая-то, но примерно столько случаев, когда предлагают зарплату ниже, чем я уже имею. И даже сильно ниже. Или что-то совершенно левое по квалификации/стеку. Яркий пример был например фейсбук, который тоже предложил что-то такое, чем я никогда не занимался.
>Что из этого убедило
На данный момент — ничего. Это стандартное предложение, и я его скорее всего отбрасываю. Ну или задаю вопрос о зарплате — и почему-то в большинстве случаев ноунейм ООО сливаются, не сумев предложить те самые +100к к зарплате. Ну ок, я готов допустить, что я в другом месте зарплатной вилки — но вопрос же можно задать и сразу?
>ну прям удивили
Вот именно. А откуда деньги-то у них?
>Второй момент: что вам толкового скажет hr?
Знаете, в моей практике hr имеют свойство сильно недооценивать мои пожелания по зарплате. В большинстве случаев — потому что не умеют читать резюме. Там написано, что в 2005 я был тимлидом — а предлагают позицию разработчика с опытом 3-5 лет. Стоит ли пояснять, куда они при этом идут?
> (стандартный на 90%, как и везде)
Это например что? Вот у меня за последние примерно 10 лет поменялось примерно пять стеков. И на сегодня у меня стек Apache Spark, Hadoop, Oozie, Scala + Java + Groovy + SQL четырех разных диалектов + еще по мелочи десяток разных фиговин, каждая из которых вполне тянет на строчку в резюме. Везде уже так? :)
Откуда деньги у них?
Много разных контор: перво на перво Сбер ))) , есть крупные маркетплейсы (валдберизы, озоны, джумы и проч), есть промышленные разработки, логистические крупные, ретейл (возьмите X5Retail, МВидео, СпортМастер и проч).
Не знаю конечно ваших потребностей, но на 400К - 450К пойти можно.
То что Вы были лидом в 2005 не говорит, о том что вы не согласитесь на синьорскую позицию. Мой предыдущий Тимлид ушел на сеньора в другую компанию (и это был осознанный шаг, не в ущерб ЧСВ).
По стеку обычно:
Java + Kotlin + Spring + SQL + NOSQL + Kafka (или MQ) + бывает Hadoop
Судите сами, сильно ли у Вас отличается.
у меня доходило до 4 в день... это дико выматывало, но опыт интересный )
абсолютно бесполезная трата времени если вы не джун, которому всё равно куда - лишь бы взяли.
Ваше право, вообще не ходить по собесам и работать на одной работе - это совсем неплохо )
Не говорите глупостей. Если вы не джун - то прохождение сотни собеседований не имеет ничего общего с поиском работы :)
Я вполне допускаю, что это может быть хобби такое. Но если вы продолжите утверждать, что так ищете работу - то я присоединюсь к оратору выше с вопросом: "Вы что, вакансии вообще не фильтруете?"
Конечно, все эти типы часто перемешиваются, как и все в жизни редко бывает с точными границами, особенно, если речь о Людях.
Во-первых, это всецело дело компании, как вести процесс найма, и у нас нет морального права это подвергать насмешками.
Право есть у каждого, кто его не побоялся взять.
Это все равно, что прийти к кому-то домой в гости и возмущаться, что вас, например, просят одеть тапочки.
Возмущаться безграмотностью совершенно нормально.
Но в конечном итоге, если не нравится — не идите в эту компанию, интервью — хорошая возможность познакомиться с компанией, ещё не поработав в ней.
Познакомиться с компанией можно только поработав в ней. На собеседованиях все Львы Толстые, творящие нетленку, а на практике всё печально.
Нашли одну ошибку на несколько абзацев текста - и не преминули об этом заявить, ещё и красным выделить. Браво! Подзарядили ЧСВ?
Нашли одну ошибку на несколько абзацев текста
Я так и знал, что по остальным пунктам моего ответа возражений не будет.
Вас же правописание озаботило больше, чем смысл. Возражать особо не на что, по существу вы ничего не написали.
Право бывает разное, не только юридическое, но и моральное (что я отметил сразу). Человек может «не побояться», и критиковать подход компании. Никто не остановит. Очень многие действия не нарушают закон, но хорошими их не назовёшь. Человек просто занимает свою нишу. Как блогер Алекс Брежнев, выливший уже тонны грязи на США - такая вот манера продвижения. И есть, кто это смотрит. Да пожалуйста. Можно хоть закритиковать то, как компании ведут найм - вместо каких-то действенных предложений и ценных наблюдений. Действия говорят сами за себя.
Познакомиться с компанией можно на собеседовании. Мне, почему-то, приходится говорить очевидные вещи, но хоть какое-то представление о компании можно сделать по интервью. Потому что эти люди здесь работают. Хочется ли с ними работать? Насколько хорош процесс интервью? Дали обратную связь? Вовремя началось интервью? Здесь миллион моментов, наблюдая за которыми можно немало узнать о компании. Ну и можно прямо задать интересующие вопросы. На деле все может оказаться хуже, от этого никто не застрахован. Здесь, как и во всем, частое случается часто, редкое - редко. У плохих компаний плохие интервью, а у хороших - хорошие. Так чаще, чем наоборот.
В некоторых фирмах столько этапов собеседования, что можно получить ачивку в карму на сбор всех категорий интервьюеров
За время, что провожу интервью, только один раз спросил о том, как работает HashMap - хотел подтвердить свою теорию, что любой, хотя бы пытавшийся готовится к интервью, знает ответ. Подтвердил. Задачки на алгоритмы? Ровно также можно готовиться на leetcode.
Что спрашиваю вместо этого? Заковырестые места предыдущих проектов, распределенные транзакции, exactly once в messaging-е, observability, разные сценарии отказа, масштабирование как сервисов, так и баз, ну и то, что интересного вычитаю из резюме. Спрошу о видах тестирования и что-то об интеграционных тестах. По Спрингу - BeanPostProcessor'ы, по Спринг Буту - рассказать о написании стартера. По самой Java вопрос обычно один - поток стартует второй поток, а как потом этот второй поток остановить? На мой взгляд, senior в современной типовой java должен спокойно рассуждать на все эти темы. Большим плюсом будет наличие pet project'ов. Если что-то одно не знает или знает плохо (да хоть тот же Спринг, к примеру) - не страшно, т.к. толковый научится.
Перед тем, как составить этот список, немало времени пришлось порефлексировать, чтобы понять что мне нужно от будущих членов команды и как, потенциально, это можно проверить.
Правда, мидлов так собеседовать бесполезно и что с этим делать - хз.
100 собесов за 2,5 года получается? Автор часто работу менял или долго искал?
И опять в точку.
За последние 5 лет работал на 4 работах. Здесь средняя по больнице температура не очень имеет смысл - где-то очень быстро уходил, где-то на 2.5 года прилипал.
С какого-то момента реально ищешь долго (1 месяц последний поиск). Но это тоже логично: требования становятся выше к ЗП, к проекту, к компании, к лиду
Ну и в целом периодически похаживаешь без смены работы
"Вопросы могут быть такими: - назовите все примитивные типы в Java, сколько каждый тип занимает памяти, если не помнишь, то посчитай; - какие методы класса Object, стандартный вопрос (многие задают), но в данном случае нужно назвать все до одного, т.к. собеседующий реально за это запаривается и сидит считает."
Так это же простые вопросы. При этом есть немало практических задач, где знание этих вещей необходимо.
Автор хочет сказать, что это всегда можно посмотреть пои необходимости. И не нужно помнить наизусть.
назовите все примитивные типы в Java, какие методы класса Object
перечислить что-то - только кажется простым вопросом от того, что не взято в расчёт, что у людей ассоциативная память. На самом деле подобные вопросы, если их не вызубрить перед интервью, могут застать врасплох любого сеньора. Если же вместо этого дать список методов и предложить рассказать их назначение, то на вопрос в таком формате ответит намного больше кандидатов.
Восьмое число после запятой в числе пи назовете по памяти? Так это же простой вопрос. При этом есть немало практических задач, где знание этих вещей необходимо.
Или все же оставим кесарю кесарево, а справочную информацию - справочникам?
Абсолютно, в точку +1
"Восьмое число после запятой в числе пи назовете по памяти?" - если вы работаете в области, где вам регулярно нужно самому проводить вычисления с числом Пи с точностью не менее 8 знаков после запятой, то вы будете знать число Пи с такой точностью. При этом вам совершенно не надо будет зубрить его. Вы его сами запомните просто по той причине, что постоянно используете. И все.
Я согласен с тем, что не нужно специально зубрить базовые вещи. В этом нет смысла. Они у вас сами выучатся входе практики. Но мне странно слышать, что вещи, которые вы используете чуть ли не каждый день, у вас так и не получилось запомнить.
Поведайте, пожалуйста, как вы чуть ли не каждый день используете методы clone, notify, notifyAll, wait, finalize класса java.lang.Object.
Если вы работаете с каким-то фреймворком более-менее высокого уровня, типа уже упомянутого спринга, то вы скорее будете помнить его API, а API Object будете использовать чуть более чем никогда.
Правда, расскажите, что вы такое пишете, что вам каждый день нужно помнить, что и как делает wait?
Восьмое число после запятой в числе пи назовете по памяти?
3.14159265358, по памяти. Но практического смысла в этом нет.
По опыту, методы Object спрашивают чтобы плавно перейти либо на wait()/notify()/synchronize()/java.util.concurrent.*, либо на equals()/hashCode()/j.u.Map.
почему то вспомнилось,
в одной немецкой компании в вопросах для трейни/джунов
был вопрос как решать квадратичные уравнения через дискриминант
потому что спрашивать их особо нечего, а этот вопрос "показывал" как они учились в школе/институте
мидлам и выше - такой вопрос уже не задавали
Определите для себя, что критически важно именно для ваших задач:
- усиленное знание БД
- знание инфраструктуры и девопсерство
- алгоритмы
- жестокая многопоточка, которая у вас используется на каждом шагу
- понимание архитектуры как приложения, взаимодействия между системами
Вообще ничего из перечисленного. В первую очередь важно следующее:
в принципе, способность понять задачу
умение задавать вопросы по задаче
искать, выбирать, предлагать варианты решения
самостоятельно принимать решения
иметь представление о процессе разработки в целом. Например, если задача не достаточно хорошо прошла этап аналитики, то разработчик не впадает в ступор и не начинает делать фигню, описанную в постановке, а задает вопросы аналитикам или сам как-то исправляет эти пробелы. Или он понимает, что дальше задача пойдет в тестирование, будет показываться заказчику и он заранее может хотя бы в целом протестировать то, что сделал, или прикинуть как заказчик может отреагировать на такую реализацию
писать адекватный код, в котором можно что-то понять, от которого не тошнит
в принципе, здравый смысл, логическое мышление, аналитическое мышление и т.п.
В принципе, способность понять задачу - ну так се проверка... если человек 5 лет не понимал задач на предыдущих местах, то это патология )
Умение задавать вопросы по задаче - ок в целом, главное чтоб не как в армии - ответ должен быть такой как в голове у командира (любой другой - не зачёт)
Искать, выбирать, предлагать варианты решения - это полностью ок (5 группа так и делает обычно)
Самостоятельно принимать решения - отнесу к предыдущему.
Иметь представление о процессе разработки в целом - как это проверяете? Задаете вопрос: "Аналитик не доработал задачу или мы вообще без аналитиков, задача не понятна, что будешь делать? Писать эхинею или вопрос задашь?"
писать адекватный код, в котором можно что-то понять, от которого не тошнит - лайв кодинг в помощь, дружище (4 группа). Правда это не 100% гарант, как и все остальное.
в принципе, здравый смысл, логическое мышление, аналитическое мышление и т.п. - 5 группа
В целом не правильно значит донес я мысль. Хотел сказать, что в технические тонкости вдаваться нужно по принципу, что у вас в проекте критически важно, то и штудируете более усиленно... Здравый смысл и "наличие рук" - это некий дефолт, без этого всем будет плохо работать, проверять нужно, конечно.
Ну-у-у… А откуда вы знаете, что он их правда понимал? Если человек, как в вашем же примере, за пять лет сменил много мест, то на каждом у него уходило достаточно много времени на то, чтобы таки научиться понимать задачи. Потому что он мог знать инструмент, но не знать бизнес. Это нормальный процесс, от момента, когда задачи вам приходится разъяснять, до момента, когда вы их начинаете ставить сами для джунов. И время это бывает сильно разным, и обычно чем человек квалифицированнее — тем оно короче.
Проверить это умение иногда сложно, да. Но смысл в такой проверке есть, самый непосредственный.
Вы разработчик "старой закалки" (в хорошем смысле слова), который долго работает на одном месте, вник и может уже лучше менеджеров разобраться как работает бизнес (это здорово). Но таких немного.
Часто работодатель нанимает не абсолютно подходящего сотрудника (супер разработчика со знанием специфики конкретного бизнеса), а просто разработчика достаточного уровня.
Как вы в таком случае сможете его протестировать на правильность понимания ваших задач (особенно если это не просто накинуть новый параметр в метод) ?
Человек из маркетплейса пришел в кредиты крупному бизнесу - что вы хотите его спросить?
Нормативы ЦБ?
Спросить как понимает, что нужно сделать если бизнес хочет позволить кредитному менеджеру внести изменения в пред расчитанные кредитные условия, на основе изменившихся данных рентабельности собственного капитала?
И это решается тем, что в компании есть аналитики и актуальная документация.
И не надо человека мучить вопросами, если Герман прибежит и поставит тебе задачу, что ты будешь делать )))
Так ведь и сказал, что это очень сложно проверить. То есть, я согласен с тем, что это очень важно (и в моей практике именно это отличает хороших разработчиков от так себе), и на эту тему стоит обязательно поговорить и разговорить. Но готовой методики, как именно, у меня нет.
>Человек из маркетплейса пришел в кредиты крупному бизнесу
Не совсем. Скорее не так. Я сталкивался с тем, что получив задачу, разработчики не пытаются вообще понять, правильно ли они прочитали постановку. И какой смысл для бизнеса в этой задаче.
Если разработчик этого не понимает (а зачастую — и не хочет), то его потолок как раз и будет где-то в районе «накинуть новый параметр в метод». Не обязательно конечно прямо так — потому что люди, не желающие вникать в бизнес, все же вполне могут быть очень полезны, и решать сложнейшие технические задачи. Но им эти задачи придется формулировать кому-то.
Если разработчик этого не понимает (а зачастую — и не хочет), то его потолок как раз и будет где-то в районе «накинуть новый параметр в метод».
Вы сейчас рассуждаете как менеджер, а не как разработчик.
Вовлеченность в проект разработчика - прямая обязанность менеджмента, бизнеса.
Нельзя переваливать на технаря понимание бизнеса, да еще и в стиле - "Сиди и разбирайся, если что спрашивай."
Для вовлеченности в процесс и вникание в суть проекта нужно знакомить и привлекать заранее разработчика как равномправного члена команды (а не как "Я бизнес даю тебе Итищнику задачу - давай делай").
Организовывать встречи с разработчиком на тему, что мы хотим и для чего, почему так важно это и нужно к примерно таким датам (условно конечно). Потом аналитик (может с помощью разработчика) описать детально задачу.
То есть задача должна прийти от бизнеса не в виде:
"Хочу через месяц новый CRM" - комментарии здесь излишни
Ну, я наполовину владелец продукта, но ни разу не менежер, и не люблю этим заниматься, хоть и приходится. И потом, мы же про собеседования, или нет? Когда я собеседую (как технический специалист) — мне не все равно, как этого человека придется менеджить, даже если это буду делать совсем не я. Потому что если он не вникает в бизнес — это придется делать кому-то за него. Во всяком случае в мелких командах, где я работал много, это именно так.
Разве я говорил, что я планирую именно перевалить понимание на технаря? Я лишь говорю о том, что разработчик, понимающий бизнес, стоит намного дороже, и приносит больше пользы. И нанимая его в проект, я бы хотел знать, попытается ли он вообще разобраться, или же свалит это на аналитиков. Или просто сделает как понял, свалив проверку правильности например на QA. Так тоже бывает.
Ну, я наполовину владелец продукта...
Ну Вы к бизнесу очень близки.
Я лишь говорю о том, что разработчик, понимающий бизнес, стоит намного дороже...
Итак, когда разработчик в вашей организации начинает понимать бизнес, на сколько вы поднимаете ему ЗП ? На сколько он станет Вам дороже? Или он будет дальше на той же ЗП, но с мыслью что он теперь ценится Вами ?
Мне, наоборот, больше всего пригождались алгоритмы, пусть и простые, ещё знание модели памяти джавы. Вот со спрингом сталкивался совсем уж давно, а про SOLID никто никогда даже не заикался.
Помню, одно время, java приравнивалось к spring, hibernate, persostence. Сейчас, наверное, так же
Вопросы могут быть такими: - назовите все примитивные типы в Java, сколько каждый тип занимает памяти, если не помнишь, то посчитай; - какие методы класса Object, стандартный вопрос (многие задают), но в данном случае нужно назвать все до одного, т.к. собеседующий реально за это запаривается и сидит считает
Для настоящего сеньора такие вопросы вообще не вызовут затруднений.
В основном это решение алгоритмических задачек онлайн в напряженной атмосфере. Здесь обойдусь без комментариев - сами решайте, что по этому поводу думать.
Ну конечно в FAANG дураки сидят и проводят по 3 алгоритмических интервью.
К слову, я не махровый кодер, в разработке около 5 лет, на позиции Senior всего 2,5 года.
То что ваша должность называлась Ведущий специалист не делает вас Senior developer. Это просто специфика нашего банковского и около государственного сектора
Я понимаю, что это обидно... на первой работе у меня был архитектор в 27 лет, который вырос из java разработчика... чувства были не самые приятные и куча мыслей...
В целом, конечно, Вы правы. Тут даже спорить смысла нет. Я всецело согласен с тем, что у меня так называются должности. Фактические же мои знания могут не соответствовать понятию даже мидла в гугле, амазоне, нетфликсе.
Компании у меня - разные банки и логистические. Госуху боюсь.
В FAANG не дураки. Они ищут, так как считают нужно именно их компании.
Дураками скорее называть стоит тех, кто не понимая своей потребности, пытается перенять эту практику (без осознанного подхода).
То что ваша должность называлась Ведущий специалист не делает вас Senior developer
Вообще-то именно это и делает. Да, в мире розовых единорогов звание синьора выдается межгалактическим магистратом в присутствии представителей всех разумных цивилизаций. А в нашем реальном мире если контора вписалась платить тебе как синьору - значит для нее ты синьор. Если другая контора не готова на такое, то для нее ты не синьор.
В условном "Смоленском банке" ты можешь называться ведущий эксперт и получать вот такую зп и выполнять работы по добавлению новой ручки или кнопочки. Но при этом люди начинают действительно себя считать серьезными специалистами, обесценивая значение этой должности
Я всегда прошу код писать. Выбираю простую задачу, близкую к бизнесовым. Хоть посмотреть как человек обычный продакшн-код пишет. Это же должно на автомате делаться. Ну и дальше по ней можно поспрашивать - зачем тут хеш и как работает, какая сложность алгоритма. Докинуть требования и посмотреть как рефачить будет.
А то современные «сеньеры» часто алгоритм на цикл и if - прям через муки пишут. А для такого мозг вообще не должен включаться, и писать надо с первого раза в code style и без багов - чтобы время было думать про архитектуру и планировать что дальше.
Всем, кому зашла статья, большое спасибо за поддержку, за терпимое отношение и способность взглянуть на ситуацию с разных сторон )
Цель статьи была - поделиться мнением, а не самоутвердиться )
Всем, кто докопался к слову Senior, решил развести холивар в субъективщине и самоутвердиться - не то место выбрали (пишите не язвительные коменты, а раскопайте в Java, то что докажет ваш уровень, и опишите в своей статье).
остался только один вопрос: почему у вас было аж 100 интервью? не берут на сеньёра? :) кстати что предлагают и какой фидбек? просто время на это всё надо не мало
Вопросов у Вас осталось не один, а целых три )))
Первое - 100 за всю мою карьеру, т.е. это не в моменте.
Второе - за те деньги, которые я прошу многие не берут - что есть то есть (извините я нескромный).
Последний поиск закончился 5 офферами на желаемую сумму - был выбор, и сначало я думал уйти в одну контору, но получил еще оффер - и он стал моим выбором. Не зря ждал и собирал офферы )
Насчет того, что предлагают - открою Вам тайну... тсс... есть портал hh - там можно за 5-10 мин всё узнать ))) А если на это нет времени, то и менять работу не надо )
как по мне, статья упрощает действительность. мне понравились ответы некоторых авторов - remal.
я много собеседовал и нанял пару десятков непосредственно в свои команды. несколько раз ошибался в людях. причем ошибки след. плана. человек доскально решает задачи. leetcode, hackerrank... наверно нужно просто просить их логин и смотреть на рейтинг. вообщем мыслят аналитически, графы, деревья, из восмиречной в 64ую систему в уме... уровень бог. не к чему придраться. а берешь на работу и чел теряеться в двух строчках кода. пишет свои структуры данных, или прикручивает спринг там где он не нужен. полное отсутствие понятия еко-системы. не знает простейший gradle... тоесть человек привык решать сложные задачи на одну страницу кода. а смоделировать финансовый инструмент в коде и базе данных или банковскую операцию от начала до конца в упор не может. и тут проблема. вроде все знает в теории а на практике бесполезн.
можно спрашивать архитектуру но важно понять на какую роль и проект идет человек. даже хороший специалист, при неправильном применении задерживает заказ и не дает отдачи.
есть еще отдельная, узкая категория ... это мега разработчики которые любят поспорить или сказать что он слишком крут для такой проблемы и смотри в его гитхаб и тд.
для senior, я склоняюсь к интервью и испытательному сроку в 90-180 дней что бы разобраться в человеке, можно по удаленке. многие разработчики интроверты и не способны полноценно думать/отвечать в режиме интервью. я сам в этой категории. очень важно способность и желание самообучаться
для senior, я склоняюсь к интервью и испытательному сроку в 90-180 дней
Senior явно не главбух, так что не более 90.
ТК РФ, Глава 70
Срок испытания не может превышать трех месяцев, а для руководителей организаций и их заместителей, главных бухгалтеров и их заместителей, руководителей филиалов, представительств или иных обособленных структурных подразделений организаций — шести месяцев.
Senior Java Developer — как проходят собеседования