Как вы определяете качество кода потенциального работодателя, прежде чем занять должность? [закрыто]

31

По моему опыту, прежде чем вы начнете работать в компании, у вас нет возможности взглянуть на кодовую базу (я спрашивал, и из соображений конфиденциальности все всегда говорили «нет», я думаю, что это справедливо), поэтому во время собеседования Как вы думаете, самые важные вопросы, которые нужно задать, чтобы выяснить, в каком состоянии находится код (в конце концов, если это собака, то вы окажетесь среди бедных несчастных, которым приходится каждый день выгуливать его)?

ОБНОВИТЬ:

Контрольный список: Спросите;

  • Что они думают о кодовой базе. И когда вы это сделаете, обратите пристальное внимание на выражения лица и время, которое требуется им, чтобы ответить. [Анон]
  • Каков уровень CMM компании [DPD] (и если вы слышите, как Уровень 5 работает в другом направлении [Doug T])
  • Какой жизненный цикл они используют [DPD] (И если вы слышите «Agile», тогда вы начинаете задавать некоторые проницательные вопросы, чтобы попытаться выяснить, означают ли «Agile» «Agile» или «ковбойское кодирование» [Carson63000])
  • Какие инструменты они используют для оценки качества кода? [DPD]
  • Какие инструменты они используют для разработки? [DPD] (ищите инструменты рефакторинга и серверы непрерывной сборки)
  • Какую систему исходного кода (контроля версий) они используют, и хорошее продолжение - спросить, почему они ее используют. [Захари К].
  • Каковы их процедуры тестирования? [Карл Билефельдт] (Особенно обратите внимание на команды, которые используют фальшивые фреймворки и делают упор на тщательном автоматизированном модульном тестировании с помощью установленных фреймворков, таких как NUnit / JUnit; не откладывайтесь на команды, которые не используют TDD для разработки через тестирование, но Осторожно, если они не считают, что тестирование является неотъемлемой частью и краеугольным камнем надежной разработки программного обеспечения. Ищите команды с преданными тестерами.)
  • Какие виды заданий даются новым разработчикам? Для опытных разработчиков? [Карл Билефельдт]
  • Сколько людей работает над проектом? [Карл Билефельдт]
  • Разрешен ли рефакторинг? Воодушевленный? [Карл Билефельдт]
  • Какие изменения в процессе или архитектуре, связанные с качеством, рассматриваются или были сделаны недавно? [Карл Билефельдт]
  • Сколько автономии имеют люди над своими модулями? [Карл Билефельдт]
  • Будете ли вы разрабатывать новые проекты (разработка новых месторождений) или унаследованные проекты (разработка новых месторождений)? (Разработка с нуля, как правило, более увлекательна и имеет меньше проблем, поскольку вы не исправляете чужие ошибки).
  • Высока ли текучесть кадров в организации или команде? (Это часто указывает на более низкое качество кода) [M.Sameer]
  • Некоторые собственные проблемы программирования; но старайтесь не казаться придурком. [Спарки]
  • Как сотрудничают разработчики и как знания распространяются среди команды? (Это должно соответствовать вашей индивидуальности; я бы сказал, что сочетание одиночной и парной работы, вероятно, лучше всего, с соотношением, соответствующим вашим социальным потребностям)
  • Насколько близка их база данных к 3-й нормальной форме (3NF), и если она отклоняется, где и почему? (Если они говорят «3NF ???», уходите. Если нет, и для этого могут быть веские причины, то выясните, что они собой представляют).

ПРИМЕЧАНИЕ: я принял ответ Анона, потому что примерно через неделю сообщество считает его лучшим - думаю, это говорит о том, что для этого нужно как-то развить шестое чувство. Но я думаю, что у каждого было что-то ценное, чтобы сказать.


