Как я могу попросить потенциального работодателя показать производственный код?

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

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

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

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

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

Могут ли они отказать по другим причинам, кроме плохого качества кода (конфиденциальность и т. д.)?

Если они откажутся, как мы можем прийти к соглашению, которое устроит обе стороны?

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

Я не соискатель. Ко мне обратились из-за моей квалификации, и я хотел бы оценить, действительно ли я заинтересован. Я не боюсь быть исключенным из гонки. Моя основная цель — выяснить, нравится ли мне еда, не съедая всю тарелку.

комментарии удалены: комментарии предназначены для того, чтобы помочь улучшить сообщение или получить разъяснения. Пожалуйста, не отвечайте на вопросы в комментариях. За них нельзя легко проголосовать как за лучшие ответы, и они могут непреднамеренно помешать другим пользователям дать реальные ответы. См. Как мне опубликовать полезный ответ без ответа, если он не должен быть комментарием? для получения дополнительной информации.
Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
@IanLewis, для обсуждений вы и другие пользователи можете использовать Чат Workplace . Однако комментарии на нашем сайте имеют вполне конкретную цель . В частности, смотрите разделы «Когда я должен комментировать» и «Когда я не должен комментировать» для получения дополнительной информации или см. Какие комментарии не являются? Надеюсь, это поможет прояснить. С учетом сказанного я автоматически переместил эти комментарии в их собственный чат, чтобы обсуждение этого вопроса могло продолжаться безостановочно. См. предыдущий комментарий для ссылки.
Не ответ на ваш вопрос, но следите за соответствующими краткосрочными консультационными проектами, а также за возможностью пообщаться с разработчиками, которые работают или работали с компанией (например, хакатоны).

Ответы (13)

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

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

  • Какой тип контроля версий вы используете?
  • Как команда сообщает об ошибках?
  • Проводите ли вы экспертную оценку кода?
  • Как вы гарантируете, что код, написанный одним разработчиком, будет легко читать и понимать другому?
  • Как вы поддерживаете устаревший код с течением времени?
  • Как вы держите членов вашей команды в курсе лучших практик и методов кодирования?
  • Используете ли вы какие-либо инструменты статического анализа, такие как Checkstyle, для обеспечения соблюдения стандартов кодирования? (@Райан)
  • Как долго ваш код замораживается перед релизом? (@Сандра Уолтерс)
  • Какова ваша тестовая среда? (@m24p)
  • На каком этапе разработки вы начали внедрять передовые методы кодирования? (@дотанкоэн)

РЕДАКТИРОВАТЬ:

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

+1 Совершенно логично. Я думаю, что начну с вопросов, которые вы предложили, и попрошу код только в том случае, если реакция будет уклончивой/испуганной/бормочущей.
Чтобы добавить к списку вопросов, я бы спросил о любых инструментах статического анализа или любых инструментах, которые автоматизируют процесс обеспечения соблюдения стандарта кодирования. Я знаю, что у Java есть Checkstyle.
Хм, во время реального интервью я попросил показать код несущественных частей приложения, и мне его показали. Я просто рассматривал это как часть «знакомства с компанией». Это было уже в тот момент, когда компания знала, что они хотят меня, и я, вероятно, согласилась.
+1. Небольшой пример кода мало что скажет вам вне контекста. Хороша кодовая база в целом или нет, во многом зависит от того, способствует ли весь процесс разработки созданию хорошего кода.
Также в этот список я бы добавил вопрос Как долго ваш код зависает перед релизом? Если ответ отрицательный или очень короткий, то это может быть магазин, который практикует производство... и вытекающее из этого веселье, связанное с исправлением ошибок в недавно выпущенном продукте.
Они могут делать все это, и после этого вы можете найти страницу, полную gotos, в ядре приложения C++. На самом деле нет определенного способа оценить навыки команды (или компании для небольших сценариев), не работая над ними.
Во время собеседования с потенциальными работодателями я спросил: «Какова ваша структура тестирования»? Если я не слышал об автоматизированных модульных тестах и ​​т. д., это был плохой знак. Еще один хороший общий вопрос — это те, которые заставляют интервьюера сказать что-то негативное о компании. Обычно вы найдете шаблон, который говорит вам что-то полезное. Если работоспособность кода является проблемой, кто-то может упомянуть об этом.
Я думаю, вы упустили один ключевой вопрос: каковы этапы цикла сборки и тестирования и сколько времени это занимает?
«Есть ли у вас автоматизированные процессы, такие как сборка и запуск тестов?» По сути, спросите о методах непрерывной интеграции.
Однажды я был на собеседовании, где мне показали живой код, даже не спрашивая. Ничего страшного.
В дополнение к этим вопросам не забудьте спросить, на каком этапе разработки они начали внедрять передовые методы кодирования . Я видел, как многие разработчики и компании упоминали методы написания кода, но когда код представлял собой беспорядок, они отвечали: «О, это ! Это было написано до бла-бла-бла». Конечно, это 90% кодовой базы.
«Также в этот список я бы добавил вопрос, как долго ваш код зависает перед релизом?». ИМО необходимость замораживания кода вообще является красным флагом. В них нет необходимости, если ваш код хорошо протестирован, а все развертывания полностью автоматизированы.

