По моим наблюдениям мужчины только рады когда в команду берут женщин. Особенно если они сильны технически.
Есть даже обратная дискриминация, когда в стремлении сбалансировать команду по половому признаку менеджеры изначально закладывают в вакансию требование чтобы QA/Support Enginner/PM была женщиной.
Или делают это неявно, отдавая предпочтение женским резюме. Неоднократно наблюдал это явление изнутри рекрутингового процесса. И то, и другое, по большому счету является нарушением трудового законодательства.
По з.п. скажу следующее. Те, кто не стремится к высокому уровню з.п. будут получать среднюю или ниже средней. Неважно, женщина или мужчина.
Знал одну джавистку, которая на то время получала раза в полтора больше медианной синьорской з.п. просто потому что умела высказать свои требования.
В данном примере минимальную поставили по одному конкретному параметру. Остальные в пределах нормы. А вообще — да, такое должно проверяться и фильтроваться. У Booking.com есть такая практика.
Открытый список проголосовавших на странице рейтинга компании — неоднозначная фича. С одной стороны видно использовались ли реальные аккаунты. С другой — в небольших компаниях могут бояться ставить низкую оценку, т.к. несложно вычислить. Это может быть одной из причин
Буквально только что наблюдал исключение из этого правила, когда из 5 человек 2 эйчара поставили максимальную оценку, а остальные 3 — минимальную. И лица всех героев красуются справа вместе со ссылками на их Линкедин аккаунты.
Ще хороший варіант з самостійною інфраструктурною командою, в якій крім опса є девелопер і QA. Тоді інші команди більш прогнозовано працюють над своїми задачами і не відволікаються на інфраструктурні активності. Планування відбувається простіше.
Проблема насправді не в поділі на команди, команди не створюють silo самі по собі, проблема в ізоляції ключових точок прийняття рішень, ієрархічності управління в класичних конторах і потоках ключової експертизи між різними командами.
Це правда. Але з моїх спостережень ефективніше працюється коли опси формально і реально розподілені між проектними командами і отримують задачі безпосередньо, ніж коли вони існують у власному світі (Operations team/ DevOps team), отримують задачі з загального пулу і пріоритизують на власний смак.
Site Reliability Engineer
За Гуглом багато західних контор почали використовувати цей тайтл, хоча він ще більш невідповідний ніж DevOps, тому що Site Reliability — це лише частина того чим вони займаються. Та і то не завжди.
Іпотека там приблизно на рівні орендної плати. Це штука євро вже, її теж десь треба взяти.
Частіше так і є.
Але я до того що це не привід відкидати аутсорс взагалі. Є хороші приклади аутсорсу і аутстафу, де ставлення як до штатного працівника, просто у віддаленій команді. І з можливостями впливати на продукт все ок.
Наявність де? Це так і так не ваш продукт. Різниця більше від адекватності менеджменту залежить.
В том чтобы ориентироваться не в ущерб основным обязанностям нет ничего плохого.
Мой изначальный коммент был о том что: ну узнал ты, к примеру, что твоя компания получила 5 млн. инвестиций — может она столько за месяц расходует, а может за год. Разница ведь огромная. Поэтому сам только размер инвестиций ничего обычному разработчику не скажет о компании.
Это не «хата скраю», а специализация и ответственность. Я поработал в разных конторах и могу сказать что наиболее эффективны те, в которых четко разделена ответственность, не важно аутсорс это или продукт. Если ответственности нету, начинается имитация бурной деятельности и вечные обсуждения радужных инвестиционных перспектив, что подозрительно напоминает разговоры обывателей о политике.
«Зачем это они рассказывают, сколько проект привлек инвестиций? Какая мне разница, сколько фаундеры положили в карман? Лучше скажите, какая зарплата», — так рассуждают некоторые девелоперы, и вот с ними нам не по пути.
Это взгляд владельца. Для инженера размер инвестиций действительно абстрактная информация, не больше: «О, 5 лямов дали — круто, фигачим дальше!». Инженер не знает расходов компании, он не знает остальных вложений. Ему нужно тратить свое время на изучение и отслеживание этого? Нет. Ему нужно вкладываться в качество продукта. Все.
Основою лояльності співробітника є збіг його життєвих цінностей та цінностей компанії, які він розуміє та в які вірить.
Можна приклади таких цінностей компанії?
Мій улюблений приклад, який часто наводжу. Інтерв’ю. Кандидат на кейсові питання відповідає, що дуже працелюбний та відповідальний. А на проективне питання, чому люди якісно працюють, відповідає, що «їх змушують обставини, зокрема лід все перевіряє, а менеджер метрики аналізує».
Ви відхиляєте кандидата в таких випадках? Чи допускаєте варіант що сам він насправді «працелюбний та відповідальний», а на питання про мотивацію інших людей він висловлює не проекцію, а власні спостереження.
Ну хз, если учесть что говорящие эти фразы поверженными в трепет не выглядят, а в лучшем случае имитируют восхищение, то я бы переводил как «впечатляюще» или «восхитительно», если речь о чем-то хорошем. Плюс к этому, на русском никто не говорит о благоговении и повержении в трепет от вида платья, так что подобный перевод будет повергать читателя или слушателя в нечто другое — в недоумение, скорее всего.
Религиозные параллели продолжают прослеживаться)
Слишком буквально. Производные от слов не всегда сохраняют тот же смысл и эмоциональный оттенок
«You look totally awesome in that dress» © Cambridge dictionary
«Ты в этом платье внушаешь благоговение»?
Ты выше уже сам написал — благоговение. Если ты к тому чтобы переводить awesome так же буквально, то это не совсем верно. Это слово теряет эмоциональную силу и тянет лишь на «впечатляющий». Можно запросто сказать «this gadget is awesome» — но никакого благоговения гаджеты никому не внушают.
Носить на работу в таком рюкзаке s.mediasole.ru/...6333102668380995667_o.jpg
Если оставлять возле раб.места, можно не лочить экран.