источник
Заливайте их продукт, разбирайте его и читайте.
Работа
4
@Job - даже если есть публичная программа для покупки, дизассемблированный код вряд ли будет напоминать не скомпилированный код.
P.Brian.Mackey
Спросите, кому принадлежит код, кто отвечает за качество. Если ответ «все делают, коллективная собственность, совместная ответственность», это может быть беспорядок. Если определенные детали назначаются конкретным лицам, чья работа заключается в том, чтобы поддерживать и охранять их конструкцию, это, вероятно, будет лучше.
Мартин Маат

Ответы:

19

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

Затем примените свои знания о невербальных жестах вашей культуры, чтобы понять, что они на самом деле говорят. Для североамериканской компании следующее должно быть точным:

  • Небольшое пожатие плечами и быстрый ответ «могло бы быть и лучше»: это, вероятно, довольно хорошо.
  • Длинная пауза, вдох, возможно, небольшой смех: это не приятно, и люди, с которыми вы беседуете, не чувствуют себя комфортно, рассказывая вам это.
  • Закатанные глаза, быстрый ответ «это отстой»: может быть хорошо, может быть плохо, но происходят политические игры. Если вы не готовы играть в эту игру или быть тихим, оставайтесь в стороне.
  • Поднятые или сжатые брови: они не понимают вопроса, а кодовая база почти наверняка гнилостная.

Конечно, если у вас есть проблемы с межличностным общением, это может не сработать для вас.

скоро
источник
1
Lol .......... :)
6
Это не говорит вам о состоянии кода, а говорит о том, что менеджеры, опрашивающие вас, считают состояние кода. Не помогает, если они были введены в заблуждение или активно обманывают себя об этом.
Джеймс
5
Я ожидаю интервью с кем-то, кто активно разрабатывает программное обеспечение; даже если бы они были исключительно архитекторами, я бы ожидал, что они прочитают написанный код.
1
@B Тайлер: Что такое «исключительно архитектор»? Там, где я работаю, архитектор хорошо знаком с кодом, потому что он написал или помог написать значительный процент от него.
Мейсон Уилер
1
@James - если у вас нет шанса дать интервью вашим потенциальным сверстникам, это вам что-то говорит, не так ли? Это, конечно, скажет мне что-нибудь.
Anon
11

Я удивлен, что ты даже спросил. Ни одна компания не покажет вам код, прежде чем вы присоединились. Даже к консультантам, вызванным для процесса, если они не подписали соглашение о конфиденциальности.

Вот что вы можете попросить выяснить.

  • Каков уровень CMM компании (в идеале 5)
  • Каков процесс, который используется в вашем предполагаемом проекте (кстати, спросить, это хорошо, потому что это показывает, что вы заинтересованы в «этой» работе, а не просто в любой работе)
  • Какой жизненный цикл они используют (не осуждайте, если вы не слышите «Agile». У них может быть веская причина для использования моделей старой школы)
  • Спросите, используют ли они какие-либо инструменты и метрики для проверки качества кода. И если да, то какой (если они используют хотя бы один инструмент для метрик, а другой для качества, это хороший знак).
  • Также обратите внимание, какие инструменты они используют. Если это дорогостоящий инструмент, такой как Resharper, а не какой-либо бесплатный инструмент, то он серьезно относится к качеству.
