У нас тест является обязательным при наборе, идет вдобавку к резюме.
Беглый взгляд на тест (5 задачи, пхп, базы, ксс+js, архитектурная) позволяет отсеять 90% людей, которые не подходят.
Зачем тратить свое время на собеседование, у вас других задач мало?
Дайте 3-5 задач типа тычки-галочки + две такие свободные, где надо порассуждать, и не принимайте на собеседование без них.
А тех, кто по тесту нравится, гоняйте по опыту и бэкграунду. Я обычно по кода теста общаюсь + 15 блиц вопросов, остальное спрашиваю, чего человек по жизни делал, к чему стремится и так далее.
>Масло маслянное? В ошибках программирования, наверное тоже, виноват только программист.
Ну модно (и я был таким раньше, и иногда бываю сейчас) обвинять кого угодно, только не себя. Не те программисты — вот посыл статьи.
>Автор предыдущей статьи был абсолютно прав в том, что для каждой работы есть некий стереотип человека, который будет эту самую работу лучше всего выполнять. Грубо говоря, человеку с лидерскими и безнес-скилами работать на «конвеере сайтов» будет ни разу не интересно. Ошибкой автора было перенести свой стереотип на остальные проекты (дескать всем нужны только забитые ботаники.)
Ну и я высказал свое мнение на этот счет, насчет идеального. Цитирую: «Идеальный программист не пишет плохой код, не срывает сроков и не существует.»
>Так что — да, каждый программист уникален. Что, однако, не мешает вам выбирать из программистов тех, кто лучше всего справится с Вашими задачами, и не уйдёт раньше срока.
спасибо за замечание.
откорректировал, добавил, что это только мое мнение, плюс смягчил формулировку.
это сугубо мой опыт анализа ухода нескольких десятков программистов, и необязательно верный. но удивительным образом работающий даже в несхожих с моей управленческой практикой ситуациях. вообще, брать на себя ответственность и думать, как избежать чего-то негативного в будущем, даже если это было случайностью — хороший момент для собственного развития.
ну там уже до нас было кеширование в виде файлов. изначально структура была слишком крутая и универсальная, и все варианты показа баннеров обсчитывались в ПХП ООП :) мы упростили структуру еще к тому же, провели рефакторинг.
Мы переписывали движок баннерокрутилки, полученный от коллег. Наш хороший разработчик переписал все на ООП PHP. Мы пытались что-то оптимизировать, но оно даже под абешкой не взлетало (50 запросов в секунду должно плевать с одного сервака, получали 99% fails).
В конце-концов в результате оптимизаций на профайлинге стала очевидность важности правильной архитектуры. Ниже этапы оптимизации и вывод.
1. Сначала убрали лишнее ООП. Помогло, не сильно
2. Увидели, что крутые ООП-оболочки над БД сильно тормозят. Переписали на голом PDO
3. Но и голое PDO стало тормозить. 90% времени съедает, 400 мс.
4. По моему предложению перенесли логику в БД. Так как там была операция в цикле и ряд запросов.
5. Сначала хранимки в БД написали " в лоб" — циклы и тд. Помогло, не сильно — 50% не работало под нагрузкой.
6. С участием нашего DBA, выдающего специалиста, переделали циклы в хранимке на язык реляционной БД — в один запрос, убрали временные таблицы из логики, и так далее.
7. В итоге менее 10% фейлов, и система стала жить на нагрузке.
Вывод — правильная архитектура решает, правильный выбор инструментов для размещения логики того или иного вида.
А вовсе не тупые оптимизации, вроде давайте заменим двойные кавычки на одинарные, или там заменим кусок сишного кода на ассемблер. А умные, которые неразрывно связаны с проникновением в предметную область задачи и понимания условий, в которых приложение будет работать.
Для того, чтобы люди ассоциировали какие-то НЕХ с реальностью, часто нужно их наделять эмоциональными поступками, и нередко — антропологичностью.
Почитайте у Каганова на эту тему. Супер-повесть про кротовые норы отсасывает, а повесть про живую машину вдруг становится популярной. Хотя в первой ДОСТОВЕРНОСТИ может быть миллион. А способности ВЫЗЫВАТЬ ЭМОЦИИ у зрителя/читателя — минимум.
Такой стиль вашего коммента бесит. Это вы издеваетесь?
Значит, давайте по-порядку.
Во-первых, я в той статьей дополнил каждый пункт личным примером. Вы плохо смотрите.
Во-вторых, аяксовое сохранение по CTRL+Enter мне было не сразу понятно. Оно скидывает в черновики, хотя логичнее было бы публиковать (именно эта кнопка основная).
В-третьих, где запрещение этого правилами?
В-четвертых, я стараюсь писать содержательные статьи, и о разном. Сам не люблю воду.
Десяток, сайты визитки, средненькие и интернет магазины. Надоеоло потому, что это конвеер и рутина. Щас уже знаю, что либо нало было стандартизировать, автоматизировать и продавать в десять раз больше, либо паспозиционироваться и добиться успешых продаж за цену в десять раз больше. А тогда мыслил только как программист и интепеса не видел
в основном, у меня стартапы не взлетали по другим причинам
— неверный рынок. сильная конкуренция, высокий порог входа
— неверная модель монетизации, думали о продукте, а не о том, как заработать денег
— слабая управленческая сторона вопроса
но некоторые взлетели. самое простое и незатейливое взлетело :)
Отмечу, что мне нравится ООП в Джаве, она в этом плане реально рулит. Ну и стек готовых технологий, фреймворков очень достоин, ничуть не хуже плюсов по полноте)
Кого-то тошит от плюсов и он боготворит Джаву, или си шарп.
А так, любой язык под свои задачи. Офисную автоматизацию я писал на Дельфях, клиент-серверное приложение для управление роботом Кавасаки на с++, под веб — в зависимости от задач, ASP/.NET, потом был перл, питон, пхп.
Все это можно и на Джаве, и на сях написать с определенными усилиями, но зачем?
и Java, и .NET обладает рядом существенных недостатков (и технических, и организационных, связанных с разработкой на этих платформах и разработчиками).
пожалуй, по универсальности, скорости, уровню интеграции с железом напрямую и мощи я признаю один язык — чистый си. с++ еще можно добавить как улучшенную версию, мощь ООП и ряд других плюшек.
впрочем, в современном мире железом можно заткнуть даже тормозную и глюкавую платформу. и это дело вкуса, как говорится.
Я у себя выбросил ежедневные митинги, совещания и тд.
только при необходимости.
плюс у меня есть правило четырех часов тишины.
оттуда
>- ежедневно надо так распределять время, чтобы у программиста было не менее 4х часов «тихого» рабочего времени в это время он отключает скайп и аську, остается доступен только через почту и джаббер.
>Недавно показательная вещь случилась. Говорю: полдня надо еще, чтобы полностью покрыть тестами. Человек, который уж очень хочет забрать код, говорит: «не надо, мы тебе и так доверяем». В итоге нашли баг, который был как раз в том месте, не покрытом тестами. Но они потратили 2 дня на его поиски. (не ТДД, каюсь, но то был проект — взять готовый код, оптимизировать и рефакторить).
если проджект адекватный и есть ведущий программист в группе, то проджект с ведущим это решат
проджект сумеет рассчитать экономический эффект от тестов (очевиден — 0.5 дня против двух * ставки людей за это время + потери необслуженных клиентов) для обоснования времени заказчикам.
а ведущий(=тимлид) будет уверен, что качество ценят, и уверит команду как «свой»
коммуникации рулят.
>Потому что рефакторинг — часть процесса, он должен быть незаметным и проводиться всё время. А если тормознули на полгода, значит говнокодили до этого долго и дошли до точки.