На фоне статей от hh и хабр-карьеры, аналитика в этой статье кажется более реальной, по крайней мере с моей колокольни...
Не хватает оценки в разрезе технологических стеков - это показало бы заметный дисбаланс между тем, кого ищут, и тем, кого готовят, особенно компании на эти 3%. Понять это достаточно просто с использованием поисковой строки hh.ru - вакансий в области 1С на порядок больше, чем по любому другому стеку. Но при этом FAANG ТОСЯ их не готовят, ибо "можно, но зачем?".
Это именно "руководство", т.е. оперативное, как капитан парусника руководит матросами, или выстроенные процессы и грамотный тим-билдинг (в прямом смысле этого термина)? Т.е. будет ли оно все также хорошо работать без вашего руководства? И если нет, то хороший ли вы руководитель?
в зависимость от одного-единственного вменяемого тракториста на всю деревню.
Без углубления в детали, аналогия все-такие подходящая - при сравнимой площади, вместо зависимости от одного тракториста, будешь зависеть от всей деревни лопато-копателей.
Но в некоторых климатических условиях, на относительно небольших объемах, плуг и лощадь, устойчивые к санкционному давлению и блокировке со стороны поставщика, могут оказаться вполне эффективными. Но вот квалификация персонала может потребоваться еще выше, чем для трактора.
Это как минимум говорит об отсутствии квалификации у нанимающей стороны. Если и решать такую задачу, то точно не исключительно языковой моделью. На эту тему целое исследование недавно опубликовано на хабре - https://habr.com/ru/articles/995822/
Суть его подхода была такой: за счет своих отличных soft skills и теоретической базы он прошел собеседование и получил оффер с высокой белой зарплатой. А потом работал в режиме энергосбережения, делая ровно столько, чтобы не уволили по статье.
А если взглянуть на этот "феномен" под другим углом. По вашему тексту, чтобы получить у вас `оффер с высокой белой зарплатой`, необходимы `отличные soft skills и теоретическая база`. И, вероятно, не только у вас, раз "Антон" продал это за несколько офферов. А раз это хорошо продается, какая причина на этом не зарабатывать?
По сути, весь этот "кризис доверия" устраняется двумя шагами - 1) тестовое задание 2) трудовая книжка. Но, так понимаю, работодателю это "дорого" организовывать (дешевле терять на повторном найме).
если мы смотрим именно на метрики, у сеньора 1) большее количество кода с 2) более сложной структурой с 3) меньшим значением цикломатической сложности.
Именно это я и написал. Или что имеется ввиду под ответом "нет"? Что мы вначале определяем "истинного сеньора", а уже потом его "отличительные признаки", и в обратном направлении это не работает?
Я увидел такой результат вашего исследования - чем больше кода, тем сложнее он организован (т.е. менее сложен цикломатически), тем меньше в нем "шаблонных решений" (относительно общего объема кода). Другими словами, статистически, чем больше кода написал разработчик, тем ближе он к "Истинному Сеньору". Итого грейд = стаж. Или нет?
Полезный комментарий. Грубый без какой-либо необходимости, но полезный. Векторизация алгоритмов не самая известная техника, но благодаря таким комментариям, чуть больше людей обратят на это внимание, чуть поднимется общий уровень в профессии. К тому же, в .NET для этого есть инструменты.
Очень похоже, что более не имеет поддержки и развития.
Не рассматривали Microsoft Solver Foundation ? Библиотека старая, но за последние десятилетия в математических методах решения уравнений ничего вроде бы не изменилось.
Добавил Interval tree (включая тесты, пример, бенчмарки). Это оптимальное решение для поиска интервалов в заданном множестве, пересекающих произвольный интервал.
var intervalTree = new IntervalTree(ranges);
var intersectingRanges = intervalTree.SearchIntersections(range);
На мой взгляд, тесты, а тем более картинки, гораздо лучше слов в данном случае. В целом, результат работы Intersections можно представить как "пересечение пересечений" - нашли все попарные пересечения, потом нашли все попарные пересечения найденных пересечений, и так далее, пока результат меняется. Это представление ожидаемого результата, сам алгоритм реализован иначе. Я все же рекомендую посмотреть на тесты - они довольно наглядные.
Примечательно, что на подтормаживает (в хроме) только когда включено отображение зависимостей. Когда показаны только точки, все в общем-то стабильно, без лагов.
Интересно посмотреть, как будут вести себя полноценные Unity приложения, экспортированные в WebGL
На фоне статей от hh и хабр-карьеры, аналитика в этой статье кажется более реальной, по крайней мере с моей колокольни...
Не хватает оценки в разрезе технологических стеков - это показало бы заметный дисбаланс между тем, кого ищут, и тем, кого готовят, особенно компании на эти 3%. Понять это достаточно просто с использованием поисковой строки hh.ru - вакансий в области 1С на порядок больше, чем по любому другому стеку. Но при этом
FAANGТОСЯ их не готовят, ибо "можно, но зачем?".Это именно "руководство", т.е. оперативное, как капитан парусника руководит матросами, или выстроенные процессы и грамотный тим-билдинг (в прямом смысле этого термина)? Т.е. будет ли оно все также хорошо работать без вашего руководства? И если нет, то хороший ли вы руководитель?
Без углубления в детали, аналогия все-такие подходящая - при сравнимой площади, вместо зависимости от одного тракториста, будешь зависеть от всей деревни лопато-копателей.
Но в некоторых климатических условиях, на относительно небольших объемах, плуг и лощадь, устойчивые к санкционному давлению и блокировке со стороны поставщика, могут оказаться вполне эффективными. Но вот квалификация персонала может потребоваться еще выше, чем для трактора.
Это как минимум говорит об отсутствии квалификации у нанимающей стороны. Если и решать такую задачу, то точно не исключительно языковой моделью. На эту тему целое исследование недавно опубликовано на хабре - https://habr.com/ru/articles/995822/
А если взглянуть на этот "феномен" под другим углом. По вашему тексту, чтобы получить у вас `оффер с высокой белой зарплатой`, необходимы `отличные soft skills и теоретическая база`. И, вероятно, не только у вас, раз "Антон" продал это за несколько офферов. А раз это хорошо продается, какая причина на этом не зарабатывать?
По сути, весь этот "кризис доверия" устраняется двумя шагами - 1) тестовое задание 2) трудовая книжка. Но, так понимаю, работодателю это "дорого" организовывать (дешевле терять на повторном найме).
Смотря как смотреть. Обижаться конечно нет смысла. И "что лично вы не прошли этот отсев заказчику плевать" суровая правда несправедливой жизни. Но:
вакансий сильно меньше, чем откликов, а не соискателей
"непонятные правила => непонятные судьи => непонятные кандидаты"
Так что в целом найм именно сломан. Пока это проблемы отдельных людей. Но к каким последствиям это приведет на горизонте два-три года?
Именно это я и написал. Или что имеется ввиду под ответом "нет"? Что мы вначале определяем "истинного сеньора", а уже потом его "отличительные признаки", и в обратном направлении это не работает?
Я увидел такой результат вашего исследования - чем больше кода, тем сложнее он организован (т.е. менее сложен цикломатически), тем меньше в нем "шаблонных решений" (относительно общего объема кода). Другими словами, статистически, чем больше кода написал разработчик, тем ближе он к "Истинному Сеньору". Итого грейд = стаж. Или нет?
Полезный комментарий. Грубый без какой-либо необходимости, но полезный. Векторизация алгоритмов не самая известная техника, но благодаря таким комментариям, чуть больше людей обратят на это внимание, чуть поднимется общий уровень в профессии. К тому же, в .NET для этого есть инструменты.
Очень похоже, что более не имеет поддержки и развития.
Не рассматривали Microsoft Solver Foundation ? Библиотека старая, но за последние десятилетия в математических методах решения уравнений ничего вроде бы не изменилось.
Возможно пора сбегать в Java. Вот такие есть свежие вакансии:
Добавил Interval tree (включая тесты, пример, бенчмарки). Это оптимальное решение для поиска интервалов в заданном множестве, пересекающих произвольный интервал.
На мой взгляд, тесты, а тем более картинки, гораздо лучше слов в данном случае. В целом, результат работы
Intersectionsможно представить как "пересечение пересечений" - нашли все попарные пересечения, потом нашли все попарные пересечения найденных пересечений, и так далее, пока результат меняется. Это представление ожидаемого результата, сам алгоритм реализован иначе. Я все же рекомендую посмотреть на тесты - они довольно наглядные.Результат на картинках. Самый близкий тест Overlapped_Ranges. В чем именно неочевидность? То есть, должен быть какой-то другой результат?
Перевод на русский английской статьи русскоязычного хабраюзера, который присутствует в комментариях к этому переводу.
Думаю, будет полезно всем заинтересованным, в том числе и вам как компании, как считаете?
Старая тема, еще с 2013 года фич-реквест. Если коротко: у TypeScript есть «идеологические несовместимости» с asm.js.
Интересно посмотреть, как будут вести себя полноценные Unity приложения, экспортированные в WebGL
Вообще, довольно странно, что в .NET Framework «из коробки» до сих пор нет например BooleanToVisibilityConverter.