Признаки настоящих программистов-сеньоров и методы их выслеживания в дикой природе

Original author: Aphinya Dechalert
  • Translation
Существует большой разброс в уровнях квалификации разработчиков. И то, что называют «сеньорностью», часто ничего не говорит о реальных возможностях программиста. Что делает некоторых разработчиков объективно лучше других? Что выделяет их из серой толпы?
Если у программиста есть пять, десять или даже пятнадцать лет «практического опыта» — это не обязательно гарантирует то, что он является эффективным и продуктивным сеньором. На самом деле — это даже не значит, что он вообще может так называться.

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



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

Автор материала, перевод которого мы сегодня публикуем, говорит, что хочет рассказать о некоторых признаках, которые помогают отличить настоящего программиста-сеньора от программиста с «сеньорностью».

Парадигмы программирования


Принципы SOLID, объектно-ориентированное и функциональное программирование — это три парадигмы программирования, три методологии написания чистого кода, которые составляют значительную часть концептуальных подходов, стоящих за созданием программ.

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

Писать код может кто угодно — точно так же, как кто угодно может написать сообщение в мессенджере или короткий обзор книги на Amazon. Но подобные тексты нельзя поставить на один уровень с романами Стивена Кинга. Парадигмы программирования действуют как направляющая сила, стоящая за кодом, который пишут сеньоры. Это делает парадигмы похожими на сюжетные структуры, которым следуют авторы художественных произведений. Все языки пронизаны формулами. Разработчики-сеньоры понимают их на глубоком уровне, до которого джунам и мидлам ещё только предстоит дойти.

Способность создавать


Когда мы впервые приходим в мир циклов for и конструкций if else, мы задаём вопросы и пытаемся найти ответы на них в виде кода, который можно откуда-то скопировать и вставить в свой проект. Уровень понимания этого кода — это то, чем характеризуется квалификация джуниоров, которые только приступили к работе, и начинающих мидлов.

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

Если им что-то неизвестно — они восполняют пробелы в знаниях, серьёзно разбираясь в неясных вопросах, не ограничиваясь лишь их поверхностным изучением. Они глубоко понимают все те инструменты, которыми пользуются. Мир кода выглядит в глазах сеньоров не так, как в глазах джунов или мидлов.

Объективная критика


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

В этом нет ничего плохого. Всё это — часть процесса профессионального роста. Для того чтобы достичь настоящей объективности суждений, программисту нужно побывать во множестве ситуаций и самому увидеть, как нечто, неприемлемое в одном случае, в другом может оказаться наилучшим решением некоей проблемы. Это развивает у разработчика нейтральный взгляд на вещи. Нет единственно правильного способа писать код. Есть лишь способы, которые эффективны в определённой ситуации и при определённом сценарии развития событий. Программисты-сеньоры это понимают. Они готовы принять то, что их код может и не быть неким «самым лучшим» кодом, и то, что он может быть подвергнуть улучшению.

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

Разница между хорошей программой и работающей программой


Разработчики создают код, главная задача которого — запуститься. Некоторые из них останавливаются на этом, и считают, что работающий код — это всё, что им нужно. Другие идут немного дальше и стремятся к тому, чтобы код был бы не только работающим, но и качественно написанным. Лучшие разработчики — это те профессионалы, которые в процессе работы редактируют и переписывают наш код. Они могут и согласиться с применением какой-нибудь неудачной конструкции, но как только у них возникнет возможность её исправить — они это сделают. Такие разработчики понимают разницу между хорошей и работающей программой.

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

Широта их знаний, понимание фреймворков и языков программирования, делают их экспертами в вопросе нахождения разницы между программами работающими и программами качественными. Они умеют создавать и то и другое. Это даёт настоящим сеньорам возможность находить креативные решения проблем в самых разных ситуациях.

Способность учить


Посредственный учитель излагает. Хороший учитель объясняет. Выдающийся учитель показывает. Великий учитель вдохновляет.
Уильям Артур Уорд


У настоящих разработчиков-сеньоров есть страсть к технологиям, которая вдохновляет их менее опытных товарищей, помогая начинающим становиться профессионалами высочайшего класса.

Программирование, само по себе, это набор неких идей. У сеньоров есть способность сжато и понятно излагать эти идеи. Способность сеньоров переносить код между разными интерфейсами и средами демонстрирует истинное понимание выбранного ими языка программирования.

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

Итоги


Настоящий разработчик-сеньор — это многогранное существо, которое иногда, если речь идёт об областях, находящихся вне сферы его основной деятельности, может выглядеть как джун или мидл. Но сеньор обладает мощной базой в области философии программирования.