Если вы поддерживаете код, вы также можете предположить, что код, который вы поддерживаете, будет каким-то образом структурно дефектным.

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

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

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

4. Кроме того, если они действительно позволяют вам увидеть образец своего кода, нет гарантии, что остальная часть кода имеет такое же качество/структуру.
@Vietnhi Спасибо за ответ, Vietnhi. Согласен с вашими пунктами 1 и 2. Гарантий нет, но к вопросу это не относится. Я не боюсь быть отвергнутым - компания достаточно четко выразила свою заинтересованность. Я прошу способ оценить, должен ли я быть заинтересован также. У вас случайно нет совета на этот счет?
@kostja В конце концов, принятие предложения о работе сводится к дерьмовой съемке, в которой ты надеешься на лучшее. Если вас специально наняли для работы над новыми проектами, начиная с нуля, вы не будете работать с устаревшим кодом. По крайней мере, сначала. Младших программистов нанимают для поддержки унаследованного кода, чтобы старшие программисты могли подключиться к интересным проектам :) Во время собеседования вы можете спросить, ожидается ли ваше развертывание в новых проектах, начинающихся с нуля, или в старых. Новый проект, который включает в себя много устаревшего кода, не считается новым проектом :)
1. бессмысленно: если захотят, могут показать. И показ пары файлов из всего проекта ничего не испортит, вряд ли вы сможете их использовать.
В дополнение к тому, что написал @Lohoris: не говоря уже о нескольких минутах просмотра, о чем, вероятно, речь пойдет, если вы спросите об этом на месте. Если вы попросите, чтобы его прислали вам, это, очевидно, несколько изменит дело, но не настолько; компания, безусловно, может выбрать какую-то часть кода, которая менее критична и/или не делает ничего важного. Я мог бы извлечь некоторый код из более крупной системы, который во многих аспектах тривиален, но все же передает читателю общий стиль кода в этой системе. Я предполагаю, что это то, что ищет ОП.
@ra_htial Ваш пункт 4 точно такой же, как и пункт 2 ответа.
Это очень показательный ответ. Такая реакция на хороший вопрос меня явно тормозит. Думаю, я бы бросил интервью сразу после 3-го пункта и оставил бы тебя наедине с твоим дерьмовым кодом.
«Зачем мне вообще вас нанимать, если мне нужно беспокоиться о том, какой унаследованный код вы готовы поддерживать?» Ну разве не в этом дело? Если вы готовы нанять только кого-то, кто счастлив поддерживать дрянной устаревший код, то это, по-видимому, означает, что поддержка дрянного устаревшего кода является частью должностной инструкции, а это означает, что Костя не хочет работать на вас . Вот и весь смысл спрашивать!
@BenAronson Повсюду паршивый код. Смело выходите из бизнеса.
Первое предложение ужасно верно: если вас наняли из соображений ремонтопригодности, в первую очередь не ожидайте отличного кода.
Этот ответ Vietnhi является отрицательным и не признает, что существуют различные степени кода, существуют различные степени обслуживания или помогают ОП определить, является ли это «разумной» или «плохой» ситуацией в этой компании.
@VietnhiPhuvan - и, пожалуйста, прочитайте ответ Мхорана ниже, job.stackexchange.com/a/34137/25730, чтобы увидеть, каков реальный ответ на этот, по общему признанию, непростой вопрос.
@ThomasW А поскольку вы только что опровергли пункты 1 и 2 моего ответа, вам нужно поработать над пониманием прочитанного. Я очень плохо отношусь к твоему покровительству.
Совет @ThomasW mhoran_psprep по заключению контрактов разумен в том смысле, что подрядчик должен знать, над чем он собирается работать, прежде чем он даже подумает о торгах, но это хороший совет: у подрядчика нет возможности узнать, над каким кодом он будет работать. через две недели после пробного периода - годится ли этот код. Аналогия с заключением контрактов на благоустройство дома неверна: дом и его проблемы видны подрядчику по благоустройству дома. С унаследованным кодом дело обстоит иначе: разработчик кода совершает прыжок веры, основываясь на остальной части кода, основанном на коде, который ему было позволено увидеть.
Работодатель обязан признать, что на самом деле он нанимает кого-то для рефакторинга горы дерьма , а не для поддержки базы кода. Работодатель должен быть в курсе этого и искать кандидата, который хочет и может выполнять такую ​​​​работу. Отношение, выраженное в этом ответе, было бы обречено на провал для работодателя, потому что они, скорее всего, получат работника, который сразу же уволится, увидев код, неряшливого подхалима, который возьмет свои деньги даром, или какого-нибудь серьезного человека. новичок, который сделает только хуже.
Вопрос был не в том, чтобы попросить неограниченный доступ ко всей кодовой базе. Имея всего несколько минут контролируемого доступа к небольшой части кодовой базы, даже человеку с фотографической памятью было бы трудно получить что-то, что он мог бы использовать злонамеренно.

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

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

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

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

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

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

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

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