DPD
источник
4
Архитектор может обойти здание предполагаемого работодателя и увидеть качество работы, которую он выполняет. Инженер может физически увидеть внутреннюю часть произведенного продукта; но часть программного обеспечения - это черный ящик. Почему бы не попросить увидеть код?
8
И если вы делаете услышать «Проворный», что, когда вы начинаете задавать некоторые проницательные вопросы , чтобы попытаться выяснить , если по «Agile» , они означают «Agile или„ковбой кодирования“.
Carson63000
26
Тьфу, если бы я услышал CMM уровня 5, я бы бежал в другую сторону.
Дуг Т.
2
@ Carson63000 «Agile» или «ковбойское кодирование» '(я думал, что это почти одно и то же!)
3
@B Тайлер: Зинг! А если серьезно, я знал ряд интервьюеров, которые думали, что определение «Agile» было «не водопадом»; они не понимали, что после того, как вы выбросили модель водопада, вам действительно нужно было заменить ее другим процессом.
Carson63000
10
  1. Спросите их, если они используют систему контроля версий.
    • Нет управления источником? -> код скорее всего хреновый
  2. Спросите их, как часто делают обзоры кода.
    • Нет проверки кода? -> код может быть подозрительным (но не обязательно, особенно если это небольшая команда, состоящая из достойных разработчиков.)
  3. Спросите их, как они тестируют и разворачивают перед началом производства?
    • Нет тестовой среды? Прямое развертывание в производство? -> код, скорее всего, дерьмовый.
  4. Спросите их, выполняют ли они непрерывную интеграцию (.ie. Запуск сборок с Hudson)
    • Нет непрерывной интеграции? -> Код может быть подозрительным, но не обязательно так.
  5. (Относится к # 3), спросите их, является ли их тестовая среда отдельной от вашей среды разработки?
    • Тест это дев? -> не очень хороший знак, если только они действительно не нуждаются в деньгах, но насколько дорогой будет дополнительная коробка?
  6. Спросите их, проверяют ли они список действий перед развертыванием в производство.
    • Нет обзора действий до развертывания производства? -> Плохо жужу.
  7. Спросите их, сколько шагов нужно для того, чтобы сделать сборку.
    • Более 3? -> Как правило, плохо жужу.
  8. Используют ли они (или предполагают) метрики кода, такие как цикломатическая сложность или LCOM (мера связности классов).
    • Да? -> возможно (но не обязательно) хороший знак в отношении качества их кода.
    • Нет, но они понимают понятия (хотя бы цикломатическая сложность)? -> Трудно сказать
    • Они думают, что цикломатическая сложность - это экзотическое блюдо или афродизиак из Тимбукту (другими словами, они не знают, что это такое)? -> Возможна плохая дзюю.
    • Они думают, что это неуместное дерьмо (или что-то подобное)? -> убежать.
  9. Спросите их, как они отслеживают ошибки.
    • Они отслеживают количество ошибок по некоторым показателям (например, по каждому проекту, количеству измененных модулей или количеству требований / запросов на изменение, что-то!)? -> хороший знак об их коде (и их программном процессе).
    • Они делают вышеуказанное и пытаются предсказать количество возможных ошибок, с которыми они могут столкнуться в будущем (или продолжающемся) проекте, основываясь на ожидаемом показателе (количество запросов на изменение, размер проекта и т. Д.)? -> очень хороший знак.
    • Они отслеживают ошибки только для устранения ошибок? -> Трудно сказать
    • Нет последовательного отслеживания? -> убежать.

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

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

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

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

  • Кстати, я искренне верю, что разработчик программного обеспечения должен хотя бы один раз поработать с каким-то кодом, который превосходит все надежды (или почти превосходит надежды). Вы переживете это и получите хорошую работу, это ценный урок.

Вы можете также столкнуться с дерьмовой группой разработчиков с дерьмовыми людьми. Очевидно, что их код будет хреновым, и они ответят на любой из этих вопросов. Они могут презирать вас за то, что они задают им жесткие вопросы (и, следовательно, могут оказывать вам услугу), или они будут нанимать вас, потому что вы нуждаетесь в них (даже если они / не смогут работать с вами).

Когда это происходит, тогда вы должны спросить себя, нужна ли вам эта работа так сильно. Иногда вы делаете, и вы должны окунуться в кучу спагетти дерьмо. Иногда нет (имеется в виду, что вы можете себе этого не позволить)

Это то, что вы должны принять во внимание, когда / если вы решили спросить интервьюера о качестве их кода и процессов программного обеспечения.

luis.espinal
источник
8

Вместо реального качества кода я бы предпочел поискать компанию, в которой важность качества кода хорошо понятна.

Например, скажем, в компании А есть менеджеры, которые считают, что «планирование - это пустая трата времени» и «мы можем исправить проблемы проектирования позже (например, когда ад замерзнет. У нас будет время)». Даже если бы у этой компании сейчас была хорошая кодовая база, она долго не будет. И вы будете тем, кто будет (будет вынужден) сделать это хуже.

С другой стороны, скажем, у компании B плохая база кода, но руководство понимает, что качество кода вызывает все эти ошибки и задержки, они видят необходимость изменений и готовы что-то с этим делать (например, крупномасштабные рефакторинг или даже переписать). Эта компания улучшит свою кодовую базу, и вы можете помочь им в этом.

Я знаю, где я хотел бы работать.

nikie
источник
Это ударило гвоздь по голове.
Уэйн Молина
6

С вероятностью 99,9% вы не сможете увидеть код перед началом работы. (Если, конечно, они не выпустили бесплатный программный продукт)

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

Захари К
источник
... или если они не предоставляют исходный код со своим патентованным продуктом. В моей сфере деятельности (НЛП) LingPipe поставляется таким образом, и должны быть другие продукты, поставляемые с источниками.
Фред Фу
6

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

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

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

Поэтому вопросы, которые я хотел бы задать для оценки качества кода:

  • Каковы ваши процедуры тестирования?
  • Какие виды заданий даются новым разработчикам? Для опытных разработчиков?
  • Сколько людей работает над проектом?
  • Разрешен ли рефакторинг? Воодушевленный?
  • Какие изменения в процессе или архитектуре, связанные с качеством, рассматриваются или были сделаны недавно?
  • Сколько автономии имеют люди над своими модулями?
Карл Билефельдт
источник
Важный факт здесь: (для вас) важно не качество базы кода, а то, насколько приятным является рабочее место в целом (и насколько вероятно, что компания будет оставаться там хотя бы столько, сколько вы захотите остаться).
gnasher729
5

Как сказали @DPD и @Zachary, процесс и SDLC являются очень важными факторами, но я хочу добавить некоторые другие факторы, которые, по моему опыту, оказывают существенное влияние на качество кода:

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

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

M.Sameer
источник
1
Я думаю, что реакция на высокий уровень текучести кадров является очень хорошим показателем ... Присутствие за провалившимся проектом, как правило,
вредно
1
@ webdad3: когда причина оборота не связана с проектом, например, с недоплатой, проект становится жертвой оборота. Это будет продолжаться до тех пор, пока оборот не вызовет значительных проблем в проекте и код не станет действительно плохим. На этом этапе повышение заработной платы не решает проблему, и оборот продолжается, и, как вы указали, состояние проекта становится невыносимым для разработчиков, чем меньше клиентов удовлетворены, и тем меньше прибывает прибыль, которая снова вызывает недоплату и увеличивает оборот. Это как эффект снежного кома.
М.Самир
3

Мое отношение таково: код есть код, если он плохой, ну, это задача сделать его лучше. Если это хорошо, ну, это еще сложнее сделать его лучше!

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

Nim
источник
4
Продукт не просто появился, люди и компания его создали. Если код плохой, нет оснований полагать, что он когда-либо будет лучше.
Крис Питман
@ Крис, это пораженец! ;) Есть много причин для плохого кода, но если отношение людей есть то, которое стремится к изменениям, почему бы и нет?
Ним
потому что, если они стремятся к хорошему коду, но их код плох, у него все еще есть причина. Очень часто это политические причины, по которым вы можете бороться против всего, что хотите. Есть достаточно мест, где нужно искать программистов, и вам не нужно брать неоптимальную работу, если только это не то, что вы ищете.
Крис Питман
Даже если есть хорошие люди, разрабатывающие программное обеспечение, которое стало плохим по историческим причинам, которые признают его плохим и хотят изменить его, изменить его все еще очень сложно. Даже с руководством, которое понимает, что такое технический долг и какие проблемы оно вызывает, разработать стратегию долгосрочных архитектурных изменений и заставить руководство расставить приоритеты по сравнению с краткосрочными запросами функций очень сложно.
1
Не могу согласиться. Хорошие разработчики знают плохой код и безжалостно уничтожают его; если код плохой, есть причина для этого (либо плохие разработчики, невежественное управление, безумные сроки или любая их комбинация), и эта причина навсегда заставит код быть плохим, потому что иначе код не был бы плохим с самого начала ,
Уэйн Молина
3

