Интернет-магазины зарабатывают не с рекламы, и у них есть крайне острая необходимость быстро и качественно внедрять новые фичи, чтобы увеличить конверсию и LTV покупателя. То же самое относится и к агрегаторам, тематическим поисковикам и SaaS-ам. Единственные ребята из веб-области, которым не нужно гнаться за скоростью и качеством внедрения новых фич — это как раз контентные сайты, которые получают доход с рекламы.
Разумеется, чтобы стать хорошим специалистом просто необходимо много практиковаться и набивать шишки реализуя свои версии известных штук. Но делать это надо в свободное время в личном проекте, потому что внедрение подобного велосипеда на работе обернется издержками для компании, и выльется в сотни человеко-часов допиливаний, фиксов и поддержки. Фреймворки на то и нужны, что весь этот путь уже пройден другими людьми, а на большинство вопросов найдется ответ на стековерфлоу.
Все равно лучше за неделю собрать из библиотек рабочее решение, а потом заменить его целиком, чем пол года разрабатывать что-то универсальное, а потом все равно его заменять целиком, потому что требования опять поменялись.
Сложное в поддержке решение всегда можно отрефакторить, если это становится причиной ошибок, и получить менее сложное, а вот архитектуру, которая гнется не в тех местах и устарела морально в процессе реализации заменять придется сразу целиком.
Задача была написать нечто где ну уж точно никто не может заподозрить ошибку.
Вы с ней не справились. a[i]!=e вот это условие явно и недвусмысленно на это намекает. В javascript и пхп сравнение всегда стоит производить оператором ===. Исключение из этого правила для js – это сравнение на «неопределенность», тогда следует писать != null, да и то из исключительно практических соображений: некоторые авторы сторонних библиотек пихают null вместо undefined в свойства объектов и передают undefined вместо null в качестве аргументов функции (обычно в функциях с сигнатурой (err, result)).
нужно встретится с представителями другой команды и «продать» вашу идею — то вы прям становитесь «мистером уверенность»
Ну вообще, да, это именно так и работает. Потому что на интервью между тобой и скептически настроенным интервьюером — лишь тонкий листочек резюме, которое все равно никто не читает и не верит написанному, а пользуется какими-то своими неведомыми стандартами оценки (вроде вашей максимы «Кандидат. Должен. Написать. Код. Точка.»), очень далекими от того, что можно прочитать даже и тут, на хабре.
В другом же случае, агентом внимания и оценки выступаешь не ты сам лично, а идея, о которой идет речь и у нее есть какие-то качества, которые ты в нее заложил и можешь внятно разъяснить.
которая обязательно должна быть дополнена умением этот код «продать»
Ну так и просите людей продать свой код на собеседовании, зачем заставлять его писать? Если вам нужен продавец, то умение писать качественный код, следовать стандартам и соглашениям, проектировать архитектуру и не подводить коллег будет не важным, и, соответственно зачем тогда просить этого, да еще и в нетипичной для соискателя ситуации?
«Любая стрессовая ситуация» на работе — это что, по-вашему? На мой вкус, на работе программистом все стрессы связаны лишь с другими людьми, и это постепенно проходит, потому что чем дольше с людьми работаешь, тем комфортнее и уверенне себя чувствуешь и, соответственно, стрессы пропадают. Многое зависит и от отношений: если отношения в коллективе здоровые, то и стрессов не возникает, а если нет, то, наверное, действительно, оправдано набирать только «стрессоустойчивых».
Интроверту просто сложно общаться с новыми людьми, вне зависимости от того, что это за люди. А на собеседовании все осложняется тем, что и соискатель и программист-интервьюер находятся в нетипичной для себя ситуации и играют непривычные роли.
Вот прям спорный момент, очень спорный. Оказался как раз в такой ситуации, где просили написать код ручкой на листочке. На интервью было 3 человека, и мне дали подобную задачу на алгоритм. И я тоже не смог его написать, потому что просто было очень сложно сосредоточиться. Разумеется, дома решил эту задачу как нефиг делать.
Собеседование — это само по себе большой стресс для интроверта (которыми, в большинстве своем являются программисты), а еще и непроизвольно пытаешься понравиться, тут не до кода, а в особенности не до кода на физическом носителе (доске).
Так что не хочу вас расстраивать, но уверен, что вы своим железным правилом обидели и упустили немало хороших кандидатов, и набрали как раз тех, кто часто меняет работу и уже не волнуется писать код на интервью.
Есть навыки, полезные при программировании и есть навыки, полезные при прохождении собеседований. Если человек часто программирует, то он развивает одни навыки, а если часто проходит собеседования, то совсем другие.
Тут я имел в виду эффект «второго прыжка»: прыгать с парашютом по-настоящему страшно во второй раз, а не в первый.
Про стандартные практики — это не столько по поводу собеседований, сколько вообще в целом, я неоднократно видел ужасные вещи, которые оправдываются тем что «ну а че, все так делают».
Есть весьма веские аргументы в пользу того, что «стандартные практики» при приеме на работу, о которых идет речь, попросту неэффективны.
Ох уж эти «стандартные практики». Не счесть сколько неимоверных глупостей я слышал перед этой формулой. В итоге, собеседования проходят не те, кто лучше остальных соискателей, а те, кто либо больше других прошел собеседований, либо еще совсем не опытный и не понимает всей серьезности ситуации: первое свое (очень суровое) собеседование я прошел без запинки, а вот на последующих уже заметно волновался, хотя и профессиональные навыки были, разумеется, уже выше.
Ага. Боюсь даже представить как будет выглядеть в такой форме какая-нибудь нетривиальная регулярка, например, на номер телефона, или, не дай боже, емейл или uri.
А какой может быть риск коллизий? Если у вас на проекте используется, например, реакт и лодаш, то довольно странно было бы иметь локальные переменные React и _, которые ссылались бы на что-нибудь другое кроме реакта и лодаша.
Проблема глобальных переменных сильно преувеличена. Да, объявлять глобальные переменные внутри модулей плохая практика, потому что это усложняет рефакторинг, но вот иметь глобальные переменные, от которых зависит проект целиком, наоборот, только упрощает дело. Разумеется, это не относится к библиотекам и изолированным частям системы. Но если у вас есть 200 ангуляр контроллеров, единственная задача которых — это удовлетворение бизнес требований, и они никому не нужны вне текущего проекта то и ничего плохого в этом нет.
Да ну все же ясно, как божий день: ПТУ у нас убили, а институт готовит либо ученых, либо инженеров. Вот и получается, что те, кому по-хорошему получить профессию и идти кодировать на благо родине идут в институт, а там их учат немного не той профессии.
Локально, не на системном уровне, проблему можно решить просто увеличив именно практику кодирования, чтобы человек за 4 года имел возможность подняться от кодировщика до, собственно, инженера.
А что по этому поводу говорит агенство стратегических инициатив (и фрии в частности), почему они не хотят влезать в эту тему, связывались ли вы с ними, и если да, то что отвечают?
Ну так это и есть приемочный тест.
Или вы имели в виду автоматизированный? Тогда студенты вообще перестанут их делать, используя одну единственную когда-то написанную программу.
Вот да. Образование все же нужно, чтобы хоть чуть-чуть ориентироваться в общем и целом. К примеру, в институте нам вбивали в голову, что пользователь и заказчик — это совершенно люди, и при разработке нужно в первую очередь изучать с какими проблемами сталкивается пользователь и решать именно их. Немного поработав, я с удивлением обнаружил, что большинство программистов и компаний которые я знаю вообще не учитывают конечного пользователя, а ориентируются только на требования заказчика, а потом ловят бугурты из за не принятого этапа, и вообще конфликтов с заказчиком.
Вы с ней не справились.
a[i]!=eвот это условие явно и недвусмысленно на это намекает. В javascript и пхп сравнение всегда стоит производить оператором ===. Исключение из этого правила для js – это сравнение на «неопределенность», тогда следует писать != null, да и то из исключительно практических соображений: некоторые авторы сторонних библиотек пихают null вместо undefined в свойства объектов и передают undefined вместо null в качестве аргументов функции (обычно в функциях с сигнатурой (err, result)).Ну вообще, да, это именно так и работает. Потому что на интервью между тобой и скептически настроенным интервьюером — лишь тонкий листочек резюме, которое все равно никто не читает и не верит написанному, а пользуется какими-то своими неведомыми стандартами оценки (вроде вашей максимы «Кандидат. Должен. Написать. Код. Точка.»), очень далекими от того, что можно прочитать даже и тут, на хабре.
В другом же случае, агентом внимания и оценки выступаешь не ты сам лично, а идея, о которой идет речь и у нее есть какие-то качества, которые ты в нее заложил и можешь внятно разъяснить.
Ну так и просите людей продать свой код на собеседовании, зачем заставлять его писать? Если вам нужен продавец, то умение писать качественный код, следовать стандартам и соглашениям, проектировать архитектуру и не подводить коллег будет не важным, и, соответственно зачем тогда просить этого, да еще и в нетипичной для соискателя ситуации?
Интроверту просто сложно общаться с новыми людьми, вне зависимости от того, что это за люди. А на собеседовании все осложняется тем, что и соискатель и программист-интервьюер находятся в нетипичной для себя ситуации и играют непривычные роли.
Собеседование — это само по себе большой стресс для интроверта (которыми, в большинстве своем являются программисты), а еще и непроизвольно пытаешься понравиться, тут не до кода, а в особенности не до кода на физическом носителе (доске).
Так что не хочу вас расстраивать, но уверен, что вы своим железным правилом обидели и упустили немало хороших кандидатов, и набрали как раз тех, кто часто меняет работу и уже не волнуется писать код на интервью.
Тут я имел в виду эффект «второго прыжка»: прыгать с парашютом по-настоящему страшно во второй раз, а не в первый.
Про стандартные практики — это не столько по поводу собеседований, сколько вообще в целом, я неоднократно видел ужасные вещи, которые оправдываются тем что «ну а че, все так делают».
Есть весьма веские аргументы в пользу того, что «стандартные практики» при приеме на работу, о которых идет речь, попросту неэффективны.
Проблема глобальных переменных сильно преувеличена. Да, объявлять глобальные переменные внутри модулей плохая практика, потому что это усложняет рефакторинг, но вот иметь глобальные переменные, от которых зависит проект целиком, наоборот, только упрощает дело. Разумеется, это не относится к библиотекам и изолированным частям системы. Но если у вас есть 200 ангуляр контроллеров, единственная задача которых — это удовлетворение бизнес требований, и они никому не нужны вне текущего проекта то и ничего плохого в этом нет.
Локально, не на системном уровне, проблему можно решить просто увеличив именно практику кодирования, чтобы человек за 4 года имел возможность подняться от кодировщика до, собственно, инженера.
Или вы имели в виду автоматизированный? Тогда студенты вообще перестанут их делать, используя одну единственную когда-то написанную программу.