Forwarded from Борис опять
На днях друг попросил помочь поторговаться за зарплату. Вот что получилось.
Дано:
* Оффер на Аналитика, 150к руб, большой Телеком.
* Оффер на ML инженера, 150к руб, небольшая техкомпания в мутной сфере, назовем ее Смолтех.
* Назревающий оффер на ML инженера в Бигтех, куда больше всего хочется.
Наблюдения:
* Никто не хочет идти работать в Телеком, но они довольно богатые , поэтому определенно готовы заплатить много денег, чтобы заманить специалиста.
* Смолтех работает в мутной и почти маргинальной сфере с огромной маржой. К ним скорее всего не выстраиваются очереди желающих. Они просто обязаны платить выше рынка, чтобы компенсировать риски мутности.
* В Бигтехе, напротив, люди готовы работать за еду и строчку в резюме.
Предложил такую стратегию:
1. Собираем свои причины торговаться. Определяем для себя зачем нам деньги. Например: надо переезжать, кризис, нужны вложения. Встаем в положение “у меня нет выбора, кроме как принять решение в пользу лучшего предложения”.
2. Относим оффер Смолтеха в Телеком и говорим: у Смолтеха интереснее работа, а деньги такие же, но я хочу к вам, потому что у них мутный сектор, и, если вы поднимете оффер, то это станет решающим.
3. Телеком скорее всего поднимет оффер примерно до 170к.
4. Берем новый оффер от Телекома и несем в Смолтех. Говорим: Телеком предлагает больше денег, и сектор не такой мутный, но у вас интереснее работа и в целом больше хочется к вам.
5. Они скорее всего поднимут еще выше.
6. При любых обновлениях офферов сразу скидываем их в Бигтех: апдейт по ситуации.
7. Когда офер в Бигтехе дозреет, он скорее всего будет выше обоих. Конечно же говорим, что больше всего хотим к ним.
8. Повторяем действия до тех пор, пока все не скажут “нет”.
Как все обернулось:
1. Телеком поднялся до 165к увидев оффер от Смолтеха.
2. Смолтех поднялся до 180к.
3. Бигтех поднялся до 187к после налогов, плюс все корпоративные бонусы, которые можно оценить еще в примерно 10к.
4. Телеком и Смолтех отказались поднимать выше.
В итоге подъем почти на 25%!
Дано:
* Оффер на Аналитика, 150к руб, большой Телеком.
* Оффер на ML инженера, 150к руб, небольшая техкомпания в мутной сфере, назовем ее Смолтех.
* Назревающий оффер на ML инженера в Бигтех, куда больше всего хочется.
Наблюдения:
* Никто не хочет идти работать в Телеком, но они довольно богатые , поэтому определенно готовы заплатить много денег, чтобы заманить специалиста.
* Смолтех работает в мутной и почти маргинальной сфере с огромной маржой. К ним скорее всего не выстраиваются очереди желающих. Они просто обязаны платить выше рынка, чтобы компенсировать риски мутности.
* В Бигтехе, напротив, люди готовы работать за еду и строчку в резюме.
Предложил такую стратегию:
1. Собираем свои причины торговаться. Определяем для себя зачем нам деньги. Например: надо переезжать, кризис, нужны вложения. Встаем в положение “у меня нет выбора, кроме как принять решение в пользу лучшего предложения”.
2. Относим оффер Смолтеха в Телеком и говорим: у Смолтеха интереснее работа, а деньги такие же, но я хочу к вам, потому что у них мутный сектор, и, если вы поднимете оффер, то это станет решающим.
3. Телеком скорее всего поднимет оффер примерно до 170к.
4. Берем новый оффер от Телекома и несем в Смолтех. Говорим: Телеком предлагает больше денег, и сектор не такой мутный, но у вас интереснее работа и в целом больше хочется к вам.
5. Они скорее всего поднимут еще выше.
6. При любых обновлениях офферов сразу скидываем их в Бигтех: апдейт по ситуации.
7. Когда офер в Бигтехе дозреет, он скорее всего будет выше обоих. Конечно же говорим, что больше всего хотим к ним.
8. Повторяем действия до тех пор, пока все не скажут “нет”.
Как все обернулось:
1. Телеком поднялся до 165к увидев оффер от Смолтеха.
2. Смолтех поднялся до 180к.
3. Бигтех поднялся до 187к после налогов, плюс все корпоративные бонусы, которые можно оценить еще в примерно 10к.
4. Телеком и Смолтех отказались поднимать выше.
В итоге подъем почти на 25%!
Forwarded from Архив Программиста
Как выучить Python в 2023 году — свежая дорожная карта от комьюнити.
В дорожной карте собрали все самые популярные и актуальные инструменты за прошедший год. Для новичков это отличная шпаргалка и понимание, с чего стоит начать, а опытным разработчикам она подскажет, куда развивать дальше.
В хорошем качестве можно глянуть тут.
В дорожной карте собрали все самые популярные и актуальные инструменты за прошедший год. Для новичков это отличная шпаргалка и понимание, с чего стоит начать, а опытным разработчикам она подскажет, куда развивать дальше.
В хорошем качестве можно глянуть тут.
Forwarded from DevFM
Программа vs процесс vs поток
В 4-минутном видео Process vs Thread раскрывается популярный на собеседовании вопрос из заголовка. Программа с диска в момент запуска становится процессом, а в процессе может быть один и более поток с общим адресным пространством. Пара слов сказана и о корутинах / зелёных потоках. Про зелёные потоки будет отдельный пост.
Для более вдумчивого чтения про процессы и потоки можем порекомендовать 2 главу Современные операционные системы Таненбаума (4 издание, 2015 год).
#skills
В 4-минутном видео Process vs Thread раскрывается популярный на собеседовании вопрос из заголовка. Программа с диска в момент запуска становится процессом, а в процессе может быть один и более поток с общим адресным пространством. Пара слов сказана и о корутинах / зелёных потоках. Про зелёные потоки будет отдельный пост.
Для более вдумчивого чтения про процессы и потоки можем порекомендовать 2 главу Современные операционные системы Таненбаума (4 издание, 2015 год).
#skills
YouTube
FANG Interview Question | Process vs Thread
Subscribe to our weekly system design newsletter: https://bit.ly/3tfAlYD
Checkout our bestselling System Design Interview books:
Volume 1: https://amzn.to/3Ou7gkd
Volume 2: https://amzn.to/3HqGozy
Other things we made:
Digital version of System Design…
Checkout our bestselling System Design Interview books:
Volume 1: https://amzn.to/3Ou7gkd
Volume 2: https://amzn.to/3HqGozy
Other things we made:
Digital version of System Design…
Forwarded from Love. Death. Transformers.
#ml #statistics
Интересная книга с Байесовским подходом в анализе данных
https://www.stat.columbia.edu/~gelman/book/BDA3.pdf
Интересная книга с Байесовским подходом в анализе данных
https://www.stat.columbia.edu/~gelman/book/BDA3.pdf
Forwarded from Artificial stupidity
#statistics
Weighted Z-test для мета-анализа результатов экспериментов.
Мне попался на глаза пост от ebay про z-test для мета-анализа (спасибо коллегам). Так что сегодня поговорим про этот метод.
Итак. Предположим, что у нас есть несколько запусков одного теста (например, волны коммуникации со схожей механикой, либо повторный запуск какого-либо эксперимента).
У нас есть N тестов (например, N t-тестов для средних), для каждого из которых есть свое p-value, свое значение статистики и свой доверительный интервал. Мы думаем, что объединение разрозненных источников информации даст нам преимущество и позволить уточнить наши выводы, увеличив мощность полученного комбинированного теста.
Для one-sided теста у нас может использоваться Fishers method. Но в случае two-sided теста нам нужен другой способ. И тут на сцену выходит Z-test.
Мы можем скомбинировать наши p-values в комбинированный p-value, используя Z-статистики из каждого эксперимента и веса, которые получаются из выражения
Соответственно, в такой постановке мы уже проверяем комбинированную гипотезу. И на ее основе решаем, что же получилось для группы тестов. А больший объем информации дает нам большую мощность эксперимента.
Какие тут плюсы и минусы?
Плюсы:
- Тест может комбинировать отдельные результаты тестов с разными размерами выборки;
- Полученная комбинация имеет большую мощность, чем каждый отдельный тест
Минусы:
- Тест предполагает нормальность распределения (не забываем о Z-статистике при его расчете);
- Тест чувствителен к весам. Соответственно, есть возможность того, что какой-то тест попросту перевесит все остальные;
- Комбинированный тест может быть сложнее к пониманию и реализации, чем единичный обычный проведенный тест
Weighted Z-test для мета-анализа результатов экспериментов.
Мне попался на глаза пост от ebay про z-test для мета-анализа (спасибо коллегам). Так что сегодня поговорим про этот метод.
Итак. Предположим, что у нас есть несколько запусков одного теста (например, волны коммуникации со схожей механикой, либо повторный запуск какого-либо эксперимента).
У нас есть N тестов (например, N t-тестов для средних), для каждого из которых есть свое p-value, свое значение статистики и свой доверительный интервал. Мы думаем, что объединение разрозненных источников информации даст нам преимущество и позволить уточнить наши выводы, увеличив мощность полученного комбинированного теста.
Для one-sided теста у нас может использоваться Fishers method. Но в случае two-sided теста нам нужен другой способ. И тут на сцену выходит Z-test.
Мы можем скомбинировать наши p-values в комбинированный p-value, используя Z-статистики из каждого эксперимента и веса, которые получаются из выражения
w_i = 1 / SE_i, где SE_i - это standart error для i-го эксперимента (формула построения доверительного интервала комбинированного эксперимента есть в исходном посте по ссылке в начале).Соответственно, в такой постановке мы уже проверяем комбинированную гипотезу. И на ее основе решаем, что же получилось для группы тестов. А больший объем информации дает нам большую мощность эксперимента.
Какие тут плюсы и минусы?
Плюсы:
- Тест может комбинировать отдельные результаты тестов с разными размерами выборки;
- Полученная комбинация имеет большую мощность, чем каждый отдельный тест
Минусы:
- Тест предполагает нормальность распределения (не забываем о Z-статистике при его расчете);
- Тест чувствителен к весам. Соответственно, есть возможность того, что какой-то тест попросту перевесит все остальные;
- Комбинированный тест может быть сложнее к пониманию и реализации, чем единичный обычный проведенный тест
Forwarded from DevFM
Идемпо… что? Улучшаем API
Когда писал пост про работу с HTTP, обнаружил непростительную оплошность. Мы ни разу не рассказывали о такой супер важной штуке, как идемпотентность API.
Начало статьи Стажёр Вася и его истории об идемпотентности API очень метко характеризует этот термин:
Звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.
В реальных приложениях не всё идет гладко, нужно продумывать граничные случаи, случаются таймауты, перезапросы, дубли.
Автор на примере приложения Такси и всего одной кнопки "Заказать такси" рассказывает о множестве подвохов, которые поджидают разработчика.
Из-за затупа с базой пользователь дважды нажал кнопку Заказать и приехало две машины.
Что ж, на фронте начали блокировать кнопку Заказать, пока не придет ответ с сервера.
Оказалось, этого не достаточно. Из-за проблем с сетью по таймауту возникла ошибка и клиентское приложение разблокировало кнопку Заказать. Но кто бы мог подумать... проблема проблемой, но до сервера запрос дошёл и даже выполнился. По итогу имеем снова две машины. Эту проблему поправили уже на беке, добавив пару if.
Проблема решена, можно заканчивать статью. А потом тарам-пам-пам... классика. Менеджер изменил бизнес требования и старое решение уже не подходит.
Тут-то автор и подходит к сути статьи. Ключ идемпотентности, что за зверь такой, как он поможет решить обозначенную проблему. Но не всё так просто, поэтому далее в статье раскрываются ещё несколько тонких моментов.
Когда я первый раз прочитал эту статью в далёком 19 году, то был в искреннем восторге, насколько доступно и на понятных примерах можно раскрыть тему. А классический пример с заказчиком: от "нам это не нужно абсолютно точно" до "срооооочно нужна эта фича" — просто вишенка на торте.
#skills
Когда писал пост про работу с HTTP, обнаружил непростительную оплошность. Мы ни разу не рассказывали о такой супер важной штуке, как идемпотентность API.
Начало статьи Стажёр Вася и его истории об идемпотентности API очень метко характеризует этот термин:
Звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.
В реальных приложениях не всё идет гладко, нужно продумывать граничные случаи, случаются таймауты, перезапросы, дубли.
Автор на примере приложения Такси и всего одной кнопки "Заказать такси" рассказывает о множестве подвохов, которые поджидают разработчика.
Из-за затупа с базой пользователь дважды нажал кнопку Заказать и приехало две машины.
Что ж, на фронте начали блокировать кнопку Заказать, пока не придет ответ с сервера.
Оказалось, этого не достаточно. Из-за проблем с сетью по таймауту возникла ошибка и клиентское приложение разблокировало кнопку Заказать. Но кто бы мог подумать... проблема проблемой, но до сервера запрос дошёл и даже выполнился. По итогу имеем снова две машины. Эту проблему поправили уже на беке, добавив пару if.
Проблема решена, можно заканчивать статью. А потом тарам-пам-пам... классика. Менеджер изменил бизнес требования и старое решение уже не подходит.
Тут-то автор и подходит к сути статьи. Ключ идемпотентности, что за зверь такой, как он поможет решить обозначенную проблему. Но не всё так просто, поэтому далее в статье раскрываются ещё несколько тонких моментов.
Когда я первый раз прочитал эту статью в далёком 19 году, то был в искреннем восторге, насколько доступно и на понятных примерах можно раскрыть тему. А классический пример с заказчиком: от "нам это не нужно абсолютно точно" до "срооооочно нужна эта фича" — просто вишенка на торте.
#skills
Telegram
DevFM
15 тривиальных фактов о правильной работе с протоколом HTTP
Полезный чеклист для всех, кто разрабатывает веб-приложения. По сути, это сборник разных и важных знаний из разных стандартов. В конце автор приводит ссылки на эти самые стандарты, так что особо…
Полезный чеклист для всех, кто разрабатывает веб-приложения. По сути, это сборник разных и важных знаний из разных стандартов. В конце автор приводит ссылки на эти самые стандарты, так что особо…
Forwarded from DevFM
Зелёные потоки в Python
Переключение между потоками — процесс очень затратный по времени, как мы уже разбирали. Для решения этой проблемы были придуманы зелёные потоки (green threads, они же coroutines или корутины), у которых вместо честного переключения потоков операционной системой реализуется виртуальное переключение потоков в пользовательском пространстве. Для IO-bound задач, где бутылочным горлышком являются медленные операции ввода-вывода, в том числе сетевого, зелёные потоки являются спасением. Для CPU-bound задач, где надо много физически вычислять на процессоре и нет простоев зелёные потоки не нужны.
Предлагаем прочитать статью Асинхронный python без головной боли (часть вторая). Начинается статья с наглядного примера асинхронности из жизни. Часто у начинающих разработчиков можно наблюдать ошибку, когда вместо подписки на событие, например, изменения файла, реализуется "жужжалка", которая в бесконечном цикле дёргает метаданные файла, загружая CPU на 100%.
Дальше на примере показывается async-await с разными нюансами, в том числе с необходимостью асинхронных функций. Потом показывается взаимосвязь корутин и генераторов, асинхронные контекстные менеджеры и приложение, которое асинхронно что-то делает с сервисом погоды.
Во второй части речь про event loop, про пример с API gateway, дополнение сервиса погоды переводчиком, асинхронным логгированием и базой.
#python
Переключение между потоками — процесс очень затратный по времени, как мы уже разбирали. Для решения этой проблемы были придуманы зелёные потоки (green threads, они же coroutines или корутины), у которых вместо честного переключения потоков операционной системой реализуется виртуальное переключение потоков в пользовательском пространстве. Для IO-bound задач, где бутылочным горлышком являются медленные операции ввода-вывода, в том числе сетевого, зелёные потоки являются спасением. Для CPU-bound задач, где надо много физически вычислять на процессоре и нет простоев зелёные потоки не нужны.
Предлагаем прочитать статью Асинхронный python без головной боли (часть вторая). Начинается статья с наглядного примера асинхронности из жизни. Часто у начинающих разработчиков можно наблюдать ошибку, когда вместо подписки на событие, например, изменения файла, реализуется "жужжалка", которая в бесконечном цикле дёргает метаданные файла, загружая CPU на 100%.
Дальше на примере показывается async-await с разными нюансами, в том числе с необходимостью асинхронных функций. Потом показывается взаимосвязь корутин и генераторов, асинхронные контекстные менеджеры и приложение, которое асинхронно что-то делает с сервисом погоды.
Во второй части речь про event loop, про пример с API gateway, дополнение сервиса погоды переводчиком, асинхронным логгированием и базой.
#python
Telegram
DevFM
Программа vs процесс vs поток
В 4-минутном видео Process vs Thread раскрывается популярный на собеседовании вопрос из заголовка. Программа с диска в момент запуска становится процессом, а в процессе может быть один и более поток с общим адресным пространством.…
В 4-минутном видео Process vs Thread раскрывается популярный на собеседовании вопрос из заголовка. Программа с диска в момент запуска становится процессом, а в процессе может быть один и более поток с общим адресным пространством.…
#career
Матрица компетенций в области SWE
https://sijinjoseph.netlify.app/programmer-competency-matrix/
Матрица компетенций в области SWE
https://sijinjoseph.netlify.app/programmer-competency-matrix/
Sijin Joseph
Programmer Competency Matrix | Sijin Joseph
Note that the knowledge for each level is cumulative; being at
level n implies that you also know everything from the
levels lower than n.
Computer Science 2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments data structures Doesn’t know the difference…
level n implies that you also know everything from the
levels lower than n.
Computer Science 2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments data structures Doesn’t know the difference…
Forwarded from Small Data Science for Russian Adventurers
#полезно
Довольно любопытный блог, в основном тут описываются идеи научных статей. Тематика: оптимизация, тензорные разложения, GAN-ы. Из последних интересных постов: качество на тестовой выборке почти совпадает с качеством на синтетической выборке, построенной с помощью GAN-a, обученного на обучении (т.е. предсказывается качество на тесте).
https://www.offconvex.org
Довольно любопытный блог, в основном тут описываются идеи научных статей. Тематика: оптимизация, тензорные разложения, GAN-ы. Из последних интересных постов: качество на тестовой выборке почти совпадает с качеством на синтетической выборке, построенной с помощью GAN-a, обученного на обучении (т.е. предсказывается качество на тесте).
https://www.offconvex.org
Forwarded from Deleted Account