Да, лулзы не выкупил и воспринял относительно серьёзно.)
Поэтому мне статья и понравилась, вы всё верно делаете и такой подход одобряю. Самому не нравятся собеседования экзамен лайк. Помню был собес, где спрашивали по всей теории, несколько часов. Когда не мог ответить, ведущие просто, молчали упиваясь моментом. Причём один раз говорил, что надо идти, но реакции ноль. С высоты текущего опыта, понимаю, что они сами в вопросах слабо разбирались. Лучшие же собесы, когда всегда уходил из компании с хорошем настроением (не важно был ли офер). Люди использовали похожие на ваш способы. Не задавали вопросы с молчанкой, а вели диалог. Мне понравился метод в одной компании, когда давали плохо написанный класс, говоря: "давайте вместе исправим". После диалога всё становилось понятно, т.к проверяли не олимпиадный рефакторинг, а навыки общения, способность быстро разбираться в чужом коде и искать решение проблем, используя все доступные возможности. Вы делаете если не точно так же, то примерно в этом же ключе, так что полностью поддерживаю.
Касаемо задачи, по идее это второй вариант решения из статьи, только заменил x - Math.floor(x) на x % 1. Про остаток от деления, помню со студенчества, поэтому первым в голову и пришёл. В люблю случае согласен, эта задача нужна для другого.)
Сначала думал, что это очередная статья в стиле "есть куда более лёгкий способ отсеять людей, чем алгоритмы", но к концу прочтения изменил мнение и во многом согласен с автором.
Я бы догодался до решения, на собесе, но к сожалению не сразу. Вот примерно, что набросал, когда прочитал и понял задачу: (x) => Math.foor(x) + (x % 1 => 0.5 ? 1 : 0)
Однако, решение в идеальном примере, мне нравится больше. Моё слишком громоздкое и хоть условие с 1 floor соблюдено, это точно всё и близко не уровень сеньора. Плюс, мой основной ЯП не JS и далеко не всю его специфику знаю.
Согласен со всем, кроме того, что "зубрить алгоритмы нужно в основном джунам". Честно я бы никому их зубрить не рекомендовал, если это напрямую не связано с работой. Знать основы алгоритмов думаю нужно всем, но углубляться в них сильно, пожеланию.
Если честно меня раздражают парадоксы найма IT сферы.
Меняешь часто место работы - ненадёжный работник. Меняешь редко - не амбициозный, кроме шаблонных задач ничего не знает.
Имеешь богатый опыт работы, но с 1 ЯП и стеком - не хочешь саморазвиваться, скорее-всего топорный. Имеешь опыт со многими ЯП и разнообразными стеками, значит не профессионал и набрался всего по вершкам.
Хочешь иметь стабильную фиксированную зп, чтобы строить планы на жизнь - без перспективный или проблемный (не захочет перерабатывать, будет стараться уделять больше времени семье, чем работе). Меняешь работу ради грейдов по зп, фу бегунок.
И список можно продолжать очень долго, вплоть до бреда с резюме, по типу: Поставил фото - дурной тон, не поставил значит серая мышь; Указал зп - плохо, не указал - не попал в фильтры и т.д.
Думаю лучший вариант, это не слушать "вредные" советы и искать то, что в первую очередь подойдёт вам. В статье автора хорошее сравнение двух специалистов. Один много лет сидел в одном месте, а другой менял работу каждый год и оба довольны, при абсолютно разных подходах, потому что каждый выбрал путь, который больше нравился.
Пример хороший. Ещё есть один способ. Можно задать прямо очень сложный вопрос и посмотреть на реакцию. Если собеседуемый даст на него ответ по гуглу или около того, всё станет ясно. Правда это может адекватному программисту показаться ред флэгом (или как там новомодно сейчас).
П.С. Меня больше смутили слова: "у нас деплой в прод идёт я наблюдаю на другом мониторе". Что он там наблюдает, лично мне не совсем ясно. Ты либо деплоишь постоянно сидя в терминале либо нет.
Плюс если, что-то важное на работе, может стоит собес перенести, на свободное время?
Автор может тоже по своему прав, но я думаю всё куда проще и менее философски.
Если вы не заметили в мире сейчас идёт глобальный экономический кризис, который появился по многим причинам, но не в этом суть.
Так вот, IT в своём большинстве дотационная сфера, т.е. она завязана на других сферах и отраслях экономики. Поэтому рассматривать IT в плане кризиса, как что-то отдельное странно.
Сейчас не только IT но и все сферы может за исключением некоторых (по типу ритуальных услуг) испытают большие трудности.
Да, в IT и программировании в частности, есть проблемы, как в любой другой сфере. Лично меня из всего перечисленного коробят только трекеры. Если работодатель ставит трекер, то для меня он сразу улетает в чс, при этом я не против например каждый день описывать часы и задачи. ИМХО если ты не справляешься с работой, никакие трекеры твою продуктивность не повысят, ровно если, как если справляешься это не сделает тебя более эффективным.
Касаемо же сферы, то при всех её проблемах быть программистом лично для меня (как думаю и для многих здесь) в разы лучше, чем работать в другой сфере. Потому что количество плюшек намного выше, количества недостатков.
Как по мне есть только один способ, оценить навык, это портфолио. Причём не просто наличие проектов, а именно более подробный рассказ, что именно человек на проекте делал, попросить показать код, задать по нему несколько наводящих вопросов и т.д. Если мы говорим про студентов, то посмотреть пед проекты. Опять же имхо, но такой подход наверное единственный адекватный из всех что остались.
Касаемо первых двух описанных проблем, полностью согласен. Они правда часто встречаются, правда я бы посоветовал для единообразия использовать оформление:
margin: 0rem 0rem;
padding: 0rem 0rem 0rem 0rem;
Имхо так код более читаем, чем с использованием -top, -bottom, -left, -right префиксов. Вместо 2-4 строчек мы всегда имеем одну.
Касаемо последней проблемы, то идея неплохая, но селектор с nth-child(2), имхо лучше не использовать в списках или перечислениях элементов в целом. В примере указан селектор (> :nth-child(2)) и он будет работать спору нет, но что произойдёт, когда количество элементов поменяется? А если нужно будет сделать несколько кнопок с особой иконкой, то нам через запятую перечислять все селекторы? Как по мне в таких случаях лучше использовать первоначальный вариант, но немного изменить его:
Брать человека не знающего SQL, для работы с БД - это уровень фразы "просчитался, но где".) Большинство ORM по умолчанию даже нормальное индексирование не делают, о чём человек, не знающий SQL знать не будет, как и банально не сможет написать специфический функционал.)
ORM по большей части используется для удобства и стандартизации работы с бд, а не ради производительности. Поэтому, как всегда всё сводится к поиску золотой середины под каждый проект в отдельности.
Конечно некоторые фишки js воспринимаю за баги. Тоже замыкание, как по мне больше похоже на баг и со сложным кодом, не представляю, как это дебажить и тем-более покрывать тестами.
Если нужно хранить состояние, лучше класс или объект создам, так будет понятнее, как по мне.
Но опять же замыкание это особенность js и знать о ней минимум стоит.
Почему файтингов мало? Помимо того, что файтинги сейчас это более нисшевый жанр (даже более нисшевый, чем например стратегии), их довольно сложно разрабатывать. В файтингах очень важен баланс и тайминги. Если вы думаете, что это просто реализовать, особенно если проект мультиплеерный, то советую попробовать. С точки зрения геймдева и кода это вполне познавательный и интересный опыт.
Если вкратце, то 2д лучше 3д, из-за особенностей отрисовки анимаций, позиционирования моделей игроков и ещё много чего. Если проект мультиплеерный, то синхронизировать например быстрые удары по таймингам поверьте та ещё задача, особенно с блоками и парированиями. С точки зрения баланса, создать несколько разных персонажей с разными приёмами, но чтобы не было читерских комбинаций и не было полных контр персонажей другим персонажам.
Всё это нс словах звучит просто, но поверьте на деле это далеко не так.
Если честно 4o1- preview версия, по личным ощущениям хуже выдаёт ответы, чем просто 4о. Плюс ещё имеет лимит на запросы, даже в платной версии. Так же хуже решает задачи, т.к. хуже понимает контекст того же кода. Задаёт много лишних вопросов, когда 4о всё понимает с полуслова.
Плюс они в любом случае быстро отсеиваются на реальных задачах. Очень легко распознать человека, который вообще ничего не знает от специалиста, который либо имеет проблемы со скилом, либо просто волнуется. Первый будет делать задачи медленно, но понимать, что от него требуют и как это реализовать. Второй подавно всё знает, просто может совершить ошибки при волнении, но он будет писать код с большим пониманием того, что делает.
Человек, который ничего не знает, пишет код странно, из той же нейронки копирует код не думая, сыпаться на нестандартных, но простых вопросах о своём же коде.
П.С. Касаемо нейросетей, то не знаю как, но я в последнее время часто замечаю, что могу отличить код того же gpt, от кода, написанного человеком. Нейронки имеют свой стиль, что-ли, из-за чего на собесах и в тестовых заданиях легко такой код заметить.
Скорее не HRM системы, а компании часто обращаются к hr агентствам, что хантят специалистов. По идее они и выступают в роли той самой базы, поскольку попав в чс к нескольким подобным агенствам можно себе добровольно закрыть доступ к рынку и проблема в том, что напрямую с компаниями в обход них тоже далеко не всегда связаться не вариант, т.к. они скорее-всего пробьют у тех же агенств информацию. Наверное это и можно назвать чёрной меткой, от которой избавиться довольно сложно.
Дело не в накрутке опыта. Банально любая проблема с работодателем может обернуться в таком случае потерей репутации и имей хоть 30 лет релевантного опыта, никто вас не возьмёт, потому что повесят ярлык проблемного, не продуктивного, не приятного в общении, внешности, характере и т.д. нужное подчеркнуть. Например, если пытаться заграницей искать работу без всех надлежащих документов, то эйчары вешают ярлык от которого не избавиться даже если гражданство страны получить.
Касаемо накрутки опыта, такой бред только на российском рынке встречал. Везде давно смотрят на портфолио, достижения на прошлых работах, плюс реальные рекомендаций (не от друга с левака, а человека с верифицированным аккаунтом и проверкой его слов). Опыт работы, как и разделение по скиллу (на джунов, сеньоров и т.д.), либо вообще не пишутся, либо указываются примерно.
Да, лулзы не выкупил и воспринял относительно серьёзно.)
Поэтому мне статья и понравилась, вы всё верно делаете и такой подход одобряю. Самому не нравятся собеседования экзамен лайк. Помню был собес, где спрашивали по всей теории, несколько часов. Когда не мог ответить, ведущие просто, молчали упиваясь моментом. Причём один раз говорил, что надо идти, но реакции ноль. С высоты текущего опыта, понимаю, что они сами в вопросах слабо разбирались. Лучшие же собесы, когда всегда уходил из компании с хорошем настроением (не важно был ли офер). Люди использовали похожие на ваш способы. Не задавали вопросы с молчанкой, а вели диалог. Мне понравился метод в одной компании, когда давали плохо написанный класс, говоря: "давайте вместе исправим". После диалога всё становилось понятно, т.к проверяли не олимпиадный рефакторинг, а навыки общения, способность быстро разбираться в чужом коде и искать решение проблем, используя все доступные возможности. Вы делаете если не точно так же, то примерно в этом же ключе, так что полностью поддерживаю.
Касаемо задачи, по идее это второй вариант решения из статьи, только заменил x - Math.floor(x) на x % 1. Про остаток от деления, помню со студенчества, поэтому первым в голову и пришёл. В люблю случае согласен, эта задача нужна для другого.)
Сначала думал, что это очередная статья в стиле "есть куда более лёгкий способ отсеять людей, чем алгоритмы", но к концу прочтения изменил мнение и во многом согласен с автором.
Я бы догодался до решения, на собесе, но к сожалению не сразу. Вот примерно, что набросал, когда прочитал и понял задачу: (x) => Math.foor(x) + (x % 1 => 0.5 ? 1 : 0)
Однако, решение в идеальном примере, мне нравится больше. Моё слишком громоздкое и хоть условие с 1 floor соблюдено, это точно всё и близко не уровень сеньора. Плюс, мой основной ЯП не JS и далеко не всю его специфику знаю.
Согласен со всем, кроме того, что "зубрить алгоритмы нужно в основном джунам". Честно я бы никому их зубрить не рекомендовал, если это напрямую не связано с работой. Знать основы алгоритмов думаю нужно всем, но углубляться в них сильно, пожеланию.
Использую в основном prime vue. Он довольно простой, относительно легковесный и даёт вполне себе гибкие возможности по кастомизации компонентов
То что несколько маленьких запросов выполняется быстрее, чем один быстрый правда. Сам заметил это давно.
Так же, как и тот факт (к теме не относится), что в mysql довольно кривые транзакции и одно время их не рекомендовали использовать сами создатели.
Статья интересная, автору спасибо.
Если честно меня раздражают парадоксы найма IT сферы.
Меняешь часто место работы - ненадёжный работник. Меняешь редко - не амбициозный, кроме шаблонных задач ничего не знает.
Имеешь богатый опыт работы, но с 1 ЯП и стеком - не хочешь саморазвиваться, скорее-всего топорный. Имеешь опыт со многими ЯП и разнообразными стеками, значит не профессионал и набрался всего по вершкам.
Хочешь иметь стабильную фиксированную зп, чтобы строить планы на жизнь - без перспективный или проблемный (не захочет перерабатывать, будет стараться уделять больше времени семье, чем работе). Меняешь работу ради грейдов по зп, фу бегунок.
И список можно продолжать очень долго, вплоть до бреда с резюме, по типу: Поставил фото - дурной тон, не поставил значит серая мышь; Указал зп - плохо, не указал - не попал в фильтры и т.д.
Думаю лучший вариант, это не слушать "вредные" советы и искать то, что в первую очередь подойдёт вам. В статье автора хорошее сравнение двух специалистов. Один много лет сидел в одном месте, а другой менял работу каждый год и оба довольны, при абсолютно разных подходах, потому что каждый выбрал путь, который больше нравился.
Пример хороший. Ещё есть один способ. Можно задать прямо очень сложный вопрос и посмотреть на реакцию. Если собеседуемый даст на него ответ по гуглу или около того, всё станет ясно. Правда это может адекватному программисту показаться ред флэгом (или как там новомодно сейчас).
П.С. Меня больше смутили слова: "у нас деплой в прод идёт я наблюдаю на другом мониторе". Что он там наблюдает, лично мне не совсем ясно. Ты либо деплоишь постоянно сидя в терминале либо нет.
Плюс если, что-то важное на работе, может стоит собес перенести, на свободное время?
Автор может тоже по своему прав, но я думаю всё куда проще и менее философски.
Если вы не заметили в мире сейчас идёт глобальный экономический кризис, который появился по многим причинам, но не в этом суть.
Так вот, IT в своём большинстве дотационная сфера, т.е. она завязана на других сферах и отраслях экономики. Поэтому рассматривать IT в плане кризиса, как что-то отдельное странно.
Сейчас не только IT но и все сферы может за исключением некоторых (по типу ритуальных услуг) испытают большие трудности.
Да, в IT и программировании в частности, есть проблемы, как в любой другой сфере. Лично меня из всего перечисленного коробят только трекеры. Если работодатель ставит трекер, то для меня он сразу улетает в чс, при этом я не против например каждый день описывать часы и задачи. ИМХО если ты не справляешься с работой, никакие трекеры твою продуктивность не повысят, ровно если, как если справляешься это не сделает тебя более эффективным.
Касаемо же сферы, то при всех её проблемах быть программистом лично для меня (как думаю и для многих здесь) в разы лучше, чем работать в другой сфере. Потому что количество плюшек намного выше, количества недостатков.
Как по мне есть только один способ, оценить навык, это портфолио. Причём не просто наличие проектов, а именно более подробный рассказ, что именно человек на проекте делал, попросить показать код, задать по нему несколько наводящих вопросов и т.д. Если мы говорим про студентов, то посмотреть пед проекты. Опять же имхо, но такой подход наверное единственный адекватный из всех что остались.
Касаемо первых двух описанных проблем, полностью согласен. Они правда часто встречаются, правда я бы посоветовал для единообразия использовать оформление:
Имхо так код более читаем, чем с использованием -top, -bottom, -left, -right префиксов. Вместо 2-4 строчек мы всегда имеем одну.
Касаемо последней проблемы, то идея неплохая, но селектор с nth-child(2), имхо лучше не использовать в списках или перечислениях элементов в целом. В примере указан селектор (> :nth-child(2)) и он будет работать спору нет, но что произойдёт, когда количество элементов поменяется? А если нужно будет сделать несколько кнопок с особой иконкой, то нам через запятую перечислять все селекторы? Как по мне в таких случаях лучше использовать первоначальный вариант, но немного изменить его:
Если нам нужно применить специальные стиль при разных вариациях иконок, то этих классов, по идее должно хватить.
Всё это неплохо, но меня только один вопрос волнует. Как можно подсчитать статистически степень вовлечённости работника?
"сотрудники демонстрируют большую вовлеченность (+230%)"
Как это рассчитывается? Почему именно 230%, а не 200 или 250?
"Как бы вы реализовали бесконечный цикл без использования ключевого слова while?"
При помощи go to конечно. 😏
Способов много , но мой любимый способ извратиться, это создать 2 класса с евентами отслеживающими изменения друг друга.
Касаемо кода с минутами, то за такое обильное количество if else if, на собесе точно не похвалят.)
Брать человека не знающего SQL, для работы с БД - это уровень фразы "просчитался, но где".) Большинство ORM по умолчанию даже нормальное индексирование не делают, о чём человек, не знающий SQL знать не будет, как и банально не сможет написать специфический функционал.)
Нет, не в меньшинстве.)
ORM по большей части используется для удобства и стандартизации работы с бд, а не ради производительности. Поэтому, как всегда всё сводится к поиску золотой середины под каждый проект в отдельности.
Хорошая статья.
Конечно некоторые фишки js воспринимаю за баги. Тоже замыкание, как по мне больше похоже на баг и со сложным кодом, не представляю, как это дебажить и тем-более покрывать тестами.
Если нужно хранить состояние, лучше класс или объект создам, так будет понятнее, как по мне.
Но опять же замыкание это особенность js и знать о ней минимум стоит.
Почему файтингов мало? Помимо того, что файтинги сейчас это более нисшевый жанр (даже более нисшевый, чем например стратегии), их довольно сложно разрабатывать. В файтингах очень важен баланс и тайминги. Если вы думаете, что это просто реализовать, особенно если проект мультиплеерный, то советую попробовать. С точки зрения геймдева и кода это вполне познавательный и интересный опыт.
Если вкратце, то 2д лучше 3д, из-за особенностей отрисовки анимаций, позиционирования моделей игроков и ещё много чего. Если проект мультиплеерный, то синхронизировать например быстрые удары по таймингам поверьте та ещё задача, особенно с блоками и парированиями. С точки зрения баланса, создать несколько разных персонажей с разными приёмами, но чтобы не было читерских комбинаций и не было полных контр персонажей другим персонажам.
Всё это нс словах звучит просто, но поверьте на деле это далеко не так.
Если честно 4o1- preview версия, по личным ощущениям хуже выдаёт ответы, чем просто 4о. Плюс ещё имеет лимит на запросы, даже в платной версии. Так же хуже решает задачи, т.к. хуже понимает контекст того же кода. Задаёт много лишних вопросов, когда 4о всё понимает с полуслова.
Плюс они в любом случае быстро отсеиваются на реальных задачах. Очень легко распознать человека, который вообще ничего не знает от специалиста, который либо имеет проблемы со скилом, либо просто волнуется. Первый будет делать задачи медленно, но понимать, что от него требуют и как это реализовать. Второй подавно всё знает, просто может совершить ошибки при волнении, но он будет писать код с большим пониманием того, что делает.
Человек, который ничего не знает, пишет код странно, из той же нейронки копирует код не думая, сыпаться на нестандартных, но простых вопросах о своём же коде.
П.С. Касаемо нейросетей, то не знаю как, но я в последнее время часто замечаю, что могу отличить код того же gpt, от кода, написанного человеком. Нейронки имеют свой стиль, что-ли, из-за чего на собесах и в тестовых заданиях легко такой код заметить.
Скорее не HRM системы, а компании часто обращаются к hr агентствам, что хантят специалистов. По идее они и выступают в роли той самой базы, поскольку попав в чс к нескольким подобным агенствам можно себе добровольно закрыть доступ к рынку и проблема в том, что напрямую с компаниями в обход них тоже далеко не всегда связаться не вариант, т.к. они скорее-всего пробьют у тех же агенств информацию. Наверное это и можно назвать чёрной меткой, от которой избавиться довольно сложно.
Дело не в накрутке опыта. Банально любая проблема с работодателем может обернуться в таком случае потерей репутации и имей хоть 30 лет релевантного опыта, никто вас не возьмёт, потому что повесят ярлык проблемного, не продуктивного, не приятного в общении, внешности, характере и т.д. нужное подчеркнуть. Например, если пытаться заграницей искать работу без всех надлежащих документов, то эйчары вешают ярлык от которого не избавиться даже если гражданство страны получить.
Касаемо накрутки опыта, такой бред только на российском рынке встречал. Везде давно смотрят на портфолио, достижения на прошлых работах, плюс реальные рекомендаций (не от друга с левака, а человека с верифицированным аккаунтом и проверкой его слов). Опыт работы, как и разделение по скиллу (на джунов, сеньоров и т.д.), либо вообще не пишутся, либо указываются примерно.