Pull to refresh
0
0
Николай @Nikolino

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

Send message

Спасибо за столь развернутый комментарий. Хотелось бы почитать вторую и другие порции исправленных неточностей (на ваш взгляд), указанных в статье.

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

Тестовые задания уважающие себя сеньоры делать будут не всегда, чаще не будут. Вместо этого потратят свое время на собесы в другие компании, в которых оффер получат и без тестовых заданий. Компании «мечты», всякие FAANGи, Яндексы и т.д., тестовые задания не дают, но там и свои минусы, это куча этапов, которые могут растянуться в месяц и большое кол-во алгоритмических задач малоприменимых в дальнейшей работе.
Сертификаты можно накрутить нагуглив или заучив ответы. На собесах же, часть вопросов задают на «подумать», единственно верного ответа на которые не существует.
Перед собесом в ту компанию, в которую хотите попасть, можно пройти два-три собеса в те компании, которые менее интересны и в которых работать не хотите. Тогда на собесе в «компанию мечты» ступора будет меньше.
Проделывать это нужно каждый раз когда собираетесь менять работу. Полезно даже если не хотите менять работу. Те вопросы, которые вызвали «ступор» на «тренировочных» собесах нужно подучить (например, наделав карточки в Anki). Как вариант, записывать экран при собесе и позже разбирать, чтобы не забыть те вопросы в которых поплыл.
недавно открыл для себя сочетание клавиш в продуктах JetBrains, которое использую чаще остальных в проектах с большим кол-вом кода. Судя по общению с коллегами, не все его знают.
ctrl+alt+left
Когда вы, читая код, проваливаетесь внутрь через ctrl+click, сочетание «ctrl+alt+left» позволяет вернуться на один уровень вверх именно на то место, в котором нажали ctrl+click. Если закопались далеко вглубь, то жмите сочетание несколько раз пока не вернетесь туда откуда начали проваливаться.
Emprove
вы используете Docker на проде?
какие сервисы из AWS вы используете? и сколько по итоговой стоимости получилось с сервисами AWS? По-моему хватило бы минимального по мощности VPS от того же Digital Ocean за $5/month.

«Роутинг кастомизировал и вынес файлы роутов из единого api.php, т.е. один файл, один роут.»
Зачем?
Ничего не сказано про тестирование моделей. А ведь туда уходит часть логики связанная именно с моделью: асессоры, мутаторы, кастинги ($casts) определенных полей, наличие полей в $fillable, relations и т.д.

Дополню тему этой ссылкой: github.com/framgia/laravel-test-guideline
По моделям там вполне исчерпывающе.

Вижу, что используется camelCase, но на мой взгляд, читается он хуже, чем snake_case, особенно в feature тестах, где тестим какую-то бизнес-логику. Авторы Laracasts используют snake_case.

Сравним:
public function test_if_total_spent_kcals_changed_after_adding_exercise() {}
public function testIfTotalSpentKcalsChangedAfterAddingExercise() {}

Вроде есть PSR-2, но по-моему очевидно, что для длинных названий методов тестов лучше не следовать camelCase.
У меня в трудовом договоре (и в книжке) «инженер-программист», а занимаюсь back-end'ом.
«Ведущий программный инженер» это менеджерская специальность (Engineering Manager), и сложно её перевести на наш рынок труда.
Rockstar разработчики обычно понимают, что их везде возьмут за высокую зарплату, поэтому зарплата не решающий фактор. Решающий фактор для них, пожалуй, интересные проекты и свобода. Если менеджеры будут пытаться «рулить» такими «рок-звездами» дедлайнами и другими ограничениями, или давать неинтересные проекты/задачи, то самые талантливые сбегут.
Да и сомневаюсь, что нужна вся команда таких вот талантов. Основной состав должен приходиться на «линейных» разработчиков, так сказать «средней руки». Они более исполнительные, поэтому их легче менеджить.
Из поста не совсем понятно, это ваш личный подход («я художник, я так вижу»), или подход компании?
Возможно в вашу же компанию и устраиваются как описано выше, а такой, весьма избирательный подход к отсеву резюме только у вас? Вы не сравнивали вашу воронку с результатами поиска кандидатов ваших коллег?
«Superstar» имелось в виду исключительно с позиции Додо, может им нужен какой-то разработчик с определенным экзотическим набором soft-skills. А суперстару в обычном понимании (разработчику с известным именем в индустрии, участнику крутых open-source проектов, конференций и т.д.) вообще рассылать резюме смысла нет. Его будут пытаться схантить, даже если он не давал понять, что рассматривает предложения.
Если нужен один superstar разработчик, то такая воронка, возможно и подойдет. А если нужно сформировать команду еще «на вчера», а новых резюме не присылают? Тогда с каждой повторной итерацией можно чуть снижать требования к резюме, пробегаясь по ранее отбракованным «скучным» резюме, приглашая новых кандидатов на интервью, в итоге планка опустится до средних резюме по рынку.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity