Fairness. Честная многопоточность.
Одна из проблем многопоточного программирования называется starvation. Её суть в том, что поток не может получить доступ к общим ресурсам и продолжать работу. Так получается, если:
- у потока низкий приоритет,
- другие потоки захватывают доступ к критической секции быстрее,
- поток вызвал wait() у объекта, но notify() достаётся другим потокам.
Ситуация неприятная: ресурсы потока заняты, а задача не выполняется. Чтобы избежать проблем выше можно использовать средства синхронизации с флажком fairness = true. Например,
Lock lock = new ReentrantLock(true);
Что при этом происходит? И почему этот параметр по умолчанию false?
При fairness=true преимущество получает самый долго ожидающий поток. При этом вероятность starvation ощутимо снижается. Конкретная очередность не гарантируется, так как параметр не влияет на планировщик потоков в ОС. Пропускная способность при этом ухудшается в разы
Интересный факт:
tryLock() не обращает внимания на параметр fairness и постарается захватить блокировку, даже если в очереди стоят другие потоки.
tryLock(0, TimeUnit.SECONDS) учитывает fairness и при наличии других ожидающих потоков встанет в общую очередь.
Что же делать? Использовать флажок fairness или нет?
Если описанные выше проблемы возможны и критичны, надёжнее использовать tryLock с увеличивающимся временем ожидания и не полагаться на fairness.
#core
Одна из проблем многопоточного программирования называется starvation. Её суть в том, что поток не может получить доступ к общим ресурсам и продолжать работу. Так получается, если:
- у потока низкий приоритет,
- другие потоки захватывают доступ к критической секции быстрее,
- поток вызвал wait() у объекта, но notify() достаётся другим потокам.
Ситуация неприятная: ресурсы потока заняты, а задача не выполняется. Чтобы избежать проблем выше можно использовать средства синхронизации с флажком fairness = true. Например,
Lock lock = new ReentrantLock(true);
Что при этом происходит? И почему этот параметр по умолчанию false?
При fairness=true преимущество получает самый долго ожидающий поток. При этом вероятность starvation ощутимо снижается. Конкретная очередность не гарантируется, так как параметр не влияет на планировщик потоков в ОС. Пропускная способность при этом ухудшается в разы
Интересный факт:
tryLock() не обращает внимания на параметр fairness и постарается захватить блокировку, даже если в очереди стоят другие потоки.
tryLock(0, TimeUnit.SECONDS) учитывает fairness и при наличии других ожидающих потоков встанет в общую очередь.
Что же делать? Использовать флажок fairness или нет?
Если описанные выше проблемы возможны и критичны, надёжнее использовать tryLock с увеличивающимся временем ожидания и не полагаться на fairness.
#core
👍13❤2🔥2
Как стать лучшим разработчиком
Главное конкурентное преимущество любого специалиста — знать правила и понимать когда, где и зачем они нужны.
Нормальный разработчик решает проблемы по мере поступления, учится тому, что пригодится в работе, бессистемно читает статьи по разным темам.
Хороший разработчик углубляет текущие знания, смотрит лекции по другим технологиям, читает фундаментальные книги.
Лучший разработчик делает то же, что и хороший. Но не просто поглощает факты, а разбирается, почему всё работает именно так. Какие границы применимости у новых знаний. Чем один подход лучше другого.
Недостаточно заучить типовые ситуации и типовые решения. В лекциях даются упрощённые однобокие примеры. На каждом проекте свои проблемы, подходы и технологии. У каждой задачи несколько решений.
Анализируйте то, что делаете. Даже если вы ещё джуниор или мидл, и задачи выглядят как «напиши это по подобию того». Посмотрите на задачу шире и постарайтесь понять, почему сделано так, а не иначе. Когда читаете статьи и смотрите лекции задавайте себе вопрос - как ещё решить исходную проблему? Когда мой вариант лучше варианта из статьи? Сначала будет казаться, что других достойных опций нет, но со временем вы будете видеть их всё чаще.
Мгновенного профита от такого процесса не будет, но если привычка закрепится — вы будете на голову выше своих коллег. Чем выше должность - тем больше принимаемых решений и тем важнее навык критического мышления.
В разработке ПО полно инертности. Однажды выбранные способы решения выбираются снова и снова. Thinking out of the box — самый редкий и ценный навык и над ним тоже нужно работать.
#soft_skills
Главное конкурентное преимущество любого специалиста — знать правила и понимать когда, где и зачем они нужны.
Нормальный разработчик решает проблемы по мере поступления, учится тому, что пригодится в работе, бессистемно читает статьи по разным темам.
Хороший разработчик углубляет текущие знания, смотрит лекции по другим технологиям, читает фундаментальные книги.
Лучший разработчик делает то же, что и хороший. Но не просто поглощает факты, а разбирается, почему всё работает именно так. Какие границы применимости у новых знаний. Чем один подход лучше другого.
Недостаточно заучить типовые ситуации и типовые решения. В лекциях даются упрощённые однобокие примеры. На каждом проекте свои проблемы, подходы и технологии. У каждой задачи несколько решений.
Анализируйте то, что делаете. Даже если вы ещё джуниор или мидл, и задачи выглядят как «напиши это по подобию того». Посмотрите на задачу шире и постарайтесь понять, почему сделано так, а не иначе. Когда читаете статьи и смотрите лекции задавайте себе вопрос - как ещё решить исходную проблему? Когда мой вариант лучше варианта из статьи? Сначала будет казаться, что других достойных опций нет, но со временем вы будете видеть их всё чаще.
Мгновенного профита от такого процесса не будет, но если привычка закрепится — вы будете на голову выше своих коллег. Чем выше должность - тем больше принимаемых решений и тем важнее навык критического мышления.
В разработке ПО полно инертности. Однажды выбранные способы решения выбираются снова и снова. Thinking out of the box — самый редкий и ценный навык и над ним тоже нужно работать.
#soft_skills
👍21❤2👎1🔥1
Бесполезная калибровка Thread.sleep
или как JDK создаёт иллюзию выбора.
Все знают метод sleep(long millis) у класса Thread. Он останавливает выполнение потока на заданное количество миллисекунд.
Также в классе есть похожий метод sleep(long millis, int nanos). Здравый смысл подсказывает, что это тот же sleep, только время приостановки задаётся точнее.
Документация к методу подтверждает нашу догадку:
...sleep for the specified number of milliseconds plus the specified number of nanoseconds.
Что тут ещё обсуждать? Расходимся!
Но всё же посмотрим в код. После проверок на валидность, видим следующие строки:
Или выставить паузу в 1 миллисекунду, если микросекунд 0, а наносекунд не 0.
У JVM доступен один нативный метод, который работает только с миллисекундами. Поэтому результат не очень удивляет. Но зачем тогда нужен второй метод?
#core
или как JDK создаёт иллюзию выбора.
Все знают метод sleep(long millis) у класса Thread. Он останавливает выполнение потока на заданное количество миллисекунд.
Также в классе есть похожий метод sleep(long millis, int nanos). Здравый смысл подсказывает, что это тот же sleep, только время приостановки задаётся точнее.
Документация к методу подтверждает нашу догадку:
...sleep for the specified number of milliseconds plus the specified number of nanoseconds.
Что тут ещё обсуждать? Расходимся!
Но всё же посмотрим в код. После проверок на валидность, видим следующие строки:
if (nanos >= 500000 || (nanos != 0 && millis == 0)) {
millis++;
}
sleep(millis);
То есть прибавить 1 миллисекунду, если наносекунд больше 500к.Или выставить паузу в 1 миллисекунду, если микросекунд 0, а наносекунд не 0.
У JVM доступен один нативный метод, который работает только с миллисекундами. Поэтому результат не очень удивляет. Но зачем тогда нужен второй метод?
#core
👍8❤1🔥1
Виды многозадачности
Сегодня выйдем за пределы JVM и посмотрим на многопоточность на уровне ОС.
Многопоточность — когда в одном процессе параллельно работают несколько потоков.
Многозадачность — несколько процессов параллельно исполняются в ОС.
При этом параллельно — не значит одновременно. Процесс/поток использует ресурсы процессора некоторое время, потом выполнение прерывается, ОС сохраняет временные данные (контекст), а ресурсы переходят на другой процесс/поток. Загружается контекст другой задачи, и выполнение продолжается.
Многозадачность бывает двух типов:
1. Вытесняющая.
ОС выделяет кванты времени для каждой задачи и управляет их переключением. Так работают потоки в джаве, а также процессы в современных ОС.
✅ не нужно думать о переключении задач, всё делает ОС
✅ повисшая задача не блокирует остальные
❌ сложная работа с общими ресурсами
❌сложно координировать связанные параллельные задачи
2. Кооперативная.
Программа/поток сами сигнализируют, что пора сохранить контекст и переключиться на другую задачу. Так были организованы ОС давным-давно. В прикладных программах эта модель реализуется через fibers – «легковесные потоки», которые исполняются на одном потоке ОС и имеют собственный планировщик.
✅ переключение контекста происходит в 10-100 раз быстрее
✅ проще работа с общими ресурсами, не нужно часто синхронизироваться
✅ эффективная обработка некоторого типа задач
❌ увеличенная сложность разработки
❌ ошибка в одной задаче сильно влияет на другие, вплоть до остановки основного процесса
По умолчанию для java программ используется вытесняющая многозадачность. Однако преимущества кооперативной модели можно получить с помощью некоторых библиотек или конструкций из котлина.
#теория
Сегодня выйдем за пределы JVM и посмотрим на многопоточность на уровне ОС.
Многопоточность — когда в одном процессе параллельно работают несколько потоков.
Многозадачность — несколько процессов параллельно исполняются в ОС.
При этом параллельно — не значит одновременно. Процесс/поток использует ресурсы процессора некоторое время, потом выполнение прерывается, ОС сохраняет временные данные (контекст), а ресурсы переходят на другой процесс/поток. Загружается контекст другой задачи, и выполнение продолжается.
Многозадачность бывает двух типов:
1. Вытесняющая.
ОС выделяет кванты времени для каждой задачи и управляет их переключением. Так работают потоки в джаве, а также процессы в современных ОС.
✅ не нужно думать о переключении задач, всё делает ОС
✅ повисшая задача не блокирует остальные
❌ сложная работа с общими ресурсами
❌сложно координировать связанные параллельные задачи
2. Кооперативная.
Программа/поток сами сигнализируют, что пора сохранить контекст и переключиться на другую задачу. Так были организованы ОС давным-давно. В прикладных программах эта модель реализуется через fibers – «легковесные потоки», которые исполняются на одном потоке ОС и имеют собственный планировщик.
✅ переключение контекста происходит в 10-100 раз быстрее
✅ проще работа с общими ресурсами, не нужно часто синхронизироваться
✅ эффективная обработка некоторого типа задач
❌ увеличенная сложность разработки
❌ ошибка в одной задаче сильно влияет на другие, вплоть до остановки основного процесса
По умолчанию для java программ используется вытесняющая многозадачность. Однако преимущества кооперативной модели можно получить с помощью некоторых библиотек или конструкций из котлина.
#теория
👍8🔥2❤1
Эффективное код ревью
и как сделать его лучше.
Практика код ревью используется на многих проектах, потому что это:
1. Обмен знаниями о проекте и технологиях внутри команды.
2. Повышение качество кода.
3. Способ найти оптимальное решение задачи.
В слаженных командах с утверждённым кодстайлом и схожим бэкграундом код ревью действительно даёт эти преимущества. А вот для новичка или в молодых командах код ревью часто приводит к конфликтам и непониманию.
Каждый проект уникален, но общие правила выглядят так:
1. Время автора кода и ревьюеров — ценный ресурс.
2. Код — это инструмент решение задачи, а не отражение личности разработчика.
3. Замечания должны быть конструктивны и понятны.
На верхнем уровне это все понимают, но чтобы на практике увеличить прозрачность и эффективность этого процесса, нужно обсудить и чётко обозначить:
1. Время, в течение которого ревьюеры обязаны посмотреть код.
2. Код-стайл команды — обычно в виде файла для настройки форматирования IDE
3. Приоритеты при решении задачи:
- производительность (высоконагруженные системы),
- чистота кода (open-source проекты),
- лёгкость понимания (проекты с большим количеством разработчиков),
- простота модификации (стартапы)
и тд.
4. Действия при разногласиях - чаще всего это предоставить решение третьей стороне конфликта
2 часа обсуждать имя переменной - это трата времени. Не надо так.
#soft_skills
и как сделать его лучше.
Практика код ревью используется на многих проектах, потому что это:
1. Обмен знаниями о проекте и технологиях внутри команды.
2. Повышение качество кода.
3. Способ найти оптимальное решение задачи.
В слаженных командах с утверждённым кодстайлом и схожим бэкграундом код ревью действительно даёт эти преимущества. А вот для новичка или в молодых командах код ревью часто приводит к конфликтам и непониманию.
Каждый проект уникален, но общие правила выглядят так:
1. Время автора кода и ревьюеров — ценный ресурс.
2. Код — это инструмент решение задачи, а не отражение личности разработчика.
3. Замечания должны быть конструктивны и понятны.
На верхнем уровне это все понимают, но чтобы на практике увеличить прозрачность и эффективность этого процесса, нужно обсудить и чётко обозначить:
1. Время, в течение которого ревьюеры обязаны посмотреть код.
2. Код-стайл команды — обычно в виде файла для настройки форматирования IDE
3. Приоритеты при решении задачи:
- производительность (высоконагруженные системы),
- чистота кода (open-source проекты),
- лёгкость понимания (проекты с большим количеством разработчиков),
- простота модификации (стартапы)
и тд.
4. Действия при разногласиях - чаще всего это предоставить решение третьей стороне конфликта
2 часа обсуждать имя переменной - это трата времени. Не надо так.
#soft_skills
👍8❤1🔥1
Создание потока в 1995 и в 2020 году
Что происходит, когда программист пишет
new Thread(...)?
В джаве используется модель native threads. Это значит, что потоки создаются в операционной системе(ОС), а в JVM хранится часть контекста.
Планирование очередности и переключения между потоками тоже делает ОС. ✅ Процессорные ресурсы используются очень эффективно. В этом главное преимущество модели native threads.
Недостатки модели:
❌ создание и утилизация потоков занимает время
❌ переключение между потоками требует сохранения и загрузки контекста
❌ доступ к общим ресурсам нужно синхронизировать.
Такая модель подходит для длительных изолированных друг от друга задач.
В Java 1.1 использовалась другая модель многопоточности, которая называется green threads. В этом случае для JVM создаётся один или несколько системных потоков, а программные потоки с ними соотносятся. Переключение между потоками и работа с контекстом также выполняется JVM.
✅ эмуляции многопоточной среды там, где это не поддерживается ОС.
✅ быстрое переключение между потоками.
❌ нерациональное использование ресурсов в многопроцессорной среде. С точки зрения ОС задачи выполняются псевдопараллелльно, что ухудшает производительность.
Модель green threads устарела и считается неэффективной. Методы ручного управления потоками помечены @Deprecated начиная с Java 1.2.
Но идея переиспользования созданных ОС потоков сейчас в тренде. Java-библиотеки и некоторые версии JVM основаны на идее легковесных потоков. Fibers, coroutines, project Loom, Quasar, Kilim, Kotlin continuations – ключевые слова для дальнейшего углубления в тему.
#теория
Что происходит, когда программист пишет
new Thread(...)?
В джаве используется модель native threads. Это значит, что потоки создаются в операционной системе(ОС), а в JVM хранится часть контекста.
Планирование очередности и переключения между потоками тоже делает ОС. ✅ Процессорные ресурсы используются очень эффективно. В этом главное преимущество модели native threads.
Недостатки модели:
❌ создание и утилизация потоков занимает время
❌ переключение между потоками требует сохранения и загрузки контекста
❌ доступ к общим ресурсам нужно синхронизировать.
Такая модель подходит для длительных изолированных друг от друга задач.
В Java 1.1 использовалась другая модель многопоточности, которая называется green threads. В этом случае для JVM создаётся один или несколько системных потоков, а программные потоки с ними соотносятся. Переключение между потоками и работа с контекстом также выполняется JVM.
✅ эмуляции многопоточной среды там, где это не поддерживается ОС.
✅ быстрое переключение между потоками.
❌ нерациональное использование ресурсов в многопроцессорной среде. С точки зрения ОС задачи выполняются псевдопараллелльно, что ухудшает производительность.
Модель green threads устарела и считается неэффективной. Методы ручного управления потоками помечены @Deprecated начиная с Java 1.2.
Но идея переиспользования созданных ОС потоков сейчас в тренде. Java-библиотеки и некоторые версии JVM основаны на идее легковесных потоков. Fibers, coroutines, project Loom, Quasar, Kilim, Kotlin continuations – ключевые слова для дальнейшего углубления в тему.
#теория
👍6❤1🔥1
Паттерн Barrier, ч.1
Если для выполнения задачи нужно дождаться завершения других параллельных задач, то используется паттерн Barrier или барьерная синхронизация.
В нём есть 2 типа участников:
1️⃣ Исполнители — выполняют параллельные задачи и сигнализируют об окончании.
2️⃣ Наблюдатели — ждут завершения указанного количества задач.
В пакете java.util.concurrent этот паттерн реализуют 3 класса:
✅ CountDownLatch
✅ CyclicBarrier
✅ Phaser
В основе их реализации лежит счётчик. Каждый поток, который завершил задачу, уменьшает его значение. Барьер переходит в состояние "преодолён", когда счётчик достигает 0.
Посмотрим, как в них распределены роли:
✔️ CountDownLatch — чёткое разделение на исполнителей и наблюдателей. Потоки исполнителей уменьшают счётчик, затем могут продолжить работу или завершиться. Наблюдатели ждут преодоления барьера, затем выполняют свою задачу.
✔️ CyclicBarrier — роли исполнителей и наблюдателей совмещены. Поток завершает задачу, уменьшает счётчик и блокируется в ожидании остальных. Можно добавить действие, который выполнит последний поток перед тем, как барьер будет считаться преодолённым.
✔️ Phaser комбинирует функционал CountDownLatch и CyclicBarrier и допускает разные варианты использования. Исполнитель может ждать преодоления барьера, а может просто уменьшить счётчик и пойти дальше.
Это основная концептуальная разница между инструментами, которая определяет когда какой использовать. Больше технических аспектов рассмотрим в части 2.
#core
Если для выполнения задачи нужно дождаться завершения других параллельных задач, то используется паттерн Barrier или барьерная синхронизация.
В нём есть 2 типа участников:
1️⃣ Исполнители — выполняют параллельные задачи и сигнализируют об окончании.
2️⃣ Наблюдатели — ждут завершения указанного количества задач.
В пакете java.util.concurrent этот паттерн реализуют 3 класса:
✅ CountDownLatch
✅ CyclicBarrier
✅ Phaser
В основе их реализации лежит счётчик. Каждый поток, который завершил задачу, уменьшает его значение. Барьер переходит в состояние "преодолён", когда счётчик достигает 0.
Посмотрим, как в них распределены роли:
✔️ CountDownLatch — чёткое разделение на исполнителей и наблюдателей. Потоки исполнителей уменьшают счётчик, затем могут продолжить работу или завершиться. Наблюдатели ждут преодоления барьера, затем выполняют свою задачу.
✔️ CyclicBarrier — роли исполнителей и наблюдателей совмещены. Поток завершает задачу, уменьшает счётчик и блокируется в ожидании остальных. Можно добавить действие, который выполнит последний поток перед тем, как барьер будет считаться преодолённым.
✔️ Phaser комбинирует функционал CountDownLatch и CyclicBarrier и допускает разные варианты использования. Исполнитель может ждать преодоления барьера, а может просто уменьшить счётчик и пойти дальше.
Это основная концептуальная разница между инструментами, которая определяет когда какой использовать. Больше технических аспектов рассмотрим в части 2.
#core
❤3👍3🔥1
Паттерн Barrier, часть 2
В предыдущей части мы рассмотрели разные реализации паттерна Barrier в java.util.concurrent.
Посмотрим на отличия в использовании. Они касаются того
▪️когда ставится начальное значение счётчика,
▪️что происходит после преодоления барьера.
1️⃣ CountDownLatch
✔️ Счётчик задаётся при создании объекта.
✔️ Поток, который встал на await(), блокируется без возможности прерывания.
✔️ Когда значение счётчика достигает 0, наблюдатель продолжает работу, а сам объект CountDownLatch больше использовать нельзя, он одноразовый.
2️⃣ CyclicBarrier
✔️ Начальное значение счётчика тоже задаётся в конструкторе.
✔️ Поток, который дошёл до барьера, блокируется.
✔️ При преодолении барьера счётчик возвращается в исходное значение и готов снова собирать потоки. Количество циклов бесконечно.
3️⃣ Phaser. Каждый цикл называется фазой.
✔️ Начальное значение счётчика может меняться в каждой фазе.
✔️ Количество фаз по умолчанию бесконечно, но можно выставить ограничение с помощью функции onAdvance.
✔️ Ожидание наблюдателей может быть блокирующим или прерываемым.
Phaser включает в себя весь функционал CountDownLatch и CyclicBarrier. Он гибкий и помогает реализовывать сложные сценарии.
При выборе класса для реализации барьера, помните простую мудрость:
✴️ Если задача решается просто, нужно решать её просто.
#core
В предыдущей части мы рассмотрели разные реализации паттерна Barrier в java.util.concurrent.
Посмотрим на отличия в использовании. Они касаются того
▪️когда ставится начальное значение счётчика,
▪️что происходит после преодоления барьера.
1️⃣ CountDownLatch
✔️ Счётчик задаётся при создании объекта.
✔️ Поток, который встал на await(), блокируется без возможности прерывания.
✔️ Когда значение счётчика достигает 0, наблюдатель продолжает работу, а сам объект CountDownLatch больше использовать нельзя, он одноразовый.
2️⃣ CyclicBarrier
✔️ Начальное значение счётчика тоже задаётся в конструкторе.
✔️ Поток, который дошёл до барьера, блокируется.
✔️ При преодолении барьера счётчик возвращается в исходное значение и готов снова собирать потоки. Количество циклов бесконечно.
3️⃣ Phaser. Каждый цикл называется фазой.
✔️ Начальное значение счётчика может меняться в каждой фазе.
✔️ Количество фаз по умолчанию бесконечно, но можно выставить ограничение с помощью функции onAdvance.
✔️ Ожидание наблюдателей может быть блокирующим или прерываемым.
Phaser включает в себя весь функционал CountDownLatch и CyclicBarrier. Он гибкий и помогает реализовывать сложные сценарии.
При выборе класса для реализации барьера, помните простую мудрость:
✴️ Если задача решается просто, нужно решать её просто.
#core
❤2👍1
Как получать достойную зарплату
Вы на собеседовании. Отвечаете на вопросы, рассказываете о своём опыте. Проходит час, а может быть и два. Разговор подходит к концу и Вам задают вопрос:
- На какую зарплату рассчитываете?💰
Как получить максимальную выгоду и не напугать работодателя? Сделать несколько простых действий.
1️⃣ До собеседования:
▪️прибавить к текущей зарплате 15 тысяч. Это сумма, при которой смена работы имеет смысл.
▪️Посмотреть требования и зарплаты в вакансиях, где зарплаты указаны. Уровень оплаты труда и требования меняются каждые полгода, скорректируйте желаемую цифру с опорой на эти данные.
2️⃣ На собеседовании. Здесь есть два варианта:
🅰️ В вакансии указан диапазон зарплат.
Ваша сумма в неё попадает — всё супер.
▪️ Если на собеседовании Вы уверенно ответили на вопросы и впечатлили интервьюера опытом, то назовите цифру чуть больше планируемой. Не стесняйтесь, компании готовы платить за хорошего специалиста.
▪️ Если собеседование прошло так себе, называйте запланированную ранее сумму. Вы ничего не теряете, а может оказаться, что недовольны собеседованием только Вы.
🅱️ В вакансии зарплата не указана.
▪️ Оцените сложность вопросов и длительность интервью. Если оно длится больше часа, и вопросы сложнее обычного, то Вас рассматривают как перспективного кандидата. В таком случае называйте сумму чуть повыше.
▪️ Если интервью было обыкновенное, называйте запланированную цифру.
❗️Важно❗️
1️⃣ Низкая желаемая зарплата не даёт никакого преимущества. В первую очередь оцениваются профессиональные навыки.
Даже если Вы на собеседовании в компанию мечты, не демпингуйте. Лучше скажите эйчару и интервьюеру как сильно Вы хотите здесь работать, это повлияет на результат гораздо сильнее.
2️⃣ Зарплата до вычета налогов называется gross, после вычета — net. Прибавляйте «на руки» или net, когда называете цифру, это поможет избежать недоразумений.
Чтобы получить адекватную оплату труда, не поленитесь тщательно изучить рынок и его требования. Тогда работа будет не только доставлять удовольствие, но и позволит жить комфортно.
#собеседование
Вы на собеседовании. Отвечаете на вопросы, рассказываете о своём опыте. Проходит час, а может быть и два. Разговор подходит к концу и Вам задают вопрос:
- На какую зарплату рассчитываете?💰
Как получить максимальную выгоду и не напугать работодателя? Сделать несколько простых действий.
1️⃣ До собеседования:
▪️прибавить к текущей зарплате 15 тысяч. Это сумма, при которой смена работы имеет смысл.
▪️Посмотреть требования и зарплаты в вакансиях, где зарплаты указаны. Уровень оплаты труда и требования меняются каждые полгода, скорректируйте желаемую цифру с опорой на эти данные.
2️⃣ На собеседовании. Здесь есть два варианта:
🅰️ В вакансии указан диапазон зарплат.
Ваша сумма в неё попадает — всё супер.
▪️ Если на собеседовании Вы уверенно ответили на вопросы и впечатлили интервьюера опытом, то назовите цифру чуть больше планируемой. Не стесняйтесь, компании готовы платить за хорошего специалиста.
▪️ Если собеседование прошло так себе, называйте запланированную ранее сумму. Вы ничего не теряете, а может оказаться, что недовольны собеседованием только Вы.
🅱️ В вакансии зарплата не указана.
▪️ Оцените сложность вопросов и длительность интервью. Если оно длится больше часа, и вопросы сложнее обычного, то Вас рассматривают как перспективного кандидата. В таком случае называйте сумму чуть повыше.
▪️ Если интервью было обыкновенное, называйте запланированную цифру.
❗️Важно❗️
1️⃣ Низкая желаемая зарплата не даёт никакого преимущества. В первую очередь оцениваются профессиональные навыки.
Даже если Вы на собеседовании в компанию мечты, не демпингуйте. Лучше скажите эйчару и интервьюеру как сильно Вы хотите здесь работать, это повлияет на результат гораздо сильнее.
2️⃣ Зарплата до вычета налогов называется gross, после вычета — net. Прибавляйте «на руки» или net, когда называете цифру, это поможет избежать недоразумений.
Чтобы получить адекватную оплату труда, не поленитесь тщательно изучить рынок и его требования. Тогда работа будет не только доставлять удовольствие, но и позволит жить комфортно.
#собеседование
👍1🔥1