"Первым ваше резюме видит HR или AI-фильтр (ATS)."
Ничто не мешает соискателю в ответ использовать те же подходы и технологии для поиска комфортной вакансии, и удобного работодателя. В итоге AI будет искать AI.
Поиск вакансии - это вычитка вакансий, это тоже труд. HR похоже, пошли по пути наименьшего сопротивления. Расскажите тогда, какой профит получили от такого подхода.
Сцены это ведь по сути и есть проект. Есть же корневые ноды у сцен. Так вот корневые ноды сцен - это основная часть проекта, потом подноды сцен. А табы для редактора скриптов сцен.
Список сцен представлен вкладками. Причем вкладки сцен как-то в стороне от дерева самой сцены. Если я удалю вкладку, то мне приходится искать сцену в дереве файлов, что неудобно.
Когда я выбираю вкладку сцены, а ожидаю, что в редакторе автоматически откроется соответствующий скрипт. Сейчас приходится вручную выбирать скрипт из боковой панели редактора. Жутко запутывает. Разве не "одна сцена -> один скрипт"?
Из второго пункта вытекает: сложно отслеживать зависимости между сигналами и слотами, особенно если сигнал/слот находятся в разных скриптах сцен.
В редакторе скрипта сцен значек наличия соединения слота появляется, если выбрать сцену и соответствующий скрипт. Почему бы не проверять по всем файлам? Разумеется, может быть медленно.
Я сделал панель плавающей, а как вернуть? Хорошо, что после перезагрузки вернулись настройки по-умолчанию.
Успеваю, не успеваю, но у меня для этого QuiteRSS есть, которым насобирал уже более 100 Мб базу статей (поздно начал). Так или иначе, что-то может пригодиться. Уже и тегами самое интересное помечено.
Подобный ответ я ожидал. Что-то мне подсказывает, что наступит время, когда возникнет тонкая грань между должностью DevOps и Developer. И тогда DevOps сможет сказать, что он Developer, а вот Developer, что он DevOps - нет.
И это весь анализ и все выводы?! От себя добавлю: HR стали "перебирать харчами". И перебирание уже начинается на этапе чтения резюме. Сколько статей от HR и компаний, как писать резюме. Если HR так сложно читать резюме, может это вопрос к его компетентности?! Если вы ищите кандидата на определенную должность, то ожидаете в резюме опыт только для этой должности? Почему я должен выкидывать из резюме свой 20-летний опыт и стаж, изложенный в хронологическом порядке, который включает владение разными языками, СУБД, технологиями?!
Знаете как делали до всего этого? Просто ходили в кафе/рестораны. Может не так часто как сейчас, раз в месяц, на праздники. И субеъктивная оценка была точной.
Иногда просто зайдя во внутрь, понимаешь, что тратиться тут не стоит. Многие факторы могут указать на качество заведения: расположение, контингент вокруг ресторана и внутри, состав меню, график работы....
Сейчас может оказаться достаточно взглянуть на панорамное фото возле ресторана на картах, чтобы принять решение о посещении.
А насколько далеко ушли Android-разработчики, со своими паттернами, ООП, SOLID, coroutines, Compose от проблемы NPE и лавирования между жизненными циклами активностей и фрагментов для достижения ожидаемого певедения приложения?
Раньше код был более оптимизирован, не смотря на сумбурность. Используя классы, прикомпилируются полно проверок и информации о классах. По поводу суперкомпьютера в кармане. Если в начале развития Android, java-разработчики были против статиков, то сейчас их генерируют полно библиотек, приложения занимают много памяти и тормозят, но зато синтаксический сахар, ООПэ и всё такое.
Если уровень сложности статьи простой, ожидается, что будут разъяснения по поводу сокращений и аббривеатур, что они значат и как работают. Я завис уже на MX-записях. Где они находятся и как образуются? Разумеется, это можно нагуглить, но стиль изложения такой, будто объясняется человеку уже с хорошим пониманием материала.
"Первым ваше резюме видит HR или AI-фильтр (ATS)."
Ничто не мешает соискателю в ответ использовать те же подходы и технологии для поиска комфортной вакансии, и удобного работодателя. В итоге AI будет искать AI.
Поиск вакансии - это вычитка вакансий, это тоже труд. HR похоже, пошли по пути наименьшего сопротивления. Расскажите тогда, какой профит получили от такого подхода.
В Visual Studio Code файловую панель сделали основой проекта. В Godot она находится внизу. Проект, сцена, файлы - не понятны приоритеты в интерфейсе.
Сцены это ведь по сути и есть проект. Есть же корневые ноды у сцен. Так вот корневые ноды сцен - это основная часть проекта, потом подноды сцен. А табы для редактора скриптов сцен.
А почему по-умолчанию не так?
Я тольно начал осваивать, но уже хочется бросить.
IDE ужасно неудобное.
Список сцен представлен вкладками. Причем вкладки сцен как-то в стороне от дерева самой сцены. Если я удалю вкладку, то мне приходится искать сцену в дереве файлов, что неудобно.
Когда я выбираю вкладку сцены, а ожидаю, что в редакторе автоматически откроется соответствующий скрипт. Сейчас приходится вручную выбирать скрипт из боковой панели редактора. Жутко запутывает. Разве не "одна сцена -> один скрипт"?
Из второго пункта вытекает: сложно отслеживать зависимости между сигналами и слотами, особенно если сигнал/слот находятся в разных скриптах сцен.
В редакторе скрипта сцен значек наличия соединения слота появляется, если выбрать сцену и соответствующий скрипт. Почему бы не проверять по всем файлам? Разумеется, может быть медленно.
Я сделал панель плавающей, а как вернуть? Хорошо, что после перезагрузки вернулись настройки по-умолчанию.
З.Ы. Понятно, что разработчики не прочитают.
Может это зависит от конфигурации, но ping в 2 раза больше чем до google.
Узрел я в этой статье рекламу внешних приводов, не более того.
Побольше бы подробностей технической реализации.
ГОДЫ СТРАНСТВИЙ
И тут, когда я эти годы, казалось бы повод для гордости, озвучиваю в резюме, на меня смотрят как на "Overqualification"....
Успеваю, не успеваю, но у меня для этого QuiteRSS есть, которым насобирал уже более 100 Мб базу статей (поздно начал). Так или иначе, что-то может пригодиться. Уже и тегами самое интересное помечено.
А принципиальность исца решается радикально, надо полагать?!
Возможно, вы имеете ввиду компанию, которая слабо связана с IT, но иммет IT-департамент в штате?
А full-stack разве не overqualified ? Просто количество навыков как-бы подозрение должно вызывать.
Подобный ответ я ожидал. Что-то мне подсказывает, что наступит время, когда возникнет тонкая грань между должностью DevOps и Developer. И тогда DevOps сможет сказать, что он Developer, а вот Developer, что он DevOps - нет.
И в таком случае DevOps - будет overqualified.
Но DevOps, почему-то, будет оставаться востребованным.
Плюшки тут второе. Более интересен список обязанностей и набор необходимых технологий для проекта, а также, насколько проект старый.
И это весь анализ и все выводы?! От себя добавлю: HR стали "перебирать харчами". И перебирание уже начинается на этапе чтения резюме. Сколько статей от HR и компаний, как писать резюме. Если HR так сложно читать резюме, может это вопрос к его компетентности?! Если вы ищите кандидата на определенную должность, то ожидаете в резюме опыт только для этой должности? Почему я должен выкидывать из резюме свой 20-летний опыт и стаж, изложенный в хронологическом порядке, который включает владение разными языками, СУБД, технологиями?!
Полагаю, что никак. Высокая концентрация конкурентов в одном месте уравнивает = уменьшает их конкурентные вохможности.
Знаете как делали до всего этого? Просто ходили в кафе/рестораны. Может не так часто как сейчас, раз в месяц, на праздники. И субеъктивная оценка была точной.
Иногда просто зайдя во внутрь, понимаешь, что тратиться тут не стоит. Многие факторы могут указать на качество заведения: расположение, контингент вокруг ресторана и внутри, состав меню, график работы....
Сейчас может оказаться достаточно взглянуть на панорамное фото возле ресторана на картах, чтобы принять решение о посещении.
А насколько далеко ушли Android-разработчики, со своими паттернами, ООП, SOLID, coroutines, Compose от проблемы NPE и лавирования между жизненными циклами активностей и фрагментов для достижения ожидаемого певедения приложения?
Раньше код был более оптимизирован, не смотря на сумбурность. Используя классы, прикомпилируются полно проверок и информации о классах. По поводу суперкомпьютера в кармане. Если в начале развития Android, java-разработчики были против статиков, то сейчас их генерируют полно библиотек, приложения занимают много памяти и тормозят, но зато синтаксический сахар, ООПэ и всё такое.
Если уровень сложности статьи простой, ожидается, что будут разъяснения по поводу сокращений и аббривеатур, что они значат и как работают. Я завис уже на MX-записях. Где они находятся и как образуются? Разумеется, это можно нагуглить, но стиль изложения такой, будто объясняется человеку уже с хорошим пониманием материала.