Для полноценной работы по созданию сайтов вам обязателньо необходим хороший удобный редактор для PHP, HTML, CSS, JavaScript
Веб-разработчик утверждает, что никогда не пользуется гуглом, т.к. все и так знает и помнит. Вам неслыханно повезло. Он просто чудо, таких людей достаточно мало и, вероятно, они вундеркинды. Другими словами - гоните его куда подальше.
Пожалуй, этот пункт относится ко всем областям разработки, а уж веб-программист просто обязан гуглить. Нет ни одного веб-разработчика, который бы за день своей работы не гуглил. Не возможно все держать в голове, но все можно найти в интернете. Невозможно решать проблемы в одиночку, но можно обратиться к сообществу.
Не столь важно какой именно стиль написания кода выбрал разработчик, как сам факт соблюдения этого стиля. Посмотрите на примеры его исходников. Код не должен быть небрежным, отступы должны подчиняться какой-то логике, пробелы и переносы строк должны расставляться однообразно.
У плохого разработчика небрежный код. Даже если он работает, это принесет кучу проблем в будущем.
Даже моя бывшая девушка могла научиться правильному написанию тегов и CSS свойств за один вечер.
Знания HTML5 и CSS3 должны заключаться не в двух маркетинговых словах, а в умении, например, сверстать сложную хитровыеизогнутую тень у элемента или добавить красивую анимацию ко всплывающему окну так, чтобы это устроило дизайнера. Спросите его про гео-локацию или LocalStorage, а еще лучше уточните, что в его понимании HTML5 и CSS3.
Не ведитесь на маркетинговые HTML5 и CSS3. Сможет ли он сделать так: http://pattle.github.io/simpsons-in-css/ Если ответ будет "да", можете начинать сильно удивляться и просить показать, и, если он и правда понимает, как подобное работает, вам очень повезло.
Его верстка смотрится идеально во всех браузерах? Попросите поменять местами два любых логически похожих блока. Это не должно вызвать проблем. В идеале, даже если поменять местами футер с шапкой, верстка не разъедется.
Я встречал случаи, когда даже два текстовых блока следующих один за другим невозможно было поменять местами не сломав половину сайта. Это очень плохо.
Почему же не стоит нанимать разработчика, который отвергает JS библиотеки? Давайте вспомним "старые отмазки" от библиотек: Вес и Скорость.
Времена, когда мы экономили байты в погоне за скоростью загрузки страниц давно прошли. Лишние 15, 30, даже 500 Кб большинство пользователей не заметит. Само-собой не стоит встраивать в страницу лишний и ненужный код, но не стоит так же бояться добавить библиотеку для "вон той единственной фичи". От этого никому плохо не станет, а поддержка в будущем облегчится за счет использования библиотеки. Разработчикам: без фанатизма, мегабайты кода ради полифила в пару строк встраивать не стоит.
Скорость. Вы правда думаете, что нашли разработчика который сможет написать манипуляцию с DOM на уровне скорости jQuery? Вряд ли. Разработчик считает что Angular работает слишком медленно медленно? Скорее всего он использует его не там и так. Популярные библиотеки уже хорошо оптимизированы под свои конкретные задачи и веб-разработчик должен понимать это, а не "писать все на pureJS с нуля потому что это круто и быстро работает".
В заключение, не бойтесь фразы "я пишу на jQuery". Проверьте знания кандидата в этой области, вполне возможно, что он знает библиотеку лучше всех ваших текущих программистов и это вполне может окупиться.
Разработчик, который сам рисует для себя макеты, скорее всего, не очень хорош. Отрисовка и проектирование макета занимает очень много времени, откуда из 24-х часов взяться дополнительному времени на изучение программирования? Веб-программирование, в частности, движется огромными шагами, очень не многие способны идти этими шагами попутно изучая дизайнерское ремесло.
Безусловно, есть исключения из этого правила, но редко.
Ни в реальном мире, ни в интернете я еще не встречал программиста, у которого бы небыло проблем с определением сроков. Это "болезнь" всех программистов. Даже самый крутой программист будет сомневаться в сроках исполнения сложной задачи, разве что вам он этого не покажет.
Если долго работать с одним и тем же проектом, одним и тем же заказчиком, то постепенно начинаешь угадывать сроки. Но именно угадывать и не более. Вы не работали со своим кандидатом ранее, поверьте, он не может назвать вам точные сроки по вашей задаче.