Однако вышеприведённые особенности сеньоров — это то, что присутствует в их личностях и в их профессиональных знаниях. Это позволяет им осваивать новые технологии быстрее, чем некоему «усреднённому» программисту. Часто сеньоры — это люди, которые способны охватить одним взглядом общую картину происходящего. Они способны смотреть на код без предрассудков и суеверий.

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

Разработчик-сеньор может быть человеком любого возраста, он может прийти из любой отрасли информационных технологий, его «практический опыт» может исчисляться любым количеством лет. Главная особенность таких людей заключается в том, что они по-настоящему умеют решать проблемы, и в том, что они способны мыслить в долгосрочной перспективе.

Уважаемые читатели! Если вы занимаетесь подбором кадров в сфере информационных технологий — просим рассказать нам о том, как вы «выслеживаете» сеньоров.

RUVDS.com
1,481.48
RUVDS – хостинг VDS/VPS серверов
Share post

Comments 99

    +10

    Слава Богу, я синьор! Нашел у себя все описанные симптомы!

      +21
      Парацетамол под язык, постельный режим и обильное питьё помогут вам. < / ирония >
        +4
        с питьем аккуратнее надо, можно прям точно начать верить что ты СИНЬор)
          +6

          Побуду адвокатом немного.


          Согласно словарю Ожегова, сеньор — господин в Испании, а синьор — господин в Италии. Так что оба варианта верны, пока речь о господах. :)


          А если не о них, то senior вообще надо переводить как «старший [разработчик]». В транскрипции английского слова тоже звук «И», кстати.

            +6
            Я думаю, что тут обыгрывалась шутка «питьё» => «синька» => «синьор», а не попытка указать на ошибку ;-)
              +1
              Да это про алкоголь
                +2

                А, блин. Не уловил шутку, позор мне. :)

                +3

                Может пора переводить как "господин разработчик"?

            +2
            Вы не скромны, а значит падаван.
              +5

              В зарубежных компаниях наоборот. :)

            +61
            Дочитал до
            Принципы SOLID, объектно-ориентированное и функциональное программирование — это три парадигмы программирования, три методологии написания чистого кода,

            решил дальше не читать.
              +8
              Да SOLID своеобразный маркер-мем. Удивительно что не притянули KISS, DRY, YAGNY и бритву Окама
                +1
                Как раз если бы упомянули KISS, YAGNI я бы стал читать дальше. А так видимо дальше водичка.

                Забавно что SOLID нынче раздается из каждого утюга, а как откроешь внутрянку: мама родная, ка кэто развидеть.

                ЗЫ еще более интересно послушать про любимый фрейм, божественность солид, а потом с любопытством понаблюдать как человек будет оправдывать нарушением activeRecord'ом божественности.
                0
                решил дальше не читать.

                Вы знаете способы получше чем SOLID, позволяющие не создавать говнокод?
                  +6
                  Использовать мозг, например
                    +1

                    Ну, так мозг (звучит странно, но ладно) и использует различные инструменты для написания кода, и SOLID это один из многих инструментов. Нельзя по фанатизму соблюдать какие-либо принципы, нужно просто черпать из них некоторые идеи, советы. Но то, что SOLID поставили на ряду с ООП и ФП, довольно странно.

                      +8

                      SOLID — не парадигма. А вот, к примеру, логическую и аспектно-ориентированную забыли… Поэтому не читать дальше — логично. Ведь автор не разбирается в самых базовых вещах.

                    +2
                    Тут дело не столько в SOLID, хотя и в нем тоже (вы не представляете сколько говнокода я видел, авторы которого придерживались SOLID), сколько в том, что автор почему-то смешал ООП и ФП с SOLID. Ощущение что текст писал копирайтер, который до этого ничего о программировании вообще не знал.
                    0
                    Чтобы быть уверенным что Solid это плохо — нужно знать и понимать Solid, для начала. Senior, который не уделял должного внимания этим принципам, вызывает большие подозрения.
                    +2
                    видимо как не было четких определений этим абстрактным понятиям, так и нет. Каждый как хочет так и видит…
                      +2
                      Не плохая статейка, сразу видно, маркетологи не спят
                        +3
                        bla-bla-bla-bla. Про парадигмы повеселило более всего. Особенно ООП, как методология написания чистого кода, с наворачиванием кучи, зачастую лишних сущностей… И звучит так, как будто чистота кода зависит напрямую от парадигмы, а не от сплава опыта и навыка.
                          +1

                          А что вы имеете против ООП?

                            0
                            Ну, ни разу не видел, что ООП применяется так, как оно задумывалось + категоричное высказывание в статье, насчет парадигмы написания чистого кода. Так же, как методология более направленная на удобство восприятия «человеками» (дописывание большого количества кода, не нужного самой программе для работы) должна была внести порядок в проекты, на деле же, может больше запутать в хаосе абстракций и искажать восприятие логики работы программы.
                              –1

                              А как оно задумывалось?
                              И если используется не так, возможно неправильно задумывалось?

                          +2
                          Прям 10х программисты
                          twitter.com/skirani/status/1149302828420067328
                            +38
                            Не стоило писать так длинно.

                            Гораздо проще другая оценка:
                            1. Приносит большой доход — Senior
                            2. Приносит небольшой доход — Middle
                            3. Приносит небольшой убыток — Junior
                            4. Приносит большой убыток — кандидат в Project Manager*

                            *шутка, не обижайтесь
                              +28
                              Лучше идти от противного:
                              1. Может нанести наибольший ущерб — Senior
                              2. Может нанести небольшой ущерб — Middle
                              3. Может нанести наименьший возможный ущерб— Junior
                                +1
                                Лучшее определение!
                                  +4
                                  3. Может нанести наименьший возможный ущерб— Junior
                                  Знаю одного Junior-а который базу на продакшне дропнул, так что не надо недооценивать их силу)
                                    +8
                                    а это уже косяк не джуна что у него доступ в прод был. в прод через CI/CD а до этого ревью сеньором
                                      0
                                      Та это понятно. Но факт остаётся фактом
                                +13
                                Специалисты по подбору кадров знают, кто — сеньор.
                                Кто может решить задание на листике.
                                Кто знает, как поведет себя хитрый кусок кода.
                                Кто знает, кем он видит себя через 5 лет.
                                  +15
                                  И кто знает, почему он хочет работать именно в вашей компании.
                                    –1
                                    Indeed!
                                    0
                                    Есть два основных подхода в современном программировании: 1) срочно написать любую фигню лишь бы она хоть как нибудь работала потому что тот продукт что ты напишешь мы уже еще вчера продали. То же касается и архитектуры.
                                    2) работает — не тронь.
                                    Ни в первом ни во втором нет места качественным программам. Где то в сферическом вакууме синьоры пишут пишут эти качественные программы таким же сферическим заказчикам
                                      0
                                      Дипломатические методы — обсуждение, убеждение, презентации для руководства разного уровня — могут принести достаточно ресурсов, чтобы сделать большую часть проекта качественно. Я в нескольких компаниях на цифрах показывал, сколько убытков в деньгах и времени приносит некачественный быстрокод и засилье «дешевых» разработчиков в проекте — и если для руководства важен бизнес и результат, а не распил, то непременно пойдут навстречу. Не с первого раза, так с десятого.
                                        +2
                                        «А она мне сказала: „я верю вам! и отдамся по сходной цене“»(с) Простите за каламбур, Вас, Дмитрий, скоро перекупят те, кому нужно срочно срочно за большие деньги. Они скажут — мы всей душей понимаем, уважаем и принимаем Ваши методы и даже сами когда то в молодости шалили подобным, но мы же хорошие парни, посмотрите на нас, напишите нам срочно к вечеру как нибудь, а с утра завтра мы обязательно соберемся что бы посмотреть презентацию, нам только костюмы надо надеть по такому случаю, а так бы уже посмотрели.
                                        И Вы не будете слишком против, потому что деньги, действительно, неплохие.
                                          0
                                          Пока (?) не перекупили, делюсь опытом для тех, кого тоже пока (?) не перекупили. Мне довелось пока (?) не превратиться в разработчика-мебель, за бонусы готового не раздражать начальство своим мнением и опытом, и исправно создающим сотни багов и мучений пользователям своим быстрокодом.
                                          А про все то что вы описываете я уже сказал — «Не с первого раза, так с десятого», зависит от того, зачем вы вообще занимаетесь программированием, и если только за деньги — возможно, это не ваше.
                                            +1
                                            А вот это меня всегда забавляло: у любого действия всегда есть какая-то основополагающая цель, ради которой это действие и совершалось. Все остальные факторы конечно важны, но они всегда сопутствующие. Так вот основная цель того, что вы ходите на работу — это получение денег. И это легко проверить: без основной цели действие теряет смысл. Т.е. вы стали бы делать вашу работу если бы за неё не платили? Очень сомневаюсь. Конечно вы скажите про ваш вклад в опенсорс, про гордость от созданного. Но всё это вторично.
                                            При этом, если вы умный человек, то вы всегда хотите получить максимальную эффективность от своих усилий. А так, как мы выяснили, что основная цель — это деньги, то максимальная эффективность будет заключаться в их количестве.
                                            Так что давайте признаем, что мы работаем за деньги. И если вы это отрицаете, то вы либо лицемер, либо ещё просто молоды и глупы.
                                              +1
                                              Достаточно классический разговор — в молодости по максимализму не раз вел такие, отстаивая идеализированный мир, где важны не деньги, а самореализация и позитивный след в истории, способствующий развитию. Со временем баланс выровнялся, и примерно ["деньги", "реализация и развитие", "польза для общества"].test(benefit => weight(benefit) === "33.3%") === true. Для меня этот баланс поддерживает гармонию компонентов в системе «личность».

                                              Я не могу сказать, что что-то здесь для меня вторично. Вполне реально найти компанию, отвечающую такому соотношению, как, в общем, и любому другому. У вас деньги занимают 90%? Найдете и такую компанию. Хотя куда проще было бы для подобной цели работать чиновником.

                                              К слову, достижение корректного соотношения в целях работает не только параллельно, но и последовательно — я могу устроиться на проектную работу ради денег на 2 месяца, а после его завершения — заняться обучением и творчеством, волонтерством на 2 месяца. В случае, если предложений от гармоничных компаний (на мой взгляд) в данный момент нет.
                                                –1
                                                При этом, если вы умный человек, то вы всегда хотите получить максимальную эффективность от своих усилий. А так, как мы выяснили, что основная цель — это деньги, то максимальная эффективность будет заключаться в их количестве.

                                                Дану, а если вам предложат на 10к больше чем сейчас, но писать надо будет на каком-то долбанутом стеке с кучей легаси кода. Пойдете на такой проект? Денег то стало больше (аж на 10к!)
                                                Или 10к мало? Тогда почему? Может потому что помимо денег в работе есть и другие мотивации?
                                                0
                                                Возможно я начал не с той стороны. Давайте попробую еще раз.
                                                Смотрите: Есть проект, есть бюджет, есть сроки и есть много много пользователей, жаждущих рабочей программы уже вчера. Они на ней зарабатывают/экономят и просто улучшают карму. У них ипотеки, фокусы кредитные, дети за взятки в садики устроенные, в общем без этой программы жизнь у них не сказать что бы даже и жизнь вообще. И им программа к вечеру нужна в любом виде, не нам. Мы же и не просим Вас писать быдлокод. Мы просим Вас в это ограниченное время написать лучшее, что вообще можно за это время написать. Потому что мы предоставляем нашим пользователям лучшее из возможного. Поэтому мы и пригласили Вас и готовы оплачивать Ваш опыт. Если бы мы хотели испортить всем жизнь, мы бы наняли хренасгоры за бюджет в 10 раз меньше Вашего, но нет. Мы хотим дать лучшее из возможного. Поэтому пожалуйста, ради котиков в ипотечных квартирах, сделайте до вечера максимально хороший релиз, а к завтрашнему вечеру предоставьте в презентации Ваше видение дальнейшего развитие проекта мы им подотремся и мы его обязательно рассмотрим
                                                  0
                                                  Полностью согласен про «лучшее из возможного» — все эти презентации, встречи и т.п. нужны для того, чтобы согласовать разумные сроки. Мне встречались такие кейсы:
                                                  — сроки назначены сверху (или клиентами), часто уже просрочены, и абсолютно оторваны от реальности. Здесь обучение руководства с помощью презентаций и маппинг их радужных представлений с реальностью необходимы, иначе проект просто умрет. Например, от сильного прессинга, под которым невозможно станет работать.
                                                  — сроки сильно приуменьшены, но реальны — как принято говорить, «минимально необходимы». В этом случае нужно донести, что бизнес-задача будет выполнена, но образуется техдолг, который будет замедлять и замедлять развитие проекта, до состояния когда простейшая задача будет выполняться полдня или целый день и приводить к непредсказуемым багам. На моем опыте в такое состояние проект приходит в среднем за полтора года, при подобной схеме управления.
                                                  — сроки адекватные, техдолг минимальный
                                                  — сроки раздутые — тут уже работу нужно проводить с командой, чтобы не распалялась на «а давайте все перепишем на новую хайповую технологию» и другие бесполезные в основном затеи.

                                                  Если работаю в компаниях с первыми двумя «управленческими схемами», и при этом «предоставьте Ваше видение мы им подотремся», варианта два — проверить себя, как долго сможешь там отсидеть, либо найти более адекватных ребят.
                                                    0
                                                    сроки у нас зачастую назначает государство исходя из не знаю чего. И тут все понимают что условие выживание бизнеса «хоть что нибудь к завтрашнему утру». Не оптимума, а банального выживания. Плюс куча взаимосвязанных поставщиков данных, которые сроки пролюбили и приходится работать с ними «по фактическим срокам выполнения ими своих обязательств». Плюс конторы навроде РКН которые просто рубят среду работы программы на корню и если ее (программу) за день срочно не переписать то к следующему утру существенная часть клиентов уже будет изучать работу в программе-конкуренте и назад их не вернешь… Так что тут даже не в деньгах дело.
                                                      0
                                                      Стараюсь не вписываться в такие проекты — жизнь одна, и если оглядываешься и видишь что полгода не развивался вообще, а писал бизнес-логику и правил баги, в постоянной спешке и стрессе, то должны быть мощнейшие другие мотивирующие факторы. В госкомпаниях и их подрядчиках таких факторов как правило немного. Благо живем в мире, переживающем глобализацию, и найти интересный и хорошо оплачиваемый проект вполне возможно
                                            0
                                            Жизненно. Описанные в статье сеньоры тоже имеют право на жизнь, но в каком-нибудь ресерче, где готово не должно было быть уже вчера
                                              +1

                                              Ну вот дальше и начинается работа программиста.
                                              Написанную в 1-м случае "срочную фигню" надо будет поддерживать. А для этого надо просмотреть написанное, и либо смириться, либо рефакторить и доводить до ума.
                                              "Работает — не тронь" — тоже можно ревьювить. Например, начать с тестирования (если есть актуальные тесты — то почему вдруг "не тронь"?).

                                              –1
                                              Меня редко подводит следующий метод:

                                              Если нужен «экспресс-анализ» — кто перед тобой. То попросить написать сортировку «Пузырьком» на листочке:
                                              1. Junior — не напишет или напишет с грубейшими ошибками;
                                              2. Regular — напишет или напишет с незначительными ошибками;
                                              3. Senior — не станет писать код, напишет «Быструю» сортировку или назовет 2-3 книжки, где можно ознакомится с сортировкой «Пузырьком».
                                                +2
                                                А если человек поклонник сортировки вставками, т.к. он всё время работал с малым количеством памяти, или слиянием, т.к. у него лучше худший случай чем у быстрой?
                                                А мб. в его жизненных кейсах постоянно требовались устойчивые сортировки?
                                                Ну и написать быструю сортировку, когда заказчик хочет пузырек — какой-то диктатурный проффесионализм, «мы лучше знаем что вам нужно», а это не во всех сферах принято.
                                                  +1
                                                  Наверное для пункта «3. Senior» лучше было сказать, что напишет любую другую сортировку, которая отличная от «Пузырька».

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

                                                        P.S. Гугл есть всегда — посмотреть «табличную информацию» (алгоритм) всегда успеется. Велосипеды свои писать черевато — лучше взять готовую реализацию.
                                                        Ну а если произойдет такая ситуация, когда гугла таки нет, то почти наверняка на планете происходят куда более важные события и уже совсем не до проблемы сортировок пузырьками.
                                                          +1

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


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


                                                          У меня бывают случаи когда я человека который пришел собеседоваться на мидла прошу написать алгоритм поиска максимального числа в массиве, а он без IDE не может вспомнить как цикл правильно написать. С одной стороны да, он без этого прекрасно участвовал в проектах, да, эта задача решается стандартной библиотекой, и да, редко когда возникает на практике. Но камон ребят! — не уметь написать цикл — это днище даже для человека с полугодом опыта работы.

                                                            0
                                                            Вот я на самом деле только из вашего комментария узнал, что такое «сортировка пузырьком». Ну не стояло никогда такой задачи. Хотя, если бы меня попросили просто написать какую-либо свою реализацию сортировки — несмотря на наличие стандартных функций — я бы наверное что-то подобное и написал. А может другое — всё же этот алгоритм не выглядит эффективным. Но обязательно спросил бы — а зачем это надо? Если просто проверить умение придумывать алгоритмы то ок. А если от меня ожидают, что я буду вместо использования стандартной библиотеки писать свои костыли — это, по меньшей мере, странно...)
                                                              0

                                                              Я тут описал сортировку выбором, пузырьковая менее интуитивная, не знаю кстати почему именно ее во всех учебниках и на собеседованиях приводят в пример как самую простую :) Сортировка выбором, я бы сказал, самая эффективная из "наивных" — тех, что можно придумать из головы прямо на ходу. Для того чтоб придумать более эффективный QuickSort нужен большой талант на грани с гениальностью.
                                                              И, кстати, умение сравнивать эффективность алгоритмов (О-нотация, вот это вот все) — тоже отличный навык, а то бывают случаи когда народ потом пишет пять вложенных циклов и удивляется почему же все тормозит.


                                                              Конечно же, эти задания нужны исключительно для того чтобы понять общую адекватность человека, чтобы понять может ли он вообще писать код и ни для чего другого, мне это кажется очевидным :) И конечно если человек не знает конкретный алгоритм, можно предложить написать что-то что он знает, или предложить придумать что-то на ходу. Так даже интереснее, видно как человек мыслит. Пусть не сортировка, пусть обход дерева, бинарный поиск, факториал через рекурсию, поиск пути в графе, поиск подстроки в строке, много есть относительно простых вещей которым учат на первом курсе университета и которые как мне кажется уж старший разработчик-то должен знать, хотя бы на уровне кругозора.


                                                              Кроме того, другие задания в рамках собеседования и придумать-то трудно, не будет же фронтэндщик на бумажке писать мне верстку или компоненты реакта. Тут только тестовое задание поможет, но в моей конторе, например, тестовые задания не приняты.

                                                                0
                                                                Для того чтоб придумать более эффективный QuickSort нужен большой талант на грани с гениальностью.

                                                                Или знание принципа «разделяй и властвуй». Правда, есть риск придумать сортировку слиянием.

                                                              +2
                                                              Но камон ребят! — не уметь написать цикл (без помощи IDE) — это днище даже для человека с полугодом опыта работы.

                                                              Когда-то и я так думал. А потом прошли годы работы, скакание по разным языкам и IDE…

                                                              Так что открою маленький секрет — вот прямо сейчас я не могу написать обычный for в котлине и лезу на SO за примером. Просто потому что не требуется для текущих задач, и голова действительно выкидывает как «ненужное» в пользу конструкций stream, rx, generics и прочих.
                                                                0

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


                                                                Можно сказать "сорри, с циклами сто лет не работал, поэтому не ручаюсь за синтаксис" но написать правильный алгоритм, хоть на псевдокоде — это будет совершенно ок. Сказать "давно не работал с циклами, давайте сделаю через функциональщину", — тоже ок, еще и показывает что человек умеет договариваться и предлагать альтернативные решения. Можно через цикл, можно через reduce, можно даже через map, хоть это и семантически не очень корректно, можно через стримы, можно рекурсией, можно через фабрику алгоритмов поиска максимальных чисел. Конечно же каждая задача — это только повод к разговору, а не бездумный маркер прошел/не прошел.


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

                                                                +1
                                                                Почему именно сортировку, а не какую-нибудь другую библиотечную функцию? Я вот когда-то аналог printf писал, почему не ее?
                                                                  0
                                                                  камон ребят

                                                                  У меня не самая большая оперативная память — без проблем, на этом основании меня могут работодатели отсеивать (проводить дискриминацию — я ни капли не обижусь).
                                                                  Я без понятия что там может скрываться за термином «сортировка пузырьком». Серьезно. Мозг занят куда более важной и критичной информацией.
                                                                  У меня есть в наличии на раскладе:
                                                                  — 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… само по себе не сложно, но когда надо добиться работы на сразу нескольких ЯП примерно одного и того же… ух, либо крыша едет, либо тефлон под пятую точку ставить.
                                                                    0

                                                                    Отписал выше: в моем примере кандидат не смог и алгоритм нормально написать, а синтаксис был уже вишенкой на торте. Сомневаюсь что вы при всем перечисленном не можете написать алгоритм поиска максимального числа в массиве.


                                                                    Можно написать не сортировку, можно бинарный поиск, обход дерева, что угодно.
                                                                    Кандидат пишет крайне сложный проект с тысячей языков и технологий, не может отсортировать массив не только предложенным, но и любым вообще способом, и говорит что эта задача его недостойна, т.к. он занимается гораздо более важными и сложными вещами? Это тоже информация, причем даже не столько о уме и умении решать сложные задачи, сколько о soft-skills.

                                                                      0
                                                                      Как-нибудь отсортировать? Это конечно смогу. Конкретная реализация (по выбору спрашивающего) — тут уже почти наверняка нет.
                                                                      В этом я и вижу проблему текущих собеседований: с одной стороны самозванцы в отрасли, а с другой, неадекватный отбор (всякое бывает же)… при всем при этом, максимально отчетливо осознаю, что есть и такие работы, где реально нужно знать те же всевозможные алгоритмы сортировок. Но это все же даже не 30% всех вакансий на рынке (по крайней мере так видится мне).

                                                                      P.S. Когда-то давно, пока жизнь не свела, делал объединение строк через обычную конкатенацию. А потом столкнулся с ситуацией «просадка производительности» и открыл для себя String/Stream-Builder. Так и со всем остальным — вменяемый человек разберется со всем, если это на самом деле надо… просто не факт, что он уже с этим успел столкнуться.
                                                                    0
                                                                    Просят — сортировку простейшую. Примитивный алгоритм, который при наличии хоть какого-то алгоритмического мышления можно вывести самому в уме.

                                                                    Есть разница в запросе написать простейшую сортировку и конкретно пузырек.
                                                                    Я вот не помню, как именно написать именно пузырек, но сортировку за n^2 напишу.
                                                                    За nlogn тоже напишу, но не быструю а слиянием.
                                                                  0
                                                                  Пузырьковая скорее всего никак. А вот другие сортировки, и например работа с графами — это большое количество примеров изящного решения задач и расширения кругозора. Как итог — гибкое инженерное мышление.

                                                                  Иными словами — все эти сортировки и алгоритмы это лакмусовая бумажка. Вполне вероятно, что человек, который никогда не трогал алгоритмы и уверен что это не применимые практики — много раз ходил в обход, не зная что можно срезать. Самое забавное — что этот человек и не узнает этого.
                                                                    –1
                                                                    Вот знаете, я в работе ни разу не писала не одну сортировку. Ибо зачем писать свой велосипед, если уже всё давно написано. А вот в свое свободное время я вот прямо должна каждый день писать сортировки? У меня семья и мне нужно так же время на отдых и на изучение чего-то нового или углубление в интересующие меня темы. Нежели увлекаться сортировкой.
                                                                      0
                                                                      Вы никому ничего не должны
                                                                        +2
                                                                        еще раз перечитал комментарий, на который вы отвечали — так и не нашел букв «долж».

                                                                        Зато фрагмент " Вполне вероятно, что человек, который никогда не трогал алгоритмы и уверен что это не применимые практики — много раз ходил в обход, не зная что можно срезать. Самое забавное — что этот человек и не узнает этого." заиграл новыми красками…
                                                                +4
                                                                а что там писать-то?
                                                                list.sort(); — готово
                                                                  0
                                                                  Лучший ответ. Зачем в очередной раз изобретать велосипед, даже понарошку?
                                                                    +1
                                                                    Затем что вы на собеседовании и хотят проверить насколько вы умеете в алгоритмы.
                                                                      –1
                                                                      Прикладные программисты не изобретают алгоритмы — этим занимаются ученые.
                                                                  0
                                                                  Так… так… а компаратор?
                                                                  –1

                                                                  Вы не корректно оцениваете, синьор должен просто посылать после такого вопроса. Форма может зависеть от воспитания конкретного синьора.

                                                                  0
                                                                  Главное отличие синьора — понимание, КАК будет работать та или иная программа. А то сегодня только один из двадцати приходящих на интервью дотнетчиков может обьяснить что будет с Task, посланным на выполнение — и чем тот же Task отличается от Thread-а. И еще — почему-то куча народу думает что код, скажем на том же .NET, будучи переписанным на Java, Node или чем-то еще (или наоборот) — сразу заработает быстрее и ошибки куда-то пропадут. Нет, не из-за разных моделей потоков или алгоритмов сборки мусора (людей, знающих такие слова, мы берем даже если они не совсем правы в конкретном случае) — а просто «интуиция им подсказывает»…
                                                                    0
                                                                    Это вообще понимает любой здравомыслящий человек — важно не только какие команды ты даешь машине (пишешь «код»), но и как машина эти команды обрабатывает
                                                                      0

                                                                      Про MESI спрашиваете на собеседовании, например?

                                                                        0
                                                                        Если вы про cache invalidation — нет, до таких глубин доходим очень редко. Нам достаточно общего понимания моделей работы множественных, «зеленых» и единичных потоков — без разделяемых переменных, кэшей и т.п.
                                                                      +2

                                                                      Senior'ов определяю как тех с кем можно нормально обменяться идеями проектов за кружкой пива. С мидлами — можно пообщаться за архитектуру и всякие solid'ы, тьфу на вас. С талантливыми джунами — за хайповые тулзы.

                                                                        +2
                                                                        Название «Сеньор» — это инструмент манипуляции со стороны менеджеров. Если человек внушаемый и его самооценка зависит от чужого мнения, то он охотно клюет на такие названия. Можно назвать программиста «сеньор», «великий лорд», «повелитель машин» — суть программиста от этого не поменяется. Но довольно многим людям это приятно
                                                                          +2
                                                                          Не раскрыто самое главное, что должен уметь сеньор.
                                                                          Он должен уметь видеть вперед на много ходов и уметь правильно спроектировать приложение. Т.е. на это уровне уже главное не качество кода как таковое, а именно закладка архитектуры.
                                                                          Писать чистый код и знать все принципы могут и продвинутые джуны. Но они еще не имеют опыта и не могут предвидеть возможных тонких мест и заранее создать/заложить обходные пути.
                                                                            +8
                                                                            Не раскрыто самое главное, что должен уметь сеньор.

                                                                            Ещё есть такие мнения из разных источников:

                                                                            Сеньор умеет писать хороший код, который при этом понятный джунам.

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

                                                                            Сеньор не перебирает проектами или командами, а работает за деньги! А не из-за того что проект интересный, или простигосподи, «прикольный»..)

                                                                            Сеньор — «взрослый» человек, который умеет общаться с бизнесом. А не малолетка-соплежуй, который не может два слова связать.

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

                                                                            Сеньор выбирает стек технологий, ориентируясь на знания команды, а не на свои.

                                                                            Сеньор никогда не критикует чужой говнокод, т.к. не знает при каких обстоятельствах он был написан, как было поставлено ТЗ и какие были сроки.
                                                                              0
                                                                              Какая концентрированная годнота! Почаще бы еще встречать таких сеньоров.
                                                                                0
                                                                                Сеньор никогда не критикует чужой говнокод, т.к. не знает при каких обстоятельствах он был написан, как было поставлено ТЗ и какие были сроки.

                                                                                Обстоятельства всегда одни и те же — сроки кратчайшие, проект должен быть сдан еще вчера. Но это не служит оправданием тому, чтобы писать говнокод, ибо говнокод порождает технический долг, а технический долг — убийца бизнеса. Лучше сразу искать нормальное место работы, чем дожидаться когда всю команду разгонят.
                                                                                  0
                                                                                  «Есть в этой жизни, друг Горацио, такое, что Вашей философии не снилось» (с)
                                                                                  Ну к примеру введенный новый менеджер какой нибудь проекта хочет Вас банально кинуть на зп. Вместе со всей командой. Вывести из разработки заменив на свою команду с которой у него заключено негласное соглашение об откате. Расскажите теперь своим ребятам (вспомним ипотеки, кредитныефордыфокусы и т.д.) о техническом долге.

                                                                                  Но даже без этих крайностей в моем опыте был случай когда заказчик прямо говорил: «мы сейчас напишем говнокод» именно этими словами.
                                                                                    +1
                                                                                    А что, аргумент однако!

                                                                                    Выходит так, что говнокод куда чаще порожден говно-управленцами и их говно-менеджментом, а не низкой квалификацией разработчиков. Остаётся вопрос: зачем сеньёру с его высокой квалификацией работать с такой компании? Чтобы жизнь была мучением?

                                                                                    PS. Особенно хороший генератор говнокода — это agile. Я бы за agile сажал в тюрьму.
                                                                                      0
                                                                                      Бывает то по разному. Но больше под свой бизнес чем сами владельцы редко кто копает, исключая случаи рейдерства. Да и что всех технарей тянет быть святее Папы Римского? Уверяю Вас, в списке причин закрытия какого нибудь бизнеса (по крайней мере на территории РФ) Ваш код будет в последней десятке.
                                                                                      0
                                                                                      Ну к примеру введенный новый менеджер какой нибудь проекта хочет Вас банально кинуть на зп. Вместе со всей командой. Вывести из разработки заменив на свою команду с которой у него заключено негласное соглашение об откате.

                                                                                      Епрст, вы где работаете?! Бегите оттуда!
                                                                                        0
                                                                                        так это 99й год, коллега) мы внедряли проект интернет классов, и да, нас кинули после внедрения. И кидали еще в жизни раз ндцать на суммы, достаточные для покупки бюджетных авто, так вот вопрос который меня гложит: должен ли я испытывать гордость за идеальные внедрения не требующие сопровождения или жалость что не сгрузил этим клиентам тонны рушащегося без моего личного присутствия и постоянного бабловысасывания говнокода?
                                                                                        Не надо с придыханием говорить «убивает бизнес», коллеги. Бизнес это всего лишь люди, и зачастую очень гнилые люди.
                                                                                0
                                                                                Настоящий разработчик-сеньор — это многогранное существо, которое иногда, если речь идёт об областях, находящихся вне сферы его основной деятельности, может выглядеть как джун или мидл.
                                                                                А иногда выглядит просто как никто, сразу так и не разглядишь, за что по иронии судьбы его и увольняют и много чего непристойного делают. После чего он прячется в свой панцирь и требует от туда уважения. Но когда перед носом начинают шелестеть купюры и он начинает слышать ласковый зов подхалимов, он сразу расправляется, распускает свой слоновий… эээ хвост и начинает им стучать.
                                                                                  0

                                                                                  Какое-то бла-бла-бла ни о чем

                                                                                    0
                                                                                    сеньор это тот, кто зарабатывает как сеньор
                                                                                      +5
                                                                                      image
                                                                                        0
                                                                                        Вот оригинал статьи: medium.com/better-programming/the-marks-of-a-true-senior-developer-d5f3b11c3375, а вот: medium.com/@PurpleGreenLemon — сам автор. Интересно, откуда девушка сия в столь юном возрасте знает про техдолг, про чистый код, и т.д.? Видать, статья заказная.
                                                                                          +1
                                                                                          ей 29 лет, так что не настолько уж «юный возраст», чтобы не иметь опыта техдолга и т.д. (у меня в ее годы уже двое детей было!)

                                                                                        Only users with full accounts can post comments. Log in, please.