Большие и сложные системы, которые пишут годами, незамутненной менеджерской гениальностью изменить невозможно по одной лишь хотелке этого самого гения. Твиттер - как раз такая большая и сложная система. Если, как тут где-то писали, 80% функционала отключили и только смс-авторизация отвалилась - то, выходит, разрабы как раз очень хорошо писали софт, раз в него не только фичи добавлялись, но еще и можно эти фичи извлечь из системы без её краха. А вот кто ставит противоречивые задачи и желает побыстрее прикрутить новую "киллер-фичу" - разрабы? Нет, это делают как раз люди, которые потом всегда валят на исполнителей, что их гениальные прозрения неправильно исполнили : )
В общем, в лучшем случае Маску потребуется вбухать кучу бабла, чтобы сделать всё "по-евоному" : ) потому что переделать такую махину как Твиттер - это вообще ни разу не просто, а Твиттер 2.0 - это шляпа, потому что поезд соцсетей уже давно ушел и никакой новизны нету. В итоге и старое (наработанную аудиторию) проимеют, и новое нафиг никому не нужно будет. Таков мой прогноз : )
Следующим этапом будет озарение, что люди в процессе - со всеми своими особенностями - это не аномалия, а часть процесса, которую следует учитывать в первую очередь. А их время - это уже производная : )
Спасибо за статью - познавательно. Однако, что касается сути вопроса - а разве не общепринят подход: multithreading - для кода ввода/вывода, multiprocessing - для CPU-bound?
А еще, если вакансия не горит (и что вполне подходит как раз для крупных компаний, которые "нанимают не на позицию, а в компанию") можно применить экспансивный подход - то есть организовать тест на соответствие ожиданиям нанимателя - чисто для кандидата. Пусть кандидат сориентируется конкретно - что от него ждут. Даже если не прошел тест - ничего страшного, можно подтянуть слабые места - причем конкретные слабые места. Можно так же написать список рекомендаций к изучению - пусть кандидат, при заинтересованности, сам дойдет до нужного компании уровня. Мне кажется это хорошим способом привлекать в компанию подготовленные кадры - и это сэкономит время как нанимателю, так и соискателю.
Автор, как насчет того, что вам банально не хватило компетенции разобраться с Mongo? Не является ли безответственным поручение сложных задач - джунам? Как вы прокомментируете отсутствие тестирования на проекте федерального масштаба?
Вам не кажется, что вы перекладываете ответственность и не замечаете гораздо более существенных проблем, всего лишь следствием которых уже являются описанные вами кейсы?
А это недалеко от истины : ) и актуально для поиска серьезного уровня разработчиков - всё равно же вся петрушка вскроется и, если новоприбывшему не по духу то, как построена работа в нанимающей компании, он все равно её покинет довольно скоро, а, значит, и время на хантинг зря потрачено, и нужно заново искать.
А вот что с другой стороны могу сказать: вакансии работодатели пишут малоинформативные и безликие, нередко - безграмотные и/или неадекватные.
По порядку:
Малоинформативные - те, где нет конкретики даже по используемому стеку, а так же нет приоритетов. Частично такие вакансии еще и неадекватно выглядят, когда в списке требований перечислено всё, о чём когда-либо слышал работодатель. Читая такие списки как минимум очень сложно понять - достаточно ли у тебя компетенции, чтобы претендовать на вакансию? А так же возникают мысли об адекватности писавших эти требования.
Безликие вакансии - потому что крайне мало вакансий с описанием что именно предстоит делать. Поймите - даже адекватного списка профтребований недостаточно, чтобы оценить интерес к вакансии. Что у вас за проект, какое направление, какие особенности? Если вы ищете безликого же кодера - то окей, но если вам нужен мотивированный - напишите с чем именно надо работать, потому что если соискатель уже не джун - ему чаще не все равно с чем работать.
Безграмотные - это где вообще неправильно написаны названия технологий, инструментов, фреймворков и т.д. Shame on you!
Про Неадекватные уже выше пояснил - ну взвесьте вы свои требования, черт побери! Знание, к примеру, PostgeSQL - это что? Поднять и настроить? Сделать распределенную инфраструктуру? Писать запросы на SQL, вьюхи и т.д.? Или это значит только то, что у вас в качестве СУБД - PostgreSQL, а разработчики дальше ORM и не ходят? Насколько это вообще актуально для вакантной позиции? Или это так, на всякий случай?
Сейчас, когда я смотрю на туже выдачу hh, я затрудняюсь понять - что из этого потенциально интересно и мне по силам - как раз ввиду вышеописанного. И поэтому время теряют и работодатели, и претенденты.
Как этот механизм выглядит, когда для управленческих инструментов требуется разнообразными способами агрегировать информацию по тысячам сущностей, в реальном времени по актуальным данным?
Это плохо выглядит везде - хоть в какой архитектуре. Запросы в оперативную базу с разлапистыми джойнами - совершенно не сахар и для самой базы данных, и требуют уже специальных решений - типа отдельной базы данных для аналитики с денормализованными данными или хотя бы отдельной реплики базы. И вот когда эта самая реплика/отдельная база появляются... тут над ними легко и создать микросервис поставки данных.
Эффект Даннинга-Крюгера не про разделение на умных и дураков, а о наличие критического мышления или его отсутствии. Собственно умным в данном случае является тот, кто об этом эффекте знает и применяет его на практике относительно своих же умозаключений, что и порождает снабжение умозаключений умного человека параметром вероятности, в то время как дурак - резко разграничивает умозаключения на "правильные" и "неправильные" - и пребывает в полной уверенности насчет своих выводов.
Был и сисадмином, и разработчиком... и геморрой обновлений с позиции разработчика - вполне очевиден. Как и опасность "протухших" компонентов системы с позиции админа. Хорошего решения тут нет. Но можно хотя бы принять правильное: с позиции администратора должен быть список ОБЯЗАТЕЛЬНЫХ обновлений (неизбежный минимум), без которых страдает безопасность, с позиции разработчика - без разговоров эти обновления накатить и решить все возникающие в результате проблемы с ПО. Это адекватное соглашение.
Банить не нужно — надо выявлять ip. А затем долбить по ним в ответ: ) Если при бане ip вы создаете парсерам проблему с одним ресурсом, то при ответном ударе — уже покрываете целый куст малины: )
Ну я писал о конкретном казусе — про сортировки. По большому счету — это уже не из набора общеупотребительных концепций, типа ООП, паттернов и структур данных — это уже скорее специализированный класс алгоритмов. И если этот класс не востребован в компании реально — это практически бессмысленный «тест» кандидата, к тому же на основе которого делаются обобщающие выводы. И это не редкость, и причин этому масса — и все они далеки от адекватности.
Иной раз так и хочется сказать — а зачем?! Вы тут велосипеды строите что ли? И ведь строят, и гордятся своими «знаниями». А потом вся эта самопальная красота выходит конторе огромным геморроем в сопровождении, ибо любая кастомная вещь — это дополнительная сложность в проект. Зато — кто-то продемонстрировал как он могёт!
Меня лично оторопь берет, когда люди хвалятся своими «хакерскими» достижениями. Потому что коммерческий софт — это не место, где надо упражняться в уникальности и забористости — это всё боком выходит в дальнейшем, если, конечно, это не какой-то усовершенствованный «хеллоуворд» или что-то из разряда «выстрелил — и забыл». А это распространенная причина включения в тесты таких специализированных вопросов от таких выбившихся выше «хакеров». Другая причина — это когда копипастом с аналогичных вакансий берут список скиллов и эти самые тестовые задания, совершенно не отражая — зачем они им?
Как и сказано в статье — под должностью Х всякий понимает что-то своё, и название «Тимлид» по большому счету ничего не дает для понимания как именно он будет тимлидить в конкретной компании — то ли будет ведущим программистом в основном, то ли будет архитектором, то ли будет ревьюировать, то ли тренировать, то ли что еще.
Поиски универсальных волшебников — это, конечно, увлекательно и возвышенно, но как минимум непрактично — я это и хотел сказать своим комментарием.
Ну и даже в этом случае — это чаще всего следствие неразумных амбиций, вместо трезвого понимания — чем именно будет заниматься человек. Конечно, если вы ищете писателя сортировок — то да, нужен такой скилл. Но действительно ли этим и будет заниматься ваш нанимаемый спец? Вот о чём речь.
Всё зависит от того, что вы хотите от тимлида, в какой пропорции и какова специфика. У человека так же ограничен ресурс знания, и держать абстрактное ВСЁ в актуальном состоянии — идеалистическая претензия. Недаром существует и разделение труда — иначе чем отличается ваш тимлид от любого другого программиста в команде. А работодатель это зачастую не понимает — отсюда монструозные списки требующихся навыков, написанных по принципу «всё-всё-всё, и еще вот это», когда из всего этого используется лишь часть и фрагментарно.
Взять тот же пример с сортировками — откуда это требование проистекает? Из действительно большой зависимости разрабатываемого кода от сортировок или «чтоб было» и «так положено»? Мало того, что все эти «на всякий случай»-навыки отфильтровывают действительно годных кандидатов, так они еще и в случае найма прошедшего такой фильтр могут просто ввести в компанию кандидата с невостребованными ею же навыками, или же привести к найму оверкомпетишн человека, которому вы будете платить деньги за знания, а не за деятельность, реально потребную вам.
Аналогично, нанимая гендиректора, допустим, фармакологической фирмы, надо спрашивать его примерно такое: «А напишите-ка нам, милейший, формулу Диметилтриптамина» — и по этому судить о его компетенции в качестве генерального директора — ведь ему не хухры-мухры, ему с химией иметь дело!
Звучит как возможность стать "Бриллиантовым партнером" какого-нибудь Гербалайфа - супер круто! : )
Большие и сложные системы, которые пишут годами, незамутненной менеджерской гениальностью изменить невозможно по одной лишь хотелке этого самого гения. Твиттер - как раз такая большая и сложная система. Если, как тут где-то писали, 80% функционала отключили и только смс-авторизация отвалилась - то, выходит, разрабы как раз очень хорошо писали софт, раз в него не только фичи добавлялись, но еще и можно эти фичи извлечь из системы без её краха. А вот кто ставит противоречивые задачи и желает побыстрее прикрутить новую "киллер-фичу" - разрабы? Нет, это делают как раз люди, которые потом всегда валят на исполнителей, что их гениальные прозрения неправильно исполнили : )
В общем, в лучшем случае Маску потребуется вбухать кучу бабла, чтобы сделать всё "по-евоному" : ) потому что переделать такую махину как Твиттер - это вообще ни разу не просто, а Твиттер 2.0 - это шляпа, потому что поезд соцсетей уже давно ушел и никакой новизны нету. В итоге и старое (наработанную аудиторию) проимеют, и новое нафиг никому не нужно будет. Таков мой прогноз : )
Следующим этапом будет озарение, что люди в процессе - со всеми своими особенностями - это не аномалия, а часть процесса, которую следует учитывать в первую очередь. А их время - это уже производная : )
Ну чтош, Илон Маск - поглядим как залетает Твиттер под твоим рукавотством : ) И не долетит ли он тупо до ближайшей корзины с мусором.
Спасибо за статью - познавательно. Однако, что касается сути вопроса - а разве не общепринят подход: multithreading - для кода ввода/вывода, multiprocessing - для CPU-bound?
Это называется KISS.
А еще, если вакансия не горит (и что вполне подходит как раз для крупных компаний, которые "нанимают не на позицию, а в компанию") можно применить экспансивный подход - то есть организовать тест на соответствие ожиданиям нанимателя - чисто для кандидата. Пусть кандидат сориентируется конкретно - что от него ждут. Даже если не прошел тест - ничего страшного, можно подтянуть слабые места - причем конкретные слабые места. Можно так же написать список рекомендаций к изучению - пусть кандидат, при заинтересованности, сам дойдет до нужного компании уровня. Мне кажется это хорошим способом привлекать в компанию подготовленные кадры - и это сэкономит время как нанимателю, так и соискателю.
Автор, как насчет того, что вам банально не хватило компетенции разобраться с Mongo? Не является ли безответственным поручение сложных задач - джунам? Как вы прокомментируете отсутствие тестирования на проекте федерального масштаба?
Вам не кажется, что вы перекладываете ответственность и не замечаете гораздо более существенных проблем, всего лишь следствием которых уже являются описанные вами кейсы?
А это недалеко от истины : ) и актуально для поиска серьезного уровня разработчиков - всё равно же вся петрушка вскроется и, если новоприбывшему не по духу то, как построена работа в нанимающей компании, он все равно её покинет довольно скоро, а, значит, и время на хантинг зря потрачено, и нужно заново искать.
А вот что с другой стороны могу сказать: вакансии работодатели пишут малоинформативные и безликие, нередко - безграмотные и/или неадекватные.
По порядку:
Малоинформативные - те, где нет конкретики даже по используемому стеку, а так же нет приоритетов. Частично такие вакансии еще и неадекватно выглядят, когда в списке требований перечислено всё, о чём когда-либо слышал работодатель. Читая такие списки как минимум очень сложно понять - достаточно ли у тебя компетенции, чтобы претендовать на вакансию? А так же возникают мысли об адекватности писавших эти требования.
Безликие вакансии - потому что крайне мало вакансий с описанием что именно предстоит делать. Поймите - даже адекватного списка профтребований недостаточно, чтобы оценить интерес к вакансии. Что у вас за проект, какое направление, какие особенности? Если вы ищете безликого же кодера - то окей, но если вам нужен мотивированный - напишите с чем именно надо работать, потому что если соискатель уже не джун - ему чаще не все равно с чем работать.
Безграмотные - это где вообще неправильно написаны названия технологий, инструментов, фреймворков и т.д. Shame on you!
Про Неадекватные уже выше пояснил - ну взвесьте вы свои требования, черт побери! Знание, к примеру, PostgeSQL - это что? Поднять и настроить? Сделать распределенную инфраструктуру? Писать запросы на SQL, вьюхи и т.д.? Или это значит только то, что у вас в качестве СУБД - PostgreSQL, а разработчики дальше ORM и не ходят? Насколько это вообще актуально для вакантной позиции? Или это так, на всякий случай?
Сейчас, когда я смотрю на туже выдачу hh, я затрудняюсь понять - что из этого потенциально интересно и мне по силам - как раз ввиду вышеописанного. И поэтому время теряют и работодатели, и претенденты.
Как этот механизм выглядит, когда для управленческих инструментов требуется разнообразными способами агрегировать информацию по тысячам сущностей, в реальном времени по актуальным данным?
Это плохо выглядит везде - хоть в какой архитектуре. Запросы в оперативную базу с разлапистыми джойнами - совершенно не сахар и для самой базы данных, и требуют уже специальных решений - типа отдельной базы данных для аналитики с денормализованными данными или хотя бы отдельной реплики базы. И вот когда эта самая реплика/отдельная база появляются... тут над ними легко и создать микросервис поставки данных.
Эффект Даннинга-Крюгера не про разделение на умных и дураков, а о наличие критического мышления или его отсутствии. Собственно умным в данном случае является тот, кто об этом эффекте знает и применяет его на практике относительно своих же умозаключений, что и порождает снабжение умозаключений умного человека параметром вероятности, в то время как дурак - резко разграничивает умозаключения на "правильные" и "неправильные" - и пребывает в полной уверенности насчет своих выводов.
Был и сисадмином, и разработчиком... и геморрой обновлений с позиции разработчика - вполне очевиден. Как и опасность "протухших" компонентов системы с позиции админа. Хорошего решения тут нет. Но можно хотя бы принять правильное: с позиции администратора должен быть список ОБЯЗАТЕЛЬНЫХ обновлений (неизбежный минимум), без которых страдает безопасность, с позиции разработчика - без разговоров эти обновления накатить и решить все возникающие в результате проблемы с ПО. Это адекватное соглашение.
Парадигмы-шмарадигмы: ) Ну а как жеж — ажно самого Роберта-свет-нашего-Мартина читает человек! Проф
фессионал!Эм-м-м-м… или это неэтично?
Иной раз так и хочется сказать — а зачем?! Вы тут велосипеды строите что ли? И ведь строят, и гордятся своими «знаниями». А потом вся эта самопальная красота выходит конторе огромным геморроем в сопровождении, ибо любая кастомная вещь — это дополнительная сложность в проект. Зато — кто-то продемонстрировал как он могёт!
Меня лично оторопь берет, когда люди хвалятся своими «хакерскими» достижениями. Потому что коммерческий софт — это не место, где надо упражняться в уникальности и забористости — это всё боком выходит в дальнейшем, если, конечно, это не какой-то усовершенствованный «хеллоуворд» или что-то из разряда «выстрелил — и забыл». А это распространенная причина включения в тесты таких специализированных вопросов от таких выбившихся выше «хакеров». Другая причина — это когда копипастом с аналогичных вакансий берут список скиллов и эти самые тестовые задания, совершенно не отражая — зачем они им?
Поиски универсальных волшебников — это, конечно, увлекательно и возвышенно, но как минимум непрактично — я это и хотел сказать своим комментарием.
Взять тот же пример с сортировками — откуда это требование проистекает? Из действительно большой зависимости разрабатываемого кода от сортировок или «чтоб было» и «так положено»? Мало того, что все эти «на всякий случай»-навыки отфильтровывают действительно годных кандидатов, так они еще и в случае найма прошедшего такой фильтр могут просто ввести в компанию кандидата с невостребованными ею же навыками, или же привести к найму оверкомпетишн человека, которому вы будете платить деньги за знания, а не за деятельность, реально потребную вам.
Это ли не безумие?