Для «непонятливых», как вы говорите, кривая триада получилась. Как минимум потому, что оснований тут должно быть не три, а два.
Навык — это закрепленное умение на уровне рефлексов.
Т.е. навык — умение второго уровня. Почему бы и для знаний так не сделать? Будут просто знания и узкие знания — знания какой-то области во всех деталях.
В общем, как обычно — придумали от балды какую-то классификацию, делаете из нее какие-то выводы, которые ошибочны просто потому что классификация изначально неверна. Даже когда намекаешь на ошибку в ней — в ответ «разъясняю для непонятливых». Ничего нового.
Логика здорового человека выглядит так:
1. Разработчик активно участвует в разработке опенсорсных проектов.
2. Если не брать различные исключения, то как правило, уровень этого разработчика гораздо выше среднего. Но даже если попалось невероятное исключение, этот разраб всё равно как минимум умеет: пользоваться гитом, писать код, читать чужой код, править баги, находится на «гребне волны» технологий.
3. Спрос на спецов в айти намного выше предложения.
4. С такими навыками выбирает он, а не его. Чтобы его захантить, будут предлагать и хорошую зарплату, и интересные проекты, и разные плюшки.
А вот логика курильщика:
1. Если разрабу нравится кодить, он не захочет заниматься ничем другим.
2. Программистов — большинство населения земного шара.
3. Согласно п2 — спрос гораздо ниже предложения, если хочешь зарабатывать кодингом, надо соглашаться на любую работу, хоть за еду, либо сменить вид деятельности. Программирование стало низкоквалифицированным трудом.
4. Согласно п1 — разраб попался в ловушку и ему придется согласиться на любую зарплату, лишь бы ему деньги платили.
Druu нужно прекращать курить ту траву, слишком жесткие у нее приходы, фантазии человек перестает отличать от реальности :)
Расширю свою мысль, раз вы меня не так поняли. То, что нужно обычной вебстудии — не то же самое, что нужно продуктовой команде. И ни тем, ни другим не нужно то же самое, что нужно гуглу. В том числе и из-за размеров. В компанию из 5 человек и из 10'000 процесс найма будет сильно различаться.
К сожалению, статью не получилось найти… Цифр там, кстати, не было, только вывод ...
Для меня подобное не может служить сильным свидетельством. Единственный адекватный вывод, который можно сделать — вопросы типа «почему люки круглые» не увеличили эффективность найма в гугле.
Ну вы наивный, как маленький ребенок. Или живете в другой реальности. В моем мире, в тех случаях, когда я участвовал в процессе найма, на каждые 10 соискателей примерно 2-3 неумех, рассказывающих на собеседовании, какие они ниндзя-супермены.
нет. бывает ИСПЫТАТЕЛЬНЫЙ СРОК.
причем оплаченный
в эти две недели и работник узнает, захочется ли ему работать над кодом-говном компании,
и в компании узнают, захотят ли они этого разработчика
Компания хочет разрабатывать продукт, внедрять фичи, фиксить баги. А не тратить по две недели на каждую попытку найма разработчика, играя в рулетку.
иного не дано
Вы довольно категорично высказываетесь. Что за черно-белое видение, либо идеальное решение, либо никакое. Никакой двигатель из возможных в реальности не может превзойти или даже быть равным КПД цикла Карно. Однако же это не значит, что нужно опустить руки и разойтись. Если есть способ увеличить шансы, кроме как «нанять случайного человека и посмотреть, как он работает на испытательном сроке» — их надо использовать, а не говорить с умным видом «ну, точно мы всё равно не можем быть уверены».
Вы пытаетесь объять необъятное и установить истину даже в крайних случаях. Это не всегда нужно.
Вот вам возможный сценарий:
Я начальник/тимлид/рекрутер.
Мне нужно нанять одного толкового человека в команду, не новичка.
Публикую вакансию с требованиями, за неделю откликнулись 50 человек. Из них не меньше 20 — полные неумехи, которые при этом умеют складно говорить.
Как сделать наиболее рациональный выбор?
1. Можно обстоятельно прособеседовать каждого (минус 50 часов на собеседования и минус еще 50 на подготовку к ним). После дать им тестовое задание (минус еще 50 часов у меня на проверку и минус 200-500 часов у соискателей на выполнение).
2. Можно написать скрипт, который выдаст в ответ случайное число, от 1 до 50 включительно.
3. Можно сделать допущение, что те, у которых есть или свои опенсорсные либы на гитхабе, или пул-реквесты к чужим — на уровне как минимум выше среднего. Если я не ищу суперзвезду, любой из них мне подойдет. Фильтрую, из 50 человек осталось 5. Разговариваю с каждым, просто чтобы оценить общую адекватность. Останется как минимум 1-2 человека, которые понравятся мне и которым понравлюсь я.
Третий способ позволит за минимум времени найти подходящего человека. Таким способом можно не угадать с лучшим из 50 откликнувшихся, но лучшее — враг хорошего.
Это как, ища хирурга, фильтровать по наличию медицинского образования. 99% населения отфильтровывается, и среди них могут быть нереально крутые самоучки. Но до тех пор, пока врачей с образованием достаточное количество, можно не слишком беспокоиться о потерях. Но если у меня полевой госпиталь где-нибудь в Африке — тут уже не до разбрасывания возможными сотрудниками, оперировал бомжей в подвале — ты нам подходишь.
Про шутку я писал в ответ на "а entrypoint'ов в ангуляре — много", а не на "нужен camelCase в json". Это почти самое первое, до чего доходит любой программист — повторяющийся код вынести и вызывать его по мере надобности, а не повторять его, как индус, которому платят за количество строк.
В остальном — как я уже писал, считаю, что бекенд должен диктовать правила. Просто потому, что он один, а разных клиентов под него — много. Но это истина лишь в первом приближении. В каждом конкретном случае могут быть особые требования или обстоятельства, из-за чего нужно будет делать по-другому.
Я не получил работу в фирме по разработке шоппинг-приложения в центре Остина.
Судя по статье — наняли другого чела, чей код смогли проверить и у которого программирование — еще и хобби. Это нытье напоминает «это потому что я черный?». Нет, это потому что нашелся кто-то более подходящий под запросы той компании. Пусть идет в энтерпрайз, там среди своих будет.
У просьбы показать свой код может быть две основных причины:
Удостовериться, что соискатель умеет работать со стеком, который указывался в вакансии, что пишет код не в стиле индусов, что умеет пользоваться гитом, что не вешает лапшу на уши.
По каким-то причинам нужен навык именно опен-сорса. Может, они в разработке какой-то популярной либы участвуют или еще что-нибудь подобное.
Вторая причина — редкость. Попалась она — значит, не ту компанию выбрал. Не жаловаться же, что не приняли к java'шникам, когда сам на питоне пишешь.
Первая же причина — частое явление. Если бы в этом мире никто никогда не лгал, принятие на работу выглядело бы так:
— Ищем фронта, используем реакт.
— Я разбираюсь в реакте.
— Вы приняты.
Но такого не бывает. А бывают технические собеседования, вопросы, тестовые задания и прочее.
Самому соискателю было бы удобней раз в несколько месяцев, когда изучаешь что-то новое, потратить день-другой, привести написанный во время изучения технологии код в порядок и выложить его на тот же гитхаб. Куча времени экономится — на собеседовании останется лишь общую адекватность проверить в обычном разговоре, а не отвечать в сотый раз, чем абстрактный класс отличается от интерфейса.
Потому что люди не роботы. Досконально изучить css просто для того, чтобы досконально изучить css — для этого нужен специфический склад ума. Обычные люди просто пилят какой-нибудь проект. Надо отверстать — гуглят css, надо интерактива форме добавить — гуглят js. Проходит время и всё, что требуется для разработки, уже само в голове откладывается. А по мелочи и разные новые штуки так и продолжают гуглиться в стаковерфлоу, блогах и спецификациях.
Закрыться на год, выучить всё что можно, а потом наконец выйти из комнаты суперменом — так не бывает :)
Это называется технический прогресс. Постоянно сменяются спецификации, вводятся новые фичи, дорабатываются существующие, старые прекращают поддерживать. С чего бы фреймворкам не сменять друг друга в такой обстановке?
«Электричество мы изобрели, но использовать его для освещения помещений не будем — у нас свечи есть» — так вы представляете себе остановку? Или думаете, что когда-нибудь соберутся все на одну большую конференцию и там объявят: «Мы наконец достигли совершенства! Изобретать больше ничего не надо, можете расходиться по домам»?
Это типа шутка такая? В ангуляре есть интерcепторы, через них подобные штуки и делаются: обработка параметров перед отправкой запроса и после получения, обновление индикатора загрузки и тд. В итоге всего в двух местах нужно код написать. А в том же jbuilder, раз уж его упомянули — нужно в каждом описывать поля. Или, если с импортом jbuilder'ов друг в друга — то в одном на каждую сущность :)
И пробуй объясни, что это jbuilder должен отдавать вражеский camelCase.
А кто мешает на фронте превращать при получении ответа все snake_case в camelCase, а при отправке запроса — camelCase в snake_case? Браузер, андроид, айос, виндовс фон, какие-то внешние системы — и каждый будет еще указывать беку, какой стайл-гайд для названий ему использовать.
Меня терзают смутные сомнения, что эти ваши тульповоды просто думают и за себя и за «тульпу», по очереди. Это как играть в шахматы самим с собой — можно даже имитировать разный уровень игроков, но это просто имитация, игрок один, даже если он иногда не пользуется крутыми ходами, чтобы быть «типа слабым».
Т.е. навык — умение второго уровня. Почему бы и для знаний так не сделать? Будут просто знания и узкие знания — знания какой-то области во всех деталях.
В общем, как обычно — придумали от балды какую-то классификацию, делаете из нее какие-то выводы, которые ошибочны просто потому что классификация изначально неверна. Даже когда намекаешь на ошибку в ней — в ответ «разъясняю для непонятливых». Ничего нового.
1. Разработчик активно участвует в разработке опенсорсных проектов.
2. Если не брать различные исключения, то как правило, уровень этого разработчика гораздо выше среднего. Но даже если попалось невероятное исключение, этот разраб всё равно как минимум умеет: пользоваться гитом, писать код, читать чужой код, править баги, находится на «гребне волны» технологий.
3. Спрос на спецов в айти намного выше предложения.
4. С такими навыками выбирает он, а не его. Чтобы его захантить, будут предлагать и хорошую зарплату, и интересные проекты, и разные плюшки.
А вот логика курильщика:
1. Если разрабу нравится кодить, он не захочет заниматься ничем другим.
2. Программистов — большинство населения земного шара.
3. Согласно п2 — спрос гораздо ниже предложения, если хочешь зарабатывать кодингом, надо соглашаться на любую работу, хоть за еду, либо сменить вид деятельности. Программирование стало низкоквалифицированным трудом.
4. Согласно п1 — разраб попался в ловушку и ему придется согласиться на любую зарплату, лишь бы ему деньги платили.
Druu нужно прекращать курить ту траву, слишком жесткие у нее приходы, фантазии человек перестает отличать от реальности :)
Для меня подобное не может служить сильным свидетельством. Единственный адекватный вывод, который можно сделать — вопросы типа «почему люки круглые» не увеличили эффективность найма в гугле.
2. Цифры «статистики гугла» в студию.
Компания хочет разрабатывать продукт, внедрять фичи, фиксить баги. А не тратить по две недели на каждую попытку найма разработчика, играя в рулетку.
Вы довольно категорично высказываетесь. Что за черно-белое видение, либо идеальное решение, либо никакое. Никакой двигатель из возможных в реальности не может превзойти или даже быть равным КПД цикла Карно. Однако же это не значит, что нужно опустить руки и разойтись. Если есть способ увеличить шансы, кроме как «нанять случайного человека и посмотреть, как он работает на испытательном сроке» — их надо использовать, а не говорить с умным видом «ну, точно мы всё равно не можем быть уверены».
Вот вам возможный сценарий:
Я начальник/тимлид/рекрутер.
Мне нужно нанять одного толкового человека в команду, не новичка.
Публикую вакансию с требованиями, за неделю откликнулись 50 человек. Из них не меньше 20 — полные неумехи, которые при этом умеют складно говорить.
Как сделать наиболее рациональный выбор?
1. Можно обстоятельно прособеседовать каждого (минус 50 часов на собеседования и минус еще 50 на подготовку к ним). После дать им тестовое задание (минус еще 50 часов у меня на проверку и минус 200-500 часов у соискателей на выполнение).
2. Можно написать скрипт, который выдаст в ответ случайное число, от 1 до 50 включительно.
3. Можно сделать допущение, что те, у которых есть или свои опенсорсные либы на гитхабе, или пул-реквесты к чужим — на уровне как минимум выше среднего. Если я не ищу суперзвезду, любой из них мне подойдет. Фильтрую, из 50 человек осталось 5. Разговариваю с каждым, просто чтобы оценить общую адекватность. Останется как минимум 1-2 человека, которые понравятся мне и которым понравлюсь я.
Третий способ позволит за минимум времени найти подходящего человека. Таким способом можно не угадать с лучшим из 50 откликнувшихся, но лучшее — враг хорошего.
Это как, ища хирурга, фильтровать по наличию медицинского образования. 99% населения отфильтровывается, и среди них могут быть нереально крутые самоучки. Но до тех пор, пока врачей с образованием достаточное количество, можно не слишком беспокоиться о потерях. Но если у меня полевой госпиталь где-нибудь в Африке — тут уже не до разбрасывания возможными сотрудниками, оперировал бомжей в подвале — ты нам подходишь.
В остальном — как я уже писал, считаю, что бекенд должен диктовать правила. Просто потому, что он один, а разных клиентов под него — много. Но это истина лишь в первом приближении. В каждом конкретном случае могут быть особые требования или обстоятельства, из-за чего нужно будет делать по-другому.
Судя по статье — наняли другого чела, чей код смогли проверить и у которого программирование — еще и хобби. Это нытье напоминает «это потому что я черный?». Нет, это потому что нашелся кто-то более подходящий под запросы той компании. Пусть идет в энтерпрайз, там среди своих будет.
Вторая причина — редкость. Попалась она — значит, не ту компанию выбрал. Не жаловаться же, что не приняли к java'шникам, когда сам на питоне пишешь.
Первая же причина — частое явление. Если бы в этом мире никто никогда не лгал, принятие на работу выглядело бы так:
— Ищем фронта, используем реакт.
— Я разбираюсь в реакте.
— Вы приняты.
Но такого не бывает. А бывают технические собеседования, вопросы, тестовые задания и прочее.
Самому соискателю было бы удобней раз в несколько месяцев, когда изучаешь что-то новое, потратить день-другой, привести написанный во время изучения технологии код в порядок и выложить его на тот же гитхаб. Куча времени экономится — на собеседовании останется лишь общую адекватность проверить в обычном разговоре, а не отвечать в сотый раз, чем абстрактный класс отличается от интерфейса.
Закрыться на год, выучить всё что можно, а потом наконец выйти из комнаты суперменом — так не бывает :)
«Электричество мы изобрели, но использовать его для освещения помещений не будем — у нас свечи есть» — так вы представляете себе остановку? Или думаете, что когда-нибудь соберутся все на одну большую конференцию и там объявят: «Мы наконец достигли совершенства! Изобретать больше ничего не надо, можете расходиться по домам»?
:)