Слегка в шутку говорю, интервью со мной .

Обычно я использую фактическую ошибку (уже исправленную) в нашей кодовой базе в качестве теста для собеседования, поэтому вы видите некоторый реальный код. Обычно немного сложный код, и в нем есть ошибка.

Я призываю всех использовать эту технику, поскольку вы уже знаете, что ошибка реальна, проблема реальна, и вы знаете, сколько времени потребовалось, чтобы найти и исправить.

Самое замечательное в том, что у тебя могут быть измеримо трудные проблемы.

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

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

Если вы не можете использовать эту технику, скажем, ненормативную лексику в кодовой базе, тогда тест работает, поскольку потенциальные сотрудники спросят «могу ли я увидеть код», и ответ будет «о, вы не можете полный ненормативной лексики ".

Конечно, стандартный ответ «все дело в секрете компании» - полный хоккей.
Мое доказательство: у моего предыдущего работодателя неконфиденциальная часть военной продукции была образцом кода для вопроса об интервью. [К счастью, не классифицировано]

Я оставляю проблему определения качества секретных проектов перед тем, как работать там кому-то умнее меня. Я предполагаю, что это может быть обычным делом, что классификация является синонимом свободного контроля.

Тим Виллискрофт
источник
2

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

Спарки
источник
Я думаю, что задание может подтолкнуть его, хотя это отличная идея, но я определенно подумал о том, чтобы задать несколько вопросов по программированию: было ли это приемлемым, будет моим следующим вопросом.
Я согласен, что это может подтолкнуть, но мне также интересно, есть ли обстоятельства, когда потенциальный работодатель может пожелать - скажем, после того, как он продлил предложение, возможно? Просто пытаюсь думать за пределами пресловутой рамки (ага, я ненавижу это выражение).
Спарки
+1 Мне нравится идея, но если вы им не очень нравитесь, большинство интервьюеров скажут вам сделать прыжок в беге.
Orbling
2

