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

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

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

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

На вашем месте я бы подал заявку либо в ИТ-консалтинговую компанию (консультационные компании потребуют от вас большего, но вы, как правило, будете работать с очень квалифицированными профессионалами и работать на пределе возможностей), либо в компанию по разработке программного обеспечения с относительно большим присутствием на рынке. Не говоря уже о крупных технологических компаниях, таких как Google или Microsoft, в которых я никогда не работал, но предположу, что их персонал должен быть близок к лучшему из имеющихся.

Удачи

Во-первых, удачи в том, чтобы они передали рабочий код кандидату.

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

Как предполагает @ User012876768, альтернативой является подача заявки в ИТ-компании Marquee, поскольку у них часто будет выбор выпускников. Я никогда не работал в такой компании, но вы можете себе представить, что у них довольно жесткие стандарты кодирования.

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

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

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

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

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

Лучший способ узнать о том, как на самом деле работает компания/отдел, — это поговорить с кем-то, кто там работает.

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

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

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

Не просто спрашивайте: «Вы следуете лучшим практикам?» потому что «лучший» очень контекстуален. Вместо этого спросите о деталях, которые вас интересуют.

Должен ли я просить о пробной работе?

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

Должен ли я приносить свои вопросы на собеседование?

Всегда приносите свои вопросы.

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

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

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

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

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

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

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

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

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

Что касается отладки чужого кода, это неизбежно. Чем моложе и менее продуктивны вы, тем больше уборки и ненужной работы вы получите. Если вы очень продуктивны, вы потратите очень мало времени на кодирование из вторых рук. Нет ничего более раздражающего, чем начинающий программист с 3000 строками в год, жалующийся на стиль базового кода. Однажды компания, в которой я работал, наняла подрядчика со слабыми способностями, которому поручили работать над некоторыми компонентами, которые составляли ничтожную часть моей продукции, и он жаловался на мой «спагетти» код. Конечно, Mr. Beautiful Code на самом деле не написал много красивого кода, и поэтому через несколько недель его уволили.

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

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

Если вы хотите узнать, как выглядит хороший код, загляните в Google Code Jam. Представления от лучших парней полностью поразили меня. Я очень хороший программист, но, глядя на это, я словно смотрю, как гроссмейстер играет в шахматы, просто потрясающе. Забудьте об объектно-ориентированной чепухе, которую извергают ваши профессора, они бесполезны; пусть парни из Code Jam будут вашими моделями, потому что они боги. Вы узнаете НАМНОГО больше, читая их код, чем какой-нибудь тупой справочник по дизайну.

Никто на 100% не согласен с лучшими практиками, тем более что рекомендации постоянно меняются.

Никто не внедряет лучшие практики на 100% по разным причинам: от прошлой истории проекта до потребностей бизнеса и авансовых затрат на их внедрение.

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

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

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