+1 Я бы, вероятно, получил гораздо больше информации, чем просто попросить показать мне код. Отличный совет.

Вы говорите, что не считаете себя кандидатом и не боитесь быть отвергнутым, но настаиваете на использовании термина «потенциальный работодатель»; вам нужно изменить свой фокус.

Вы хотите работать в качестве подрядчика. Они не потенциальный работодатель; они потенциальный клиент.

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

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

Вы, конечно, подпишете любые соглашения о конфиденциальности, которые они потребуют.

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

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

Я бы попытался поговорить с будущими коллегами . Желательно больше одного.

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

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

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

Просто задайте несколько вопросов, взятых из теста Джоэла :

Пример теста Джоэла

Я не думаю, что это вообще поможет в ситуации, которую описывает ОП. Он говорит: «...Я часто разочаровываюсь, поскольку оказывается, что приверженность качеству кода — это скорее фигура речи». По моему опыту, многие люди ответили бы «да» на вопросы теста Джоэла, но когда дело доходит до драки, они на самом деле не живут этим ответом «да».
@ Carson63000: и отчасти причина, по которой им это сходит с рук, заключается в том, что, как и в случае с любым кратким критерием, в любом случае есть веские причины для хеджирования некоторых пунктов Джоэла, и они превращаются в плохие причины. В качестве надуманного примера хорошей причины, если «лучший инструмент, который можно купить за деньги», часто чередуется между различными пакетами X и Y для достижения одной и той же цели, поскольку каждый из них превосходит другой с каждым новым выпуском, тогда 50% время нет, мы не используем «лучший инструмент, который можно купить за деньги», мы придерживаемся одного, чтобы избежать затрат на постоянное переключение ;-)
... точно так же я не покупаю новый процессор каждый раз, когда выпускается более быстрый. Так что почти в 100% случаев я не использую лучший инструмент, который можно купить за деньги в этой категории. У меня есть тот, который соответствует моим требованиям, но если бы нарушение для меня от получения более быстрого было нулевым, то я бы, вероятно, взял его, поэтому тот, который у меня есть, не «лучший». Но любой из моих примеров может превратиться в компанию, полную людей, использующих устаревшие инструменты, если вы никогда серьезно не оцениваете альтернативы вашим текущим инструментам и не можете ли вы улучшить то, что у вас есть. Они могут полагать, что у них есть лучшее из-за невежества
Я должен согласиться со всеми вами. Однако я думал о том, чтобы использовать качественный подход, а не количественный. Некоторые вопросы более субъективны, чем другие, поэтому я бы сначала спросил: «Используете ли вы систему управления версиями?», а если да, то я спросил бы, какой инструмент они используют, как они используют изо дня в день и т. д. Таким образом вы проявляете интерес к ваш вопрос, а не подозрение.
Я могу только согласиться; Недавно я начал задавать вопросы теста на собеседованиях, и это всегда приводило к хорошим дискуссиям с достаточным пониманием, чтобы получить представление об общем качестве / уровне наследия кодовой базы.

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

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

