Обновить
53
6.6

Пользователь

Отправить сообщение

И здесь возникает знакомая многим дилемма выбора маленькой или крупной компании. В первой специалист, как правило, может получить семейную атмосферу и большую компенсацию сразу, зато вторая почти наверняка даст солидные возможности для обучения

Во-первых, кажется, что вы сами себе противоречите. Абзацем выше писали, как попали в маленькую компанию из 20 человек и попали на хардкор. А теперь вдруг маленькая компания - комфорт и большая компенсация.

Во-вторых, по моему опыту все ровно наоборот. В мелком стартапе надо впахивать на трех ролях сразу за ценник ниже рынка. Зато умеешь потом вообще всё. Работая же в гиганте, можно за солидные деньги плевать в потолок.

В разработке нужно думать про «устойчивость»: создавать простые решения, использовать минимум ресурсов. Если решение запускается на одном сервере, то стоит в будущем полагаться на оптимизацию, меньше полагаться на избыточные технические возможности масштабирования. Решения живут достаточно долго, поэтому на момент их разработки, за счет минимизации негативного влияния, например на экологию, можно внести свой вклад в «устойчивость» всего  проекта и компании, – говорит Владимир Мигуро. 

Миллениалы изобрели оптимизацию

По сути единственная полезная информация - разрез по сферам деятельности. И то по большей части напутано теплое с мягким. Можно подумать, например, что high load и e-commerce какие-то ортогональные вещи. Еще подозрительнее разделение embedded и IoT.

Все остальное без революций. Более скилловым и усидчивым платят больше - неизменный принцип со времен появления оплаты труда как таковой.

Даже странно, что не со стороны сбера инициатива. Это же так в их стиле: перегреть рынок труда, охренеть от собственных размеров ФОТ и придумать вот эту мерзость.

А из нищеты и берутся. Пока не можешь хапать - работаешь более-менее честно. Когда можешь хапать - хапаешь. Нищета рождает коррупцию, коррупция рождает нищету. У меня есть теория, что все наши проблемы связаны с тем, что у "уважаемых людей" было нищее детство с прибитыми к полу игрушками. Выросли - стали хапать в качестве компенсации.

Если прийти в любой ТЦ в 5 утра или в 11 вечера, то тоже можно сделать вывод, что вы тут один. Но если простоять там с 5 утра до 11 вечера, то мимо вас пройдут тысячи человек. По-моему, это самый очевидный ответ на парадокс Ферми - ничтожное по меркам Вселенной время наблюдения.

Мне кажется, все эти "достижения" (распознавание лиц, фокусы с нейросетями) однажды будут запрещены международной конвенцией так же, как запрещены сейчас химическое оружие, кассетные боеприпасы и экспансивные пули. Когда-то это все тоже было достижением инженерии и вызывало восторг в определенных кругах. Вопрос, понадобится ли для этого глобальный катаклизм.

Да скорее не восторг, а чувство "жизы". Многим знакома ситуация, когда ты лишь раз упомянул джаваскрипт в своем резюме бэкендера - и в тебя уже летит пачка "вы нам очень интересны на позицию ведущего реакт-разработчика". Ну а тут по классике абсурдность создает комичный эффект.

Может быть в России более грамотно подходят к подбору персонала и читают резюме от корки до корки, а алгоритмы подбора умнее, как считаете?

Если повторить описанный трюк, то, готов поспорить, легко заинтересуешь и пройдешь первичное интервью в половине наших компаний. Шутка юмора раскроется только на техническом собесе. Высока вероятность, что отошьют в маленьких конторах. А вот сбер какому-нибудь синьор-помидор девелоперу будет на голубом глазу с утра до вечера письмами спамить.

В статье можно заменить "разработчик" на любую другую роль в команде - и общий посыл ни на йоту не изменится. Потому что должна быть синергия и взаимопроникновение опыта. Что бывает редко.

Но я не вижу статей вроде "как стать отличным аналитиком и начать писать ТЗ, а не филькины грамоты". Вместо этого зачастили статьи, где учат жить разрабов, причем довольно топорно.

я не утверждаю, что паттерны проектирования безусловно необходимы, и что если человек не прочитал паттерны Банды Четырех, то он не может называться разработчиком

