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

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

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

1. Он (очень) беспечен

Современные IDE (интегрированная среда разработки) достаточно умны, чтобы намекнуть вам на самые неосторожные ошибки, но он все же может сделать некоторые. Он будет называть переменные и методы с неправильным написанием и никогда не будет дважды проверять свою работу, прежде чем попросить своих коллег проверить. Жалко его коллегам тратить время на рецензирование его ужасных работ.

Однажды я работал в компании, где кто-то неправильно написал cookie «anonymous_id» на «annoymous_id», и он был обнаружен после того, как cookie уже был загружен в десятки тысяч браузеров. Технически мы можем решить эту проблему, но будет ли проще, если мы будем осторожны вначале?

2. Он неорганизован

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

3. Он невежественный

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

4. Он говорит на другом языке.

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

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

Вы когда-нибудь встречали в своей карьере программистов такого типа? Они наконец стали хорошими? Расскажите в комментариях!