По моему опыту, прежде чем вы начнете работать в компании, у вас нет возможности взглянуть на кодовую базу (я спрашивал, и из соображений конфиденциальности все всегда говорили «нет», я думаю, что это справедливо), поэтому во время собеседования Как вы думаете, самые важные вопросы, которые нужно задать, чтобы выяснить, в каком состоянии находится код (в конце концов, если это собака, то вы окажетесь среди бедных несчастных, которым приходится каждый день выгуливать его)?
ОБНОВИТЬ:
Контрольный список: Спросите;
- Что они думают о кодовой базе. И когда вы это сделаете, обратите пристальное внимание на выражения лица и время, которое требуется им, чтобы ответить. [Анон]
- Каков уровень CMM компании [DPD] (и если вы слышите, как Уровень 5 работает в другом направлении [Doug T])
- Какой жизненный цикл они используют [DPD] (И если вы слышите «Agile», тогда вы начинаете задавать некоторые проницательные вопросы, чтобы попытаться выяснить, означают ли «Agile» «Agile» или «ковбойское кодирование» [Carson63000])
- Какие инструменты они используют для оценки качества кода? [DPD]
- Какие инструменты они используют для разработки? [DPD] (ищите инструменты рефакторинга и серверы непрерывной сборки)
- Какую систему исходного кода (контроля версий) они используют, и хорошее продолжение - спросить, почему они ее используют. [Захари К].
- Каковы их процедуры тестирования? [Карл Билефельдт] (Особенно обратите внимание на команды, которые используют фальшивые фреймворки и делают упор на тщательном автоматизированном модульном тестировании с помощью установленных фреймворков, таких как NUnit / JUnit; не откладывайтесь на команды, которые не используют TDD для разработки через тестирование, но Осторожно, если они не считают, что тестирование является неотъемлемой частью и краеугольным камнем надежной разработки программного обеспечения. Ищите команды с преданными тестерами.)
- Какие виды заданий даются новым разработчикам? Для опытных разработчиков? [Карл Билефельдт]
- Сколько людей работает над проектом? [Карл Билефельдт]
- Разрешен ли рефакторинг? Воодушевленный? [Карл Билефельдт]
- Какие изменения в процессе или архитектуре, связанные с качеством, рассматриваются или были сделаны недавно? [Карл Билефельдт]
- Сколько автономии имеют люди над своими модулями? [Карл Билефельдт]
- Будете ли вы разрабатывать новые проекты (разработка новых месторождений) или унаследованные проекты (разработка новых месторождений)? (Разработка с нуля, как правило, более увлекательна и имеет меньше проблем, поскольку вы не исправляете чужие ошибки).
- Высока ли текучесть кадров в организации или команде? (Это часто указывает на более низкое качество кода) [M.Sameer]
- Некоторые собственные проблемы программирования; но старайтесь не казаться придурком. [Спарки]
- Как сотрудничают разработчики и как знания распространяются среди команды? (Это должно соответствовать вашей индивидуальности; я бы сказал, что сочетание одиночной и парной работы, вероятно, лучше всего, с соотношением, соответствующим вашим социальным потребностям)
- Насколько близка их база данных к 3-й нормальной форме (3NF), и если она отклоняется, где и почему? (Если они говорят «3NF ???», уходите. Если нет, и для этого могут быть веские причины, то выясните, что они собой представляют).
ПРИМЕЧАНИЕ: я принял ответ Анона, потому что примерно через неделю сообщество считает его лучшим - думаю, это говорит о том, что для этого нужно как-то развить шестое чувство. Но я думаю, что у каждого было что-то ценное, чтобы сказать.
Ответы:
Вместо того, чтобы просить увидеть их код, спросите, что они думают о базе кода. И когда вы это сделаете, обратите пристальное внимание на выражения лица и время, которое требуется им, чтобы ответить.
Затем примените свои знания о невербальных жестах вашей культуры, чтобы понять, что они на самом деле говорят. Для североамериканской компании следующее должно быть точным:
Конечно, если у вас есть проблемы с межличностным общением, это может не сработать для вас.
источник
Я удивлен, что ты даже спросил. Ни одна компания не покажет вам код, прежде чем вы присоединились. Даже к консультантам, вызванным для процесса, если они не подписали соглашение о конфиденциальности.
Вот что вы можете попросить выяснить.
источник
Это было бы от макушки моей головы. Вы заметите, что некоторые из моих вопросов относятся к процессу разработки программного обеспечения, а не только строго к кодированию. Качество последних является прямой функцией качества первых.
С учетом сказанного, когда вы задаете эти вопросы, действуйте с осторожностью. Изучите их и выберите несколько во время интервью.
Несколько вещей, которые вы должны иметь в виду. Хорошая команда разработчиков будет рада услышать, как интервьюируемый задает эти вопросы ... при условии, что они заданы тактично. Сделайте это неправильно, и вы дадите интервьюеру впечатление высокомерия и перфекционизма. Независимо от того, насколько хороша команда разработчиков, ни одна группа не является идеальной, и у них у всех есть проблемы, которые нужно решить, компромиссы в качестве и тому подобное. Они хотят командного игрока со склонностью к качеству, а не разрушительного перфекциониста. Так что будь осторожен.
Кроме того, могут быть случаи, когда у вас есть команда хороших людей, которые по внешним обстоятельствам должны работать в коде, который не соответствует качеству (они могут быть младшими разработчиками, или они просто унаследовали кучу дерьма, над которым они теперь должны работать с ограниченными ресурсы, предназначенные для повышения качества.) Вы можете работать с дерьмовым кодом и при этом иметь хороший опыт работы, если окружающие вас люди тоже хорошие (как лично, так и профессионально). Когда вы задаете вопросы, у них складывается неправильное впечатление, и они могут вообще не нанимать вас (лишая вас возможности работать с хорошими людьми в очень сложной и сложной ситуации).
Вы можете также столкнуться с дерьмовой группой разработчиков с дерьмовыми людьми. Очевидно, что их код будет хреновым, и они ответят на любой из этих вопросов. Они могут презирать вас за то, что они задают им жесткие вопросы (и, следовательно, могут оказывать вам услугу), или они будут нанимать вас, потому что вы нуждаетесь в них (даже если они / не смогут работать с вами).
Когда это происходит, тогда вы должны спросить себя, нужна ли вам эта работа так сильно. Иногда вы делаете, и вы должны окунуться в кучу спагетти дерьмо. Иногда нет (имеется в виду, что вы можете себе этого не позволить)
Это то, что вы должны принять во внимание, когда / если вы решили спросить интервьюера о качестве их кода и процессов программного обеспечения.
источник
Вместо реального качества кода я бы предпочел поискать компанию, в которой важность качества кода хорошо понятна.
Например, скажем, в компании А есть менеджеры, которые считают, что «планирование - это пустая трата времени» и «мы можем исправить проблемы проектирования позже (например, когда ад замерзнет. У нас будет время)». Даже если бы у этой компании сейчас была хорошая кодовая база, она долго не будет. И вы будете тем, кто будет (будет вынужден) сделать это хуже.
С другой стороны, скажем, у компании B плохая база кода, но руководство понимает, что качество кода вызывает все эти ошибки и задержки, они видят необходимость изменений и готовы что-то с этим делать (например, крупномасштабные рефакторинг или даже переписать). Эта компания улучшит свою кодовую базу, и вы можете помочь им в этом.
Я знаю, где я хотел бы работать.
источник
С вероятностью 99,9% вы не сможете увидеть код перед началом работы. (Если, конечно, они не выпустили бесплатный программный продукт)
Итак, что вы можете сделать, я бы спросил о процессе, в целом хороший процесс будет производить хороший код. Я бы начал с теста Джоэла и спросил о методе разработки. Также выходите за рамки основ. Например, я всегда спрашиваю, какую систему исходного кода они используют, поэтому хорошее продолжение - спросить, почему они ее используют.
источник
Место, где я работал с очень качественным кодом, практически не позволяло двум третям разработчиков касаться кода. Другие вместо этого написали сценарии автоматического тестирования черного ящика. Если вы доказали, что достойны изменить реальный код, требования были настолько чрезмерно завышены, что это была не более чем транскрипция в исходный код. Тестовые сценарии на самом деле было веселее писать.
Места, где я видел код самого низкого качества, были совершенно противоположными: только относительно неопытные или неученые программисты когда-либо касались кода, обычно потому, что это был инструмент, не имеющий прямого отношения к продукту компании или считающийся экспериментальным.
Самые приятные места для работы имеют баланс. Новым разработчикам дают реальные задания, но наставничество. Существует хороший отдел QA и процесс экспертной оценки, чтобы поймать ваши ошибки. Вы не наказаны за ошибки, но должны исправлять их и учиться на них. Иногда плохо написанный модуль проваливается, но вас не критикуют за то, что вы тратите время на улучшение качества кода, когда сталкиваетесь с ними. Компания в целом постоянно ищет новые способы улучшить код.
Поэтому вопросы, которые я хотел бы задать для оценки качества кода:
источник
Как сказали @DPD и @Zachary, процесс и SDLC являются очень важными факторами, но я хочу добавить некоторые другие факторы, которые, по моему опыту, оказывают существенное влияние на качество кода:
Обратите внимание, что процесс очень помогает, но он не даст полного иммунитета против вышеуказанных факторов. Когда многие разработчики передают проект, каждый приходит с другим мышлением. Архитектор и разработчик не будут следовать точному пути своих предшественников, что приведет к некоторым несоответствиям.
источник
Мое отношение таково: код есть код, если он плохой, ну, это задача сделать его лучше. Если это хорошо, ну, это еще сложнее сделать его лучше!
Самое важное для меня - хочу ли я работать на компанию и людей, с которыми у меня есть возможность взаимодействовать. Код может быть изменен, люди не могут ...
источник
Слегка в шутку говорю, интервью со мной .
Обычно я использую фактическую ошибку (уже исправленную) в нашей кодовой базе в качестве теста для собеседования, поэтому вы видите некоторый реальный код. Обычно немного сложный код, и в нем есть ошибка.
Я призываю всех использовать эту технику, поскольку вы уже знаете, что ошибка реальна, проблема реальна, и вы знаете, сколько времени потребовалось, чтобы найти и исправить.
Самое замечательное в том, что у тебя могут быть измеримо трудные проблемы.
В качестве вопроса о последнем интервью я использовал очень сложную проблему, чтобы отделить экспертов от довольно хороших.
Актуальность вопроса ОП заключается в том, что каждый, кто придет на физическое собеседование, увидит какой-то код. (Не с конфиденциальным контентом компании)
Если вы не можете использовать эту технику, скажем, ненормативную лексику в кодовой базе, тогда тест работает, поскольку потенциальные сотрудники спросят «могу ли я увидеть код», и ответ будет «о, вы не можете полный ненормативной лексики ".
Конечно, стандартный ответ «все дело в секрете компании» - полный хоккей.
Мое доказательство: у моего предыдущего работодателя неконфиденциальная часть военной продукции была образцом кода для вопроса об интервью. [К счастью, не классифицировано]
Я оставляю проблему определения качества секретных проектов перед тем, как работать там кому-то умнее меня. Я предполагаю, что это может быть обычным делом, что классификация является синонимом свободного контроля.
источник
Сомнительно, что они позволят вам увидеть свой код, но вы, возможно, сможете понять, на что это может быть похоже, если вы дадите им домашнее задание по программированию. Во многих местах респонденты получают домашнее задание по программированию, которое они могут использовать, чтобы оценить вас. Верните услугу - ожидайте одного из них, чтобы вы могли лучше оценить, во что вы могли бы втянуть себя.
источник
Спросите, что требуется для кода, чтобы сделать его в производственной сборке. Если вы получите «эээ ... разработчик совершает это ...», то это почти наверняка мусор.
Есть ряд вещей, которые имеют тенденцию повышать качество кода (очевидно, нет никаких гарантий).
Это может помочь улучшить не только прочность кода, но и качество кода.
источник
Спросите их о модульном тестировании. Если они воспримут это всерьез, то у интервьюера, вероятно, будут определенные мнения по этому вопросу, и он будет рад поделиться ими. Если ответы расплывчаты, это большой предупредительный знак.
Если это магазин Java, спросите их, какую библиотеку ORM они используют. Если они свернули свои собственные, то это могло бы пойти в любую сторону - это могло бы отстой, или это могло бы быть хорошо. Если они не используют, бегите к двери прямо сейчас.
Это трудная задача, потому что существует так много разных плохих методов кодирования, что вы никогда не сможете предсказать их все.
источник
Вы не можете, к сожалению. Ни одна компания не позволит вам увидеть их код (но они попросят увидеть ВАШ код ...), и есть вероятность, что вы зададите им вопросы об окружении, в котором вы либо будете полностью обмануты («Контроль версий? Конечно ... мы используем ... э-э ... думая Sub .. Sub-что-то ") или заблуждаемся по поводу качества (" Мы используем новейшую и самую лучшую версию .NET 4 "только для того, чтобы узнать, что при использовании .NET 4 они ' переписываешь как .NET 1.1).
В прошлом я был сожжен этим много раз, и мне еще предстоит найти хороший способ оценить качество. Обычно лучший способ - использовать собственное суждение, и если оно сводится к нему, немедленно уйти, если оно хуже, чем вы думали; Вы могли бы закончить работу бункером, но вы сохраните здравомыслие.
источник