От вас, кажется, ускользнуло главное. Паттерны не то что "нужны или не нужны". Они просто есть. Есть ряд стандартных задач - есть ряд стандартных решений. Даже если кого-то трясет в негодовании от одного слова "паттерны", то это ничего не меняет. В коде таких людей тоже гарантированно есть повторяющиеся приемы. Просто умные дяди GOF эти приемы обобщили.

Ну и по теме. Утверждать после одного лишь чтения, что вы что-то "качественно изучили" это несерьезно. Паттерны - сугубо практическая тема. Книга тут лишь отправная точка и толчок к размышлению.

Вы правы, никому. Операционные системы давно уже пишутся сами, а штуки вроде Кубера, Кафки или Кликхауса аист приносит.

Вам следует перестать "учиться", варясь в собственном соку, и пойти искать работу. Если это ваша цель, конечно. Находясь в изоляции "обучения" зачастую очень трудно осознать, что и основы языка так себе, и SQL не особо хороший, и магазин на спринге имеет корявое апи и ужасную архитектуру. Но вполне вероятно, что у вас все отлично, я лишь предполагаю из своего опыта. No offence, как говорится.

Ошибаетесь. Мистер Гейтс уже в 20 лет был крепким системным программистом. Сейчас такой парень в наших реалиях уже имел бы всевозможные стипендии от всяких Сколтехов и выбирал бы работодателя из списка тех-гигантов. Галеры его бы просто не интересовали.

Если что и нужно, то это это научиться с первых минут определять кадров, которые строят все интервью на бестолковой банальщине. И не тратить на них свое время.

Технические собесы, конечно, нужны. Хотя бы потому, что мы технари. Но их нужно уметь проводить.

Спрашивать по сотому разу разницу между реализациями листа - значит не уважать ни себя, ни кандидата, ни свое рабочее время. Это иногда напоминает протокольные разговоры о погоде в карикатурном представлении о высшем свете.

У тебя на проекте есть стек технологий и есть стек задач. И у кандидата был стек технологий и стек задач. До сих пор кажется, что не о чем поговорить, кроме линкед листа?

Допустим у тебя Kotlin + Spring + Postgres + Kafka. У кандидата Java + Camel + Oracle + ActiveMQ. Да здесь тупо по сравнительному анализу технологий и их применимости уже разговоров на час. Простой вопрос "в чем разница между kafka и activemq" может невероятно много рассказать о кандидате. Вот хотя бы читал ли он что-то о вашей кафке или надеется "приду - научат".

Но нет. Нам ведь лень читать резюме и вникать в персону кандидата. Лень придумывать вопросы, исходя из контекста. Давайте лучше на всякий случай про линкед лист уточним.

Распространенная проблема № 1: поспешный переход к написанию кода

На одном из интервью в 2012 году я стал свидетелем того, как такое недостаточное планирование серьезно подвело претендента

можно потратить слишком много времени на проектирование структуры кода

Господа, вы или крестик снимите или трусы наденьте. Планирование и проектирование - это то, чем люди занимаются в свои трудовые будни. Это все в человеко-часах и в человеко-днях измеряется обычно. Причем зачастую все и начинается с поделки из клея и желудей, а потом итеративно доводится до ума.

Вы ждете того же самого, но за 15 минут и применимо к очередной дурацкой задачке с литкода? И еще и пеняете, что человек в стрессовой ситуации делает не то, что вам нравится?

Верно, в итоге причина была в "не интересно",. Однако у взрослого человека есть опция спокойно уволиться, если не интересно. К сожалению, люди и не увольнялись и не работали. Просто нахаляву пару зп получили и дальше пошли кому-то голову морочить.

У меня сложилось впечатление, что проблема "взяли - а он не шарит" возникает только с джунами. Чем выше грейд, тем выше риск проблемы "взяли - а он штаны просиживает". В течение 2021 года дважды нанимал вполне опытных людей и наблюдал производительность "1 коммит в неделю". И тут вообще не просматривается существующего решения.

По опыту пройеднного цикла собеседований (сентябрь 2021) зачастую компания "средней руки" легко перебивает предложение "топов". Исключение - Зеленый гигант. Его не перебьешь ничем.

Информация

В рейтинге
827-й
Зарегистрирован
Активность

Специализация

Бэкенд разработчик
Старший
Java
Kotlin