Откуда вы взяли 18% для Германии? Я в который раз пытаюсь вам намекнуть, что в Германии прогрессивная система не такая же, как в Польше или еще где, и уплата налога там не разбивается по налоговым порогам — с такой-то суммы я заплачу столько-то, а с остатка больше.
Вы становитесь контрактором, самозанятым. Формально, сотрудником фирмы вы больше не являетесь, соотв. на вас не распространяются законы о защите наемных сотрудников — уволить могут тут же, сами разбираетесь со страховками, никаких «отпускных» и т.д. Но это позволяет больше зарабатывать, т.к. работодатель не платит за вас налоги (для него это вообще расходы, потому он может оптимизировать их таким путем), а вы платите тот же «подоходный», но со значительно большего брутто. Как-то так.
А я и не налоговые ставки складывал. А если я сильно переплатил, так возврат налогов работает — после подачи декларации налоговая пересчитает сама и вернет «надплату», если таковая была.
Я хотел от комментатора выше калькуляций зп для Германии, разбитой по налоговым порогам, как он думает это считается. В случае Польши, где работает система разбивки дохода по порогам, ваш пример верен. Хотелось бы тоже самое увидеть для Германии.
Божечки, какой срыв покровов. Для Польши два порога, в которые попадают айтишники, это 18 и 32 процента. Со средней зп для сеньера на здешнем рынке в 3500$ это примерно дает 24-25%, которыми пользуются для быстрой оценки того, сколько заработаешь.
Тогда я попрошу практика рассчитать по налоговым порогам зп женатого разработчика с условными 85k евро брутто в год в Германии, в Берлине, например. Желательно, со ссылками на соотв. документы.
>Другое дело что для того чтобы перейти на частную страховку надо иметь определённую минимальную зарплату.
А потом сравнить с калькулятором цифры. Я ж не спорю, что может быть по-разному, но знаю примеры, когда соотношения получаемой зп к планируемому повышению было не совсем оптимальным, скажем так.
24% я вам привел как примерный аккумулированный процент от части зп по 18% и 32%. Прирост оно дает, в том числе и довольно ощутимый для работодателя, для которого рост вашей зп на 10% не означает роста его расходов на 10%. Везде, где я знаю, системы разные, даже в пределах EU. Пример — Польша и Германия. По Германии еще больным моментом является мед. страховка, которая может оплачиваться 100% работодателем, а может только половина, а может и ничего в зависимости от порога годовой зп, а она дорогая, эта страховка. И есть случаи, при которых выгоднее остаться с меньшей зп но частичной страховкой, чем с повышенной зп, но уже без оплаты страховки работодателем.
Смотрите, предположим, зп составляла 2000 у.е. при налоговой ставке 18%, для простоты будем считать, что на руки сотрудник получает 1640 у.о. Ему повысили зп на ~10% до 2200 у.о., но он уже переходит в следующий налоговый диапазон и налог составит уже 24%, соотв. от 2200 останется 1672 у.о. при увеличении налоговой нагрузки и на работодателя. Бывают варианты, когда при повышении зп и переходе на другой налог зп вообще уменьшается. Чтобы повышение было ощутимым для работника, его надо делать на значительную сумму, что уже сильно может сказаться на бюджете работодателя. Как-то так.
Ваш ответ никак не противоречит тому, что сказал я. Выступление на конфах поддерживает бизнес, создавая некие ценности для него. Да, это ситуация win-win, но причина все же в том, что это хорошо для бизнеса, а не для вас (как спикера, я имею в виду) лично.
Если вы хотите получать больше, то одна из самых частых опций — переход на B2B контракт, т.к. сумма налогов ваших + работодателя будет слишком большая для того, чтобы рассматривать грейд всерьез. Грубо говоря, есть бюджет на команду, предположим, и чтобы повысить зп и не выйти за бюджет — переход на B2B, т.к. он позволяет налоги оптимизировать. Ну а дальше, думаю, все понятно.
PS. За весь EU не могу говорить, но в Польше и Германии такое практикуется.
3000$ за джуна в Европе? Очень интересно было бы послушать, о каком конкретно джуне и какой конкретно стране идет речь, ибо медиана зп по EU колеблется от 40k до 50k в год, и сильно зависит от страны, технологии и квалификации. Ну и конечно же, зарплаты чаще всего указываются ДО выплаты налогов, а это может быть около 25-30%, например, а иногда и выше. А еще прогрессивный налог, так что иногда повышать ЗП банально не выгодно.
В остальном я не вижу сильных отличий от «там» и «тут». Проблемы с менеджментом, кадрами, рабочей техникой и т.п. Да, есть культурные отличия, которые не позволят конфликту стать открытым – к примеру, с криками в переговорке. Но хорошо это или нет – я уже затрудняюсь сказать.
Последний абзац вообще какая-то миллениальская наивная чушь, уж простите – наемные сотрудники, которые возомнили себя невесть кем. Программистов нанимают помогать зарабатывать деньги компании, а не для саморазвития и партнерских отношений. Если вы «делитесь опытом» на конференциях вместо помощи бизнесу — вас уволят, тут же. Выглядит это так — к вам приходит менеджер, зовет в переговорку, показывает бумагу и ровно с этого момента вы уже безработный. «Отсюда» эти отношения гораздо лучше видны и сильнее ощущаются, не смотря на ореол «заботы». Мне кажется, что большинство путают заботу об эффективности работы сотрудника с заботой о самом сотруднике — это разные вещи.
А чтобы знать себе цену — ходите на собеседования, регулярно, даже если не намерены работу менять.
Http де-факто, как самый популярный транспорт. В стандарте ничего специфичного для него нет, да и разработчики заявляли, что GraphQL is protocol agnostic.
А вы знаете в чем проблема «одного единого стандарта»? Ну и да, странно звучит, вот ребята используют какой-то sdl, а в стандарте его нет. GraphQL это тоже идея, все-таки. А структуру все все равно будут делать по своему.
sdl это какой-то инструмент сбоку для описания схемы, у меня в Эликсире там тоже свой дсл, но для клиента это будет тот же самый GraphQL, по стандарту. Это не идея, можно пойти и скачать спецификацию. Спецификации REST в природе не существует.
Посмотрите на проблему с точки зрения клиента, в особенности – мобильного, на слабом канале, когда очень желательно получать минимум требуемых данных, без лишнего «мусора». Отсюда и «шейпинг» возвращаемых данных клиентом при запросе. В случае решения а-ля REST (т.к. это уже ни разу не REST, а JSON RPC какой-то) приходится или плодить кучу эндпоинтов на каждый чих, либо снабжать ресурс кучей get-параметров, определяющих результат, что, по-факту, и есть переизобретение GraphQL. Да, можно сказать, что возможные запросы предопределены, но в зависимости от набора полей в запросе, нормальный бекенд будет делать разные запросы в хранилище. Банальный пример – не делать лишний запрос или join для вложенной коллекции модели, если ее не просили.
А потом сравнить с калькулятором цифры. Я ж не спорю, что может быть по-разному, но знаю примеры, когда соотношения получаемой зп к планируемому повышению было не совсем оптимальным, скажем так.
goaleurope.com/2016/10/26/software-developer-salary-europe-survey-results-2016
www.daxx.com/article/it-salaries-software-developer-trends-2018
www.oreilly.com/ideas/2016-european-software-development-salary-survey
PS. За весь EU не могу говорить, но в Польше и Германии такое практикуется.
В остальном я не вижу сильных отличий от «там» и «тут». Проблемы с менеджментом, кадрами, рабочей техникой и т.п. Да, есть культурные отличия, которые не позволят конфликту стать открытым – к примеру, с криками в переговорке. Но хорошо это или нет – я уже затрудняюсь сказать.
Последний абзац вообще какая-то миллениальская наивная чушь, уж простите – наемные сотрудники, которые возомнили себя невесть кем. Программистов нанимают помогать зарабатывать деньги компании, а не для саморазвития и партнерских отношений. Если вы «делитесь опытом» на конференциях вместо помощи бизнесу — вас уволят, тут же. Выглядит это так — к вам приходит менеджер, зовет в переговорку, показывает бумагу и ровно с этого момента вы уже безработный. «Отсюда» эти отношения гораздо лучше видны и сильнее ощущаются, не смотря на ореол «заботы». Мне кажется, что большинство путают заботу об эффективности работы сотрудника с заботой о самом сотруднике — это разные вещи.
А чтобы знать себе цену — ходите на собеседования, регулярно, даже если не намерены работу менять.
sdl это какой-то инструмент сбоку для описания схемы, у меня в Эликсире там тоже свой дсл, но для клиента это будет тот же самый GraphQL, по стандарту. Это не идея, можно пойти и скачать спецификацию. Спецификации REST в природе не существует.