1. Ну согласен, конечно, бывают и хорошие патентованные алгоритмы и т.д.
2. Про сборку и запуск проекта — лично у меня это принципиальная позиция, проект должен собираться и запускаться легко, это как тест. Если это не так, значит нужно потратить время и сделать чтобы это было так, иначе проект представляет из себя очень хрупкую субстанцию.
3. Тут тоже понимаю что такое может быть, а часто так и бывает. Но, это ужасно не эффективно. Менеджеру такого проекта 2 в дневник и идти обратно переучиваться. Одна из типовых рекомендация в таком случае — рефакторить. разбивать на модули, документацию переписывать/писать в тестируемые spec-и.
То есть о чем я хочу сказать, понятно что это может работать не во всех случах, но также понятно что в тех случаях, зачастую низкий уровень организованности проекта.
А как должен выглядеть процесс отбора кандидата на ваш взгляд? Если объективно, учитывая все ваши тредования/опасения как разработчика, а также учитвая нюансы компании, что в нее приходит 5-10 писем от кандидатов ежедневно?
Предлагаю пофантазировать и найти взаимовыгодный механизм.
К счастью нам не нужны «показатели реальных знаний и умений», нам от веб-разработчика требуется на самом деле не многое — эффектинове выполнение задач из списка, который уже составили взрослые дяди.
Понимаю что не многим это нравится, поэтому сразу и сообщаю.
Если разработчик чувствует себя взрослым дядей достойным раздавать задачи и заниматься проектированием это уже другой вопрос, другая должность и иная методика отбора.
Про посмотреть код приложения — очень резоный довод. Да и локально приложение тоже должно запускаться с полпинка со всеми тестами, это показатель отношения к новичкам.
Не работу, а задание. Если он нам не подошел, значит и задание не выполнял, оплачивать нечего. Если выполнил, то оплачивается в независимости от того сошлись по работе или нет.
А что мешает поговорить? Мне не очень интересно резюме разработчика, я его и не спрашиваю, общих вопросов достаточно, а ему, возможно, мое резюме интересно — так никто не запрещает его у меня спросить.
Тем более если он мне написал, то наверное уже что-то знает обо мне и хочет тут работать.
2. Про сборку и запуск проекта — лично у меня это принципиальная позиция, проект должен собираться и запускаться легко, это как тест. Если это не так, значит нужно потратить время и сделать чтобы это было так, иначе проект представляет из себя очень хрупкую субстанцию.
3. Тут тоже понимаю что такое может быть, а часто так и бывает. Но, это ужасно не эффективно. Менеджеру такого проекта 2 в дневник и идти обратно переучиваться. Одна из типовых рекомендация в таком случае — рефакторить. разбивать на модули, документацию переписывать/писать в тестируемые spec-и.
То есть о чем я хочу сказать, понятно что это может работать не во всех случах, но также понятно что в тех случаях, зачастую низкий уровень организованности проекта.
Предлагаю пофантазировать и найти взаимовыгодный механизм.
Понимаю что не многим это нравится, поэтому сразу и сообщаю.
Если разработчик чувствует себя взрослым дядей достойным раздавать задачи и заниматься проектированием это уже другой вопрос, другая должность и иная методика отбора.
У нас есть INSTALL.txt который периодически дописывают ребята, столкнувшиеся с неожиданными трудностями.
В Ruby кстати с этим проще, там практически все устанавливается сразу парой стандартных команд.
Тем более если он мне написал, то наверное уже что-то знает обо мне и хочет тут работать.
3. Вот тут можно по-подробнее, в чем вы узрели закрытие?
Я на самом деле не скарказничаю, очень важна точка зрения со стороны, тем более разработчика.
То есть вот я ничего не скрываю, даже наоборот — отдаю ему код (что многие вообще боятся делать), а у него складывается ощущения что я что-то скрываю?
На счет патчей к php — почему бы не выложить патченный код в одном место?