Comments 99
Слава Богу, я синьор! Нашел у себя все описанные симптомы!
Парацетамол под язык, постельный режим и обильное питьё помогут вам. < / ирония >
с питьем аккуратнее надо, можно прям точно начать верить что ты СИНЬор)
Вы не скромны, а значит падаван.
Дочитал до
решил дальше не читать.
Принципы SOLID, объектно-ориентированное и функциональное программирование — это три парадигмы программирования, три методологии написания чистого кода,
решил дальше не читать.
Да SOLID своеобразный маркер-мем. Удивительно что не притянули KISS, DRY, YAGNY и бритву Окама
Как раз если бы упомянули KISS, YAGNI я бы стал читать дальше. А так видимо дальше водичка.
Забавно что SOLID нынче раздается из каждого утюга, а как откроешь внутрянку: мама родная, ка кэто развидеть.
ЗЫ еще более интересно послушать про любимый фрейм, божественность солид, а потом с любопытством понаблюдать как человек будет оправдывать нарушением activeRecord'ом божественности.
Забавно что SOLID нынче раздается из каждого утюга, а как откроешь внутрянку: мама родная, ка кэто развидеть.
ЗЫ еще более интересно послушать про любимый фрейм, божественность солид, а потом с любопытством понаблюдать как человек будет оправдывать нарушением activeRecord'ом божественности.
решил дальше не читать.
Вы знаете способы получше чем SOLID, позволяющие не создавать говнокод?
Использовать мозг, например
Ну, так мозг (звучит странно, но ладно) и использует различные инструменты для написания кода, и SOLID это один из многих инструментов. Нельзя по фанатизму соблюдать какие-либо принципы, нужно просто черпать из них некоторые идеи, советы. Но то, что SOLID поставили на ряду с ООП и ФП, довольно странно.
Тут дело не столько в SOLID, хотя и в нем тоже (вы не представляете сколько говнокода я видел, авторы которого придерживались SOLID), сколько в том, что автор почему-то смешал ООП и ФП с SOLID. Ощущение что текст писал копирайтер, который до этого ничего о программировании вообще не знал.
Чтобы быть уверенным что Solid это плохо — нужно знать и понимать Solid, для начала. Senior, который не уделял должного внимания этим принципам, вызывает большие подозрения.
видимо как не было четких определений этим абстрактным понятиям, так и нет. Каждый как хочет так и видит…
Не плохая статейка, сразу видно, маркетологи не спят
bla-bla-bla-bla. Про парадигмы повеселило более всего. Особенно ООП, как методология написания чистого кода, с наворачиванием кучи, зачастую лишних сущностей… И звучит так, как будто чистота кода зависит напрямую от парадигмы, а не от сплава опыта и навыка.
А что вы имеете против ООП?
Ну, ни разу не видел, что ООП применяется так, как оно задумывалось + категоричное высказывание в статье, насчет парадигмы написания чистого кода. Так же, как методология более направленная на удобство восприятия «человеками» (дописывание большого количества кода, не нужного самой программе для работы) должна была внести порядок в проекты, на деле же, может больше запутать в хаосе абстракций и искажать восприятие логики работы программы.
Прям 10х программисты
twitter.com/skirani/status/1149302828420067328
twitter.com/skirani/status/1149302828420067328
Не стоило писать так длинно.
Гораздо проще другая оценка:
1. Приносит большой доход — Senior
2. Приносит небольшой доход — Middle
3. Приносит небольшой убыток — Junior
4. Приносит большой убыток — кандидат в Project Manager*
*шутка, не обижайтесь
Гораздо проще другая оценка:
1. Приносит большой доход — Senior
2. Приносит небольшой доход — Middle
3. Приносит небольшой убыток — Junior
4. Приносит большой убыток — кандидат в Project Manager*
*шутка, не обижайтесь
Специалисты по подбору кадров знают, кто — сеньор.
Кто может решить задание на листике.
Кто знает, как поведет себя хитрый кусок кода.
Кто знает, кем он видит себя через 5 лет.
Кто может решить задание на листике.
Кто знает, как поведет себя хитрый кусок кода.
Кто знает, кем он видит себя через 5 лет.
Есть два основных подхода в современном программировании: 1) срочно написать любую фигню лишь бы она хоть как нибудь работала потому что тот продукт что ты напишешь мы уже еще вчера продали. То же касается и архитектуры.
2) работает — не тронь.
Ни в первом ни во втором нет места качественным программам. Где то в сферическом вакууме синьоры пишут пишут эти качественные программы таким же сферическим заказчикам
2) работает — не тронь.
Ни в первом ни во втором нет места качественным программам. Где то в сферическом вакууме синьоры пишут пишут эти качественные программы таким же сферическим заказчикам
Дипломатические методы — обсуждение, убеждение, презентации для руководства разного уровня — могут принести достаточно ресурсов, чтобы сделать большую часть проекта качественно. Я в нескольких компаниях на цифрах показывал, сколько убытков в деньгах и времени приносит некачественный быстрокод и засилье «дешевых» разработчиков в проекте — и если для руководства важен бизнес и результат, а не распил, то непременно пойдут навстречу. Не с первого раза, так с десятого.
«А она мне сказала: „я верю вам! и отдамся по сходной цене“»(с) Простите за каламбур, Вас, Дмитрий, скоро перекупят те, кому нужно срочно срочно за большие деньги. Они скажут — мы всей душей понимаем, уважаем и принимаем Ваши методы и даже сами когда то в молодости шалили подобным, но мы же хорошие парни, посмотрите на нас, напишите нам срочно к вечеру как нибудь, а с утра завтра мы обязательно соберемся что бы посмотреть презентацию, нам только костюмы надо надеть по такому случаю, а так бы уже посмотрели.
И Вы не будете слишком против, потому что деньги, действительно, неплохие.
И Вы не будете слишком против, потому что деньги, действительно, неплохие.
Пока (?) не перекупили, делюсь опытом для тех, кого тоже пока (?) не перекупили. Мне довелось пока (?) не превратиться в разработчика-мебель, за бонусы готового не раздражать начальство своим мнением и опытом, и исправно создающим сотни багов и мучений пользователям своим быстрокодом.
А про все то что вы описываете я уже сказал — «Не с первого раза, так с десятого», зависит от того, зачем вы вообще занимаетесь программированием, и если только за деньги — возможно, это не ваше.
А про все то что вы описываете я уже сказал — «Не с первого раза, так с десятого», зависит от того, зачем вы вообще занимаетесь программированием, и если только за деньги — возможно, это не ваше.
А вот это меня всегда забавляло: у любого действия всегда есть какая-то основополагающая цель, ради которой это действие и совершалось. Все остальные факторы конечно важны, но они всегда сопутствующие. Так вот основная цель того, что вы ходите на работу — это получение денег. И это легко проверить: без основной цели действие теряет смысл. Т.е. вы стали бы делать вашу работу если бы за неё не платили? Очень сомневаюсь. Конечно вы скажите про ваш вклад в опенсорс, про гордость от созданного. Но всё это вторично.
При этом, если вы умный человек, то вы всегда хотите получить максимальную эффективность от своих усилий. А так, как мы выяснили, что основная цель — это деньги, то максимальная эффективность будет заключаться в их количестве.
Так что давайте признаем, что мы работаем за деньги. И если вы это отрицаете, то вы либо лицемер, либо ещё просто молоды и глупы.
При этом, если вы умный человек, то вы всегда хотите получить максимальную эффективность от своих усилий. А так, как мы выяснили, что основная цель — это деньги, то максимальная эффективность будет заключаться в их количестве.
Так что давайте признаем, что мы работаем за деньги. И если вы это отрицаете, то вы либо лицемер, либо ещё просто молоды и глупы.
Достаточно классический разговор — в молодости по максимализму не раз вел такие, отстаивая идеализированный мир, где важны не деньги, а самореализация и позитивный след в истории, способствующий развитию. Со временем баланс выровнялся, и примерно
Я не могу сказать, что что-то здесь для меня вторично. Вполне реально найти компанию, отвечающую такому соотношению, как, в общем, и любому другому. У вас деньги занимают 90%? Найдете и такую компанию. Хотя куда проще было бы для подобной цели работать чиновником.
К слову, достижение корректного соотношения в целях работает не только параллельно, но и последовательно — я могу устроиться на проектную работу ради денег на 2 месяца, а после его завершения — заняться обучением и творчеством, волонтерством на 2 месяца. В случае, если предложений от гармоничных компаний (на мой взгляд) в данный момент нет.
["деньги", "реализация и развитие", "польза для общества"].test(benefit => weight(benefit) === "33.3%") === true. Для меня этот баланс поддерживает гармонию компонентов в системе «личность».Я не могу сказать, что что-то здесь для меня вторично. Вполне реально найти компанию, отвечающую такому соотношению, как, в общем, и любому другому. У вас деньги занимают 90%? Найдете и такую компанию. Хотя куда проще было бы для подобной цели работать чиновником.
К слову, достижение корректного соотношения в целях работает не только параллельно, но и последовательно — я могу устроиться на проектную работу ради денег на 2 месяца, а после его завершения — заняться обучением и творчеством, волонтерством на 2 месяца. В случае, если предложений от гармоничных компаний (на мой взгляд) в данный момент нет.
При этом, если вы умный человек, то вы всегда хотите получить максимальную эффективность от своих усилий. А так, как мы выяснили, что основная цель — это деньги, то максимальная эффективность будет заключаться в их количестве.
Дану, а если вам предложат на 10к больше чем сейчас, но писать надо будет на каком-то долбанутом стеке с кучей легаси кода. Пойдете на такой проект? Денег то стало больше (аж на 10к!)
Или 10к мало? Тогда почему? Может потому что помимо денег в работе есть и другие мотивации?
Возможно я начал не с той стороны. Давайте попробую еще раз.
Смотрите: Есть проект, есть бюджет, есть сроки и есть много много пользователей, жаждущих рабочей программы уже вчера. Они на ней зарабатывают/экономят и просто улучшают карму. У них ипотеки, фокусы кредитные, дети за взятки в садики устроенные, в общем без этой программы жизнь у них не сказать что бы даже и жизнь вообще. И им программа к вечеру нужна в любом виде, не нам. Мы же и не просим Вас писать быдлокод. Мы просим Вас в это ограниченное время написать лучшее, что вообще можно за это время написать. Потому что мы предоставляем нашим пользователям лучшее из возможного. Поэтому мы и пригласили Вас и готовы оплачивать Ваш опыт. Если бы мы хотели испортить всем жизнь, мы бы наняли хренасгоры за бюджет в 10 раз меньше Вашего, но нет. Мы хотим дать лучшее из возможного. Поэтому пожалуйста, ради котиков в ипотечных квартирах, сделайте до вечера максимально хороший релиз, а к завтрашнему вечеру предоставьте в презентации Ваше видение дальнейшего развитие проектамы им подотремся и мы его обязательно рассмотрим
Смотрите: Есть проект, есть бюджет, есть сроки и есть много много пользователей, жаждущих рабочей программы уже вчера. Они на ней зарабатывают/экономят и просто улучшают карму. У них ипотеки, фокусы кредитные, дети за взятки в садики устроенные, в общем без этой программы жизнь у них не сказать что бы даже и жизнь вообще. И им программа к вечеру нужна в любом виде, не нам. Мы же и не просим Вас писать быдлокод. Мы просим Вас в это ограниченное время написать лучшее, что вообще можно за это время написать. Потому что мы предоставляем нашим пользователям лучшее из возможного. Поэтому мы и пригласили Вас и готовы оплачивать Ваш опыт. Если бы мы хотели испортить всем жизнь, мы бы наняли хренасгоры за бюджет в 10 раз меньше Вашего, но нет. Мы хотим дать лучшее из возможного. Поэтому пожалуйста, ради котиков в ипотечных квартирах, сделайте до вечера максимально хороший релиз, а к завтрашнему вечеру предоставьте в презентации Ваше видение дальнейшего развитие проекта
Полностью согласен про «лучшее из возможного» — все эти презентации, встречи и т.п. нужны для того, чтобы согласовать разумные сроки. Мне встречались такие кейсы:
— сроки назначены сверху (или клиентами), часто уже просрочены, и абсолютно оторваны от реальности. Здесь обучение руководства с помощью презентаций и маппинг их радужных представлений с реальностью необходимы, иначе проект просто умрет. Например, от сильного прессинга, под которым невозможно станет работать.
— сроки сильно приуменьшены, но реальны — как принято говорить, «минимально необходимы». В этом случае нужно донести, что бизнес-задача будет выполнена, но образуется техдолг, который будет замедлять и замедлять развитие проекта, до состояния когда простейшая задача будет выполняться полдня или целый день и приводить к непредсказуемым багам. На моем опыте в такое состояние проект приходит в среднем за полтора года, при подобной схеме управления.
— сроки адекватные, техдолг минимальный
— сроки раздутые — тут уже работу нужно проводить с командой, чтобы не распалялась на «а давайте все перепишем на новую хайповую технологию» и другие бесполезные в основном затеи.
Если работаю в компаниях с первыми двумя «управленческими схемами», и при этом «предоставьте Ваше видение мы им подотремся», варианта два — проверить себя, как долго сможешь там отсидеть, либо найти более адекватных ребят.
— сроки назначены сверху (или клиентами), часто уже просрочены, и абсолютно оторваны от реальности. Здесь обучение руководства с помощью презентаций и маппинг их радужных представлений с реальностью необходимы, иначе проект просто умрет. Например, от сильного прессинга, под которым невозможно станет работать.
— сроки сильно приуменьшены, но реальны — как принято говорить, «минимально необходимы». В этом случае нужно донести, что бизнес-задача будет выполнена, но образуется техдолг, который будет замедлять и замедлять развитие проекта, до состояния когда простейшая задача будет выполняться полдня или целый день и приводить к непредсказуемым багам. На моем опыте в такое состояние проект приходит в среднем за полтора года, при подобной схеме управления.
— сроки адекватные, техдолг минимальный
— сроки раздутые — тут уже работу нужно проводить с командой, чтобы не распалялась на «а давайте все перепишем на новую хайповую технологию» и другие бесполезные в основном затеи.
Если работаю в компаниях с первыми двумя «управленческими схемами», и при этом «предоставьте Ваше видение мы им подотремся», варианта два — проверить себя, как долго сможешь там отсидеть, либо найти более адекватных ребят.
сроки у нас зачастую назначает государство исходя из не знаю чего. И тут все понимают что условие выживание бизнеса «хоть что нибудь к завтрашнему утру». Не оптимума, а банального выживания. Плюс куча взаимосвязанных поставщиков данных, которые сроки пролюбили и приходится работать с ними «по фактическим срокам выполнения ими своих обязательств». Плюс конторы навроде РКН которые просто рубят среду работы программы на корню и если ее (программу) за день срочно не переписать то к следующему утру существенная часть клиентов уже будет изучать работу в программе-конкуренте и назад их не вернешь… Так что тут даже не в деньгах дело.
Стараюсь не вписываться в такие проекты — жизнь одна, и если оглядываешься и видишь что полгода не развивался вообще, а писал бизнес-логику и правил баги, в постоянной спешке и стрессе, то должны быть мощнейшие другие мотивирующие факторы. В госкомпаниях и их подрядчиках таких факторов как правило немного. Благо живем в мире, переживающем глобализацию, и найти интересный и хорошо оплачиваемый проект вполне возможно
Жизненно. Описанные в статье сеньоры тоже имеют право на жизнь, но в каком-нибудь ресерче, где готово не должно было быть уже вчера
Ну вот дальше и начинается работа программиста.
Написанную в 1-м случае "срочную фигню" надо будет поддерживать. А для этого надо просмотреть написанное, и либо смириться, либо рефакторить и доводить до ума.
"Работает — не тронь" — тоже можно ревьювить. Например, начать с тестирования (если есть актуальные тесты — то почему вдруг "не тронь"?).
Меня редко подводит следующий метод:
Если нужен «экспресс-анализ» — кто перед тобой. То попросить написать сортировку «Пузырьком» на листочке:
1. Junior — не напишет или напишет с грубейшими ошибками;
2. Regular — напишет или напишет с незначительными ошибками;
3. Senior — не станет писать код, напишет «Быструю» сортировку или назовет 2-3 книжки, где можно ознакомится с сортировкой «Пузырьком».
Если нужен «экспресс-анализ» — кто перед тобой. То попросить написать сортировку «Пузырьком» на листочке:
1. Junior — не напишет или напишет с грубейшими ошибками;
2. Regular — напишет или напишет с незначительными ошибками;
3. Senior — не станет писать код, напишет «Быструю» сортировку или назовет 2-3 книжки, где можно ознакомится с сортировкой «Пузырьком».
А если человек поклонник сортировки вставками, т.к. он всё время работал с малым количеством памяти, или слиянием, т.к. у него лучше худший случай чем у быстрой?
А мб. в его жизненных кейсах постоянно требовались устойчивые сортировки?
Ну и написать быструю сортировку, когда заказчик хочет пузырек — какой-то диктатурный проффесионализм, «мы лучше знаем что вам нужно», а это не во всех сферах принято.
А мб. в его жизненных кейсах постоянно требовались устойчивые сортировки?
Ну и написать быструю сортировку, когда заказчик хочет пузырек — какой-то диктатурный проффесионализм, «мы лучше знаем что вам нужно», а это не во всех сферах принято.
Наверное для пункта «3. Senior» лучше было сказать, что напишет любую другую сортировку, которая отличная от «Пузырька».
Я не предлагаю написанную сортировку применять в каком-либо проекте. Обычно даю такое задание на техническом интервью: смотрю как кандидат код пишет и какие ошибки делает. Если хочет кандидат писать другую сортировку — Welcome!
Я не предлагаю написанную сортировку применять в каком-либо проекте. Обычно даю такое задание на техническом интервью: смотрю как кандидат код пишет и какие ошибки делает. Если хочет кандидат писать другую сортировку — Welcome!
По вашему получается, что сортировка пузырьком это показатель уровня развития программиста?
Конечно, только задание с сортировкой не покажет уровень развития программиста.
Но для меня такое задание — один из важных показателей уровня кандидата: насколько хорошо кандидат способен теоретические знания воплотить в виде кода.
Но для меня такое задание — один из важных показателей уровня кандидата: насколько хорошо кандидат способен теоретические знания воплотить в виде кода.
Ну умеет он написать эту сортировку, точнее вызубрил. Но вот как это знание поможет в проектировании архитектуры?
Скажу даже больше — далеко не первый год в разработке. Но заморочиваться над сортировками не приходилось почти никогда (с ходу не могу вспомнить ни одного случая… может быть такого даже и не было).
И в голове есть осознание, что «существуют разные сортировки», но что там термины под собой подразумевают — я даже и не знаю. Да и зачем париться над сфероконями, когда перед глазами реальные задачи-проблемы?
К примеру, больше беспокоит тандемная работа драйверов между собой (когда один уже в памяти, а другой надо «сцепить» корректным образом с первым). Или передача данных между изолированными инстансами (посредством промежуточного сервиса).
P.S. Гугл есть всегда — посмотреть «табличную информацию» (алгоритм) всегда успеется. Велосипеды свои писать черевато — лучше взять готовую реализацию.
Ну а если произойдет такая ситуация, когда гугла таки нет, то почти наверняка на планете происходят куда более важные события и уже совсем не до проблемы сортировок пузырьками.
И в голове есть осознание, что «существуют разные сортировки», но что там термины под собой подразумевают — я даже и не знаю. Да и зачем париться над сфероконями, когда перед глазами реальные задачи-проблемы?
К примеру, больше беспокоит тандемная работа драйверов между собой (когда один уже в памяти, а другой надо «сцепить» корректным образом с первым). Или передача данных между изолированными инстансами (посредством промежуточного сервиса).
P.S. Гугл есть всегда — посмотреть «табличную информацию» (алгоритм) всегда успеется. Велосипеды свои писать черевато — лучше взять готовую реализацию.
Ну а если произойдет такая ситуация, когда гугла таки нет, то почти наверняка на планете происходят куда более важные события и уже совсем не до проблемы сортировок пузырьками.
Меня немного пугает когда сортировку пузырьком/выбором называют "табличной информацией", или что это оторванное от реальности задание. Тут же не просят написать реализацию хеш-таблиц, сжатие рядами Фурье или кодирование Хаффмана. Даже быструю сортировку не просят написать, в которой действительно надо более-менее помнить принцип.
Просят — сортировку простейшую. Примитивный алгоритм, который при наличии хоть какого-то алгоритмического мышления можно вывести самому в уме. Выбрать максимальное число в массиве — переместить на первое место. Выбрать максимальное число из оставшихся — переместить на второе, и так далее. Это минимальная проверка того что человек вообще умеет программировать — писать циклы, вложенные циклы, проверять границы, сравнивать, прости господи, числа и понимать какое из них куда надо положить.
У меня бывают случаи когда я человека который пришел собеседоваться на мидла прошу написать алгоритм поиска максимального числа в массиве, а он без IDE не может вспомнить как цикл правильно написать. С одной стороны да, он без этого прекрасно участвовал в проектах, да, эта задача решается стандартной библиотекой, и да, редко когда возникает на практике. Но камон ребят! — не уметь написать цикл — это днище даже для человека с полугодом опыта работы.
Вот я на самом деле только из вашего комментария узнал, что такое «сортировка пузырьком». Ну не стояло никогда такой задачи. Хотя, если бы меня попросили просто написать какую-либо свою реализацию сортировки — несмотря на наличие стандартных функций — я бы наверное что-то подобное и написал. А может другое — всё же этот алгоритм не выглядит эффективным. Но обязательно спросил бы — а зачем это надо? Если просто проверить умение придумывать алгоритмы то ок. А если от меня ожидают, что я буду вместо использования стандартной библиотеки писать свои костыли — это, по меньшей мере, странно...)
Я тут описал сортировку выбором, пузырьковая менее интуитивная, не знаю кстати почему именно ее во всех учебниках и на собеседованиях приводят в пример как самую простую :) Сортировка выбором, я бы сказал, самая эффективная из "наивных" — тех, что можно придумать из головы прямо на ходу. Для того чтоб придумать более эффективный QuickSort нужен большой талант на грани с гениальностью.
И, кстати, умение сравнивать эффективность алгоритмов (О-нотация, вот это вот все) — тоже отличный навык, а то бывают случаи когда народ потом пишет пять вложенных циклов и удивляется почему же все тормозит.
Конечно же, эти задания нужны исключительно для того чтобы понять общую адекватность человека, чтобы понять может ли он вообще писать код и ни для чего другого, мне это кажется очевидным :) И конечно если человек не знает конкретный алгоритм, можно предложить написать что-то что он знает, или предложить придумать что-то на ходу. Так даже интереснее, видно как человек мыслит. Пусть не сортировка, пусть обход дерева, бинарный поиск, факториал через рекурсию, поиск пути в графе, поиск подстроки в строке, много есть относительно простых вещей которым учат на первом курсе университета и которые как мне кажется уж старший разработчик-то должен знать, хотя бы на уровне кругозора.
Кроме того, другие задания в рамках собеседования и придумать-то трудно, не будет же фронтэндщик на бумажке писать мне верстку или компоненты реакта. Тут только тестовое задание поможет, но в моей конторе, например, тестовые задания не приняты.
Но камон ребят! — не уметь написать цикл (без помощи IDE) — это днище даже для человека с полугодом опыта работы.
Когда-то и я так думал. А потом прошли годы работы, скакание по разным языкам и IDE…
Так что открою маленький секрет — вот прямо сейчас я не могу написать обычный for в котлине и лезу на SO за примером. Просто потому что не требуется для текущих задач, и голова действительно выкидывает как «ненужное» в пользу конструкций stream, rx, generics и прочих.
Да я тоже как бы немало языков повидал, понимаю что "на кончиках пальцев" у каждого свое. В том примере что я привел соискатель и логику алгоритма построить правильно не смог, а синтаксис — то уже была вишенка на тортике.
Можно сказать "сорри, с циклами сто лет не работал, поэтому не ручаюсь за синтаксис" но написать правильный алгоритм, хоть на псевдокоде — это будет совершенно ок. Сказать "давно не работал с циклами, давайте сделаю через функциональщину", — тоже ок, еще и показывает что человек умеет договариваться и предлагать альтернативные решения. Можно через цикл, можно через reduce, можно даже через map, хоть это и семантически не очень корректно, можно через стримы, можно рекурсией, можно через фабрику алгоритмов поиска максимальных чисел. Конечно же каждая задача — это только повод к разговору, а не бездумный маркер прошел/не прошел.
А вот если просишь написать выбор максимального числа, а тебе говорят "на практике таких задач никогда не возникает, я решал другие задачи, и эту решать не буду. А если будет надо — погуглю две минуты и найду готовую функцию или скачаю пакет" — ну что ж, это тоже важная информация о кандидате.
Почему именно сортировку, а не какую-нибудь другую библиотечную функцию? Я вот когда-то аналог printf писал, почему не ее?
камон ребят
У меня не самая большая оперативная память — без проблем, на этом основании меня могут работодатели отсеивать (проводить дискриминацию — я ни капли не обижусь).
Я без понятия что там может скрываться за термином «сортировка пузырьком». Серьезно. Мозг занят куда более важной и критичной информацией.
У меня есть в наличии на раскладе:
— PHP 5/7 + Smarty + малопопулярная ORM
— JS «classic-vanila» + ESCMA 6/7 + Webpack/Babel + Vue
— Bootstrap 2-3-4 + SCSS препроцессинг
— Java (основной профиль) 8-11 (стараюсь быть в курсе новинок в 12-13) + SpringBoot 2 + Hibernate (всех видов и расцветок: xml/annotation + реализация в спринге)
— database (тут в основе MySQL но бывает и иначе)
И вот после такого, без обид, мне абсолютно по одному месту какая там у кого сортировка висит в голове. Мне проект писать. Крайне сложный. Мультипроцессный, многопоточный и асинхронный.
UPD: Ах да, еще куча всякого-всевозможного посыпано сверху, те же WebSockets… само по себе не сложно, но когда надо добиться работы на сразу нескольких ЯП примерно одного и того же… ух, либо крыша едет, либо тефлон под пятую точку ставить.
Отписал выше: в моем примере кандидат не смог и алгоритм нормально написать, а синтаксис был уже вишенкой на торте. Сомневаюсь что вы при всем перечисленном не можете написать алгоритм поиска максимального числа в массиве.
Можно написать не сортировку, можно бинарный поиск, обход дерева, что угодно.
Кандидат пишет крайне сложный проект с тысячей языков и технологий, не может отсортировать массив не только предложенным, но и любым вообще способом, и говорит что эта задача его недостойна, т.к. он занимается гораздо более важными и сложными вещами? Это тоже информация, причем даже не столько о уме и умении решать сложные задачи, сколько о soft-skills.
Как-нибудь отсортировать? Это конечно смогу. Конкретная реализация (по выбору спрашивающего) — тут уже почти наверняка нет.
В этом я и вижу проблему текущих собеседований: с одной стороны самозванцы в отрасли, а с другой, неадекватный отбор (всякое бывает же)… при всем при этом, максимально отчетливо осознаю, что есть и такие работы, где реально нужно знать те же всевозможные алгоритмы сортировок. Но это все же даже не 30% всех вакансий на рынке (по крайней мере так видится мне).
P.S. Когда-то давно, пока жизнь не свела, делал объединение строк через обычную конкатенацию. А потом столкнулся с ситуацией «просадка производительности» и открыл для себя String/Stream-Builder. Так и со всем остальным — вменяемый человек разберется со всем, если это на самом деле надо… просто не факт, что он уже с этим успел столкнуться.
В этом я и вижу проблему текущих собеседований: с одной стороны самозванцы в отрасли, а с другой, неадекватный отбор (всякое бывает же)… при всем при этом, максимально отчетливо осознаю, что есть и такие работы, где реально нужно знать те же всевозможные алгоритмы сортировок. Но это все же даже не 30% всех вакансий на рынке (по крайней мере так видится мне).
P.S. Когда-то давно, пока жизнь не свела, делал объединение строк через обычную конкатенацию. А потом столкнулся с ситуацией «просадка производительности» и открыл для себя String/Stream-Builder. Так и со всем остальным — вменяемый человек разберется со всем, если это на самом деле надо… просто не факт, что он уже с этим успел столкнуться.
Просят — сортировку простейшую. Примитивный алгоритм, который при наличии хоть какого-то алгоритмического мышления можно вывести самому в уме.
Есть разница в запросе написать простейшую сортировку и конкретно пузырек.
Я вот не помню, как именно написать именно пузырек, но сортировку за n^2 напишу.
За nlogn тоже напишу, но не быструю а слиянием.
Пузырьковая скорее всего никак. А вот другие сортировки, и например работа с графами — это большое количество примеров изящного решения задач и расширения кругозора. Как итог — гибкое инженерное мышление.
Иными словами — все эти сортировки и алгоритмы это лакмусовая бумажка. Вполне вероятно, что человек, который никогда не трогал алгоритмы и уверен что это не применимые практики — много раз ходил в обход, не зная что можно срезать. Самое забавное — что этот человек и не узнает этого.
Иными словами — все эти сортировки и алгоритмы это лакмусовая бумажка. Вполне вероятно, что человек, который никогда не трогал алгоритмы и уверен что это не применимые практики — много раз ходил в обход, не зная что можно срезать. Самое забавное — что этот человек и не узнает этого.
Вот знаете, я в работе ни разу не писала не одну сортировку. Ибо зачем писать свой велосипед, если уже всё давно написано. А вот в свое свободное время я вот прямо должна каждый день писать сортировки? У меня семья и мне нужно так же время на отдых и на изучение чего-то нового или углубление в интересующие меня темы. Нежели увлекаться сортировкой.
Вы никому ничего не должны
еще раз перечитал комментарий, на который вы отвечали — так и не нашел букв «долж».
Зато фрагмент " Вполне вероятно, что человек, который никогда не трогал алгоритмы и уверен что это не применимые практики — много раз ходил в обход, не зная что можно срезать. Самое забавное — что этот человек и не узнает этого." заиграл новыми красками…
Зато фрагмент " Вполне вероятно, что человек, который никогда не трогал алгоритмы и уверен что это не применимые практики — много раз ходил в обход, не зная что можно срезать. Самое забавное — что этот человек и не узнает этого." заиграл новыми красками…
а что там писать-то?
list.sort(); — готово
list.sort(); — готово
Лучший ответ. Зачем в очередной раз изобретать велосипед, даже понарошку?
Затем что вы на собеседовании и хотят проверить насколько вы умеете в алгоритмы.
Так… так… а компаратор?
Вы не корректно оцениваете, синьор должен просто посылать после такого вопроса. Форма может зависеть от воспитания конкретного синьора.
Главное отличие синьора — понимание, КАК будет работать та или иная программа. А то сегодня только один из двадцати приходящих на интервью дотнетчиков может обьяснить что будет с Task, посланным на выполнение — и чем тот же Task отличается от Thread-а. И еще — почему-то куча народу думает что код, скажем на том же .NET, будучи переписанным на Java, Node или чем-то еще (или наоборот) — сразу заработает быстрее и ошибки куда-то пропадут. Нет, не из-за разных моделей потоков или алгоритмов сборки мусора (людей, знающих такие слова, мы берем даже если они не совсем правы в конкретном случае) — а просто «интуиция им подсказывает»…
Senior'ов определяю как тех с кем можно нормально обменяться идеями проектов за кружкой пива. С мидлами — можно пообщаться за архитектуру и всякие solid'ы, тьфу на вас. С талантливыми джунами — за хайповые тулзы.
Название «Сеньор» — это инструмент манипуляции со стороны менеджеров. Если человек внушаемый и его самооценка зависит от чужого мнения, то он охотно клюет на такие названия. Можно назвать программиста «сеньор», «великий лорд», «повелитель машин» — суть программиста от этого не поменяется. Но довольно многим людям это приятно
Не раскрыто самое главное, что должен уметь сеньор.
Он должен уметь видеть вперед на много ходов и уметь правильно спроектировать приложение. Т.е. на это уровне уже главное не качество кода как таковое, а именно закладка архитектуры.
Писать чистый код и знать все принципы могут и продвинутые джуны. Но они еще не имеют опыта и не могут предвидеть возможных тонких мест и заранее создать/заложить обходные пути.
Он должен уметь видеть вперед на много ходов и уметь правильно спроектировать приложение. Т.е. на это уровне уже главное не качество кода как таковое, а именно закладка архитектуры.
Писать чистый код и знать все принципы могут и продвинутые джуны. Но они еще не имеют опыта и не могут предвидеть возможных тонких мест и заранее создать/заложить обходные пути.
Не раскрыто самое главное, что должен уметь сеньор.
Ещё есть такие мнения из разных источников:
Сеньор умеет писать хороший код, который при этом понятный джунам.
Сеньор умеет вытаскивать проекты из дна! Потихоньку, постепенно, маленькими шажками, по принципу бойскаута. Засучив рукава лопатой разгребать говнокод.
Сеньор не перебирает проектами или командами, а работает за деньги! А не из-за того что проект интересный, или простигосподи, «прикольный»..)
Сеньор — «взрослый» человек, который умеет общаться с бизнесом. А не малолетка-соплежуй, который не может два слова связать.
Сеньор умеет управлять своей производительностью и своей прокрастинацией. Качество работы не зависит от настроения.
Сеньор выбирает стек технологий, ориентируясь на знания команды, а не на свои.
Сеньор никогда не критикует чужой говнокод, т.к. не знает при каких обстоятельствах он был написан, как было поставлено ТЗ и какие были сроки.
Какая концентрированная годнота! Почаще бы еще встречать таких сеньоров.
Сеньор никогда не критикует чужой говнокод, т.к. не знает при каких обстоятельствах он был написан, как было поставлено ТЗ и какие были сроки.
Обстоятельства всегда одни и те же — сроки кратчайшие, проект должен быть сдан еще вчера. Но это не служит оправданием тому, чтобы писать говнокод, ибо говнокод порождает технический долг, а технический долг — убийца бизнеса. Лучше сразу искать нормальное место работы, чем дожидаться когда всю команду разгонят.
«Есть в этой жизни, друг Горацио, такое, что Вашей философии не снилось» (с)
Ну к примеру введенный новый менеджер какой нибудь проекта хочет Вас банально кинуть на зп. Вместе со всей командой. Вывести из разработки заменив на свою команду с которой у него заключено негласное соглашение об откате. Расскажите теперь своим ребятам (вспомним ипотеки, кредитныефордыфокусы и т.д.) о техническом долге.
Но даже без этих крайностей в моем опыте был случай когда заказчик прямо говорил: «мы сейчас напишем говнокод» именно этими словами.
Ну к примеру введенный новый менеджер какой нибудь проекта хочет Вас банально кинуть на зп. Вместе со всей командой. Вывести из разработки заменив на свою команду с которой у него заключено негласное соглашение об откате. Расскажите теперь своим ребятам (вспомним ипотеки, кредитныефордыфокусы и т.д.) о техническом долге.
Но даже без этих крайностей в моем опыте был случай когда заказчик прямо говорил: «мы сейчас напишем говнокод» именно этими словами.
А что, аргумент однако!
Выходит так, что говнокод куда чаще порожден говно-управленцами и их говно-менеджментом, а не низкой квалификацией разработчиков. Остаётся вопрос: зачем сеньёру с его высокой квалификацией работать с такой компании? Чтобы жизнь была мучением?
PS. Особенно хороший генератор говнокода — это agile. Я бы за agile сажал в тюрьму.
Выходит так, что говнокод куда чаще порожден говно-управленцами и их говно-менеджментом, а не низкой квалификацией разработчиков. Остаётся вопрос: зачем сеньёру с его высокой квалификацией работать с такой компании? Чтобы жизнь была мучением?
PS. Особенно хороший генератор говнокода — это agile. Я бы за agile сажал в тюрьму.
Ну к примеру введенный новый менеджер какой нибудь проекта хочет Вас банально кинуть на зп. Вместе со всей командой. Вывести из разработки заменив на свою команду с которой у него заключено негласное соглашение об откате.
Епрст, вы где работаете?! Бегите оттуда!
так это 99й год, коллега) мы внедряли проект интернет классов, и да, нас кинули после внедрения. И кидали еще в жизни раз ндцать на суммы, достаточные для покупки бюджетных авто, так вот вопрос который меня гложит: должен ли я испытывать гордость за идеальные внедрения не требующие сопровождения или жалость что не сгрузил этим клиентам тонны рушащегося без моего личного присутствия и постоянного бабловысасывания говнокода?
Не надо с придыханием говорить «убивает бизнес», коллеги. Бизнес это всего лишь люди, и зачастую очень гнилые люди.
Не надо с придыханием говорить «убивает бизнес», коллеги. Бизнес это всего лишь люди, и зачастую очень гнилые люди.
Настоящий разработчик-сеньор — это многогранное существо, которое иногда, если речь идёт об областях, находящихся вне сферы его основной деятельности, может выглядеть как джун или мидл.А иногда выглядит просто как никто, сразу так и не разглядишь, за что по иронии судьбы его и увольняют и много чего непристойного делают. После чего он прячется в свой панцирь и требует от туда уважения. Но когда перед носом начинают шелестеть купюры и он начинает слышать ласковый зов подхалимов, он сразу расправляется, распускает свой слоновий… эээ хвост и начинает им стучать.
Какое-то бла-бла-бла ни о чем
UFO just landed and posted this here
Вот оригинал статьи: medium.com/better-programming/the-marks-of-a-true-senior-developer-d5f3b11c3375, а вот: medium.com/@PurpleGreenLemon — сам автор. Интересно, откуда девушка сия в столь юном возрасте знает про техдолг, про чистый код, и т.д.? Видать, статья заказная.
Sign up to leave a comment.
Признаки настоящих программистов-сеньоров и методы их выслеживания в дикой природе