Все же throw это не совсем goto. Throw - это структурированный goto с понятными правилами куда он выкинет. Если идти дальше в этом направлении, то нужно забанить и return, поскольку return может выходить из середины функции или блока. Вместо этого все обмазывать флагами чтобы выход был только один в самом конце. Просто код с флагами будет хуже читаем, поэтому и делают return и throw. Это компромисс.
Интересная тема насчет наследства. В целом совпадает с моими размышлениями. В продолжение темы, кроме ограничения на передачу капиталов по наследству имеет смысл ввести в целом ограничения на передачу средств. Например, если ты успешный бизнесмен или талантливый музыкант, ты можешь тратить все что ты заработал на себя как угодно, купаться в роскоши и покупать люксовые бренды. Но тратить только на себя лично. Ты не можешь тратить деньги даже на ближайших родственников и супругу(а). Это ограничение реализуется путем отмены налички и в введения окрашенных цифровых денег. Это правило плюс безусловные базовый доход для всех граждан. В качестве более мягкого варианта: хочешь потратить X денег на ближайших родственников - платишь N * X в виде налога для всех остальных.
Касательно производства людей, здесь не все так однозначно. Есть материнский инстинкт, заложенный природой, и от него просто так не избавиться. Поэтому мыслю так: если у кого-то есть желание лично заниматься воспитанием своих детей, то они могут это делать, но опять же с учетом вышеупомянутых ограничений на траты.
А в чем тогда преимущество tailwind если вы все равно длинные стили выносите в отдельный от вашего компонента объект с @apply?
Вместо этого можно выкинуть tailwind и использовать обычный (s)css.
Кстати сами авторы tailwinds не рекомендуют @apply:
"Whatever you do, don’t use @apply just to make things look “cleaner”
И забыли еще один большой минус tailwind - у него свое понятие размеров и цветов, надо запоминать что означают все эти bg-red-400 и mr-10. Если бы 10 означало 10px, это бы еще понятно, но 10 - это что-то относительно rem. Очень странная логика у tailwind.
Извините, не совсем понял как эксперимент Белла опровергает теорию скрытых переменных.
Мне кажется тут есть пара необоснованных допущений:
1. Утверждается что когда атом испускает два электрона, разлетающихся в противоположные стороны, то мы уже знаем что у них спины направлены строго противоположно (то есть под углом 180 градусов друг относительно друга). В дальнейшем это допущение используется в неравенствах Белла для приведения уравнений к базису одной и той же частицы.
Однако то что у двух этих частиц спины строго противоположно направлены под углом в 180 градусов никак не обосновано. В общем случае они могут быть направлены под разными углами по отношению друг к другу, например, 179 градусов или даже 151 градус.
Есть эксперименты где измеряли спины частиц при помощи устройств Штерна-Герлаха, направленных противоположно друг относительно друга и получали взаимно противоположные результаты. Но по моему пониманию эти устройства представляют собой грубые фильтры которые выдают один и тот же результат для достаточно широкого разброса углов. Например спин «вниз» может быть как для угла 180 градусов, так и для угла 91 градус, а спин «вверх» может быть как для 0 так и для 89 градусов.
2. Из первого допущения следует второе необоснованное допущение: то что вероятности появления всех комбинаций вверх-вниз для разных углов измерения («Программ» как указано в оригинальном посте автора) одинаковы. Выводы из неравенства Белла основаны на анализе вероятностей при большом количестве тестов и сравнении количества результатов с ожидаемой вероятностью. Постулирую что свойства частиц реального мира таковы, что какие-то «Программы» будут встречаться чаще чем другие и вследствие этого выводы из неравенств Белла, якобы опровергающие теорию скрытых параметров, неверны.
Если мои выводы неверны и эти два допущения валидны и были проверены на экспериментах или каким-то другим образом, буду благодарен за ссылку на пруфы.
Зарплата по результатам собеседования - на это отвечаю, ок, мой минимум XXX, если согласны, продолжаем общение.
И лучше это зафиксировать письменно в чате или email.
Тестовые задания "на дом" беру но только если
1) гарантируется что будет возможность напрямую уточнять возникающие вопросы у технических специалистов , не через рекрутера , и,
2) если разбор решения будет онлайн вместе со мной на следующем этапе собеседования.
Не рекомендую брать тестовые задания если их анализ будет без вашего участия и вам просто потом заявят что вы неправильно поняли задачу. Такие задания в топку.
"Я ответить тоже не смог и сего прикола не понял. "
Если мне не изменяет память, то там было что-то связанное с тем, что побеждает более длинная цепочка блоков, а также с оптимистической предпосылкой о том, что в среднем честных валидаторов больше, чем нечестных. А прикол в том, что выданный нейронкой ответ звучит довольно логично и правдоподобно для тех, кто вообще не знаком с темой, и при этом он совершенной неверный.
Ну, в какой-то степени расчитывал на то, что информация из проверенных материалов имеет больший вес , чем коментарии рандомных людей. К тому же где-то раньше писали, что один из основных юзкейсов chat gpt - это поиск информации, как продвинутая замена гуглу.
Еще появилось ощущение, что зачем-то ввели искусственные ограничения на темы. Кроме тем пикантного содержания, например, он не дает ответы связанные с предсказаниями курсов или результатов спортивных соревнований. Возможно это сделано для прикрытия задницы, чтобы OpenAI не предъявили потом за убытки, но если это так, то со временем вообще все темы так можно прикрыть. Ведь так кто-то может сдуру скопировать код из chatGPT и вставить в прод и потом что-то сломается и компания потеряет кучу денег.
Вот какой ответ мне выдало. Этот ChatGPT прикол, а не что-то что можно реально использовать.
Question: Two users want to add their transactions to the ledger. User Alice has valid transaction, and user Bob has fraudulent transaction. Both Alice and Bob need to perform a certain amount of computational work. Alice's transaction is for $5 and Bob's transaction is for $100000. Both have completed their work at the same time. Whose transaction will be added to the ledger and why?
Answer: In a proof of work system, transactions are added to the ledger in blocks, and each block can only hold a limited number of transactions. When two users, such as Alice and Bob, want to add their transactions to the ledger at the same time, the network will typically choose the block of transactions that has the most computational work behind it. In other words, the network will choose the block that required the most effort to produce. In this case, it is likely that Alice's transaction will be added to the ledger, because it is part of a block that required less computational work to produce than the block containing Bob's fraudulent transaction. This is because Alice's transaction is for a smaller amount of money, and therefore it is less likely to be considered fraudulent by the network. Additionally, since Alice's transaction is for a smaller amount of money, it will require less computational work to produce the block containing her transaction.
So, in this situation, it is likely that Alice's transaction will be added to the ledger, while Bob's fraudulent transaction will not be included. This is because the network will typically prioritize transactions that are considered to be less risky and require less computational work to produce.
Если фича технически реализуема, не ломает общую архитектуру и не вызывает каких-то адских костылей она планируется и делается.
Нравится разработчику то что она делает или не нравится это не важно.
Если вышеописанные условия соблюдаются и нет риска, что поддержка фичи вызовет головные боли в будущем, и при этом нет более простого, дешевого способа решить ту же бизнес проблему, то не вижу причины почему бы она должна не понравиться разработчику.
Обычно процесс устроен так, что бизнес аналитик или клиент формулирует "что" и "зачем" в максимально абстрактном виде. "Что" и "зачем" - это важная часть.
Разработчики совместно с дизайнером и продакт менеджером формулируют "как" это будет реализовано (в том числе, с точки зрения UX) c учетом существующей архитектуры, подобных UX в других фичах, а также простоту поддержки в будущем. Естественно, нужно учитывать и простоту использования для пользователя. Для этого заранее готовятся описания персон.
BA может предложить какой-то вариант решения проблемы ("как"), "но не факт что это предложение пройдет" ;).
Но по-хорошему, все разумные люди, и должны идти навстречу друг другу. В особенности, когда заказчик внешний.
Срочно это в смысле надо садится и делать начиная с завтра. А не еще пару месяцев заниматься чем-то другим и только потом приступать
Здесь не имею принципиальных возражений, разве что могут быть редкие случаи, когда бросить то, что делаешь сейчас, и переключиться на новую задачу может вылиться в то, что в будущем контекст будет потерян и текущую задачу нужно будет начинать с нуля. В таких случаях лучше потратить немного времени и довести задачу до какой-то точки.
Хочет или нет разработчик писать кучу крудов и перекладывать вагон джейносов никому не интересно в этот момент.
Да это обычно не проблема. Хотите платить миллион за перекладывание джейсонов, пожалуйста. Хороший разработчик всегда найдет себе интересную задачу и помимо основной работы, в пет-проекте. Правда опыт скорее показывает, что больше платят за более сложные задачи , где требуется поломать голову.
По техническим вопросам убедите команду (около 10-20 человек все программисты) что это хорошо. Команде с этим жить потом, их мнение важно.
Это всегда пожалуйста, я могу детально обосновать все изменения, и технические, и процессные. Готов для каждого предоставить все за и против. Но может оказаться так, что несущественные против будут против существенных за. Тогда нужна будет поддержка сверху для проталкивания изменений.
По продуктовым вероятно никак. Это надо в менеджеры переходить.
Часто путают проектный менеджмент и продуктовый. То, как собираются, формализуются требования и на их основе формируется беклог и принимаются и документируются решения по дизайну, не должно смешиваться с построением планов, сроков, управлением ресурсами, майлстонами, бюджетами, отчетами. Это разные активности.
Срочно делать.
При нормально выстроенном процессе продуктовые фичи делаются плюс-минус в срок и без спешки. Если эти авралы частое явление, тогда наверно стоит на ретроспективе задать себе вопрос, а что мы делаем не так? Неправильно понимаем скоуп, плохо оцениваем, плохо планируем, или может нам не хватает ресурсов? Готов помочь выправить и эту проблему.
Честные ответы приветствуются, хотя по моему опыту чаще всего кандидатам на такие вопросы стараются правду не отвечать, или приукрасить действительность. Но в приниципе после прохождения десятка собесов научаешься это распознавать.
Конечно это вопросы не на позицию мидла, а на сениора.
В вашем случае я бы спросил, а готовы ли вы к быстрым улучшениям с моей помощью и дадите ли мне карт-бланш на внесение изменений.
Если не готовы, то скорее всего вам действительно стоит рассматривать кандидатов мидл-уровня, сениоры вам не нужны, это будет заколачивание гвоздей микроскопом. При таких условиях скорее всего у вас окажется и вилка по зарплатам ниже рынка, поэтому буду рассматривать другие предложения.
Что касается вопросов из статьи, только часть из них для меня важна
1. В каком формате проходит тех. интервью - не важно, они все обычно более-менее одинаковые.
2. Вопросы про удаленный режим работы, гибкий график, переработки, отпуска и больничные – важно.
3. Вопросы про офис и командировки, а также дресс-код для меня лично неактуальны, поскольку я рассматриваю только 100% удаленку. Но для тех, кому нравится офис, наверное важны.
4. Учет времени – для меня непринципиально. Даже если он автоматический, я в среднем работаю > 8 часов в день.
5. Длительность испытательного срока и ожидания от него – вообще неважно, если только на нем нет каких-то ограничений по зарплате. По моему опыту, ни разу не увольняли с испытательного. А наоборот – пару раз бывало, сам уходил.
6. Бюджет на образование, компьютер – ну камон, это не так дорого стоит по сравнению с зарплатами, даже топовый MB Pro. Я даже лицензии на софт покупал за свои и не просил компенсировать.
7. количество инженеров и их распределение по командам – по-моему не важно.
8. Возможность переходить между проектами, возможность пилить свои пет проекты – важно.
9. Performance review – лучше бы их вообще не было, обычно это такой BS.
Это упрощенная математическая модель с 2 состояниями. На деле же состояние может описано вектором размерности N. При измерении же состоянию приписываются значения up или down в зависимости от того, в какую сторону наклонен вектор в одной из проекций.
Но измеренное состояние != исходному состоянию, поэтому неравенства Белла тут не применимы.
Тоже всегда не понимал этого. Если убрать ограничения, то теорема Белла становится неверной , а гипотеза о скрытых параметрах вполне верной, и никакой магии
В дополнение к вышеозвученному, обычно спрашиваю следующее (это на позицию senior):
как устроен процесс разработки (scrum, kanban). Как коммуницируются требования разработчикам. Чем обуславливаются приоритеты задач и их скоуп.
процесс планирования и оценки. Есть ли дедлайны и как/кем они определяются.
как устроен процесс коммуникации в команде (offline-first или online-first). Какие есть обязательные митинги и сколько они занимают
в какой стадии проект, какие будут задачи (какой баланс между поддержкой legacy и разработкой нового)
как устроен процесс принятия решений (технических или нетехнических), насколько просто предложить и внести изменения
как обстоит дело с документацией по продукту (собираем требования по jira ticketам или есть единый детальный документ, который поддерживается в актуальном состоянии)
какая политика по тестам (есть ли порог по покрытию, что тестируем)
какие будут обязанности по данной вакансии (например, будут ли менеджерские задачи и какой % времени они занимают)
вопрос к человеку , который проводит техническое интервью: как вам самому нравится в этой компании, довольны ли вы?
Можете ли вы «на бумаге» проконтролировать, равномерно ли происходит голосование, нет ли скачков «за» или «против»?
Если в ЭГ на графиках по времени видны скачки за и против — то это всего лишь показывает недостаток квалификации тех кто программировал вбросы. Ну какой идиот будет вбросы делать пачкой в один момент времени? Элементарно можно размазать вбросы по времени / участкам так что никакой Шпилькин ничего не обнаружит. Говорю так потому что по опыту сталкивался с искусной накруткой реалтайм статистики (правда не связанной с голосованием). Было сделано так, что и по времени не было скачков и по разбросу мат. ожиданий все сходилось и отчеты в разных разрезах бились между собой.
Расшифровать голоса до сборки ключа невозможно
. Никто не мешает им вести параллельно две системы учета голосов. Реальные данные складывать в первую, итоги считать по второй. Они могли бы даже дать наблюдателям доступ к мониторингу первой.
сделать голосование платным
Как proof of stake, но чтобы это работало нужно чтобы плата была значительной и сразу в крипте, чтобы результаты шли в публичный блокчейн, где каждый избиратель мог бы сразу после отправки увидеть как его транзакция отразилась в блокчейне.
Но даже этот подход не помогает от вбросов голосов фейковых избирателей.
Лучше всего все же дублирующий подсчет в системе под контролем независимых организаций (что то наподобие exit polls).
А как вообще возможна защита от фальсификаций и верификация:
— изменения отдельных голосов с Да на Нет перед внесением в базу
— удаления отдельных нежелательных голосов
— добавления голосов тех кто не проголосовал
— добавления фейковых избирателей сверх количества зарегистрированных избирателей на определенных участках
— добавления новых фиктивных участков с фейковыми избирателями
— искажения результатов при подсчете (когда сумма не равна количеству отдельных бюллетеней)
— искажения результатов при суммировании итогов (общая сумма != сумме частных подытогов)
Предполагаю что наилучшим вариантом была бы возможность дублирующего подсчета голосов против в независимой системе голосования под контролем независимой структуры от государства (под контролем правозащитных организаций или оппозиционных партий).
Например те, кто голосовал «против» могли бы по желанию дополнительно анонимно проголосовать в такой второй системе. Понятно, что в этой системе скорее всего будет перекос в сторону голосов «против», но тем не менее можно было бы сравнить абсолютное количество голосов «против» в разрезе участков и выявить сильное расхождение на конкретных участках. Такие участки были бы кандидатами на необходимость детальной перепроверки и пересчета.
Интересно было бы сравнение с 4x RTX 3090 попарно связанными NVLink
Все же throw это не совсем goto. Throw - это структурированный goto с понятными правилами куда он выкинет. Если идти дальше в этом направлении, то нужно забанить и return, поскольку return может выходить из середины функции или блока. Вместо этого все обмазывать флагами чтобы выход был только один в самом конце. Просто код с флагами будет хуже читаем, поэтому и делают return и throw. Это компромисс.
Странный промпт. Возможно криво сформулирован.
Думаю так: хочешь сам(а) воспитывать своего ребенка - становись воспитательницей группы из N рандомных детей, в состав которой этот ребенок включен.
Хочешь чтобы твои близкие пользовались роскошью, на которую ты заработал - поделись ей в равной степени с N рандомными не-родственниками.
Хочешь передать какие-то навыки или опыт своему отпрыску , передай их в равной степени еще N рандомным людям.
Интересная тема насчет наследства. В целом совпадает с моими размышлениями. В продолжение темы, кроме ограничения на передачу капиталов по наследству имеет смысл ввести в целом ограничения на передачу средств. Например, если ты успешный бизнесмен или талантливый музыкант, ты можешь тратить все что ты заработал на себя как угодно, купаться в роскоши и покупать люксовые бренды. Но тратить только на себя лично. Ты не можешь тратить деньги даже на ближайших родственников и супругу(а). Это ограничение реализуется путем отмены налички и в введения окрашенных цифровых денег. Это правило плюс безусловные базовый доход для всех граждан. В качестве более мягкого варианта: хочешь потратить X денег на ближайших родственников - платишь N * X в виде налога для всех остальных.
Касательно производства людей, здесь не все так однозначно. Есть материнский инстинкт, заложенный природой, и от него просто так не избавиться. Поэтому мыслю так: если у кого-то есть желание лично заниматься воспитанием своих детей, то они могут это делать, но опять же с учетом вышеупомянутых ограничений на траты.
А в чем тогда преимущество tailwind если вы все равно длинные стили выносите в отдельный от вашего компонента объект с @apply?
Вместо этого можно выкинуть tailwind и использовать обычный (s)css.
Кстати сами авторы tailwinds не рекомендуют @apply:
"Whatever you do, don’t use
@applyjust to make things look “cleaner”И забыли еще один большой минус tailwind - у него свое понятие размеров и цветов, надо запоминать что означают все эти bg-red-400 и mr-10. Если бы 10 означало 10px, это бы еще понятно, но 10 - это что-то относительно rem. Очень странная логика у tailwind.
хорошо бы осветить поподробнее тему квантовых оракулов и примеры их реализации, алгоритм дойча-йожи
Мне кажется тут есть пара необоснованных допущений:
1. Утверждается что когда атом испускает два электрона, разлетающихся в противоположные стороны, то мы уже знаем что у них спины направлены строго противоположно (то есть под углом 180 градусов друг относительно друга). В дальнейшем это допущение используется в неравенствах Белла для приведения уравнений к базису одной и той же частицы.
Однако то что у двух этих частиц спины строго противоположно направлены под углом в 180 градусов никак не обосновано. В общем случае они могут быть направлены под разными углами по отношению друг к другу, например, 179 градусов или даже 151 градус.
Есть эксперименты где измеряли спины частиц при помощи устройств Штерна-Герлаха, направленных противоположно друг относительно друга и получали взаимно противоположные результаты. Но по моему пониманию эти устройства представляют собой грубые фильтры которые выдают один и тот же результат для достаточно широкого разброса углов. Например спин «вниз» может быть как для угла 180 градусов, так и для угла 91 градус, а спин «вверх» может быть как для 0 так и для 89 градусов.
2. Из первого допущения следует второе необоснованное допущение: то что вероятности появления всех комбинаций вверх-вниз для разных углов измерения («Программ» как указано в оригинальном посте автора) одинаковы. Выводы из неравенства Белла основаны на анализе вероятностей при большом количестве тестов и сравнении количества результатов с ожидаемой вероятностью. Постулирую что свойства частиц реального мира таковы, что какие-то «Программы» будут встречаться чаще чем другие и вследствие этого выводы из неравенств Белла, якобы опровергающие теорию скрытых параметров, неверны.
Если мои выводы неверны и эти два допущения валидны и были проверены на экспериментах или каким-то другим образом, буду благодарен за ссылку на пруфы.
Зарплата по результатам собеседования - на это отвечаю, ок, мой минимум XXX, если согласны, продолжаем общение.
И лучше это зафиксировать письменно в чате или email.
Тестовые задания "на дом" беру но только если
1) гарантируется что будет возможность напрямую уточнять возникающие вопросы у технических специалистов , не через рекрутера , и,
2) если разбор решения будет онлайн вместе со мной на следующем этапе собеседования.
Не рекомендую брать тестовые задания если их анализ будет без вашего участия и вам просто потом заявят что вы неправильно поняли задачу. Такие задания в топку.
"Я ответить тоже не смог и сего прикола не понял. "
Если мне не изменяет память, то там было что-то связанное с тем, что побеждает более длинная цепочка блоков, а также с оптимистической предпосылкой о том, что в среднем честных валидаторов больше, чем нечестных. А прикол в том, что выданный нейронкой ответ звучит довольно логично и правдоподобно для тех, кто вообще не знаком с темой, и при этом он совершенной неверный.
Ну, в какой-то степени расчитывал на то, что информация из проверенных материалов имеет больший вес , чем коментарии рандомных людей. К тому же где-то раньше писали, что один из основных юзкейсов chat gpt - это поиск информации, как продвинутая замена гуглу.
Еще появилось ощущение, что зачем-то ввели искусственные ограничения на темы. Кроме тем пикантного содержания, например, он не дает ответы связанные с предсказаниями курсов или результатов спортивных соревнований. Возможно это сделано для прикрытия задницы, чтобы OpenAI не предъявили потом за убытки, но если это так, то со временем вообще все темы так можно прикрыть. Ведь так кто-то может сдуру скопировать код из chatGPT и вставить в прод и потом что-то сломается и компания потеряет кучу денег.
Вот какой ответ мне выдало. Этот ChatGPT прикол, а не что-то что можно реально использовать.
Question: Two users want to add their transactions to the ledger. User Alice has valid transaction, and user Bob has fraudulent transaction. Both Alice and Bob need to perform a certain amount of computational work. Alice's transaction is for $5 and Bob's transaction is for $100000. Both have completed their work at the same time. Whose transaction will be added to the ledger and why?
Answer: In a proof of work system, transactions are added to the ledger in blocks, and each block can only hold a limited number of transactions. When two users, such as Alice and Bob, want to add their transactions to the ledger at the same time, the network will typically choose the block of transactions that has the most computational work behind it. In other words, the network will choose the block that required the most effort to produce. In this case, it is likely that Alice's transaction will be added to the ledger, because it is part of a block that required less computational work to produce than the block containing Bob's fraudulent transaction. This is because Alice's transaction is for a smaller amount of money, and therefore it is less likely to be considered fraudulent by the network. Additionally, since Alice's transaction is for a smaller amount of money, it will require less computational work to produce the block containing her transaction.
So, in this situation, it is likely that Alice's transaction will be added to the ledger, while Bob's fraudulent transaction will not be included. This is because the network will typically prioritize transactions that are considered to be less risky and require less computational work to produce.
Если вышеописанные условия соблюдаются и нет риска, что поддержка фичи вызовет головные боли в будущем, и при этом нет более простого, дешевого способа решить ту же бизнес проблему, то не вижу причины почему бы она должна не понравиться разработчику.
Обычно процесс устроен так, что бизнес аналитик или клиент формулирует "что" и "зачем" в максимально абстрактном виде. "Что" и "зачем" - это важная часть.
Разработчики совместно с дизайнером и продакт менеджером формулируют "как" это будет реализовано (в том числе, с точки зрения UX) c учетом существующей архитектуры, подобных UX в других фичах, а также простоту поддержки в будущем. Естественно, нужно учитывать и простоту использования для пользователя. Для этого заранее готовятся описания персон.
BA может предложить какой-то вариант решения проблемы ("как"), "но не факт что это предложение пройдет" ;).
Но по-хорошему, все разумные люди, и должны идти навстречу друг другу. В особенности, когда заказчик внешний.
Здесь не имею принципиальных возражений, разве что могут быть редкие случаи, когда бросить то, что делаешь сейчас, и переключиться на новую задачу может вылиться в то, что в будущем контекст будет потерян и текущую задачу нужно будет начинать с нуля. В таких случаях лучше потратить немного времени и довести задачу до какой-то точки.
Да это обычно не проблема. Хотите платить миллион за перекладывание джейсонов, пожалуйста. Хороший разработчик всегда найдет себе интересную задачу и помимо основной работы, в пет-проекте. Правда опыт скорее показывает, что больше платят за более сложные задачи , где требуется поломать голову.
Это всегда пожалуйста, я могу детально обосновать все изменения, и технические, и процессные. Готов для каждого предоставить все за и против. Но может оказаться так, что несущественные против будут против существенных за. Тогда нужна будет поддержка сверху для проталкивания изменений.
Часто путают проектный менеджмент и продуктовый. То, как собираются, формализуются требования и на их основе формируется беклог и принимаются и документируются решения по дизайну, не должно смешиваться с построением планов, сроков, управлением ресурсами, майлстонами, бюджетами, отчетами. Это разные активности.
При нормально выстроенном процессе продуктовые фичи делаются плюс-минус в срок и без спешки. Если эти авралы частое явление, тогда наверно стоит на ретроспективе задать себе вопрос, а что мы делаем не так? Неправильно понимаем скоуп, плохо оцениваем, плохо планируем, или может нам не хватает ресурсов? Готов помочь выправить и эту проблему.
Честные ответы приветствуются, хотя по моему опыту чаще всего кандидатам на такие вопросы стараются правду не отвечать, или приукрасить действительность. Но в приниципе после прохождения десятка собесов научаешься это распознавать.
Конечно это вопросы не на позицию мидла, а на сениора.
В вашем случае я бы спросил, а готовы ли вы к быстрым улучшениям с моей помощью и дадите ли мне карт-бланш на внесение изменений.
Если не готовы, то скорее всего вам действительно стоит рассматривать кандидатов мидл-уровня, сениоры вам не нужны, это будет заколачивание гвоздей микроскопом. При таких условиях скорее всего у вас окажется и вилка по зарплатам ниже рынка, поэтому буду рассматривать другие предложения.
Что касается вопросов из статьи, только часть из них для меня важна
1. В каком формате проходит тех. интервью - не важно, они все обычно более-менее одинаковые.
2. Вопросы про удаленный режим работы, гибкий график, переработки, отпуска и больничные – важно.
3. Вопросы про офис и командировки, а также дресс-код для меня лично неактуальны, поскольку я рассматриваю только 100% удаленку. Но для тех, кому нравится офис, наверное важны.
4. Учет времени – для меня непринципиально. Даже если он автоматический, я в среднем работаю > 8 часов в день.
5. Длительность испытательного срока и ожидания от него – вообще неважно, если только на нем нет каких-то ограничений по зарплате. По моему опыту, ни разу не увольняли с испытательного. А наоборот – пару раз бывало, сам уходил.
6. Бюджет на образование, компьютер – ну камон, это не так дорого стоит по сравнению с зарплатами, даже топовый MB Pro. Я даже лицензии на софт покупал за свои и не просил компенсировать.
7. количество инженеров и их распределение по командам – по-моему не важно.
8. Возможность переходить между проектами, возможность пилить свои пет проекты – важно.
9. Performance review – лучше бы их вообще не было, обычно это такой BS.
Это упрощенная математическая модель с 2 состояниями. На деле же состояние может описано вектором размерности N. При измерении же состоянию приписываются значения up или down в зависимости от того, в какую сторону наклонен вектор в одной из проекций.
Но измеренное состояние != исходному состоянию, поэтому неравенства Белла тут не применимы.
Тоже всегда не понимал этого. Если убрать ограничения, то теорема Белла становится неверной , а гипотеза о скрытых параметрах вполне верной, и никакой магии
В дополнение к вышеозвученному, обычно спрашиваю следующее (это на позицию senior):
как устроен процесс разработки (scrum, kanban). Как коммуницируются требования разработчикам. Чем обуславливаются приоритеты задач и их скоуп.
процесс планирования и оценки. Есть ли дедлайны и как/кем они определяются.
как устроен процесс коммуникации в команде (offline-first или online-first). Какие есть обязательные митинги и сколько они занимают
в какой стадии проект, какие будут задачи (какой баланс между поддержкой legacy и разработкой нового)
как устроен процесс принятия решений (технических или нетехнических), насколько просто предложить и внести изменения
как обстоит дело с документацией по продукту (собираем требования по jira ticketам или есть единый детальный документ, который поддерживается в актуальном состоянии)
какая политика по тестам (есть ли порог по покрытию, что тестируем)
какие будут обязанности по данной вакансии (например, будут ли менеджерские задачи и какой % времени они занимают)
вопрос к человеку , который проводит техническое интервью: как вам самому нравится в этой компании, довольны ли вы?
Если в ЭГ на графиках по времени видны скачки за и против — то это всего лишь показывает недостаток квалификации тех кто программировал вбросы. Ну какой идиот будет вбросы делать пачкой в один момент времени? Элементарно можно размазать вбросы по времени / участкам так что никакой Шпилькин ничего не обнаружит. Говорю так потому что по опыту сталкивался с искусной накруткой реалтайм статистики (правда не связанной с голосованием). Было сделано так, что и по времени не было скачков и по разбросу мат. ожиданий все сходилось и отчеты в разных разрезах бились между собой.
. Никто не мешает им вести параллельно две системы учета голосов. Реальные данные складывать в первую, итоги считать по второй. Они могли бы даже дать наблюдателям доступ к мониторингу первой.
Как proof of stake, но чтобы это работало нужно чтобы плата была значительной и сразу в крипте, чтобы результаты шли в публичный блокчейн, где каждый избиратель мог бы сразу после отправки увидеть как его транзакция отразилась в блокчейне.
Но даже этот подход не помогает от вбросов голосов фейковых избирателей.
Лучше всего все же дублирующий подсчет в системе под контролем независимых организаций (что то наподобие exit polls).
— изменения отдельных голосов с Да на Нет перед внесением в базу
— удаления отдельных нежелательных голосов
— добавления голосов тех кто не проголосовал
— добавления фейковых избирателей сверх количества зарегистрированных избирателей на определенных участках
— добавления новых фиктивных участков с фейковыми избирателями
— искажения результатов при подсчете (когда сумма не равна количеству отдельных бюллетеней)
— искажения результатов при суммировании итогов (общая сумма != сумме частных подытогов)
Предполагаю что наилучшим вариантом была бы возможность дублирующего подсчета голосов против в независимой системе голосования под контролем независимой структуры от государства (под контролем правозащитных организаций или оппозиционных партий).
Например те, кто голосовал «против» могли бы по желанию дополнительно анонимно проголосовать в такой второй системе. Понятно, что в этой системе скорее всего будет перекос в сторону голосов «против», но тем не менее можно было бы сравнить абсолютное количество голосов «против» в разрезе участков и выявить сильное расхождение на конкретных участках. Такие участки были бы кандидатами на необходимость детальной перепроверки и пересчета.