Друзья, вашему вниманию обзор критериев, по которым, по моему опыту, судят ваши coding challenge. Это, так сказать, выжимка из моего опыта работы с техническими вакансиями в консалтинге и продуктовых компаниях. Некоторые моменты могут показаться спорными, но тем не менее 😊

  1. Extensibility – SoC (separation of concerns). На что обращают внимание – попытки проделать сепарацию display and model. Идеальный вариант, когда код fully extensible, и организация классов стройна и хороша собой 😊
  2. Simplicity – ну тут понятно. Простейшее решение, которое работает, при этом код читается, расширяется и тестится. На что обращают внимание – НЕ нравятся – длинные громоздкие функции, слишком навороченные tools, которые ничего не решают. Что нравится – все что просто, понятные названия функций и сами функции короткие и емкие, у каждого метода только одно назначение, код consistency, no long nested conditions.
  3. Robustness – как код работает с ошибками и репортает их. Что не нравится – ignoring a lot of use cases, only catch or throw all exceptions, code can crash without ERROR message.

Что нравится – репортает все ошибки в юзер френдли режиме.

  1. Usability – работает ли оно все? Что НЕ нравится -когда НЕ работает, или кучу всего нужно скачивать из инета, чтобы заработало. Что нравится – интуитивный UX, readme – понятно и четко описано, не нужно много чесать голову над тем, как программа работает (use build tools or wrapper script).
  2. Test coverage – breaking changes should break your tests. Что НЕ нравится – бессмысленные тесты, тесты очень тесно работают с input data, однотипные тесты (типа только юнит или только на интеграцию). Что нравится – тесты разных типов там, где нужно. Покрытие тестирования хотя бы 80%.
  3. Performance – как оно все будет работать при бОльшей нагрузке (больше даты, больше юзеров). Что НЕ нравится – когда все медленно, ненужные сложности типа загрузка всего в память. Что нравится – когда все быстренько, видны попытки improving on linear (e.g. inverted index).

На что еще обращать внимание:

— выбирайте лучшее решение для задачи, а не что-то диковинное и громоздкое.

— не делайте code repetition, если код можно рефакторить

— аккуратность. Убедитесь, что у вас везде consistent spacing, не висят пустые файлы и тд

— Read.me красивый и понятный

Зачастую компании анонсируют, что им пофиг на чем вы пишете, лишь бы все работало. Если компания большая, и система оценки налажена, то конечно можно, подаваясь на вакансию фронт енд, написать тестовое задание на Elixir, если это ваш лучший скилл, и вы считаете, что эта технология идеальна для задания. Но так как система оценки кодинговых челленджей далеко не везде идеальна, не рискуйте использовать технологию, которую в команде не используют, не смогут вас правильно оценить или просто не любят.

Возьмите лучше бОльше времени, но напишите хороший код – мой последний совет.

Show Buttons
Hide Buttons