• Я единственный из 1400, или самый крутой рекрутинг, что я проходил
    0
    Хорошо, допустим всё так «просто». У вас есть 2 кандидата делающих тестовое задание. Один выбрал юнит тесты, второй решил что хватит функционального тестирования конечного рендеринга таблицы. Один решил отрендерить html через движок шаблонов типа jinja, второй — через какой-то pyhtml. Один решит что перед ним типовая задача и ПРОСТО прочитает файл в память, чтобы работать с ним как-со строкой, второй будет читать построчно(побайтово), подумав, что его проверяют, сколько потенциальных проблем он может найти. Один решит что стоит использовать mmap, другой что нет. Один сделает дотошную обработку ошибок и дотошную ловлю всех исключений, другой — решит что и так сойдет(и судя по тому как работает 90% софта так оно и есть). Таких развилок можно еще кучу найти, вплоть до того что код написан в недостаточно python way. Но оба кандидата решает вашу задачу.

    Всё ещё думаете, что это не качнет ваши, конечно же объективные критерии выбора, в пользу одного из кандидатов? Кстати независимо от ваших критериев и их объективности чьи-то потреченные часы уйдут на свалку. Второго кандидата я добавил, чтобы вам не пришло в голову сказать, что мол из-за таких-то мелочей не брать человека.
  • Я единственный из 1400, или самый крутой рекрутинг, что я проходил
    +44
    4) задание «fuzzy» — сказано, что должно быть в итоге, но как это получить — кандидат решает сам; мы оцениваем, насколько кандидат умеет здраво мыслить и понимать требования клиентов


    Каждый раз когда я встречаю задание в таком стиле, я извиняюсь что оно слишком сложное для меня и иду гулять. Потому что задания с открытыми вопросами обычно проверяют не вашу здравость мышления, а то насколько вы мыслите также как и автор задания. Я могу всрать 5 часов на идеальное выполнение задания с линтером, тестами, комментариями, только для того чтобы выяснить что здесь обязательно должен быть применен такой вот паттерн а не этот. А применен он должен быть потому что на проекте автора задания это сработало, и по-другому и быть не может. И от подробного фидбэка толку ноль в таком случае, потому что суть фидбэка — мы в нашей компании работает вот так, но как — заранее не скажем.

    Даже лайвкодинг и построение иерархии классов на словах проще пройти(при условии что вы не испытываете стресс в таких ситуациях в принципе). Потому что на это потребуется полчаса и фидбэк будет мгновенным. На тестовое задание потребуется день, даже если на словах оно на 3 часа, потому что его нужно оформлять лучше чем 90% кода, что пишется для реальных проектов.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    0
    Так фичи и фичи + продумывание архитектуры + тесты — это разное время и объем работы. Время работы и сумма обычно в контракте оговаривается. Качесто кода — нет. Если вы начнете его обговаривать и повышать сумму, то контракт скорее всего заключат не с вами. И на крупных проектах все даже хуже порой — там положим деньги дать готовы, но сроки для больших проектов берутся с потолка, а уровень программистов(если это гугл), как правило, ниже чем в небольших командах, можно сказать дно, если это глобальный аутсорс. А это делает сроки еще менее предсказуемыми.

    На мой взглядл, среди всех препон, мешающих писать тесты, плохое качество кода находится на последнем месте.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    0
    Ну знаете, как только мы вступаем на скользкую дорожку вычисления вероятности в субъективных предпочтениях, можно додуматься, что каждую ночь человеку снятся гномы с лицом Fabien Potencier одетые в футболки с логотипом Symfony, и щекочут несчастного.

    Обычно всё гораздо прозаичнее
  • Как и почему я перестал покупать новые ноутбуки
    0
    У вас в расчетах не учтена стоимость гражданства страны, где ноутбуки оставляют у мусорок.
  • Так какими же должны быть идеальные шахматы?
    0
    Идеальные шахматы — это когда по однут сторону шахматной доски сидит Збигнев Бжезинский, а по другую — голубь. И каждую партию они сводят в ничью.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    0
    Никаким образом не мешает. И статья не об этом. Она о неуместности оверинжиниринга из явамирка для большинства проектов на PHP.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    0
    Я вам немного про другое. Допустим вам не нравится Laravel, но попался очень вкусный проект на нём. В процессе собеседования вы демонстрируете достаточные знания фреймворка, но на вопрос о предпочтениях замечаете, что предпочитаете Symfony. И тут вашего собеседника передергивает, и он вам говорит, что мол нет, нам такие бойцы не нужны. Подразумевая, что ему нужны люди, которые живут Laravel и дышат им. При это вы понимаете, что смогли бы с легкостью писать по ларавеловской доке и копировать уже имеющийся код стайл проекта, потому что этот фреймворк уже даже не пятый по счету в вашей карьере.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    –1
    Нет, ну а вы видели-то докладчиков этих?
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    –1
    А в чем особенность Японии в этом плане?
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    –2
    Ну куда же вы, я же еще не успел добавить сакрального «да там же работы на полчаса»!
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    0
    Для формирования команд программистов, которые страшные индивидуалисты в массе своей — плохо. Для поиска жены или воспитания детей — отличная стратегия.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    0
    Laravel выглядит как удачная попытка махнуть рукой на усилия перетащить слабую часть сообщества на бест практисес. Для меня названия классов и их иерархия контр-интуитивна, но значительной части коллег нравится. И если отбросить вопросы именования, то в Laravel действительно хороший набор компонентов для типовых задач.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    +5
    Код только ради конечного результата остался где-то в 60-70-х годах


    Теперь это называется MVP.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    0
    То что вы пишите, звучит разумно, но тут все глубже чем формальные методики типа код стандарта или подхода к организации кода, именованию классов и т.д. Люди хотят чтобы ты думал как они, восторгался тем же чем восторгаются они, разделял их точку зрения, а не просто соглашался с ней для кооперации.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    +8
    Я вас умоляю! Наша токсичность абсолютно непродуктивна, потому что у нас в культуре неявно прописано, что кто неправ, тот лох; если ошибся, то могут спросить. Не так грубо как в подворотне и не прям в таких формулировках как я описал, но все это исподоволь проникает в наше сознание через воспитание, массмедиа, быт. И если в западных командах, когда я поднимал спорные вопросы, мне приходилось преодолевать только административное сопротивление, то в снг-командах каждый тянет одеяло на себя и противоречит чисто из синдрома вахтёра.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    0
    Проблема в том, что слишком категорично. На любой вкус — это аутсорс в непонятный проект. СНГ-шные команды это 2 крайности, либо говнокод, либо «SOLID или смерть».
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    –18
    К сожалению я недостаточно умён, чтобы его заметить. О моём низком уровне интеллекта также свидетельствует то, что я опускаюсь до прямых оскорблений.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    +3
    Вы верно заметили про разрыв между квалификациями и часовую ставку. Вполне вероятно что все 4 раза подряд вы имели дело с субподрядчиком с неприятным гортанным английским, получающим в 3-10 раз меньше, чем ваш прямой подрядчик. На одеске и прочих подобных местах это классика.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    +34
    Вы хотите использовать переменную, но делаете это без уважения?
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    +1
    Это решается даже традиционными для всех языков способами — демонами, разгребающими сообщения и FastCGI.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    –12
    Современные PHP-конференции(и в т.ч. подкасты) — это мероприятия, где ораторы собираются в кружок и надрачивают друг другу ЧСВ. Что прямо говорит о пошлости данных мероприятий, и косвенно — об ориентации ораторов на этих мероприятиях. Боюсь, что если бы я честно написал о наших PHP конференциях, то хабр не пропустил бы это порнографию.

    В ваших цитатах моего текста я противоречия не нашел. И независимо от того, кто из нас дурак, сомневаюсь что мы друг другу что-то докажем.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    +9
    $ всё ещё нужен.
  • PHP коммьюнити в СНГ. Было плохо — стало хуже
    +25
    Примерно на 6 из 10.
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    +1
    Компания предоставляет квартиру — на деле это жуткий клоповник, в котором жить невозможно.
    Начальник отдела под управлением которого вы будете работать может быть неизвестен до последнего момента и оказаться индусом в плохом смысле этого слова.
    Да на вас просто смогут давить как захотят — потому что ваша альтернатива это собирать манатки и возвращаться в родной мордор, в котором 10 человек на низком старте уже готово занять ваше место.

    Конечно, топовых специалистов это обычно не касается, но вы точно топовый?
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    +1
    Не можешь. В двух последних компаниях в США, где я работал, отзывы на гласдоре были отвратительные, при этом я вспоминаю их как одни из лучших мест работы. Сами сотрудники, особенно в тех же США, особенно те кто повязаны контрактом и визой, боятся говорить нелицеприятную правду о своей компании. Так что ты никогда не узнаешь до самого последнего момента всех «приятных» особенностей.
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    +1
    Если тебе так плохо у работодателя что ты не можешь работать на него 2 года, то зачем ты вообще к нему пошел?


    Очевидно потому что никто не говорит тебе что будет там, когда ты переедешь. А ты уже потратился на переезд.
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    0
    Дайте угадаю, а «толковый специалист» — это такое рекурсивное определение, которое подразумевает, что если специалист толковый, то он получает столько сколько местные. А все кто не попадает под определение — нетолковые. И это можно было воспринять всерьез, если бы я не видел кучу примеров когда рядовых формошлепов релоцируют внутри компании и они там сидят как мышки, и молятся, чтобы им продлили визу. А сколько народу релоцируют по анальным контрактам и визам привязанным к конкретному работодателю можно только догадываться.
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    0
    Я-то положим его когда-нибудь познаю, но как быть с необучаемыми людьми, что пишут фразы-заголовки из моей статьи и надеются на правильное восприятие того, что они сказали?
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    –1
    Нет нужды ничего разбирать, судя по вашим комментариям к статьям Собеседование на миддла за деньги, после которого я готов идти джуном за еду и Вы безумны, остановитесь пока не поздно, вы как раз из тех о ком моя статья.
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    0
    Это уже немного из другой оперы, то чего хотят от взаимотношений в рабочем коллективе вообще словами не передать. Можно только прийти самому и почувствовать, надо оно тебе или нет.
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    0
    В смысле субъективщины? Я вполне конкретно прошу писать объективные факты, а не субъективные типа «мы платим достаточно», «кандидаты ничего не знают», «у нас рыночная зарплата».
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    +1
    Да, и многие работодатели этого не понимают. Но скорее не хотят признавать, ведь то же самое есть и в других отраслях, где у хороших кадров есть хоть малейшая возможность уехать в ту же Москву.
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    +2
    Все не так просто. Куча вариантов релокации предполагает, что ты несколько лет сидишь на зарплате ниже рынка, и потом может быть получаешь гражданство. Другие причины для переезда — так они для каждого другие. А деньги можно выразить в цифрах.
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    –2
    Если не видите в чем в описанных ситуациях недоговорки и двойные стандарты, и даже не встречали подобных примеров, то эта статья просто вне вашего интереса. Столкнетесь — поймете, не столкнетесь — да и слава богу. Покормил.
  • Пишите зарплаты, траты и чего вы хотите. Или не пишите ничего
    0
    разве ваша статья не построена на ваших пожеланиях (хотелках), которые сформировались очевидно из личного опыта наблюдения «несправедливости» в мире также через некоторую призму.


    Раз моя статья о недоговорках и двойных стандартах, то почему бы мне самому в качестве примера, который вы просите, не использовать применение разновидности двойных стандартов. Вот вам и ответ на ваш вопрос и пример.
  • JAM-стэк — нищета на стероидах
    0
    И в том хорошем кейсе автору намекнули о проблемности такого подхода:

    habr.com/ru/company/e-Legion/blog/440134/#comment_20004358
    habr.com/ru/company/e-Legion/blog/440134/#comment_20007458
    habr.com/ru/company/e-Legion/blog/440134/#comment_20012014
  • JAM-стэк — нищета на стероидах
    0
    Только безопасность! Никаких ЯП на проде. Сечин вас не покормит колбаской, если там разместят хукеры что нибудь из, естественно, Украины. Эта единственная причина, которая затирает все остальное.


    Это легко достигается решениями типа Jekyll.

    С таким рылом на собеседование не завалишься. Я тут чувак из старой школы, вы тут все просто хайпуете и даже если я на 100% прав это не является критерием. Новое хуже не значит хуже для всего. Лучше для вас, в качестве опыта, только из-за новизны.


    Это уже тема взаимоотношений при найме и на работе.

    Во первых, 20% вам… как в том анекдоте… а почемы бы и нет раз есть бабки? Чо толку то предыдущий опыт обсусоливать?


    Абырвалг?
  • JAM-стэк — нищета на стероидах
    0
    Не обязательно так радикально идти в какую-то сторону.


    На данный момент JAM и является достаточно радикальным решением при наличии традиционных и технически более удачных.

    Например можно взять несколько решений и объединить в одно, напрмер cms + сторонний сервис для медиа контента, или сторонний полнотекстовый поиск.


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

    А бэкэнд в любом случае делается под фронт. Например если для открытия домашней страницы нужно сделать 20 JOIN операций, то это точно ни к чему хорошему не приведет. Но в JAM подходе мы можем разбить один большой монолит бэкэнда на отдельные сервисы


    В JAM подходе вы никуда не денетесь от алгоритмической сложности 20 джойнов, если они нужны. Задолго до JAM существовали WSDL и RPC, даже задолго до того как все стали носиться с микросервисами. Кто хотел, тот пользовался.

    А эта проблема была изначально: представим что нам нужно передать состояние с бэка на фронт. Это будет либо через глобальные JS переменные записанные в script тэги, либо через data-* атрибуты прямо в DOM элементы. Тогда придется работать с одной и той же логикой в темплейте, записывая туда данные с бэка, а затем на фронте. Это очень плохо масштабируется и поддерживается, а при использовании UI фреймворков становится совсем тяжело из-за того что они берут на себя рендер страницы. В случае server-side rendering этот процесс происходит автоматически, и DOM дерево построенное на сервере совпадает с DOM деревом которое построит клиент, а значит с ним можно работать без дополнительных обработок глобальных переменных и data-* атрибутов, а самое главное что это происходит автоматически.


    Описанное вами — скорее проблема роста сайта, который изначально не был рассчитан на сложный фронтенд. У нее нет хорошего решения, потому что либо вы оставляете минимальный фронтенд, либо вы переделываете все в угоду фронтенду. Если изначально у нас есть бэкенд, который только отдает данные, но не рендерит, то проблемы нет. Но вот вопрос, в каком проценте случаев, особенно если речь о нижнем сегменте фриланса, куда пихают JAM, нужен этот серьезный фронтенд?

    Тут уже вопрос поддержки legacy кода: фиксировать версии плагинов jQuery или скачивать их на свой хостинг. Новые же страницы на Vue/React не будут страдать от таких проблем с поддержкой.

    Это опять вопрос к работе с legacy на jQuery, сейчас все компоненты для react/Vue/angular ставятся через npm, где можно зафиксировать версии и где есть уверенность в том что версия не будет удалена. Версия npm не влияет на сборку (кроме версий <5, из-за package-lock), но его можно обновить через него самого. У того же gatsby версии node поддерживаются все корторые обозначены как lts, и бинарные зависимости скорее всего для них уже будут собраны.


    Типичная проблема — у вас есть сайт на не новом реакте, где используется куча библиотек, завязанных на эту версию, обновлять её сейчас дорого. Но вам нужно срочно добавить новую юиблиотеку, завязанную на реакт новой версии. Проблема общая для всех проектов со сколько-то сложными зависимостями, если у вас нет лишних программистов, которые будут все это обновлять. И в случае JAM для мелких недорогих сайтов эта проблема очень острая, потому что сходу прилетает куча зависимостей, и как эти зависимости будут совместимы с еще одной которая еще не появилась — вопрос. Это проблема в принципе любой экосистемы любого языка, но в случае Javascript она стоит особенно сильно.

    Ну и последнее: любую новую технологию пытаются продать, и многие будут ее представлять как серебрянную пулю, что не есть правильно. На своем опыте «JAM» (название появилось уже после того как он был применен, до этого я не знал что пишу на JAM) стэк хорошо себя показал как внутренняя система для сотрудников (nuxt + firebase для realtime), как быстрый способ создать документацию (такую как сейчас делают многие opensource проекты, прямо из readme файла с редактируемыми примерами, поиском и локализацией) и как способ создавать дополнительные страницы в уже существующем проекте, без больших migration скриптов и создания сущностей в cms на каждый чих


    Так у вас был JAM здорового человека.
  • JAM-стэк — нищета на стероидах
    0
    Так весь вопрос в том, кому именно она нужна, разработчику, заказчику, или тому парню, которые продает первым двум свой serverless SAAS.