Ты соврал в опыте, чтобы пройти "формальный фильтр" HR. Теперь у тебя в резюме ещё порядка 20 технологий (если уровня git и bush считать) - в скольких ты ещё соврал? Вот теперь я таки-должен тебе поверить или ты опять соврал чтобы пройти проще формальный фильтр "нужные технологии" перед устройством на работу? Что мне теперь делать с тобой: - поверить что ты не врёшь (а если технологий не знаешь - доучивать за свой счёт)? - проверять каждый пункт резюме и взять откуда-то второй час для собеседования по-существу?
Хм... кажется ты предлагаешь мне заведомо плохой выбор - поверить заведомому вруну или потерять лишний час времени (это на собеседование джуна-то!). Рациональное решение с моей точи зрения поставить фильтр: джун заведомо соврал в резюме сразу отказ.
И это мы ещё даже не приступали к ключевому вопросу - человек врущий в резюме также будет врать по работе?
Когда я набирал джунов год назад - сразу после универа рассматривал, самоучек рассматривал, после школ - не рассматривал. В том числе, но не только, потому что их учат врать.
I. От людей по-умолчанию ожидается соблюдение обычаев делового оборота (не врать в резюме, не врать в отчётах, выполнять обещания....). Если кто-то их не соблюдает - он уже сразу в софт-скилах хуже буквально всех людей окружающих меня по работе, включая девочку тим-ассистанта. Может быть через 5 лет "традиции делового оборота" изменятся - и врать в резюме будет никак не связано с "врать в недельных отчётах". Но пока эти требования стоят в одном ряду.
II. Школы "войти-в-айти" в этом смысле очень плохой бизнес - в том смысле что они торгуют заведомо невыполнимыми обещаниями, о чём они знают, а люди несущие им по 100тыр - не знают. При этом эти 100тыр - для многих весьма значительные деньги.
III. Сейчас не набираю. Год назад на прошлой работе я нанимал - сконтачился бы с вами. Рассматривал джунов "писать сервисы для системного программирования".
Отсобеседовав пару дюжин выпускников курсов за пару недель - принял решения резюме со "школами" не рассматривать вообще. Универ - рассматривать, самоучек - рассматривать, школы - нет. Смущало две вещи:
Очевидно, что эти люди давали обещания "не знаю но буду учиться, буду работать..." ни на секунду не задумываясь почему если они сейчас не знают, то справятся? И не взвешивая по силам ли им эта задача, будут ли они это делать, не говоря уже о сделают, в реальности.
При том, что они готовы были рассказать про SOLID и перечислить наизусть мутабельные и иммутабельные типы в Python - они совершено не умели программировать (хотя бы как любой мой одноклассник из 8 компьютерного класса - я не шучу). Т.е. разницы, условно, между вложенным циклом и проходом туплом по зипу - не понимали с ходу. Т.е. эти люди просто не могут рассматриваться как программисты - если с ходу не отличают цикломатическую сложность 1, от 2.
Т.е. этих людей целенаправленно учили проходить собеседования, в том числе давая невыполнимые обещания. Но мне всё-таки нужны были люди умеющие работать, а не проходить собеседования.
IV.
Если кому нужен Junior Python Backend напишите мне) Он уже подготовлен не хуже ваших лидов)
Ну вот взяли и испортили хорошее впечатление (потому, что делаете хорошее дело) о себе ;) Скажите, хотя бы, что они уже минимально-программисты, а не зубрилки SOLID и детских болезней из п.3 у них нет.
Я прошу прощения - там 4 строчки (9 если считать хэдер и футер).
Идея agile: 1. Не подменяйте свою цель средствами её достижения и KPI. 2. Ваша ваша - работающий код. Работающий так, как просил заказчик.
Разумеется "продаются" только средства и KPI. Т.е. SCRUM (набор методов и метрик) - уже сама по себе осквернение идеи Agile. Но в отличии от Kanban - SCRUM ещё и имплементируется анти-Agile образом.
Плохо. Человеческий интеллект - самый ценный ресурс сегодня. И вся экономика будет в выигрыше, чем точнее произойдёт match - самые подходящие кандидаты займут самые подходящие вакансии. Т.е. "умный" Петя пойдёт программистом, "средний" Вася - тестировать, а "глупый" Толя мыть полы в их кабинетах. А вы предлагаете отбирать не по способностям, а по умению врать.
Ну это не считая ещё накладных расходов на борьбу с обманом. Пройдите 3 стадии интервью, чтобы доказать, что вы не самозванец, накрутивший опыт. А эти "3 стадии интервью для борьбы с обманом" тратят миллионы человеко-часов и дополнительно понижают мобильность при смене работы.
Т.е. на уровне экономики фактически налагают на всю экономику издержки.
Казалось бы - такая схема это идеальный способ вкатывать людей в IT. Курсы - начинают получать деньги не за "набор студентов", а за "успешное трудоустройство". Т.е. появляется стимул реально обучать.
Но прямой обман (с накруткой опыта в резюме) - разумеется портит всю схему. Т.е. выгоднее (дешевле) научить обманывать работодателя, чем учить студентов IT-шке, что долго и дорого.
Именно поэтому я, к стати, осуждаю накрутку опыта как и другой прямой обман. В этом случае человек не только локально обманул "занял место другого лучшего, но честного кандидата". В этом случае на всём рынке найма возникают дополнительные транзакционные издержки на борьбу с обманом. Ну вот пройдите 3 стадии интервью, чтобы доказать, что вы не самозванец накрутивший опыт - это же ровно приспособление компаний к таким накруткам.
Грубо есть 3 варианта: 1. на текущей "базе" (*) выжать из моделей ещё что-то дополнительно не удастся. 2. на текущей "базе" удастся добиться качественного скачка (**) 3. будет какой-то дополнительный фундаментальный (сравнимый скажем с аттеншном) прорыв в построении нейросетей.
Какой из вариантов 1-3 выбирать - собственно вопрос веры и каких-либо содержательных аргументов в любую сторону я не видел.
*) С момента открытия механизма Attention ( https://arxiv.org/abs/1706.03762 ) прошло 7 лет и х30 капитализации nVidia. И уже на этой базе модели "почти думают".
**) Очевидно, что сейчас поле нейросетей находится на стадии "застолбить поляну", т.е. показать результаты любой ценой. А за efficiency (скажем за напрашивающийся прунинг аттеншна) - ещё толком и не принимались.
- У нас есть 14 способов разработки проектов, но все они слишком формальны не гибки и как следствие плохо справляются с вызовами реального мира к IT-проектам; - Мы придумали Agile - Отлично, формализуйте его каталогизируйте и мы сможем начать его применять! - У нас есть 15 способов разработки проектов, но все они слишком....
В каждом подходе - есть "ядро" (проблемы на момент создания и идеи как эти проблемы обойти), формальное изложение и типовая имплементация.
Вот Agile - яркий пример как имплементации (я сейчас про SCRUM), является буквально противоположностью заложенных туда идей.
По какому принципу книги первой половины 20 века не попадают в список (просто слишком долго перечислять)?
Я бы, например для начала: 1. Определился с годом отсечки. 2. Взял распарсил (или даже рошёлся вручную) 2-3 сайта с фантастикой в вытащил оттуда все доступные книги. Например:
А - проверять остатки от деления на произведения первых n простых множителей. Но кроме х2 - она ведёт к неприятной иррегулярности, которая выливается во вложенный цикл и усложнение кода. К тому же эти остатки надо ещё сформировать. Либо руками (и тогда считать их не ошибаясь) либо автоматически (и тогда это фактически удваивает размер кода)
Это уже учтено в решении автора. Это уже в предлагаемом решении, о чём я прямо написал вот тут: > Учитывая, что список простых чисел у вас уже есть, причём в отсортированном виде (*).
Так что я не очень понимаю, что вы хотели сказать? *) исходя из этого вся разница сведётся к диффу:
< for divisor in range( 2, check_upper_bound + 1):
---
> for divisor in primes:
> if divisor > check_upper_bound:
> break
При проверке на простоту достаточно проверить не делимость только на простые числа. Учитывая, что список простых чисел у вас уже есть, причём в отсортированном виде - можно и нужно идти по нему.
1. Вам можно забить на согласованность (*) - просто кладёте эти данные в отдельный кэшик и забываете 2. Вам нельзя забивать на согласованность - данные иногда будут инвалидироваться => подолгу будут недоступны. Лучшее что вы можете сделать это повысить приоритет данных при вытеснении (такая возможность наверняка должна быть).
Честно говоря супер пространное описание. Смутно похоже на 1 из 3 вещей: - Tight Coupled Memory (программно управляемый кэш) - LL SC синхронизацию - watch points В целом неясно в чём смысл: оставить надолго некоторые данные в кэше или же "разбудить" ожидающий процесс? Если цель "разбудеть" - то обычно так не делают скрыто в аппаратуре, а посылают уснувшему процессу явный сигнал на уровне программной модели.
В общем случае в микроэлектронике - сложность сделать доступ к памяти быстрой. А в программном кэше сложность - вовремя инвалидировать устаревшие данные (т.к. данные мимо кэша идут в виде "запросов" по которым надо угадать что может инвалидироваться).
Вот вокруг этого: сложности инвалидации (а ещё и "когерентности", если она есть) - построена основная архитектура программных кэшей.
В интел little endian.
Ну а дальше всё логично.
Ты соврал в опыте, чтобы пройти "формальный фильтр" HR.
Теперь у тебя в резюме ещё порядка 20 технологий (если уровня git и bush считать) - в скольких ты ещё соврал?
Вот теперь я таки-должен тебе поверить или ты опять соврал чтобы пройти проще формальный фильтр "нужные технологии" перед устройством на работу?
Что мне теперь делать с тобой:
- поверить что ты не врёшь (а если технологий не знаешь - доучивать за свой счёт)?
- проверять каждый пункт резюме и взять откуда-то второй час для собеседования по-существу?
Хм... кажется ты предлагаешь мне заведомо плохой выбор - поверить заведомому вруну или потерять лишний час времени (это на собеседование джуна-то!). Рациональное решение с моей точи зрения поставить фильтр: джун заведомо соврал в резюме сразу отказ.
И это мы ещё даже не приступали к ключевому вопросу - человек врущий в резюме также будет врать по работе?
Когда я набирал джунов год назад - сразу после универа рассматривал, самоучек рассматривал, после школ - не рассматривал. В том числе, но не только, потому что их учат врать.
I.
От людей по-умолчанию ожидается соблюдение обычаев делового оборота (не врать в резюме, не врать в отчётах, выполнять обещания....).
Если кто-то их не соблюдает - он уже сразу в софт-скилах хуже буквально всех людей окружающих меня по работе, включая девочку тим-ассистанта.
Может быть через 5 лет "традиции делового оборота" изменятся - и врать в резюме будет никак не связано с "врать в недельных отчётах". Но пока эти требования стоят в одном ряду.
II.
Школы "войти-в-айти" в этом смысле очень плохой бизнес - в том смысле что они торгуют заведомо невыполнимыми обещаниями, о чём они знают, а люди несущие им по 100тыр - не знают. При этом эти 100тыр - для многих весьма значительные деньги.
III.
Сейчас не набираю. Год назад на прошлой работе я нанимал - сконтачился бы с вами. Рассматривал джунов "писать сервисы для системного программирования".
Отсобеседовав пару дюжин выпускников курсов за пару недель - принял решения резюме со "школами" не рассматривать вообще. Универ - рассматривать, самоучек - рассматривать, школы - нет. Смущало две вещи:
Очевидно, что эти люди давали обещания "не знаю но буду учиться, буду работать..." ни на секунду не задумываясь почему если они сейчас не знают, то справятся? И не взвешивая по силам ли им эта задача, будут ли они это делать, не говоря уже о сделают, в реальности.
При том, что они готовы были рассказать про SOLID и перечислить наизусть мутабельные и иммутабельные типы в Python - они совершено не умели программировать (хотя бы как любой мой одноклассник из 8 компьютерного класса - я не шучу). Т.е. разницы, условно, между вложенным циклом и проходом туплом по зипу - не понимали с ходу. Т.е. эти люди просто не могут рассматриваться как программисты - если с ходу не отличают цикломатическую сложность 1, от 2.
Т.е. этих людей целенаправленно учили проходить собеседования, в том числе давая невыполнимые обещания. Но мне всё-таки нужны были люди умеющие работать, а не проходить собеседования.
IV.
Ну вот взяли и испортили хорошее впечатление (потому, что делаете хорошее дело) о себе ;)
Скажите, хотя бы, что они уже минимально-программисты, а не зубрилки SOLID и детских болезней из п.3 у них нет.
Я прошу прощения - там 4 строчки (9 если считать хэдер и футер).
Идея agile:
1. Не подменяйте свою цель средствами её достижения и KPI.
2. Ваша ваша - работающий код. Работающий так, как просил заказчик.
Разумеется "продаются" только средства и KPI.
Т.е. SCRUM (набор методов и метрик) - уже сама по себе осквернение идеи Agile.
Но в отличии от Kanban - SCRUM ещё и имплементируется анти-Agile образом.
так можно же
[tk]diff file_before.md file_after.md
Плохо.
Человеческий интеллект - самый ценный ресурс сегодня.
И вся экономика будет в выигрыше, чем точнее произойдёт match - самые подходящие кандидаты займут самые подходящие вакансии.
Т.е. "умный" Петя пойдёт программистом, "средний" Вася - тестировать, а "глупый" Толя мыть полы в их кабинетах. А вы предлагаете отбирать не по способностям, а по умению врать.
Ну это не считая ещё накладных расходов на борьбу с обманом.
Пройдите 3 стадии интервью, чтобы доказать, что вы не самозванец, накрутивший опыт.
А эти "3 стадии интервью для борьбы с обманом" тратят миллионы человеко-часов и дополнительно понижают мобильность при смене работы.
Т.е. на уровне экономики фактически налагают на всю экономику издержки.
Казалось бы - такая схема это идеальный способ вкатывать людей в IT.
Курсы - начинают получать деньги не за "набор студентов", а за "успешное трудоустройство". Т.е. появляется стимул реально обучать.
Но прямой обман (с накруткой опыта в резюме) - разумеется портит всю схему. Т.е. выгоднее (дешевле) научить обманывать работодателя, чем учить студентов IT-шке, что долго и дорого.
Именно поэтому я, к стати, осуждаю накрутку опыта как и другой прямой обман.
В этом случае человек не только локально обманул "занял место другого лучшего, но честного кандидата". В этом случае на всём рынке найма возникают дополнительные транзакционные издержки на борьбу с обманом.
Ну вот пройдите 3 стадии интервью, чтобы доказать, что вы не самозванец накрутивший опыт - это же ровно приспособление компаний к таким накруткам.
Грубо есть 3 варианта:
1. на текущей "базе" (*) выжать из моделей ещё что-то дополнительно не удастся.
2. на текущей "базе" удастся добиться качественного скачка (**)
3. будет какой-то дополнительный фундаментальный (сравнимый скажем с аттеншном) прорыв в построении нейросетей.
Какой из вариантов 1-3 выбирать - собственно вопрос веры и каких-либо содержательных аргументов в любую сторону я не видел.
*) С момента открытия механизма Attention ( https://arxiv.org/abs/1706.03762 ) прошло 7 лет и х30 капитализации nVidia. И уже на этой базе модели "почти думают".
**) Очевидно, что сейчас поле нейросетей находится на стадии "застолбить поляну", т.е. показать результаты любой ценой. А за efficiency (скажем за напрашивающийся прунинг аттеншна) - ещё толком и не принимались.
- У нас есть 14 способов разработки проектов, но все они слишком формальны не гибки и как следствие плохо справляются с вызовами реального мира к IT-проектам;
- Мы придумали Agile
- Отлично, формализуйте его каталогизируйте и мы сможем начать его применять!
- У нас есть 15 способов разработки проектов, но все они слишком....
В каждом подходе - есть "ядро" (проблемы на момент создания и идеи как эти проблемы обойти), формальное изложение и типовая имплементация.
Вот Agile - яркий пример как имплементации (я сейчас про SCRUM), является буквально противоположностью заложенных туда идей.
По какому принципу книги первой половины 20 века не попадают в список (просто слишком долго перечислять)?
Я бы, например для начала:
1. Определился с годом отсечки.
2. Взял распарсил (или даже рошёлся вручную) 2-3 сайта с фантастикой в вытащил оттуда все доступные книги.
Например:
А - проверять остатки от деления на произведения первых n простых множителей.
Но кроме х2 - она ведёт к неприятной иррегулярности, которая выливается во вложенный цикл и усложнение кода.
К тому же эти остатки надо ещё сформировать. Либо руками (и тогда считать их не ошибаясь) либо автоматически (и тогда это фактически удваивает размер кода)
2k => 2k +1
6k => 6k + {1, 5}
30k => 30k + {1, 7, 11, 13, 17, 19, 23, 29}
Мы заведомо проверяем только делимость на заведомо простые, причём меньшеие, чем sqrt(candidate))
Какую ещё оптимизацию вы предлагаете?
Это уже учтено в решении автора.
Это уже в предлагаемом решении, о чём я прямо написал вот тут:
> Учитывая, что список простых чисел у вас уже есть, причём в отсортированном виде (*).
Так что я не очень понимаю, что вы хотели сказать?
*) исходя из этого вся разница сведётся к диффу:
Да согласен.
решение в целом же неверное (ну вы же даблы не всерьёз используете, да?).
primes_count(x) = log(x) - это формула примерная и на неё полагаться нельзя.
Правильным будет то, что ниже.
*) Ну и примитивное "решето Эратосфена" же всё равно быстрее, если можете позволить себе память.
При проверке на простоту достаточно проверить не делимость только на простые числа.
Учитывая, что список простых чисел у вас уже есть, причём в отсортированном виде - можно и нужно идти по нему.
Понял. Ну из общих соображений:
1. Вам можно забить на согласованность (*) - просто кладёте эти данные в отдельный кэшик и забываете
2. Вам нельзя забивать на согласованность - данные иногда будут инвалидироваться => подолгу будут недоступны. Лучшее что вы можете сделать это повысить приоритет данных при вытеснении (такая возможность наверняка должна быть).
*) В терминах CAP-теоремы
Честно говоря супер пространное описание.
Смутно похоже на 1 из 3 вещей:
- Tight Coupled Memory (программно управляемый кэш)
- LL SC синхронизацию
- watch points
В целом неясно в чём смысл: оставить надолго некоторые данные в кэше или же "разбудить" ожидающий процесс? Если цель "разбудеть" - то обычно так не делают скрыто в аппаратуре, а посылают уснувшему процессу явный сигнал на уровне программной модели.
В общем случае в микроэлектронике - сложность сделать доступ к памяти быстрой. А в программном кэше сложность - вовремя инвалидировать устаревшие данные (т.к. данные мимо кэша идут в виде "запросов" по которым надо угадать что может инвалидироваться).
Вот вокруг этого: сложности инвалидации (а ещё и "когерентности", если она есть) - построена основная архитектура программных кэшей.
Поскольку кэш работает на уровне кэшлайнов, а не страниц, то "фриз кэш страниицы" - звучит как какая-то ерунда.
Вам наверное на уровне идеи лучше объяснить какое поведение вы подразумеваете.
О какой "заморозке" в процессорных кэшах идёт речь?
И да программный кэш очень сильно отличается от процессорного по внутренней архитектуре и основным сложностям.