Спросите, что требуется для кода, чтобы сделать его в производственной сборке. Если вы получите «эээ ... разработчик совершает это ...», то это почти наверняка мусор.

Есть ряд вещей, которые имеют тенденцию повышать качество кода (очевидно, нет никаких гарантий).

  • Статический анализ (в .NET это такие вещи, как fxcop / stylecop)
  • Подмножество (или полный набор) набора тестов - модуль / интеграция / регрессия / руководство и т. Д.
  • Приятная сборка (другой разработчик в команде создает изменения, чтобы увидеть, есть ли какие-либо проблемы, зависящие от машины / пользователя - иногда также выполняется быстрое исправление)
  • Обзор кода

Это может помочь улучшить не только прочность кода, но и качество кода.

Стивен Эверс
источник
1

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

Если это магазин Java, спросите их, какую библиотеку ORM они используют. Если они свернули свои собственные, то это могло бы пойти в любую сторону - это могло бы отстой, или это могло бы быть хорошо. Если они не используют, бегите к двери прямо сейчас.

Это трудная задача, потому что существует так много разных плохих методов кодирования, что вы никогда не сможете предсказать их все.

Майк Баранчак
источник
1

Вы не можете, к сожалению. Ни одна компания не позволит вам увидеть их код (но они попросят увидеть ВАШ код ...), и есть вероятность, что вы зададите им вопросы об окружении, в котором вы либо будете полностью обмануты («Контроль версий? Конечно ... мы используем ... э-э ... думая Sub .. Sub-что-то ") или заблуждаемся по поводу качества (" Мы используем новейшую и самую лучшую версию .NET 4 "только для того, чтобы узнать, что при использовании .NET 4 они ' переписываешь как .NET 1.1).

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

Уэйн Молина
источник