Возьму на себя ответственность немного поправить некоторые моменты.
Не смотря на NDA, судя по вашей агрессии, сразу возникает впечатление, что с вами будет сложно договориться.
Лично мне кажется, что тут не агрессия, а просто усталость от постоянных статей на хабре, где с одной стороны эффективные hr с красивыми метриками и фильтрами, с другой интервьюеры, которые время от времени уходят в крайности(одни в алгоритмы и только харды, другие в софт скилы, а харды 10 планом), а с третьей стороны разработчики, которые ищут 1000 и 1 способ обойти предыдущие 2 стороны этого треугольника.
А конторы, которые готовы брать на работу всех, кто не выглядит "обколотым наркотой" раз в полгода меняют название и не платят зарплату. Точнее платят знакомым и друзьям, а не тем кто реально работает.
Между берем всех подряд знакомых, и сотрудник компании предлагает своего друга или знакомого(в тексте этого нет, но я надеюсь частично под свою ответственность или хотя бы под условный кредит доверия), после чего с ним говорит "босс", после чего идет 1 месяц испытательного срока и только после этого будет уже офер. 1 месяц работы расскажет о человеке гораздо больше, чем самое длинное собеседование. Хотя и у этого подхода есть свой минус, мало кто захочет тратить месяц, но и люди, которые действительно только собесы зубрили скорее всего сразу откажутся и пойдут искать работу в классическом варианте.
Боюсь, маловероятно, что кто-то под этой статьёй сможет вам ответить на этот вопрос(хотя не исключаю такой возможности). Но вам ничего не мешает создать таблицу при помощи 1с и, используя информацию из этой статьи, самостоятельно проверить таблицу на выравнивание.
Там проблема в другом. Функция fmt.Scanln() принимает any, т.е может принять любой тип, а по факту сама функция хочет получить указатель на переменную, в которую нужно будет положить значение. Из-за того, что мы передаем не указатель, мы и получаем ошибку (type not a pointer) в рантайме, а компилятор видит, что в any кидают любой тип и его это устраивает.
На самом деле go отлично подходит для сложной бизнес логики, как и С, Java, Rust. Чего только стоит возможность легко превращать синхронный код в асинхронный(Правда это дает возможность по неопытности выстрелить себе в ногу датарейсами, дедлоками, лайфлоками и прочими интересными вещами). Есть и нейтральные моменты, обработка ошибок, хотя она позволяет не пропускать обработку ошибок, но и прокидывать их по стеку вызова при необходимости не очень приятно. Из неприятных моментов большое количество бойлерплейта. Для работы с большим числом разных данных лучше подошел бы python к примеру, для кроссплатформенности я бы до сих пор предпочел Java и тд. В любом случае языки приходят и уходят, это просто инструмент, любой разработчик, начиная наверное с мидла, при необходимости может поменять за 1-2 месяца яп, естественно с небольшой потерей грейда, но это быстро восполняется(ну и с условного python, js или php переходить на go/c/c++/c#/java/rust больнее, чем наоборот). Главное не доводить до состояния, под названием "когда у тебя в руках молоток все вокруг превращается в гвозди".
На самом деле для написания сложной бизнес логики по хорошему просто нужен человек, который умеет качественно и надёжно писать код, а также правильно проектировать эту логику. Язык же выбирается исходя немного из других параметров: скорость разработки, производительность языка, количество и компетентность людей в штате знающих определённый язык, как этот язык поддерживается,тип типизации и многое другое. К примеру, если для какого-то приложения характерно множество io-bound задач, то go,java,rust,c(++/#) не сильно выиграют по сравнению с js,python и тд. Другой пример, приложению характерны cpu-bound задачи с возможностью их распараллелить - тут уже победа будет за go,rust и тд. Но это касается средне-крупных компаний, в более маленьких компаниях зачастую не используются 10 разных языков, поэтому и выбирать не из чего.
Ну и плюс, редко требуется писать с нуля всё приложение
Тесты из разных пакетов буду запускаться в любом случае параллельно(только если не ограничить количество одновременных задач, см первый вариант), t.Parallel() указывается для параллельного запуска тестов из одного пакета или сабтестов. В этом и была проблема, у меня несколько пакетов, 1 за каждую таблицу. Если я где-то ошибаюсь, то буду рад если кто-то меня поправит.
Отличная статья! Есть пример для семафора, к сожалению он не затрагивает воркер пул, но думаю тк статья про семафор, то имеет место быть. Плюс, если кто-то захочет найти еще примеры использования семафора, то может посмотреть исходники pgx (а точнее pgxpool).
Когда я писал тесты для слоя базы данных(тестировал без мока бд). То была проблема с тем, что тесты ломали друг друга. Решений было несколько: 1. Ограничить количество одновременных тестов до 1 (т.к у нас не только бд тесты, то их выполнение на 1 потоке занимает много времени) 2. Создавать отдельные схемы для каждого тесты (усложнение логики) 3. Запускать для каждого теста отдельный контейнер 4. Использовать семафор с размером 1 для лока 1 теста бд за раз (плюсы: простая логика. Минусы, при большом количество тестов для базы данных скорее всего это станет узким горлом). Собственно 4 вариант и был выбран. К слову, если кто-то знает еще варианты решения этого вопроса, то буду рад узнать, как минимум для понимания того, что я мог упустить.
Также было бы интересно посмотреть использование паттернов fan-in и fan-out на практике.
Если я правильно понял ваше высказывание по поводу логики, то крайне согласен. Дать кандидату небольшую задачу, к примеру сокращение урлов (знаю, что эту задачу уже 100 раз изъездили все, кто мог, но для примера он подойдет, а для собеседования все же лучше придумать другие задачи), ну и дальше смотреть какие вопросы кандидат уточнит и как будет строить свои рассуждения по решению этой задачи: какая максимальная длина урла должна быть? нужно ли использовать новый домен для этого? если нет, то есть какое доменное имя будет использовано? Нужно ли учитывать длину этого домена? Нужно ли делать какой-то путь помимо домена, чтобы сокращенный урл в случае чего не конфликтовал с другими урлами? Должен ли быть этот урл читаемым([cat, dog, car] запоминаются лучше, чем X34j78)?Насколько большим должен быть пул урлов(частично связан с предыдущем вопросом)? Урл должен быть временным или постоянным, или должен быть выбор? Урл должен быть на определенное количество переходов? Есть ли какая-то существующая инфраструктура для реализации(будь то монолит или микросервисы, функции и тд)? Какой приоритет задачи(далеко не всегда бывает, что новую задачу выдают, когда завершаешь предыдущую, нужно понимать, что важнее делать в данный момент)? Для чего будут использовать этот сервис(от этого может зависеть потенциальная нагрузка на эту часть приложения; может выйти неприятная ситуация, когда менеджеры сделали рассылку условной миллионной аудитории с какой-нибудь акцией, а ссылки не работают из-за нагрузки)? Не все эти вопросы надо задавать тому кто ставит задачу в обычных условиях, часть из них разработчик должен задать себе в голове, но на интервью озвучить их надо. На основе этих вопросов будет уже понятно, какая модель хранения данных будет, нужен ли кеш, в зависимости от нагрузки. Не лишним будет спросить, как этот сервис тестировать, какие пограничные случаи бывают. От каждого пункта выше можно развить еще несколько вопросов. На основе всего этого будет уже понятно: как кандидат размышляет, какие подходы использует, как подходит к написанию тестов, любит ли изобретать велосипеды. Останется разве что дополнительно уточнить моменты по яп, который нужен компании. Как он обращается к базе данных к примеру, как обрабатывает ошибки, какие стандартный библиотеки использует, какие использует не стандартные библиотеки и для каких задач, как структурирует код и тд.
Ну в целом некоторые проблемы в статье есть, но отчасти с автором соглашусь, куда не посмотри, на технических собесах иногда происходит какой-то хаос. Где-то требуют знание конкретных мало кому известных технологий, когда это абсолютно не нужно. Где-то требуют знания алгоритмов наизусть, опять же не понимая зачем они нужны. Зачем условному гуглу или яндексу алгоритмы я понимаю, им проще нанять работника на основе понимания общих концепций CS, а не каких-то отдельных реализациях. Рынку в целом не хватает золотой середины.
Справедливости ради, но раннее вы перешли на личности и такой тон.
А вы точно в айти хотя бы рядом проходили? Нет, не в госконторах, где "программистом" называют студента-эникейщика, который настолько запуган, что рта открыть не смеет, а в нормальных?
Если вы не сталкивались с этой частью работы, значит вы, вероятно, сильно начинающий и она просто скрыта от вас.
Сильно ничего против перехода на личности я сам не имею, но других не стоит в этом упрекать, когда сами это используете.
Полностью с вами согласен, но если так подумать, то гарантий нет нигде, но где-то шансы выше, где-то ниже, в случае с преподавателем, я думаю, шансы избежать ошибок выше, чем просто с гуглом под рукой(естественно пока нет минимального навыка фильтрации информации). Да и про несовременные подходы это самое минимальное, есть шанс на раннем этапе усвоить антипаттерны, а в не очень современных подходах нет ничего плохого, любые подходы ситуативный, довольно часто какой-то старый подход лучше подходит для решения конкретной задачи.
Тут есть несколько моментов, которые стоит учитывать:
Кому-то нужный внешний стимул: курс который тебя подгоняет, потраченные деньги и тд
Информация, которую ищешь сам, не всегда структурирована(в том числе книги, такое тоже бывает)
Гугл тебе не всегда может ответить прямо на твой вопрос, наставник же может, если он знает ответ на этот вопрос конечно(другой вопрос насколько человек умеет хорошо гуглить)
В случае с книгами очень часто требуется самопроверка, это безусловно важный навык, но далеко не все им обладают
С другой стороны никто не гарантирует, что наставник будет вменяемым, хотя не могу говорить за практикум. Плюс самостоятельный поиск информации обязателен разработчику, НО, как мне кажется, у начинающих разработчиков должен быть человек, который поможет отсеять некорректную информацию, а то может случиться ситуация, когда человек принимает первые ответы гугла за чистую монету и тащит их в прод, ну или из самого безобидного начнет применять не самые современные подходы. В общем все крайне индивидуально и каждый человек сам должен понимать нужны ему курсы или нет. К слову, у меня с автором отчасти история схожа, начинал как разработчик на питоне, задача была сделать сайт, все что я знал на тот момент, что есть django, есть html css js, надо из этого сделать сайт. Рядом со мной был только гугл, поэтому я наступил на всевозможные грабли, из-за чего к слову в какой-то момент сильно устал от поиска информации, когда ты даже спросить совет нигде толком не можешь(Кстати, Роман (@suran), у вас была такая проблема? Когда уже банально сложно самому что-то искать и хочется немного расслабиться, но не сбавлять темпы обучения). Собственно тогда я и задумался на счет курсов, понимая, что нужно закрывать пробелы в знаниях и немного их структурировать. Но в конечном итоге силы я все же нашел, курс брать не стал, а просто начал просматривать CS50 от гарварда + leetcode. Ну и в конечном итоге принял решение перейти с python на go, о чем нисколько не жалею.
Уходят в прошлое? Можете рассказать подробнее? Первый раз просто подобное слышу и действительно стало интересно. Я всё же в основном бек пишу, а mui, bootstrap, как раз подходят, когда что-то быстро надо сделать. Хотя я больше tailwind предпочитаю в последнее время. Кстати, а по вашему мнению tailwind тоже уходит в прошлое? И если да, то по каким причинам? Единственная проблема таких технологий, как по мне, в том, что многие начинающие разработчики вместо чистого html/css учат их и остаются без базовых знаний.
На всякий случай хотел уточнить, а так и должно быть? Правится конечно изменением высоты через инструменты разработчика в браузере. (Если так все же не планировалось, то система macOS Monterey, браузер Safari 15.1)
Не совсем понимаю, почему углубление в стек стоит первым пунктом. Как мне кажется это даже анти-совет, мидл уже должен быть способен без особых проблем поменять фреймворк(да, я знаю, что для смены фреймворка нужно изучить хотя бы один, но знание стека это в любом случае не тот навык, что отделяет джуна от мидла). Особенно это может быть вредно для фронтенда, где каждый месяц с десяток новых фреймворков выходит(столько же правда каждый месяц и умирает), а кто-то до сих пор использует jQuery, просто потому что он так научился 10 лет назад и не может поменять свой стек. Ну а в целом, понимание работы своих основных инструментов для мидла куда важнее(js,ts,браузер и тд). Также многим джунам(да и некоторым мидлам тоже) не хватает понимания как работают встроенные функции и методы(к примеру includes работает О(n) и когда, он встречается в цикле, то надо понимать, что фактически это вложенный цикл). Еще из важных моментов, многие джуны боятся залезать в исходники тех или иных библиотек, хотя это такой же код, как и все остальное, это не магический черный ящик. Алгоритмы... вот опять про алгоритмы упомянули, но опять без мысли, что алгоритмы не нужно зубрить, не нужно знать их наизусть, нужно понимать отличие основных алгоритмов и структур данных друг от друга и критерии по которым для определенных задач нужно подбирать определенные алгоритмы и структуры данных, но ситуация на рынке сейчас такая, что все джуны просто сидят на литкоде и зубрят.
Или может возникнуть обратная ситуация, когда менеджер/руководитель будет руководствоваться сухими цифрами. 2021 Xsolla, достаточно много тогда шума было. В любом случае, зачастую такие новшества направлены в основном на исполнителей, а вот менеджеров оно затрагивает крайне редко, хотя зачастую среди менеджеров среднего звена и скрывается огромное число людей, которые выполняют пустую работу(к примеру в биг техе, это огромная проблема сейчас - big tech fake job).
А в чем смысл этого? Давно интересует этот вопрос. И распространяется ли это на всех? Или для специалистов определенного уровня это требование может быть опущено?
Ну вообще в теории способ есть, делать не черный лист мыла для регистрации, а белый (mail.ru, yandex.ru и тд). А способы геопозицию определить есть, ну а если пользователь использует впн, то тут уже ничего толком не сделать. Другой вопрос, что это костыли и потеря какого-то числа аудитории.
Возьму на себя ответственность немного поправить некоторые моменты.
Лично мне кажется, что тут не агрессия, а просто усталость от постоянных статей на хабре, где с одной стороны эффективные hr с красивыми метриками и фильтрами, с другой интервьюеры, которые время от времени уходят в крайности(одни в алгоритмы и только харды, другие в софт скилы, а харды 10 планом), а с третьей стороны разработчики, которые ищут 1000 и 1 способ обойти предыдущие 2 стороны этого треугольника.
Между берем всех подряд знакомых, и сотрудник компании предлагает своего друга или знакомого(в тексте этого нет, но я надеюсь частично под свою ответственность или хотя бы под условный кредит доверия), после чего с ним говорит "босс", после чего идет 1 месяц испытательного срока и только после этого будет уже офер. 1 месяц работы расскажет о человеке гораздо больше, чем самое длинное собеседование. Хотя и у этого подхода есть свой минус, мало кто захочет тратить месяц, но и люди, которые действительно только собесы зубрили скорее всего сразу откажутся и пойдут искать работу в классическом варианте.
Боюсь, маловероятно, что кто-то под этой статьёй сможет вам ответить на этот вопрос(хотя не исключаю такой возможности). Но вам ничего не мешает создать таблицу при помощи 1с и, используя информацию из этой статьи, самостоятельно проверить таблицу на выравнивание.
Там проблема в другом. Функция fmt.Scanln() принимает any, т.е может принять любой тип, а по факту сама функция хочет получить указатель на переменную, в которую нужно будет положить значение. Из-за того, что мы передаем не указатель, мы и получаем ошибку (type not a pointer) в рантайме, а компилятор видит, что в any кидают любой тип и его это устраивает.
На самом деле go отлично подходит для сложной бизнес логики, как и С, Java, Rust. Чего только стоит возможность легко превращать синхронный код в асинхронный(Правда это дает возможность по неопытности выстрелить себе в ногу датарейсами, дедлоками, лайфлоками и прочими интересными вещами). Есть и нейтральные моменты, обработка ошибок, хотя она позволяет не пропускать обработку ошибок, но и прокидывать их по стеку вызова при необходимости не очень приятно. Из неприятных моментов большое количество бойлерплейта.
Для работы с большим числом разных данных лучше подошел бы python к примеру, для кроссплатформенности я бы до сих пор предпочел Java и тд.
В любом случае языки приходят и уходят, это просто инструмент, любой разработчик, начиная наверное с мидла, при необходимости может поменять за 1-2 месяца яп, естественно с небольшой потерей грейда, но это быстро восполняется(ну и с условного python, js или php переходить на go/c/c++/c#/java/rust больнее, чем наоборот).
Главное не доводить до состояния, под названием "когда у тебя в руках молоток все вокруг превращается в гвозди".
На самом деле для написания сложной бизнес логики по хорошему просто нужен человек, который умеет качественно и надёжно писать код, а также правильно проектировать эту логику. Язык же выбирается исходя немного из других параметров: скорость разработки, производительность языка, количество и компетентность людей в штате знающих определённый язык, как этот язык поддерживается,тип типизации и многое другое. К примеру, если для какого-то приложения характерно множество io-bound задач, то go,java,rust,c(++/#) не сильно выиграют по сравнению с js,python и тд. Другой пример, приложению характерны cpu-bound задачи с возможностью их распараллелить - тут уже победа будет за go,rust и тд. Но это касается средне-крупных компаний, в более маленьких компаниях зачастую не используются 10 разных языков, поэтому и выбирать не из чего.
Ну и плюс, редко требуется писать с нуля всё приложение
Тесты из разных пакетов буду запускаться в любом случае параллельно(только если не ограничить количество одновременных задач, см первый вариант), t.Parallel() указывается для параллельного запуска тестов из одного пакета или сабтестов. В этом и была проблема, у меня несколько пакетов, 1 за каждую таблицу. Если я где-то ошибаюсь, то буду рад если кто-то меня поправит.
Отличная статья! Есть пример для семафора, к сожалению он не затрагивает воркер пул, но думаю тк статья про семафор, то имеет место быть. Плюс, если кто-то захочет найти еще примеры использования семафора, то может посмотреть исходники pgx (а точнее pgxpool).
Когда я писал тесты для слоя базы данных(тестировал без мока бд). То была проблема с тем, что тесты ломали друг друга. Решений было несколько:
1. Ограничить количество одновременных тестов до 1 (т.к у нас не только бд тесты, то их выполнение на 1 потоке занимает много времени)
2. Создавать отдельные схемы для каждого тесты (усложнение логики)
3. Запускать для каждого теста отдельный контейнер
4. Использовать семафор с размером 1 для лока 1 теста бд за раз (плюсы: простая логика. Минусы, при большом количество тестов для базы данных скорее всего это станет узким горлом).
Собственно 4 вариант и был выбран. К слову, если кто-то знает еще варианты решения этого вопроса, то буду рад узнать, как минимум для понимания того, что я мог упустить.
Также было бы интересно посмотреть использование паттернов fan-in и fan-out на практике.
Если я правильно понял ваше высказывание по поводу логики, то крайне согласен. Дать кандидату небольшую задачу, к примеру сокращение урлов (знаю, что эту задачу уже 100 раз изъездили все, кто мог, но для примера он подойдет, а для собеседования все же лучше придумать другие задачи), ну и дальше смотреть какие вопросы кандидат уточнит и как будет строить свои рассуждения по решению этой задачи: какая максимальная длина урла должна быть? нужно ли использовать новый домен для этого? если нет, то есть какое доменное имя будет использовано? Нужно ли учитывать длину этого домена? Нужно ли делать какой-то путь помимо домена, чтобы сокращенный урл в случае чего не конфликтовал с другими урлами? Должен ли быть этот урл читаемым([cat, dog, car] запоминаются лучше, чем X34j78)?Насколько большим должен быть пул урлов(частично связан с предыдущем вопросом)? Урл должен быть временным или постоянным, или должен быть выбор? Урл должен быть на определенное количество переходов? Есть ли какая-то существующая инфраструктура для реализации(будь то монолит или микросервисы, функции и тд)? Какой приоритет задачи(далеко не всегда бывает, что новую задачу выдают, когда завершаешь предыдущую, нужно понимать, что важнее делать в данный момент)? Для чего будут использовать этот сервис(от этого может зависеть потенциальная нагрузка на эту часть приложения; может выйти неприятная ситуация, когда менеджеры сделали рассылку условной миллионной аудитории с какой-нибудь акцией, а ссылки не работают из-за нагрузки)?
Не все эти вопросы надо задавать тому кто ставит задачу в обычных условиях, часть из них разработчик должен задать себе в голове, но на интервью озвучить их надо. На основе этих вопросов будет уже понятно, какая модель хранения данных будет, нужен ли кеш, в зависимости от нагрузки. Не лишним будет спросить, как этот сервис тестировать, какие пограничные случаи бывают.
От каждого пункта выше можно развить еще несколько вопросов. На основе всего этого будет уже понятно: как кандидат размышляет, какие подходы использует, как подходит к написанию тестов, любит ли изобретать велосипеды. Останется разве что дополнительно уточнить моменты по яп, который нужен компании. Как он обращается к базе данных к примеру, как обрабатывает ошибки, какие стандартный библиотеки использует, какие использует не стандартные библиотеки и для каких задач, как структурирует код и тд.
Ну в целом некоторые проблемы в статье есть, но отчасти с автором соглашусь, куда не посмотри, на технических собесах иногда происходит какой-то хаос. Где-то требуют знание конкретных мало кому известных технологий, когда это абсолютно не нужно. Где-то требуют знания алгоритмов наизусть, опять же не понимая зачем они нужны. Зачем условному гуглу или яндексу алгоритмы я понимаю, им проще нанять работника на основе понимания общих концепций CS, а не каких-то отдельных реализациях. Рынку в целом не хватает золотой середины.
Справедливости ради, но раннее вы перешли на личности и такой тон.
Сильно ничего против перехода на личности я сам не имею, но других не стоит в этом упрекать, когда сами это используете.
Полностью с вами согласен, но если так подумать, то гарантий нет нигде, но где-то шансы выше, где-то ниже, в случае с преподавателем, я думаю, шансы избежать ошибок выше, чем просто с гуглом под рукой(естественно пока нет минимального навыка фильтрации информации). Да и про несовременные подходы это самое минимальное, есть шанс на раннем этапе усвоить антипаттерны, а в не очень современных подходах нет ничего плохого, любые подходы ситуативный, довольно часто какой-то старый подход лучше подходит для решения конкретной задачи.
Тут есть несколько моментов, которые стоит учитывать:
Кому-то нужный внешний стимул: курс который тебя подгоняет, потраченные деньги и тд
Информация, которую ищешь сам, не всегда структурирована(в том числе книги, такое тоже бывает)
Гугл тебе не всегда может ответить прямо на твой вопрос, наставник же может, если он знает ответ на этот вопрос конечно(другой вопрос насколько человек умеет хорошо гуглить)
В случае с книгами очень часто требуется самопроверка, это безусловно важный навык, но далеко не все им обладают
С другой стороны никто не гарантирует, что наставник будет вменяемым, хотя не могу говорить за практикум. Плюс самостоятельный поиск информации обязателен разработчику, НО, как мне кажется, у начинающих разработчиков должен быть человек, который поможет отсеять некорректную информацию, а то может случиться ситуация, когда человек принимает первые ответы гугла за чистую монету и тащит их в прод, ну или из самого безобидного начнет применять не самые современные подходы.
В общем все крайне индивидуально и каждый человек сам должен понимать нужны ему курсы или нет.
К слову, у меня с автором отчасти история схожа, начинал как разработчик на питоне, задача была сделать сайт, все что я знал на тот момент, что есть django, есть html css js, надо из этого сделать сайт. Рядом со мной был только гугл, поэтому я наступил на всевозможные грабли, из-за чего к слову в какой-то момент сильно устал от поиска информации, когда ты даже спросить совет нигде толком не можешь(Кстати, Роман (@suran), у вас была такая проблема? Когда уже банально сложно самому что-то искать и хочется немного расслабиться, но не сбавлять темпы обучения). Собственно тогда я и задумался на счет курсов, понимая, что нужно закрывать пробелы в знаниях и немного их структурировать. Но в конечном итоге силы я все же нашел, курс брать не стал, а просто начал просматривать CS50 от гарварда + leetcode. Ну и в конечном итоге принял решение перейти с python на go, о чем нисколько не жалею.
Уходят в прошлое? Можете рассказать подробнее? Первый раз просто подобное слышу и действительно стало интересно. Я всё же в основном бек пишу, а mui, bootstrap, как раз подходят, когда что-то быстро надо сделать. Хотя я больше tailwind предпочитаю в последнее время. Кстати, а по вашему мнению tailwind тоже уходит в прошлое? И если да, то по каким причинам? Единственная проблема таких технологий, как по мне, в том, что многие начинающие разработчики вместо чистого html/css учат их и остаются без базовых знаний.
На всякий случай хотел уточнить, а так и должно быть? Правится конечно изменением высоты через инструменты разработчика в браузере. (Если так все же не планировалось, то система macOS Monterey, браузер Safari 15.1)
Не совсем понимаю, почему углубление в стек стоит первым пунктом. Как мне кажется это даже анти-совет, мидл уже должен быть способен без особых проблем поменять фреймворк(да, я знаю, что для смены фреймворка нужно изучить хотя бы один, но знание стека это в любом случае не тот навык, что отделяет джуна от мидла). Особенно это может быть вредно для фронтенда, где каждый месяц с десяток новых фреймворков выходит(столько же правда каждый месяц и умирает), а кто-то до сих пор использует jQuery, просто потому что он так научился 10 лет назад и не может поменять свой стек. Ну а в целом, понимание работы своих основных инструментов для мидла куда важнее(js,ts,браузер и тд). Также многим джунам(да и некоторым мидлам тоже) не хватает понимания как работают встроенные функции и методы(к примеру includes работает О(n) и когда, он встречается в цикле, то надо понимать, что фактически это вложенный цикл). Еще из важных моментов, многие джуны боятся залезать в исходники тех или иных библиотек, хотя это такой же код, как и все остальное, это не магический черный ящик. Алгоритмы... вот опять про алгоритмы упомянули, но опять без мысли, что алгоритмы не нужно зубрить, не нужно знать их наизусть, нужно понимать отличие основных алгоритмов и структур данных друг от друга и критерии по которым для определенных задач нужно подбирать определенные алгоритмы и структуры данных, но ситуация на рынке сейчас такая, что все джуны просто сидят на литкоде и зубрят.
Или может возникнуть обратная ситуация, когда менеджер/руководитель будет руководствоваться сухими цифрами. 2021 Xsolla, достаточно много тогда шума было. В любом случае, зачастую такие новшества направлены в основном на исполнителей, а вот менеджеров оно затрагивает крайне редко, хотя зачастую среди менеджеров среднего звена и скрывается огромное число людей, которые выполняют пустую работу(к примеру в биг техе, это огромная проблема сейчас - big tech fake job).
А в чем смысл этого? Давно интересует этот вопрос. И распространяется ли это на всех? Или для специалистов определенного уровня это требование может быть опущено?
Ну вообще в теории способ есть, делать не черный лист мыла для регистрации, а белый (mail.ru, yandex.ru и тд). А способы геопозицию определить есть, ну а если пользователь использует впн, то тут уже ничего толком не сделать. Другой вопрос, что это костыли и потеря какого-то числа аудитории.
Меня другое интересует, а прокси на gmail, но с русским доменом это ру почта?
В законе написано, что это касается только жителей рф.