Так я и не расстраиваюсь, я обычно прохожу собеседование максимум за минут 30-40 этого вполне хватает, чтобы все все поняли. У меня есть прекрасная работа, а на собесы я хожу чтобы быть в тонусе. Поэтому ни малейший ноты расстройства. Из этого квеста ясно одно, в Тиньке сами не знают кого хотят найти и на какие деньги. Я же не все рассказал, о чем говорил с HR, так вот мой результат собеса был лучше ожидаемого, потому команд и не нашлось, потому что искали кандидатов слабей. Им и платить надо меньше, и работать они будут лучше, ведь им на собесе сказали что вы многое не знаете надо качать скиллы))) Но я правда хочу на го стек, джава уже в печенке. Да и сам я пишу на гошке, вот скоро запилю статейку про написание экспортера для VMware.
Вы категорически не правы, эти 5-10 минут начинаются не с пересказа резюме, а с момента когда респондент рассказывает о последнем опыте, реальном, а не то что сказано в документике, который моно почитать
Поделитесь ответом, очен интересно. Я же например отметил, что мне важно попасть именно в Go backend команду, так как в последнее время мне интересен процесс прокачки скиллов в этом направления и я сам пишу на Go поэтому к продакшен коду хотелось бы быть поближе, напоминаю у меня Java, ну и естественно не помирать под задачами. Вроде было что то еще, но "мы вам перезвоним" не последовало.
Ну вот когда я общался с конкретной командой то навыков найти в коде и как котенка потыкать как раз таки не было) Поэтому я у HR спрашивал нафига мы прогали, если это не надо. А вот тенденция к требованиям и пожары тушить, и на дудке играть, при этом плясать и в бубуен бить к сожалению не только у Тинька есть. Я не против таких скиллов, вопрос только в том, сколько конкретный подрядчик готов за них платить, и вот тут начинается самое интересное. Платить мы будем как джуну, по пятницам доширак за счет компании, но работать надо как сеньер и даже круче))) Встречал таких, увы.
Возможно первый раз ваше резюме смотрел подрядчик, к качеству их работы конечно есть претензии. Но ситуация конечно интересная. Хотя тут могла сработать ситуация на безрыбье и рак рыба, потому как денег могли предлагать мало а опыта хотелось много. тут только гадать.
С одной стороны вы полностью правы, но умение нагуглить решение и его адаптировать тоже важный навык, мы напомню делаем тестовое задание, за бесплатно, а не продакшен код за деньги пишем (хотя и тут бывают их гуглят). Насчет показать ход мыслей полностью поддерживаю, сам об этом говорю далее в свои мыслях и о том как провожу интервью я.
А вот если кандидат не способен за час интервью решить задачу про морской бой, у меня бы лично возникли сомнения, а можно ли такого кандидата вообще оценить выше уровня джуниор+
Если мы собеседуем сотрудника ТП, которому кодинг вообще не нужен, как мы тогда его оценивать будем? Если мы нанимаем разработчика то эта секция полезна, но будет ли полезна ему секция траблшутинга?
В том то и дело что никак) Но в целом прокачает навык решения задач на алгоритмы, тут вопрос другой а надо ли иметь этот навык DevOps или SRE инженеру, ведь по факту кода придется писать не так много, если вообще придется, и я сейчас не о коде CI/CD а скорей о разработке инструментов автоматизации.
Вопрос интересный, и если посмотреть мое мнение то я произношу те же мысли, что все эти этапы бесполезная история, исключение траблшутинг когда надо понимать что ты делаешь чтобы тушить пожар.
А вот таким кодом есть риск поломаться, если в хендлер придет нагрузка, вы конечно можете сказать ято это прекрасный вариант схлопнуть запросу, скажу что нет. Для этого используйте sync и SingleFlightGroup.
И это я глянул только 1 сервис, не смотря что там дальше, при этом я не го разработчик, а девопс. Но даже я на своем уровне знания код так не пишу, потому что он уж очень новичковый, и напоминает код который пишут ютуберы, которые пытаются учить гошке.
Если вы беретесь за то чтобы показать как надо, то делайте это правильно, представьте сколько не окрепших умов попытаются протащить такое в продакшен))) Ну и на последок, тащить gin ради 1 ручки, можно было бы взять чего попроще, родной http или fastHttp ну на крайняк mux, который вроде до сих пор в архиве.
У меня все, коллеги разработчики если что еще поправят.
для этого нужно попасть в сеть, более того ограничить мы можем ипом, а не целой подсетью, и сменить роль айди гораздо проще чем отзывать сертификаты и прочее.
Надеюсь вы понимаете почему так? Все дело в том, что у контейнеров в рамках пода разный chroot это значит, что контейнеры не видят файловую систему друг друга, и исполнять бинари из одного контейнера в другом мы физически не можем, но при этом мы можем использовать межпроцессное взаимодействие с помощью сигналов, что и реализовано в темплейте вольта.
вот лишь бы написать, я конечно понимаю что вы не внимательно читали, команда выполняется из контейнера с вольтом, там нет никакого nginx, ровно как и pkill, если смотреть манифест то там контейнерам разрешен shareProcessNamespace: true
это значит что один контейнер может видеть процессы другого в рамках пода, и все что мы можем сделать это взаимодействовать через сигналы, отправка сигнала HUP равна nginx -s reload, но вызвать его напрямую из контейнера с вольтом мы не можем.
Не разобравшись в теме, еще и минусят карму, вот зачем не понимаю?
Статья год в черновиках лежала, что то мог и сам упустить, а что то упрощено специально, чтобы каждый мог воспроизвести. Что собственно подтверждается двумя абзацами ранее:
Для дальнейшего конфигурирования данного метода авторизации можно использовать root token. Что само по себе не безопасно и не рекомендуется. Хорошей практикой является создавать отдельные учетные записи для каждого инженера или, например, включить авторизацию через LDAP.
Чтобы пользователь смог выполнять действия по дальнейшему конфигурированию, необходимо назначить для него следующую политику.
Естественно, что политики создают админы, и "create" как правило выдавать нужно не везде. Но мы даем разрешению пользователю с админискими правами.
не было задачи обидеть кого-то, гугл дока решила что правильно писать так, что я с ней спорить буду? у меня по русскому 2йка была в школе)))
Так я и не расстраиваюсь, я обычно прохожу собеседование максимум за минут 30-40 этого вполне хватает, чтобы все все поняли. У меня есть прекрасная работа, а на собесы я хожу чтобы быть в тонусе. Поэтому ни малейший ноты расстройства. Из этого квеста ясно одно, в Тиньке сами не знают кого хотят найти и на какие деньги. Я же не все рассказал, о чем говорил с HR, так вот мой результат собеса был лучше ожидаемого, потому команд и не нашлось, потому что искали кандидатов слабей. Им и платить надо меньше, и работать они будут лучше, ведь им на собесе сказали что вы многое не знаете надо качать скиллы))) Но я правда хочу на го стек, джава уже в печенке. Да и сам я пишу на гошке, вот скоро запилю статейку про написание экспортера для VMware.
Вы категорически не правы, эти 5-10 минут начинаются не с пересказа резюме, а с момента когда респондент рассказывает о последнем опыте, реальном, а не то что сказано в документике, который моно почитать
Поделитесь ответом, очен интересно. Я же например отметил, что мне важно попасть именно в Go backend команду, так как в последнее время мне интересен процесс прокачки скиллов в этом направления и я сам пишу на Go поэтому к продакшен коду хотелось бы быть поближе, напоминаю у меня Java, ну и естественно не помирать под задачами. Вроде было что то еще, но "мы вам перезвоним" не последовало.
Ну вот когда я общался с конкретной командой то навыков найти в коде и как котенка потыкать как раз таки не было) Поэтому я у HR спрашивал нафига мы прогали, если это не надо. А вот тенденция к требованиям и пожары тушить, и на дудке играть, при этом плясать и в бубуен бить к сожалению не только у Тинька есть. Я не против таких скиллов, вопрос только в том, сколько конкретный подрядчик готов за них платить, и вот тут начинается самое интересное. Платить мы будем как джуну, по пятницам доширак за счет компании, но работать надо как сеньер и даже круче))) Встречал таких, увы.
Возможно первый раз ваше резюме смотрел подрядчик, к качеству их работы конечно есть претензии. Но ситуация конечно интересная. Хотя тут могла сработать ситуация на безрыбье и рак рыба, потому как денег могли предлагать мало а опыта хотелось много. тут только гадать.
Так мы говорим о SRE
почему убрали и как оценивают: https://tellmeabout.tech/troubleshooting-interview-3690b40a3d77
как проходит интервью SRE: https://www.tinkoff.ru/career/it/interview/sre/?internal_source=profpage_sre
Сходите на собес узнаете, я намеренно не сообщаю ее, зачем? Иначе найдут решение и задачу сменят. Возможно на более сложную.
С одной стороны вы полностью правы, но умение нагуглить решение и его адаптировать тоже важный навык, мы напомню делаем тестовое задание, за бесплатно, а не продакшен код за деньги пишем (хотя и тут бывают их гуглят). Насчет показать ход мыслей полностью поддерживаю, сам об этом говорю далее в свои мыслях и о том как провожу интервью я.
Если мы собеседуем сотрудника ТП, которому кодинг вообще не нужен, как мы тогда его оценивать будем? Если мы нанимаем разработчика то эта секция полезна, но будет ли полезна ему секция траблшутинга?
Его давно исключили, это есть в материалах самого Тинькофф
В том то и дело что никак) Но в целом прокачает навык решения задач на алгоритмы, тут вопрос другой а надо ли иметь этот навык DevOps или SRE инженеру, ведь по факту кода придется писать не так много, если вообще придется, и я сейчас не о коде CI/CD а скорей о разработке инструментов автоматизации.
Вопрос интересный, и если посмотреть мое мнение то я произношу те же мысли, что все эти этапы бесполезная история, исключение траблшутинг когда надо понимать что ты делаешь чтобы тушить пожар.
это был сарказм))) зачем за это минусить? зачем вообще dos когда linux есть?
Вот и импортозамещеночка подтянулась, ща какой нить хитрый вендор форкнет, назовет условно Vendor-DOS и будет новая ОС для "Российских" ПК!
Я еще я заметил сразу не читая весь код целиком, что вы любите паниковать, тем самым нарушая один из принципов самого GO.
В таких местах лучше заменить на Fatal, а лучше вообще обработать ошибку.
А вот в этой горутине вы читаете из канала, при этом никак не обрабатывая дефолт, например на случай если канал уже закрыт.
А вот таким кодом есть риск поломаться, если в хендлер придет нагрузка, вы конечно можете сказать ято это прекрасный вариант схлопнуть запросу, скажу что нет. Для этого используйте sync и SingleFlightGroup.
И это я глянул только 1 сервис, не смотря что там дальше, при этом я не го разработчик, а девопс. Но даже я на своем уровне знания код так не пишу, потому что он уж очень новичковый, и напоминает код который пишут ютуберы, которые пытаются учить гошке.
Если вы беретесь за то чтобы показать как надо, то делайте это правильно, представьте сколько не окрепших умов попытаются протащить такое в продакшен))) Ну и на последок, тащить gin ради 1 ручки, можно было бы взять чего попроще, родной http или fastHttp ну на крайняк mux, который вроде до сих пор в архиве.
У меня все, коллеги разработчики если что еще поправят.
для этого нужно попасть в сеть, более того ограничить мы можем ипом, а не целой подсетью, и сменить роль айди гораздо проще чем отзывать сертификаты и прочее.
соглашусь, вариант хороший
Надеюсь вы понимаете почему так? Все дело в том, что у контейнеров в рамках пода разный chroot это значит, что контейнеры не видят файловую систему друг друга, и исполнять бинари из одного контейнера в другом мы физически не можем, но при этом мы можем использовать межпроцессное взаимодействие с помощью сигналов, что и реализовано в темплейте вольта.
вот лишь бы написать, я конечно понимаю что вы не внимательно читали, команда выполняется из контейнера с вольтом, там нет никакого nginx, ровно как и pkill, если смотреть манифест то там контейнерам разрешен
shareProcessNamespace: trueэто значит что один контейнер может видеть процессы другого в рамках пода, и все что мы можем сделать это взаимодействовать через сигналы, отправка сигнала HUP равна nginx -s reload, но вызвать его напрямую из контейнера с вольтом мы не можем.
Не разобравшись в теме, еще и минусят карму, вот зачем не понимаю?
Статья год в черновиках лежала, что то мог и сам упустить, а что то упрощено специально, чтобы каждый мог воспроизвести. Что собственно подтверждается двумя абзацами ранее:
Для дальнейшего конфигурирования данного метода авторизации можно использовать root token. Что само по себе не безопасно и не рекомендуется. Хорошей практикой является создавать отдельные учетные записи для каждого инженера или, например, включить авторизацию через LDAP.
Чтобы пользователь смог выполнять действия по дальнейшему конфигурированию, необходимо назначить для него следующую политику.
Естественно, что политики создают админы, и "create" как правило выдавать нужно не везде. Но мы даем разрешению пользователю с админискими правами.