за пределами столиц как было очко, так и осталось. какой там уровень подрос в условном Канске или Ангарске? или за пределами столиц - это сразу за МКАДом?
про золотой век - мощно сказано. можете оценить его величие на заводе - через пару месяцев ваш слух начнет вас покидать, даже если будете ходить в берушах всё время, а ночные смены тоже заметно отразятся на общем состоянии и психике. или прочувствовать, как горят стопы после 3 дней подряд проведенных на ногах по 12 часов, работая в супермаркете. или можете заценить, как лопается кожа на руках от бесконечных коробок по 25 кг каждая. много в современном мире разного - когда садитесь утром в уютное кресло с кофейком, имейте в виду - вам просто везет... пока)
Есть опция MTU ignore при настройке роутеров многих вендоров - она отключает согласование MTU между соседями, соответственно некоторым кажется, что это отличное решение. На деле это создает проблемы, когда уже после настройки OSPF в один конечный роутер навтыкают сетей и router LSA превысят MTU - да, начнет расти счетчик отброшенных пакетов, но это не так заметно на больших сетях, где всё время что-то отбрасывается. Или еще хуже - сети поднимали по-очереди, поэтому LSU пролезали в MTU, а потом что-то сбойнуло, и они упали одновременно, но LSU уже в окно MTU не пролез - как результат, рассинхронизация LSDB при поднятом в FULL соседстве. Если же выключить MTU ignore, то один из роутеров начнет посылать вполне конкретные сообщения в логи, что не может согласовать MTU (кстати, это не единственная причина, почему соседи не могут подняться до FULL, так что правильный ответ на вопрос интервьюера был бы "надо посмотреть в логи - там 90% указана причина или 10% указаны последствия причины")
Про фрагментацию - да, она работает, но она жрет ресурсы роутера и увеличивает количество пакетов, а в момент поднятия большого фрагмента сети там и так несколько секунд идет шторм из анонсов разных, так что не рекомендую на нее делать ставку
Еще можно было бы проверять MTU на маршруте специальными сообщениями ICMP, но большинство провайдеров душат весь ICMP траффик (кроме пинга) чисто на всякий случай
Тлдр: чтобы детишки больше не могли ударить себя граблями по лбу, в новом стандарте все грабли будут разобраны на части.
Собсна, мой главный вопрос - в коде
int a;
int * a_ptr = &a;
printf("%d", *a_ptr);
будет какое поведение?
Если возникнет ошибка или выведется заготовленное плохое значение, значит компилятор собрал программу, которая потратила ресурсы на инициализацию переменной, о чем разраб не просил.
Иначе - это новое ограничение языка, выдающееся как фича нового стандарта, работает лишь в некоторых случаях и обходится одной дополнительной строкой.
деньги платят за работу. т.е. что успел с перерывами на обед и перекур сделать в спокойном темпе - то и сделал. а ковыряние в коде до часа ночи или работа без выходных и с минимальными перерывами на перекус в режиме экстренного допиливания - это уже опция, о которой надо договариваться
Лишний раз убеждаюсь, что живу с некоторыми комментаторами на разных планетах. Странно сравнивать мечтательный поиск той самой идеальной работы и стремление выжить. Интереснее всего - развивать свой бизнес за папины деньги, но это дано очень малому числу людей. Остальным приходится зарабатывать на свою жизнь. И тут обычно выбор между тем, что тебе не нравится, и тем, что очень не нравится.
Спасибо, что открыли глаза на важные для резюме вещи! Я как-то не допустил драки двух коллег. Пройдемся методом стар:
Ситьюэйшн - два злых программиста зацепились на ровном месте.
Таск - мне надо было ковырять мои задачки, а их ругань меня отвлекала. Ну и мое место было рядом - могли нечаянно зацепить. Возникла задача прекратить их конфликт.
Экшн - я сказал им, чтоб х..йней не маялись и чо ваще?
Резалт - выяснилось, что в основе конфликта лежит плохое физическое состояние обоих в следствии бесконтрольного употребления алкоголя накануне. На этом конфликт был исчерпан.
Вот, релевантный опыт для тимлида, побежал включать в свое резюме вместо скучных технических данных. Еще раз спасибо за ценный совет!
Ходят слухи, что нормальный HR может пробежаться по отделам и договориться, чтоб сотрудника перевели к другому начальнику, если сам сотрудник не совсем деревянный. Я даже целый один раз такое видел. В большинстве же случаев, конечно, HR выполняет роль надувной куклы эстетическую, так что каких-то осознанных телодвижений по решению проблем от них ждать не стоит. Ну, может кофе принести
"крутой спец", "классный проект" - меня одного смущают такие формулировки у ичаров? будто постоянно под кокаином. работа программиста, как и любая другая работа - это набор задач, которые нужно выполнить с определенным качеством и в определенный срок. это не про приколы и веселье - это про ответственность и настойчивость. про ковыряние, когда кажется, что уже всё перепробовал. про допиливание до 3х часов ночи, если завтра дэдлайн. про коммуникацию с другими специалистами, которые тоже выполняют свою работу. а у ичаров постоянно какой-то бесконечный трип
Надеялся, что по фразе "за пять минут с гуглом написал" понятно, что я имел в виду сложность с синтаксисом, а не с примерным пониманием. Ну и само понятие "обертка" предполагает, что логика остается неизменной, а значит примерное понимание один хрен присутствует
Про кандидата выше уровнем, чем интервьюер. Чтоб понять, что кандидат ответил на вопрос более глубоко, чем его понимает интервьюер, необходимо, чтобы интервьюер усмирил свое ЧСВ и захотел вникнуть в то, что ему говорят. В 100% интервью, где меня собеседовали, этого не произошло, хотя я потом перепроверил свои ответы и оказался прав. Ты можешь быть бесконечно прав, но какой в этом толк, если интервьюер ебл... уеб... уверен в обратном.
Про неадекватность. Иногда в жизни случается жопа и приходится идти туда, куда берут. Иногда это оказывается завод со сменами по 12 часов и зп, которой хватает, чтоб иногда поесть. Когда ты в таком режиме работаешь несколько месяцев, а потом вдруг приезжаешь на собес в хайтек айти мега корпорэйшн, то довольно трудно вести себя позитивно и доброжелательно. К сожалению, часто это воспринимается как пассивная агрессия, отсутствие вовлеченности, заряженности и вот это вот всё. Когда потом получаешь отказ, а за пропущенный день из твоей зп на заводе уже вычли, это тоже не добавляет радости. (Лайфхак для тех, кто сейчас в такой ситуации - можно ездить на собесы после ночной смены. Лучше невыспавшимся проходить интервью, чем сидеть потом без денег).
Про списывание. Опыт у всех разный. Не всегда его можно сравнить однозначно "больше-меньше". Поэтому часто возникают ситуации "то, чего ты еще не знаешь, я уже забыл". Спрашивают какую-то хрень, которой ты не пользовался последние лет пять, потому что в твоем проекте эти стандартные функции обернуты в три слоя для удобства конкретно в этом проекте - ну всё, наврал в резюме, к гадалке не ходи! Доблестный техлид вычислил самозванца, браво! А то, что ты за пять минут с гуглом всё бы написал - это уже никого не волнует.
З.ы. Предугадывая вопрос "А ты бы как собеседовал?" - я бы предлагал конкретные кейсы из проекта и спрашивал, как кандидат будет их решать. Как будет локализовать баг? На что обратит внимание при реализации фичи? Главное - без решения на листочке за ограниченное время шизанутых задачек с литкода, которые относятся к реальной разработке, как бальные танцы к тяжелой атлетике.
З.з.ы. Спасибо за картинку - сохранил для важных переговоров! Всем добра и счастья!
Докер - контейнер. Нужен, чтобы не перенастраивать переменные окружения под сборку каждого проекта, например. Виртуальная машина на минималках.
Три предложения - и джун в ваших глазах превращается... превращается... ну хотя бы в мидла. А если ему рассказать про кросскомпиляцию - это еще два предложения - то там и до сеньора не далеко)
Вроде, для таких ситуаций скрам и придумали. Раз в день каждый говорит, что сделал, что делает, как и в чём в данный момент затык, если он есть. Либо проблема решается тут же на скраме мудрым советом старших товарищей, либо можно подойти к сотруднику и позже подробно разобрать, что он там наворотил. Просто ответы 'делаю задачу, всё хорошо' не принимать и расспрашивать, что конкретно делает и что конкретно хорошо
Ну вот был у нас такой модуль, который такие синьоры писали. Всё очень красиво, очень структурировано, с кучей ассертов, чтоб не дай боже чего-нибудь куда-нибудь не туда не пошло. Прилетела задача в этом модуле поправить поведение. В итоге пришлось несколько дней штудировать доку, чтоб понять, что решение может быть только временным, т.к. очень умные сеньоры, которые всё это писали, почему-то не подумали об ограниченности ресурсов, с которым мы столкнулись в рамках этой задачи. Но переделка этого модуля потребовала бы отдать на это дело сеньора как минимум на месяц.
Ну и еще байка туда же - другой был модуль, в котором всё было очень запутано, многие ветераны даж говорили, что туда заходить боятся, т.к. там сам черт ногу сломит. А вылезла задача, т.к. у кого-то где-то там что-то ломалось - и железка падала примерно раз в месяц (а должна работать непрерывно годы). Ну и я начал там разгребать весь этот перемудрёный код, нашел много потенциально опасных операций с данными - и выпросил у начальника разрешения всё это переписать. Переработал структуры, хранившие данные, написал промежуточные функции для работы с ними, переписал функции верхних уровней, которые в старом коде дёргали данные напрямую без каких-либо проверок. Проблемы решились, код стал компактней, ресурсы высвободились, хоть это и не ставилось как цель, но разработка и отладка этого заняла больше ГОДА с перерывами на другие задачи.
Это я к тому, что после этого сформулировал свой критерий оценки качества кода, из-за которого у меня перманентное недопонимание с нынешним поколением тимлидов - код должен быть настолько простым и понятным, насколько это возможно для решения задачи, которую он выполняет
Почему-то многие сейчас считают, что сеньоры всё наусложняют - и это нормально. Когда я учился программировать, умные книжки читал и потом общался с коллегами (лет 5 назад), то наоборот считалось, что более квалифицированный прогер напишет более простой, эффективный и понятный каждому код, а сложный и непонятный код пишет мудила-понторез, который вместо работы занят самоутверждением. Видимо, теперь эти понторезы продвинулись в тимлиды
я, собственно, про это и говорил - Можайск и Тула - практически Москва, Ангарск и Канск - Сибирь
за пределами столиц как было очко, так и осталось. какой там уровень подрос в условном Канске или Ангарске? или за пределами столиц - это сразу за МКАДом?
хз про 20, но 17 лет назад был лучший год в истории человечества - 2007 XD
про золотой век - мощно сказано. можете оценить его величие на заводе - через пару месяцев ваш слух начнет вас покидать, даже если будете ходить в берушах всё время, а ночные смены тоже заметно отразятся на общем состоянии и психике. или прочувствовать, как горят стопы после 3 дней подряд проведенных на ногах по 12 часов, работая в супермаркете. или можете заценить, как лопается кожа на руках от бесконечных коробок по 25 кг каждая. много в современном мире разного - когда садитесь утром в уютное кресло с кофейком, имейте в виду - вам просто везет... пока)
Есть опция MTU ignore при настройке роутеров многих вендоров - она отключает согласование MTU между соседями, соответственно некоторым кажется, что это отличное решение. На деле это создает проблемы, когда уже после настройки OSPF в один конечный роутер навтыкают сетей и router LSA превысят MTU - да, начнет расти счетчик отброшенных пакетов, но это не так заметно на больших сетях, где всё время что-то отбрасывается. Или еще хуже - сети поднимали по-очереди, поэтому LSU пролезали в MTU, а потом что-то сбойнуло, и они упали одновременно, но LSU уже в окно MTU не пролез - как результат, рассинхронизация LSDB при поднятом в FULL соседстве. Если же выключить MTU ignore, то один из роутеров начнет посылать вполне конкретные сообщения в логи, что не может согласовать MTU (кстати, это не единственная причина, почему соседи не могут подняться до FULL, так что правильный ответ на вопрос интервьюера был бы "надо посмотреть в логи - там 90% указана причина или 10% указаны последствия причины")
Про фрагментацию - да, она работает, но она жрет ресурсы роутера и увеличивает количество пакетов, а в момент поднятия большого фрагмента сети там и так несколько секунд идет шторм из анонсов разных, так что не рекомендую на нее делать ставку
Еще можно было бы проверять MTU на маршруте специальными сообщениями ICMP, но большинство провайдеров душат весь ICMP траффик (кроме пинга) чисто на всякий случай
Тлдр: чтобы детишки больше не могли ударить себя граблями по лбу, в новом стандарте все грабли будут разобраны на части.
Собсна, мой главный вопрос - в коде
будет какое поведение?
Если возникнет ошибка или выведется заготовленное плохое значение, значит компилятор собрал программу, которая потратила ресурсы на инициализацию переменной, о чем разраб не просил.
Иначе - это новое ограничение языка, выдающееся как фича нового стандарта, работает лишь в некоторых случаях и обходится одной дополнительной строкой.
а нанять одного разраба проектно для решения нельзя? чтоб без прослойки в виде манагера
деньги платят за работу. т.е. что успел с перерывами на обед и перекур сделать в спокойном темпе - то и сделал. а ковыряние в коде до часа ночи или работа без выходных и с минимальными перерывами на перекус в режиме экстренного допиливания - это уже опция, о которой надо договариваться
Лишний раз убеждаюсь, что живу с некоторыми комментаторами на разных планетах. Странно сравнивать мечтательный поиск той самой идеальной работы и стремление выжить. Интереснее всего - развивать свой бизнес за папины деньги, но это дано очень малому числу людей. Остальным приходится зарабатывать на свою жизнь. И тут обычно выбор между тем, что тебе не нравится, и тем, что очень не нравится.
в этом комменте больше практического смысла, чем в статье)
Рад, что вы нашли свое призвание. Надеюсь, профессия вас не разочарует, когда прилетят задания, типа этого (основано на реальных событиях):
Нужно нарисовать красный кабриолет
В нем должны чувствоваться скорость, роскошь и свобода
Размер изображения 10х10 пикселей
Спасибо, что открыли глаза на важные для резюме вещи! Я как-то не допустил драки двух коллег. Пройдемся методом стар:
Ситьюэйшн - два злых программиста зацепились на ровном месте.
Таск - мне надо было ковырять мои задачки, а их ругань меня отвлекала. Ну и мое место было рядом - могли нечаянно зацепить. Возникла задача прекратить их конфликт.
Экшн - я сказал им, чтоб х..йней не маялись и чо ваще?
Резалт - выяснилось, что в основе конфликта лежит плохое физическое состояние обоих в следствии бесконтрольного употребления алкоголя накануне. На этом конфликт был исчерпан.
Вот, релевантный опыт для тимлида, побежал включать в свое резюме вместо скучных технических данных. Еще раз спасибо за ценный совет!
Ходят слухи, что нормальный HR может пробежаться по отделам и договориться, чтоб сотрудника перевели к другому начальнику, если сам сотрудник не совсем деревянный. Я даже целый один раз такое видел. В большинстве же случаев, конечно, HR выполняет роль
надувной куклыэстетическую, так что каких-то осознанных телодвижений по решению проблем от них ждать не стоит. Ну, может кофе принести"крутой спец", "классный проект" - меня одного смущают такие формулировки у ичаров? будто постоянно под кокаином. работа программиста, как и любая другая работа - это набор задач, которые нужно выполнить с определенным качеством и в определенный срок. это не про приколы и веселье - это про ответственность и настойчивость. про ковыряние, когда кажется, что уже всё перепробовал. про допиливание до 3х часов ночи, если завтра дэдлайн. про коммуникацию с другими специалистами, которые тоже выполняют свою работу. а у ичаров постоянно какой-то бесконечный трип
Надеялся, что по фразе "за пять минут с гуглом написал" понятно, что я имел в виду сложность с синтаксисом, а не с примерным пониманием. Ну и само понятие "обертка" предполагает, что логика остается неизменной, а значит примерное понимание один хрен присутствует
Имхо, есть несколько нюансов:
Про кандидата выше уровнем, чем интервьюер. Чтоб понять, что кандидат ответил на вопрос более глубоко, чем его понимает интервьюер, необходимо, чтобы интервьюер усмирил свое ЧСВ и захотел вникнуть в то, что ему говорят. В 100% интервью, где меня собеседовали, этого не произошло, хотя я потом перепроверил свои ответы и оказался прав. Ты можешь быть бесконечно прав, но какой в этом толк, если интервьюер ебл... уеб... уверен в обратном.
Про неадекватность. Иногда в жизни случается жопа и приходится идти туда, куда берут. Иногда это оказывается завод со сменами по 12 часов и зп, которой хватает, чтоб иногда поесть. Когда ты в таком режиме работаешь несколько месяцев, а потом вдруг приезжаешь на собес в хайтек айти мега корпорэйшн, то довольно трудно вести себя позитивно и доброжелательно. К сожалению, часто это воспринимается как пассивная агрессия, отсутствие вовлеченности, заряженности и вот это вот всё. Когда потом получаешь отказ, а за пропущенный день из твоей зп на заводе уже вычли, это тоже не добавляет радости. (Лайфхак для тех, кто сейчас в такой ситуации - можно ездить на собесы после ночной смены. Лучше невыспавшимся проходить интервью, чем сидеть потом без денег).
Про списывание. Опыт у всех разный. Не всегда его можно сравнить однозначно "больше-меньше". Поэтому часто возникают ситуации "то, чего ты еще не знаешь, я уже забыл". Спрашивают какую-то хрень, которой ты не пользовался последние лет пять, потому что в твоем проекте эти стандартные функции обернуты в три слоя для удобства конкретно в этом проекте - ну всё, наврал в резюме, к гадалке не ходи! Доблестный техлид вычислил самозванца, браво! А то, что ты за пять минут с гуглом всё бы написал - это уже никого не волнует.
З.ы. Предугадывая вопрос "А ты бы как собеседовал?" - я бы предлагал конкретные кейсы из проекта и спрашивал, как кандидат будет их решать. Как будет локализовать баг? На что обратит внимание при реализации фичи? Главное - без решения на листочке за ограниченное время шизанутых задачек с литкода, которые относятся к реальной разработке, как бальные танцы к тяжелой атлетике.
З.з.ы. Спасибо за картинку - сохранил для важных переговоров! Всем добра и счастья!
Докер - контейнер. Нужен, чтобы не перенастраивать переменные окружения под сборку каждого проекта, например. Виртуальная машина на минималках.
Три предложения - и джун в ваших глазах превращается... превращается... ну хотя бы в мидла. А если ему рассказать про кросскомпиляцию - это еще два предложения - то там и до сеньора не далеко)
Вроде, для таких ситуаций скрам и придумали. Раз в день каждый говорит, что сделал, что делает, как и в чём в данный момент затык, если он есть. Либо проблема решается тут же на скраме мудрым советом старших товарищей, либо можно подойти к сотруднику и позже подробно разобрать, что он там наворотил. Просто ответы 'делаю задачу, всё хорошо' не принимать и расспрашивать, что конкретно делает и что конкретно хорошо
Ну вот был у нас такой модуль, который такие синьоры писали. Всё очень красиво, очень структурировано, с кучей ассертов, чтоб не дай боже чего-нибудь куда-нибудь не туда не пошло. Прилетела задача в этом модуле поправить поведение. В итоге пришлось несколько дней штудировать доку, чтоб понять, что решение может быть только временным, т.к. очень умные сеньоры, которые всё это писали, почему-то не подумали об ограниченности ресурсов, с которым мы столкнулись в рамках этой задачи. Но переделка этого модуля потребовала бы отдать на это дело сеньора как минимум на месяц.
Ну и еще байка туда же - другой был модуль, в котором всё было очень запутано, многие ветераны даж говорили, что туда заходить боятся, т.к. там сам черт ногу сломит. А вылезла задача, т.к. у кого-то где-то там что-то ломалось - и железка падала примерно раз в месяц (а должна работать непрерывно годы). Ну и я начал там разгребать весь этот перемудрёный код, нашел много потенциально опасных операций с данными - и выпросил у начальника разрешения всё это переписать. Переработал структуры, хранившие данные, написал промежуточные функции для работы с ними, переписал функции верхних уровней, которые в старом коде дёргали данные напрямую без каких-либо проверок. Проблемы решились, код стал компактней, ресурсы высвободились, хоть это и не ставилось как цель, но разработка и отладка этого заняла больше ГОДА с перерывами на другие задачи.
Это я к тому, что после этого сформулировал свой критерий оценки качества кода, из-за которого у меня перманентное недопонимание с нынешним поколением тимлидов - код должен быть настолько простым и понятным, насколько это возможно для решения задачи, которую он выполняет
Почему-то многие сейчас считают, что сеньоры всё наусложняют - и это нормально. Когда я учился программировать, умные книжки читал и потом общался с коллегами (лет 5 назад), то наоборот считалось, что более квалифицированный прогер напишет более простой, эффективный и понятный каждому код, а сложный и непонятный код пишет мудила-понторез, который вместо работы занят самоутверждением. Видимо, теперь эти понторезы продвинулись в тимлиды