Ну окей. Сдаюсь. Термин выбран неудачно, а с 56 я пытаюсь реабилитирвоаться за неудачно выбранный термин. Сам всегда говорил что сижу зубрю, но это было именно попыткой разобраться. Повторять, разбираясь заново в том что когда-то знал, но забыл, для меня такая же унылая и бессмысленная затея как зубрежка. Но это субъективное моё, так что возражения по поводу зубрежки принимаю.
Вопрос про полезность экзамена на эти "часто попадающиеся на собесах задачи" оставим за скобками. Таки я алгосы учил и математику учил и хоть и не люблю проходить алгоритмические секции и сам никогда их не даю на собесах, но некоторых коллег (не мною нанятых) я бы туда воткнул носом и держал бы пока они не перестали писать тот ужас что они пишут. Так что тут одного мнения даже среди одного меня нет.
А когда у вас 56 разделов и на каждый 5-6 подходов то это уже опять зубрежка. Вот как-то так. Потому что вы не сможете это держать в голове вечно, вам потребуется для этого какой-то конспект, который вы будете время от времени механически повторять.
Интересное мнение. Но нет, ни IQ ни алгосы - не черепомерка, а задачи на приобретаемые навыки. От природы вы ни читать, ни писать, ни говорить не умели.
Я тоже не комментирую ценность. Её комментировать бесполезно в виду различия предметных областей у прикладного ПО. Кому-то необходимо считать установившееся напряжение в электросети, кому-то крудошлепать.
У вас походу чисто терминологическая претензия к "зубрежке". Она по-вашему не сопровождается разбором теории и практическими занятиями. Но это далеко не так. Вы изучаете раздел с алгоритмами на тех же графах или, я не знаю там, вычислительные методы решения системы дифференциальных уравнений. Читаете теорию, решаете задачи. Со временем из памяти без применения оно выветривается и вы идете и повторяете все это в более сжатом виде (потому что досканально повторять все - долго), попутно вспоминая что и зачем. И вот тут механизм аналогичен зазубриванию, не конкретных, естественно, задач, а теории раздела.
Без этой систематики просто открыть учебник и решить десять рандомных задач - просто глупость. Во-первых при достаточной сложности задач это у вас не получится без теории или подглядывания в решение, а во-вторых у этого процесса как у самурая - нет цели, только путь.
То как кандидат решает подобные задачи показывает его знание самого раздела алгоритмов и структур: теории, основных подходов и проблематики.
Опять же, это не оценочная, а целеполагательная поправка. Вы утверждаете что можно проверить абстрактный навык абстрагировать, приоретизировать, оценивать краевых и т.п на алгоритмах. Я утверждаю что алгоритмической задачей можно проэкзаменовать на знание раздела теории алгоритмов и на практические навыки применения этого раздела теории в первую очередь.
Часть навыков (оценка краевых) будет действительно наработанным общим для всех разделов. Тут кстати смешной момент. Сталкивался с тем что с ней на собесе и у собеседующего не всегда хорошо. Скажем любящие спрашивать на собесе даже такую бесхитростную вещь как RLE не всегда готовы к алгоритму не нуждающемуся в явной проверке краевых условий. Даже если им объяснили почему так. Хотя казалось бы задача максимально простая, пишется за 5 минут и благоволит тому чтобы по-быстрому все аспекты выяснить.
И какой мистический навык, скажите-ка мне, нужно соискателю развить чтобы сходу на собесе решить задачу из неизвестного ему раздела? Скажем он знаком с бинарными поисковыми деревьями и не знаком с задачами на циклических графах. Или все-таки ему придется пойти и изучить типовые обходы, проблематику и область применения, чтобы хотя бы знать в какую сторону копать? Что это как не зубрежка? ДП как раз пример типового подхода который надо именно что знать.
Уважаемый. Программирование и вообще инженерия это не изобретение бесконечных эвристик. По большей части это сведение к "известной задаче", знаете анекдот про математика и чайник? Ну тот в котором он воду выливает из чайника потому что алгоритм заварки с чайником без воды ему уже известен. Вот оно. Но в несколько иной форме. Ну и знание инструментов. Чаще даже не само по себе знание, а знание об их существовании и сфере применения, благо никто не мешает порисечить что лучше подходит в каждом конкретном случае.
Олимпиадные задачи по программированию равно как и по математике именно что придуманы так что решения без эвристики для них нет. Нужно вскрыть неявную закономерность, потому что для решения в лоб там просто недостаточно данных. А дальше применять подход (вот тут базовые знания нужны) характерный для этой закономерности - уже в лоб. Я в спешал олимпикс по программирования например никогда не участвовал, но в математику - был в олимпиадном кружке. В основном вся магия нестандартности сводится к тому что ты заучиваешь множество разнообразных базовых вещей чтобы видеть их там где хотя бы кончик уха от них торчит.
Неуча ответ. Вы видимо мало учили алгосов и структур, например не учили их в институте. Они точно так же там сдавались ПО БИЛЕТАМ на которые мы писали ШПАРГАЛКИ. Ей-богу, детский сад.
Беспроигрышный вариант хайпануть - запилить статью на тему "раньше мы из говна и палок делали космические корабли на 640 КБ памяти действительно запускали корабли в космос, а теперь текстовый редактор на электроне требует гигабайт памяти". Снизу обязательно будет срач в каментах, бывалые разработчики поставят лайк, птушта у них это все за годы в ушах просвистело и начинали они с курсовой по визуализации бикубических поверхностей которая писалась в турбо цпп, а проснулись за написанием плагина под десктоп на msvc под какой-нить флаттер и - не этого они от жизни ждали.
Я бы только вас поправил. 10 лет назад на дворе был 2014 - уже пятый дроид, пятый нексус, на носу (в 15-м) аж 10-я винда и тот самый vs code и прототип флаттера. Маркетинговые отделы получали премии за наполнение 75% поверхности сайта рекламными материалами, SPA давно вошли в полную силу, клан PWA в гугле тоже расцвел. Электрон начинал победное шествие, в гибридном мобайле, покушавшемся на мультиплатформу, были свои аналоги, джава-разработчики делали первые робкие попытки внедрить в прод еще не релизнувшийся котлин (в основном мобильщики, все знают что мобильщики безумны). Там же где-то и свифт (я помню мы с коллегой айосником в 14-м году учили их одновременнно - я котлин, он свифт). Ребята из бигтеха уже начали безумную модуляризацию своих проектов, что через год-два породит волну однояйцевых докладов на конференции "как мы ускорили сборку многомодульных проектов", то есть героически решили проблему абсолютной перегрузки сборки бесконечными градл-тасками, которую сами же и создали, решив что им нужна команда в 100 тел на одно маленькое приложение чтобы родить его не за 9 а за 0,09 месяцев и стало быть их детище должно быть попилено до рождения на 1000 частей, чтобы, стало быть, каждый рожал в день по нескольку десятков его кусков. И еще инфраструктурная команда, ежедневно принимающая роды (туши свет! они на свет лезут!).
Чуть позже, где-то году в 15-м или 16-м мне коллега скинет ровно такую же статью на том же самом хабре, только переводную. И в ней уже будет мгла. То есть вы что-то иное нежели мглу могли застать только в университете, где время, по объективным причинам, остановилось. А в жизни до работы просто не сталкивались с зоопарками, карго-культом и кадрово-ориентированным программированием (спойлер - оно всегда именно таково) и его главным постулатом: время компа уже в 90-е перестало быть дороже времени человека, что и привело к техническому взрыву.
Но это все лирика, вы вот скажите: вас самого не коробит от подстановки рядом слов "богобоязненный" и C#? Спрашиваю как сам бывший в несколько более далеком прошлом C# разработчиком.
Два возражения: 1. Контексты в общем случае пересекают системы вложенные в другой контекст, случай когда там только апи торчит - идеален.
2.Ирония насчет того что смежники не пересекают свои компетенции довольно смешная, обычно пересекают, САшки тут не единственные мученики, причем случай когда это прям для всех так это опять-таки идеал. Максимальная ответственность падает на самого ответственного и это было и будет.
Алгоритмы, структуры и паттерны проектирования + хорошая насмотренность в рамках рабочего и смежных стеков нужны и важны, в первую очередь, для того чтобы инженер имел инструментальную базу. Оная база позволяет опытному инженеру предложить не одно, а несколько решений задачи по разному весу в треугольнике "деньги-время-качество", отсеяв из них то не что подходит под область определения данной задачи.
Давать литкод-задачки, спрашивать основы фреймворка/языка, проверять количество запомненных дезигн-шаблонов на собесе бесполезно с уровня миддл+, это я вам как человек проводивший много собесов могу сказать. Все это хорошо для недавнего выпускника вуза у которого нет реального опыта, или для чуваков у которых он сильно однообразен. В первую голову мы матчим человека с проектом куда он пойдет и пытаемся определить справится ли он, во вторую насколько мы с ним сработаемся.
"Не терять форму" проходя собесы хорошо для собесов и вообще никак для работы. Встречал экстремально анекдотичных персонажей обоих сторон - и тех кто которые отшлифовали собес-скиллы и абсолютно непригодны для работы и тех кто вносят серьезный вклад в сложные проекты, но на собесах никакие. Сам в некоторые периоды жизни бывал во второй роли, фиксится это заплывом по этим самым собесам после любого перерыва.
Ну и - собесы не скатились. Собеседуют люди, люди все разные, опыт в найме это отдельный скилл. Чекнуть именно этот скилл - практически невозможно. Задачи набрать разработчиков умеющих подбирать других разработчиков никогда не стоит. В итоге техсобесы в подавляющем большинстве случаев проводят буквально дилетанты.
Вот вам и вся история с наймом и алгоритмами. Это не параллельные вселенные, но пересекаются они единожды.
С ним вообще весело пипец, даже если принять количественную величину на веру для ясности
Он фрактальный - если, скажем, в коллективе в котором 20% людей делают 80% работы отделить успешную выборку - они так же поделятся (даже если он один - по этому же принципу он 80% времени делает якобы незначимую фигню, а из 20% еще 80% тоже не такую значимую, итд)
Есть еще веселый эффект бабочки, который утверждает даже что самый малозначительный из факторов в неэффективных 80% может значительно повлиять остальные на 20%, но это случится не в первой итерации фрактала, а на достаточно удаленных его итерациях. Тут у нас расстоянием до другого конца планеты служит глубина анализа самых значимых факторов и разложение их на факторы поменьбше.
Очень примитивный пример: сотрудник Вася постоянно травит анекдоты в курилке и самый плохой работник месяца, сотрудник Петя самый результативный работник месяца. С первого взгляда Вася влияет на общий результат никак или очень мало (нормировка вклада от нуля, без отрицательных значений). Однако отбросив Васю как сырой фактор и детально прорабатывая Петины действия в течение месяца мы обнаруживаем что гениальная идея сильно повлиявшая на результат пришла Пете в курилке, когда он услышал анекдот от Васи (итерируем по фракталу Петиных действий, расщепляя их и отбрасывая 80% по влиянию на результат). И вот нам уже надо менять вес Васиного вклада в результат, но мы этого конечно делать не будем, потому что Вася раздолбай и нормально не умеет работать. Мы его уволим и возьмем Гену. Гена умный парень, результаты Пети, который хорошо общался с Васей возможно чуть упадут, но зато ему надо будет меньше вкалывать
Пока писал еще подумал еще про одну забавную связь Парето и каузальной атрибуции: Вася и Петя появились в одном отделе по-разному: Петя на 80% старался и ему на 20% повезло, а Вася на 20% старался и на 80% ему повезло, но оба считают что они молодцы.
Ну то есть в итоге контингент в основном это X-Y-Z. У которого такой дихотомии нет. Особенно смешно миллениалам, про которых медиа несли абсолютно ту же чушь что сейчас про зумеров еще лет 10-15 назад, а потом переключились на свежее поколение не меняя риторики. У людей чисто по субкультурным пристрастиям различий больше. Или по региональным. Но подаем как дихотомию, заметая все иксы и игреки под ковер к бумерам. Окей, чо. Я не то чтобы на вас наехать хочу, просто замечаю что сводить к дихотомии бумер-зумер это такой вот и есть неосознанный эйджизм. Как и то что саксесс-стори с возрастными людьми всегда пахнут немного как "ой вы посмотрите кто не накрылся своей простыней и не пополз на кладбище, как мило".
Индустрия взрослеет. Двадцать лет назад она была не такой большой и найти программиста с опытом в те же двадцать лет было очень и очень сложно. Так что в целом она была моложе. Но тогда же она и росла уже ударными темпами - в нее пришла куча людей которые к настоящему времени обзавелись теми самими двадцатью годами опыта. Как только появляется существенный разброс возрастов - начинается рефлексия. В частности появляется и эйджизм в обе стороны. И он никуда не уйдет, все с ним живут, во всех профессиях. "Мерзкий старикашка" и "заносчивый щенок" - стереотипные персонажи не просто так.
"Щас неизвестную алгоритмическую задачу без подготовки решу, в гугол возьмут, и миллион денег дадут" - вот Шариков.жпг
Ну окей. Сдаюсь. Термин выбран неудачно, а с 56 я пытаюсь реабилитирвоаться за неудачно выбранный термин. Сам всегда говорил что сижу зубрю, но это было именно попыткой разобраться. Повторять, разбираясь заново в том что когда-то знал, но забыл, для меня такая же унылая и бессмысленная затея как зубрежка. Но это субъективное моё, так что возражения по поводу зубрежки принимаю.
Вопрос про полезность экзамена на эти "часто попадающиеся на собесах задачи" оставим за скобками. Таки я алгосы учил и математику учил и хоть и не люблю проходить алгоритмические секции и сам никогда их не даю на собесах, но некоторых коллег (не мною нанятых) я бы туда воткнул носом и держал бы пока они не перестали писать тот ужас что они пишут. Так что тут одного мнения даже среди одного меня нет.
> что показывает умение решать незнакомые алгоритмические задачи
то что они вам незнакомы
в крупные компании таки ищутся те кому они знакомы
а IQ-тест и вся вышеперечисленная лабуда себя скомпрометировали задолго до конца прошлого века
А когда у вас 56 разделов и на каждый 5-6 подходов то это уже опять зубрежка. Вот как-то так. Потому что вы не сможете это держать в голове вечно, вам потребуется для этого какой-то конспект, который вы будете время от времени механически повторять.
Интересное мнение. Но нет, ни IQ ни алгосы - не черепомерка, а задачи на приобретаемые навыки. От природы вы ни читать, ни писать, ни говорить не умели.
Я тоже не комментирую ценность. Её комментировать бесполезно в виду различия предметных областей у прикладного ПО. Кому-то необходимо считать установившееся напряжение в электросети, кому-то крудошлепать.
У вас походу чисто терминологическая претензия к "зубрежке". Она по-вашему не сопровождается разбором теории и практическими занятиями. Но это далеко не так. Вы изучаете раздел с алгоритмами на тех же графах или, я не знаю там, вычислительные методы решения системы дифференциальных уравнений. Читаете теорию, решаете задачи. Со временем из памяти без применения оно выветривается и вы идете и повторяете все это в более сжатом виде (потому что досканально повторять все - долго), попутно вспоминая что и зачем. И вот тут механизм аналогичен зазубриванию, не конкретных, естественно, задач, а теории раздела.
Без этой систематики просто открыть учебник и решить десять рандомных задач - просто глупость. Во-первых при достаточной сложности задач это у вас не получится без теории или подглядывания в решение, а во-вторых у этого процесса как у самурая - нет цели, только путь.
То как кандидат решает подобные задачи показывает его знание самого раздела алгоритмов и структур: теории, основных подходов и проблематики.
Опять же, это не оценочная, а целеполагательная поправка. Вы утверждаете что можно проверить абстрактный навык абстрагировать, приоретизировать, оценивать краевых и т.п на алгоритмах. Я утверждаю что алгоритмической задачей можно проэкзаменовать на знание раздела теории алгоритмов и на практические навыки применения этого раздела теории в первую очередь.
Часть навыков (оценка краевых) будет действительно наработанным общим для всех разделов. Тут кстати смешной момент. Сталкивался с тем что с ней на собесе и у собеседующего не всегда хорошо. Скажем любящие спрашивать на собесе даже такую бесхитростную вещь как RLE не всегда готовы к алгоритму не нуждающемуся в явной проверке краевых условий. Даже если им объяснили почему так. Хотя казалось бы задача максимально простая, пишется за 5 минут и благоволит тому чтобы по-быстрому все аспекты выяснить.
И какой мистический навык, скажите-ка мне, нужно соискателю развить чтобы сходу на собесе решить задачу из неизвестного ему раздела? Скажем он знаком с бинарными поисковыми деревьями и не знаком с задачами на циклических графах. Или все-таки ему придется пойти и изучить типовые обходы, проблематику и область применения, чтобы хотя бы знать в какую сторону копать? Что это как не зубрежка? ДП как раз пример типового подхода который надо именно что знать.
Уважаемый. Программирование и вообще инженерия это не изобретение бесконечных эвристик. По большей части это сведение к "известной задаче", знаете анекдот про математика и чайник? Ну тот в котором он воду выливает из чайника потому что алгоритм заварки с чайником без воды ему уже известен. Вот оно. Но в несколько иной форме. Ну и знание инструментов. Чаще даже не само по себе знание, а знание об их существовании и сфере применения, благо никто не мешает порисечить что лучше подходит в каждом конкретном случае.
Олимпиадные задачи по программированию равно как и по математике именно что придуманы так что решения без эвристики для них нет. Нужно вскрыть неявную закономерность, потому что для решения в лоб там просто недостаточно данных. А дальше применять подход (вот тут базовые знания нужны) характерный для этой закономерности - уже в лоб. Я в спешал олимпикс по программирования например никогда не участвовал, но в математику - был в олимпиадном кружке. В основном вся магия нестандартности сводится к тому что ты заучиваешь множество разнообразных базовых вещей чтобы видеть их там где хотя бы кончик уха от них торчит.
Неуча ответ. Вы видимо мало учили алгосов и структур, например не учили их в институте. Они точно так же там сдавались ПО БИЛЕТАМ на которые мы писали ШПАРГАЛКИ. Ей-богу, детский сад.
Алгосы - такая же зубрежка как все остальное.
я ждал что вы подыграете и напишете "с божией помощью"
Ну я вот просто не знаю как можно играться в цпп-интероп и при этом бояться чего/кого бы то ни было, даже если это Бог.
Беспроигрышный вариант хайпануть - запилить статью на тему "раньше мы
из говна и палок делали космические кораблина 640 КБ памяти действительно запускали корабли в космос, а теперь текстовый редактор на электроне требует гигабайт памяти". Снизу обязательно будет срач в каментах, бывалые разработчики поставят лайк, птушта у них это все за годы в ушах просвистело и начинали они с курсовой по визуализации бикубических поверхностей которая писалась в турбо цпп, а проснулись за написанием плагина под десктоп на msvc под какой-нить флаттер и - не этого они от жизни ждали.Я бы только вас поправил. 10 лет назад на дворе был 2014 - уже пятый дроид, пятый нексус, на носу (в 15-м) аж 10-я винда и тот самый vs code и прототип флаттера. Маркетинговые отделы получали премии за наполнение 75% поверхности сайта рекламными материалами, SPA давно вошли в полную силу, клан PWA в гугле тоже расцвел. Электрон начинал победное шествие, в гибридном мобайле, покушавшемся на мультиплатформу, были свои аналоги, джава-разработчики делали первые робкие попытки внедрить в прод еще не релизнувшийся котлин (в основном мобильщики, все знают что мобильщики безумны). Там же где-то и свифт (я помню мы с коллегой айосником в 14-м году учили их одновременнно - я котлин, он свифт). Ребята из бигтеха уже начали безумную модуляризацию своих проектов, что через год-два породит волну однояйцевых докладов на конференции "как мы ускорили сборку многомодульных проектов", то есть героически решили проблему абсолютной перегрузки сборки бесконечными градл-тасками, которую сами же и создали, решив что им нужна команда в 100 тел на одно маленькое приложение чтобы родить его не за 9 а за 0,09 месяцев и стало быть их детище должно быть попилено до рождения на 1000 частей, чтобы, стало быть, каждый рожал в день по нескольку десятков его кусков. И еще инфраструктурная команда, ежедневно принимающая роды (туши свет! они на свет лезут!).
Чуть позже, где-то году в 15-м или 16-м мне коллега скинет ровно такую же статью на том же самом хабре, только переводную. И в ней уже будет мгла. То есть вы что-то иное нежели мглу могли застать только в университете, где время, по объективным причинам, остановилось. А в жизни до работы просто не сталкивались с зоопарками, карго-культом и кадрово-ориентированным программированием (спойлер - оно всегда именно таково) и его главным постулатом: время компа уже в 90-е перестало быть дороже времени человека, что и привело к техническому взрыву.
Но это все лирика, вы вот скажите: вас самого не коробит от подстановки рядом слов "богобоязненный" и C#? Спрашиваю как сам бывший в несколько более далеком прошлом C# разработчиком.
Два возражения:
1. Контексты в общем случае пересекают системы вложенные в другой контекст, случай когда там только апи торчит - идеален.
2.Ирония насчет того что смежники не пересекают свои компетенции довольно смешная, обычно пересекают, САшки тут не единственные мученики, причем случай когда это прям для всех так это опять-таки идеал. Максимальная ответственность падает на самого ответственного и это было и будет.
Алгоритмы, структуры и паттерны проектирования + хорошая насмотренность в рамках рабочего и смежных стеков нужны и важны, в первую очередь, для того чтобы инженер имел инструментальную базу. Оная база позволяет опытному инженеру предложить не одно, а несколько решений задачи по разному весу в треугольнике "деньги-время-качество", отсеяв из них то не что подходит под область определения данной задачи.
Давать литкод-задачки, спрашивать основы фреймворка/языка, проверять количество запомненных дезигн-шаблонов на собесе бесполезно с уровня миддл+, это я вам как человек проводивший много собесов могу сказать. Все это хорошо для недавнего выпускника вуза у которого нет реального опыта, или для чуваков у которых он сильно однообразен. В первую голову мы матчим человека с проектом куда он пойдет и пытаемся определить справится ли он, во вторую насколько мы с ним сработаемся.
"Не терять форму" проходя собесы хорошо для собесов и вообще никак для работы. Встречал экстремально анекдотичных персонажей обоих сторон - и тех кто которые отшлифовали собес-скиллы и абсолютно непригодны для работы и тех кто вносят серьезный вклад в сложные проекты, но на собесах никакие. Сам в некоторые периоды жизни бывал во второй роли, фиксится это заплывом по этим самым собесам после любого перерыва.
Ну и - собесы не скатились. Собеседуют люди, люди все разные, опыт в найме это отдельный скилл. Чекнуть именно этот скилл - практически невозможно. Задачи набрать разработчиков умеющих подбирать других разработчиков никогда не стоит. В итоге техсобесы в подавляющем большинстве случаев проводят буквально дилетанты.
Вот вам и вся история с наймом и алгоритмами. Это не параллельные вселенные, но пересекаются они единожды.
решение неформализованной задачи начинается с допроса с пристрастием всех к ней причастных и никак иначе
С ним вообще весело пипец, даже если принять количественную величину на веру для ясности
Он фрактальный - если, скажем, в коллективе в котором 20% людей делают 80% работы отделить успешную выборку - они так же поделятся (даже если он один - по этому же принципу он 80% времени делает якобы незначимую фигню, а из 20% еще 80% тоже не такую значимую, итд)
Есть еще веселый эффект бабочки, который утверждает даже что самый малозначительный из факторов в неэффективных 80% может значительно повлиять остальные на 20%, но это случится не в первой итерации фрактала, а на достаточно удаленных его итерациях. Тут у нас расстоянием до другого конца планеты служит глубина анализа самых значимых факторов и разложение их на факторы поменьбше.
Очень примитивный пример: сотрудник Вася постоянно травит анекдоты в курилке и самый плохой работник месяца, сотрудник Петя самый результативный работник месяца. С первого взгляда Вася влияет на общий результат никак или очень мало (нормировка вклада от нуля, без отрицательных значений). Однако отбросив Васю как сырой фактор и детально прорабатывая Петины действия в течение месяца мы обнаруживаем что гениальная идея сильно повлиявшая на результат пришла Пете в курилке, когда он услышал анекдот от Васи (итерируем по фракталу Петиных действий, расщепляя их и отбрасывая 80% по влиянию на результат). И вот нам уже надо менять вес Васиного вклада в результат, но мы этого конечно делать не будем, потому что Вася раздолбай и нормально не умеет работать. Мы его уволим и возьмем Гену. Гена умный парень, результаты Пети, который хорошо общался с Васей возможно чуть упадут, но зато ему надо будет меньше вкалывать
Пока писал еще подумал еще про одну забавную связь Парето и каузальной атрибуции: Вася и Петя появились в одном отделе по-разному: Петя на 80% старался и ему на 20% повезло, а Вася на 20% старался и на 80% ему повезло, но оба считают что они молодцы.
Не отпускает первое апреля короче.
Я тоже умею в занимательную статистику. Подержите мое пиво.
У 80% сотрудников HR когнитивные способности недостаточны для оценки кандидатов.
У 80% кандидатов когнитивные способности недостаточны для выполнения работы.
У 80% авторов хабра когнитивные способности недостаточны для того чтобы быть авторами технических статей.
У 80% комментаторов недостаточные когнитивные способности чтобы адекватно воспринять и прокомментировать статью по существу.
У 80% людей которые затирают про статистику цифры берутся с потолка.
Ну привет, заканчивается. Там ты такой красивый румяный сорокалетний будешь за пивом бегать олдскульным бородачам, потому что молодой ещо.
Ну то есть в итоге контингент в основном это X-Y-Z. У которого такой дихотомии нет. Особенно смешно миллениалам, про которых медиа несли абсолютно ту же чушь что сейчас про зумеров еще лет 10-15 назад, а потом переключились на свежее поколение не меняя риторики. У людей чисто по субкультурным пристрастиям различий больше. Или по региональным. Но подаем как дихотомию, заметая все иксы и игреки под ковер к бумерам. Окей, чо. Я не то чтобы на вас наехать хочу, просто замечаю что сводить к дихотомии бумер-зумер это такой вот и есть неосознанный эйджизм. Как и то что саксесс-стори с возрастными людьми всегда пахнут немного как "ой вы посмотрите кто не накрылся своей простыней и не пополз на кладбище, как мило".
Индустрия взрослеет. Двадцать лет назад она была не такой большой и найти программиста с опытом в те же двадцать лет было очень и очень сложно. Так что в целом она была моложе. Но тогда же она и росла уже ударными темпами - в нее пришла куча людей которые к настоящему времени обзавелись теми самими двадцатью годами опыта. Как только появляется существенный разброс возрастов - начинается рефлексия. В частности появляется и эйджизм в обе стороны. И он никуда не уйдет, все с ним живут, во всех профессиях. "Мерзкий старикашка" и "заносчивый щенок" - стереотипные персонажи не просто так.