Утвердительный ответ на вопрос «Используете ли вы систему управления версиями?» на самом деле может быть так же ужасно, как «мы работаем с FTP и резервируем это в CVS в конце месяца». Если этот материал важен для того, собираетесь ли вы работать с этими людьми или (возможно, что более важно) сколько вы собираетесь брать с них, чтобы компенсировать их некомпетентность, вам нужно выяснить это путем непосредственного наблюдения . Люди, которые не заключают контракты с разработчиками программного обеспечения, вероятно, этого не поймут.

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

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

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

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

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

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

Мой совет? Скорее всего, вы никогда не увидите производственный код, пока не окажетесь в самой компании. И если это не соответствует вашим стандартам, просто продолжайте искать новый концерт.

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

Все очень просто: предложите подписать соглашение о неразглашении (NDA) . Это юридически (но не технически) не позволит вам использовать их код в ваших собственных проектах.

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

Я бы не стал так быстро подписывать соглашение о неразглашении — это может помешать вам не только использовать их код, но и сделать что-то подобное самостоятельно в будущем. Отказ от права самостоятельно думать над тем же фрагментом кода — это реальная цена.
Да, идея подписания NDA ЕСТЬ , чтобы вы не могли использовать их код ;-) Что еще более важно, все разработчики УЖЕ рискуют, но нарушением авторских прав, а не NDA, каждый раз, когда они «думают об одном и том же бите» кода. Подписание NDA не является проблемой именно по этой причине.
А если бы код был достаточно очевиден, чтобы вы сами додумались до него, если бы столкнулись с той же проблемой? Если вы столкнетесь с той же проблемой в будущем, вы не сможете ее решить. Это не проблема, если код, который вам показывают, действительно уникален и особенный, но вы не знаете, так ли это, когда приходите на собеседование. Я хочу сказать, что, увидев код и согласившись не использовать его, вы отказываетесь от чего-то по сравнению с тем, что никогда его не видели.
Если вы видели какой-то код и не подписали NDA, то, как говорит Эндрю, вы все равно не можете его использовать из-за авторских прав. Так что проблема здесь, если она есть, заключается в том, чтобы «просмотреть код», а не «подписать соглашение о неразглашении». NDA может сказать что угодно, например: «Я никогда не буду использовать язык программирования, на котором был написан код», и в этом случае, конечно, не подписывайте его. Но даже смутно разумное соглашение о неразглашении не помешает вам когда-либо использовать (скажем) быструю сортировку только потому, что в коде, который вы просматриваете под соглашением о неразглашении, есть быстрая сортировка. Алгоритм быстрой сортировки — это не то, что защищает NDA. Их конкретная реализация это.
... однако то, что делает NDA (и то, о чем заботится человек, чей код это заботится), запрещает вам ходить, говоря, что «компания X использует Quicksort». Простое авторское право, конечно, не мешает вам это делать, и это основная причина, по которой вы можете получить доступ к вещам под NDA, которые они не хотели бы предоставлять посторонним, просто под ограничительной лицензией, которая не позволяет вам адаптировать код самостоятельно в ваших будущих проектах. .

Спросите о:

  • Тестовое покрытие
  • TDD — разработка через тестирование
  • Как осуществляется объектно-ориентированный анализ и проектирование
  • Используют ли они принципы SOLID
  • Использование Sonar, Veracode или других инструментов анализа кода
  • Практика CI/CD
  • Самый большой класс в проекте

Я говорю ... «не тратьте время на компании, которые каким-то образом ожидают, что вы «напишете код» импровизированно. Если они действительно не верят, что вы действительно можете написать исходный код на {вставьте здесь язык программирования}, почему- черт возьми, они пригласили вас на собеседование?

Теперь – только что сказав это – я также должен признать, что «есть самозванцы». И есть также причины, по которым компании научились проводить поверхностную проверку криминального прошлого каждого кандидата...! (Я мог бы сейчас рассказать вам истории, но не буду.)

Так что - решать вам, я думаю. «Насколько сильно ты хочешь эту работу?»

Вы не можете, как в других ответах.

Однако у вас больше шансов получить от них согласие сообщить вам идентификаторы пользователей некоторых из их программистов, у которых есть учетные записи в StackOverflow и Programmer.

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

Ужасный совет. Никто не хочет, чтобы люди преследовали его в Stack Overflow. И, хотите верьте, хотите нет, но многие превосходные программисты не задают вопросов о Stack Overflow. Что бы вы сделали, если бы они сказали: «У нас нет представителей программистов с аккаунтом?
Как я могу попросить потенциального работодателя показать производственный код?
СпросиСетьПолитика конфиденциальности1y, 0v