Честно говоря, не готов подсказать готовое решение, которое было бы оптимально для Вашего случая, так как мне неизвестны требования, текущая и планируемая нагрузка и состав самих данных.
На заре своей карьеры я отработал несколько месяцев в библиотеке, поддерживая работу простенького Window NT-домена с парой десяткой станций и софта. Деньги там плевые платили, но зато поиграться с технологиями было можно. Так что ищущий найдет возможности.
Для джунов - вполне хороший шанс начать даже с такой работы, по пути набирая опыт и играясь с технологиями. Там можно поиграться с тем, что не доверят в обычных частных компаниях и наработать резюме. Все лучше, чем тому же Скиллбоксу платить за обучение.
В этом случае первый джун у вас не 0,5 ментора съест, а парочку специалистов и не подавится.
Никакой нормальный менеджер не разрешит нанять джуна, который съест время двух спецов. Разные, конечно есть, но мы же про адекватных говорим сейчас, а не про пограничные случаи?
А часто живые проекты не столь хорошо приспособлены для выращивания джунов.
Я писал по своему опыту, и он говорит, что джуны вполне полезны в устоявшихся конторах, где разработчиков более 5. А если в конторе полтора вялых землекопа, то еще один джун несильно повлияет на ситуацию.
Был один сильный сотрудник — наняли джуна — вместе их стало 0,5.
Ну это может у вас в Holyweb так? Никто не будет тратить половину времени сеньора на какого-то там джуна - не такая уж это и важная птица. Реально это будет процентов 10 времени максимум, ведь сеньору никто не будет делать поблажки, а джун будет делать простые или рутинные вещи, которые самому сеньору не интересны и подходят джуну по уровню.
Дабы не зависнуть в этом статусе на многие годы, стоит сделать следующее:
1. Определиться со стеком
Бесполезный совет, а где-то даже и вредный. Джуну надо изучать то, на что сейчас есть спрос и на что берут даже джунов. Тогда его опыт позже будет востребован. Например, сейчас есть огромный спрос на блокчейн-спецов и джун через полгода-год будет вполне востребован и доволен по деньгам.
Поддерживаю. Это весьма полезно по многим причинам. Иногда попадают весьма интересные собеседующие, которые и про стэк расскажут и про инфраструктуру свою, а всегда интересно, на чем в известных компаниях пишут/строят. Ну и конечно можно вполне получить интересные предложения, а там уже и к своему руководству с офером прийти, показать, попросить надбавку.
Каких либо четких признаков нет, но обычно у хороших сеньоров резюме по возрастающей и должности - только технические, образование можно не смотреть совсем, хотя профильные бауманка или ЛИТМО дадут небольшой плюс, конечно же.
Например - начал с уровня техподдержки, пока учился в универе, потом - пару лет джуниором в одном месте, потом пару лет миддлом в другом, потом сеньором. В описаниях, чем занимался - тоже по возрастающей сложности. Когда сеньорские должности уже - то там "Разработал с нуля". Есть опыт тимлидства - тоже плюсик. Работал в стартапах - еще плюсик.
Вообще резюме бывают и совсем необычно оформленные, но опытный глаз способен выцепить нужное, а в разговоре уже подтвердить или опровергнуть предположения.
Я даже специально статью написал про тестовые задания ). С уровня Middle+ тестовое задание - это просто трата времени и ничего не говорит про уровень именно разработки, а не написания кода. У сеньора время непосредственно на написание кода уходит 20-30% в среднем, остальное это - сбор требований, планирование архитектуры, взаимодействие с другими членами команды и обсуждение подходов, поиск ошибок, дебаггинг.
Зачем я буду давать тестовое на 3 часа, если человек уже делал гораздо более сложные вещи, может показать какой-то код и обсудить его плюсы-минусы?
Я Вам в качестве примера могу привести Тинькофский NPM-модуль для работы с их API. При том, что сам код написан вполне неплохо и наверняка разработчик у Тинькофф считается сеньором минимум, он имеет массу недоработок, что говорит об отсутствии опыта у разработчика. Один из основных, базовых недостатков - разработчик забыл про таймауты. Или вообще не знал. А это базовые знания для разработки сетевого ПО вобщем и API SDK в частности. Поэтому я совсем не удивлен, что вся их платформа постоянно глючит и народ воет от багов.
Я лично провел не одну сотню собесов, могу сказать, что автор прав для уровня хороший Middle+. Какой смысл спрашивать джуниорские вопросы у сеньора про классы - меня это до сих пор удивляет. На 90% сеньор виден из резюме, подтверждается это обычно первыми 5 минутами разговора. Всегда надо помнить - человек берется для решения конкретных задач, а не как советник по документации Java.
Я вот тимлид, вырастил команду с 4 до 16 человек, проект высоконагруженный, 2млн запросов в час, 24/7.
Вы, конечно, извините, но это Ваше представление ровным счетом ни о чем не говорит. Нанять 12 человек - да проще простого. 2млн запросов в час - тоже не говорит ни о чем, каких запросов, куда? 24/7 - ну это вообще само собой подразумевается, в 2021-м году-то.
Надо представляться примерно так: Собеседовал 500, нанял 100, сделали google.com и amazon.com, а в свободное время запускаем ракеты к Марсу.
Ваши сомнения на самом деле не имеют должного обоснования. Человек мог в минуту подзабыть все, что знал из-за стресса или банально не помнить что-то. Если человек технически грамотный и с правильным подходом - он решит эту задачу в спокойном рабочем порядке, сделав небольшой research. Умение найти решение проблемы гораздо важнее непосредственно знаний!
Такие парни действительно есть, но раз его не увольняют - то это проблема его непосредственного начальника, который не может организовать эффективную работу.
Обычно собеседующий (технический) хочет узнать то, что он сам хорошо знает. А так как уровень обычно невысок и знания фрагментарны - то и получается, что собеседующий занимается чем угодно, но не оценкой тех. уровня кандидата.
У этих тоже крестик слева в macOs.
Честно говоря, не готов подсказать готовое решение, которое было бы оптимально для Вашего случая, так как мне неизвестны требования, текущая и планируемая нагрузка и состав самих данных.
Не очень понял Ваш пассаж про "много данных", почему Вы считаете, что репликация не будет работать, если данных много?
Данная репликация как раз и предусматривает тот случай, что у автора - два кластера с ненадежным соединением между ними.
Судя по тому, что автор не совсем понимает, как ES-кластер работает он и изобретает какие-то лютые велосипеды. А по сути все уже придумано до наc:
https://www.elastic.co/guide/en/elasticsearch/reference/current/xpack-ccr.html
На заре своей карьеры я отработал несколько месяцев в библиотеке, поддерживая работу простенького Window NT-домена с парой десяткой станций и софта. Деньги там плевые платили, но зато поиграться с технологиями было можно. Так что ищущий найдет возможности.
Для джунов - вполне хороший шанс начать даже с такой работы, по пути набирая опыт и играясь с технологиями. Там можно поиграться с тем, что не доверят в обычных частных компаниях и наработать резюме. Все лучше, чем тому же Скиллбоксу платить за обучение.
Никакой нормальный менеджер не разрешит нанять джуна, который съест время двух спецов. Разные, конечно есть, но мы же про адекватных говорим сейчас, а не про пограничные случаи?
Я писал по своему опыту, и он говорит, что джуны вполне полезны в устоявшихся конторах, где разработчиков более 5. А если в конторе полтора вялых землекопа, то еще один джун несильно повлияет на ситуацию.
Автор как-то довольно далек от работы с джунами.
Ну это может у вас в Holyweb так? Никто не будет тратить половину времени сеньора на какого-то там джуна - не такая уж это и важная птица. Реально это будет процентов 10 времени максимум, ведь сеньору никто не будет делать поблажки, а джун будет делать простые или рутинные вещи, которые самому сеньору не интересны и подходят джуну по уровню.
Бесполезный совет, а где-то даже и вредный. Джуну надо изучать то, на что сейчас есть спрос и на что берут даже джунов. Тогда его опыт позже будет востребован. Например, сейчас есть огромный спрос на блокчейн-спецов и джун через полгода-год будет вполне востребован и доволен по деньгам.
Поддерживаю. Это весьма полезно по многим причинам. Иногда попадают весьма интересные собеседующие, которые и про стэк расскажут и про инфраструктуру свою, а всегда интересно, на чем в известных компаниях пишут/строят. Ну и конечно можно вполне получить интересные предложения, а там уже и к своему руководству с офером прийти, показать, попросить надбавку.
Ниже ответил
Каких либо четких признаков нет, но обычно у хороших сеньоров резюме по возрастающей и должности - только технические, образование можно не смотреть совсем, хотя профильные бауманка или ЛИТМО дадут небольшой плюс, конечно же.
Например - начал с уровня техподдержки, пока учился в универе, потом - пару лет джуниором в одном месте, потом пару лет миддлом в другом, потом сеньором. В описаниях, чем занимался - тоже по возрастающей сложности. Когда сеньорские должности уже - то там "Разработал с нуля". Есть опыт тимлидства - тоже плюсик. Работал в стартапах - еще плюсик.
Вообще резюме бывают и совсем необычно оформленные, но опытный глаз способен выцепить нужное, а в разговоре уже подтвердить или опровергнуть предположения.
Я даже специально статью написал про тестовые задания ). С уровня Middle+ тестовое задание - это просто трата времени и ничего не говорит про уровень именно разработки, а не написания кода. У сеньора время непосредственно на написание кода уходит 20-30% в среднем, остальное это - сбор требований, планирование архитектуры, взаимодействие с другими членами команды и обсуждение подходов, поиск ошибок, дебаггинг.
Зачем я буду давать тестовое на 3 часа, если человек уже делал гораздо более сложные вещи, может показать какой-то код и обсудить его плюсы-минусы?
Я Вам в качестве примера могу привести Тинькофский NPM-модуль для работы с их API. При том, что сам код написан вполне неплохо и наверняка разработчик у Тинькофф считается сеньором минимум, он имеет массу недоработок, что говорит об отсутствии опыта у разработчика. Один из основных, базовых недостатков - разработчик забыл про таймауты. Или вообще не знал. А это базовые знания для разработки сетевого ПО вобщем и API SDK в частности. Поэтому я совсем не удивлен, что вся их платформа постоянно глючит и народ воет от багов.
Уровень в разработке на самом деле мало кореллирует с количеством лет, отданных IT. И смотреть в резюме надо не на количество лет.
Смешно. А если он погуглил за минуту и уже знает отличия, он за минуту стал хорошим?
10К запросов - тоже ни о чем. Мы же не знаем, сколько на бэке серверов обслуживает. Если их там 1000 - то это всего 10 запросов в секунду.
Я лично провел не одну сотню собесов, могу сказать, что автор прав для уровня хороший Middle+. Какой смысл спрашивать джуниорские вопросы у сеньора про классы - меня это до сих пор удивляет. На 90% сеньор виден из резюме, подтверждается это обычно первыми 5 минутами разговора. Всегда надо помнить - человек берется для решения конкретных задач, а не как советник по документации Java.
Вы, конечно, извините, но это Ваше представление ровным счетом ни о чем не говорит. Нанять 12 человек - да проще простого. 2млн запросов в час - тоже не говорит ни о чем, каких запросов, куда? 24/7 - ну это вообще само собой подразумевается, в 2021-м году-то.
Надо представляться примерно так:
Собеседовал 500, нанял 100, сделали google.com и amazon.com, а в свободное время запускаем ракеты к Марсу.
Ваши сомнения на самом деле не имеют должного обоснования. Человек мог в минуту подзабыть все, что знал из-за стресса или банально не помнить что-то. Если человек технически грамотный и с правильным подходом - он решит эту задачу в спокойном рабочем порядке, сделав небольшой research. Умение найти решение проблемы гораздо важнее непосредственно знаний!
Такие парни действительно есть, но раз его не увольняют - то это проблема его непосредственного начальника, который не может организовать эффективную работу.
Обычно собеседующий (технический) хочет узнать то, что он сам хорошо знает. А так как уровень обычно невысок и знания фрагментарны - то и получается, что собеседующий занимается чем угодно, но не оценкой тех. уровня кандидата.