Чем детальнее мы опишем критерии и задание, тем более слабый специалист его сможет выполнить хорошо.
Когда у нас вакансия для джуниора такой подход замечательно сработает, т.к. мы ищем специалиста, который будет получать детализированную задачу. Но большинство наших вакансий — это мидл и выше, т.е. люди, от которых мы ожидаем решение задач в общем виде без многих тонкостей и деталей.
Переходя на аналогию с дизайнером мы ищем именно того, кто сможет сделать логотип, по которому будут покупать больше. У такого дизайнера уже есть опыт тестирования логотипов, он умеет строить гипотезы, проверять их и доносить всё это до заказчика при необходимости.
Причины вполне простые:
1) написать их — время, которое могло быть потрачено на разработку функционала
2) сложно написать не подсказав как стоило делать правильно
Мы попробуем поэкспериментировать и давать ответы кандидатам, скорее всего это будет шаблонный ответ с краткими пояснениями. В худшем случае станем предупреждать кандидатов о нашем подходе заранее.
Нам правда хочется давать хороший полезный ответ даже тем, кому мы отказываем, но и жертвовать развитием продукта мы не можем.
про зарплату: всего на moikrug.ru сейчас 70 вакансий фуллстеков, 17 из них с зарплатой от 140 000, 2 из 17 от skyeng.
по тестовому заданию мы не даём комментариев по двум причинам:
1) иногда написать хороший аргументированный ответ с критикой дольше, чем проверить само задание
2) этот аргументированный ответ кандидат может показать своим друзьям, выложить куда-то в публичный доступ, тем самым сильно упростив его выполнение слабым кандидатам
CRM изначально написана на yii 1/mysql и до сих пор так и есть. Проблемы в ней возникали время от времени, чаще всего это были письма и вывод самой приоритетной заявки. Письма у нас сгружаются с почтового сервера в базу и вот эта выгрузка иногда ломалась. С заявкой сложный алгоритм расчёта у кого именно самый высокий приоритет, который с ростом школы приходилось оптимизировать.
Расписания мы переписали полностью с нуля в конце прошлого года на symfony/doctrine/mysql и angular 1, фронтенд получился в виде single page application, который общается по апи с бекендом.
При переписывании важно было:
— решить текущие проблемы (сложно дорабатывать, падения, медленная работа)
— перенести все взаимосвязи с другими проектами во взаимодействие через апи, на тот момент расписания были завязаны со всеми остальным и через базу, и через код
— мигрировать все данные и ничего потерять
В общем-то все эти важности и были трудностями. Пришлось продумать зоны отвественности проектов — кто кому какие данные отдаёт, кто и что получает. Сделать чтобы быстро работало (было 5-15 секунд на посмотреть с кем у учителя занятия, стало — 200-300мс). Найти все взаимосвязи и переписать их.
Когда у нас вакансия для джуниора такой подход замечательно сработает, т.к. мы ищем специалиста, который будет получать детализированную задачу. Но большинство наших вакансий — это мидл и выше, т.е. люди, от которых мы ожидаем решение задач в общем виде без многих тонкостей и деталей.
Переходя на аналогию с дизайнером мы ищем именно того, кто сможет сделать логотип, по которому будут покупать больше. У такого дизайнера уже есть опыт тестирования логотипов, он умеет строить гипотезы, проверять их и доносить всё это до заказчика при необходимости.
1) написать их — время, которое могло быть потрачено на разработку функционала
2) сложно написать не подсказав как стоило делать правильно
Мы попробуем поэкспериментировать и давать ответы кандидатам, скорее всего это будет шаблонный ответ с краткими пояснениями. В худшем случае станем предупреждать кандидатов о нашем подходе заранее.
Нам правда хочется давать хороший полезный ответ даже тем, кому мы отказываем, но и жертвовать развитием продукта мы не можем.
Аудио генерируется с помощью Amazon Polly
Через какое-то время вернём это, но уже только с разрешения пользователя.
по тестовому заданию мы не даём комментариев по двум причинам:
1) иногда написать хороший аргументированный ответ с критикой дольше, чем проверить само задание
2) этот аргументированный ответ кандидат может показать своим друзьям, выложить куда-то в публичный доступ, тем самым сильно упростив его выполнение слабым кандидатам
Расписания мы переписали полностью с нуля в конце прошлого года на symfony/doctrine/mysql и angular 1, фронтенд получился в виде single page application, который общается по апи с бекендом.
При переписывании важно было:
— решить текущие проблемы (сложно дорабатывать, падения, медленная работа)
— перенести все взаимосвязи с другими проектами во взаимодействие через апи, на тот момент расписания были завязаны со всеми остальным и через базу, и через код
— мигрировать все данные и ничего потерять
В общем-то все эти важности и были трудностями. Пришлось продумать зоны отвественности проектов — кто кому какие данные отдаёт, кто и что получает. Сделать чтобы быстро работало (было 5-15 секунд на посмотреть с кем у учителя занятия, стало — 200-300мс). Найти все взаимосвязи и переписать их.