Мониторинг: есть у вас сервис берущий байтики из одного места, как-то их преобразующий по данным из других мест и кладущий результат в третье место. Админы не знают не могут и будут его мониторить.
И не фиг им это знать. Есть стандарт OpenTelemetry и зона ответственности админов начинается разве что начиная с коллектора.
Мне не попадались еще ни разу проекты без специфики. Где то требовались хотя бы поверхностные знания GAAP и российского учета. Где-то - логистики и складского учета. Где-то - особенностей непрерывного производства и интеграции с SCADA. Где-то - энергетики, АСКУЭ и биллинга. Где-то - транспортных оптимизационных задач и прогнозирования.
Я даже не представляю себе нормальный проект без своей специфики. Везде приходится погружаться в проблемную область.
основной язык разработки на центральных серверах - RPG
Это уже слишком. На COBOL я еще изредка подработки брал. Но RPG никакой даже по сравнению с COBOL. Да, последний более многословен, но его генератор отчетов ни в чем не уступает RPG, а вот со строками и массивами в COBOL на ЕС ЭВМ было работать намного удобней. Впрочем, последний раз RPG я видел в 1987 году. С этого времени многое могло измениться.
Сможете сходу хоть что-нибудь в эмуляторе терминала IBM5250 изобразить?
Ну он намного дружелюбней IBM3270 с которым я в свое время вволю пообщался. Так что разобраться недолго. Я думаю, даже быстрее, чем я разобирался когда-то с консолью SVS/TKS
В каких? Впервые такое слышу. Более того, меня чуть ли не заставляли все проекты вписывать на LinkedIn. Даже в которых я принимал непродолжительное и косвенное участие. Интегратор потом на тендерах использует это в качестве демонстрации компетенций своего персонала.
судя по вашим утверждениям, вы слабо осознать, что соискатель не обязан выполнять работу так, как выполняете вы.
Хватит лгать. Я утверждал прямо противоположное:
"я, обычно, и не надеюсь, что человек "завтра же начнëт решать рабочие задачи". Это невозможно, каким бы опытным он ни был. Всегда есть специфика. Важнее всего оценить, какие ресурсы и какое время потребуется для обучения соискателя."
Вы явно что-то перепутали. Речь про оптимизацию запросов касалась собеседования только в части оспаривания утверждения
оптимизации SQL запросов каждый день, то человек, который не умеет этого делать быстро, зато легко решает логические задачи - это трата денег работодателя
А вот послушать логику рассуждений соискателя в течении пяти минут - это уже полезно.
Нравится Вам это или нет, но разработчики на удаленке и есть самый натуральный детсад.
Кто-то "забыл" предупредить, что два дня работать не сможет из-за своей любимой бабушки и собирался это отработать в выходные. А в выходные инфраструктурщики сетевые работы затеяли и отрубили доступ.
Кто-то увлеченно ищет несуществующую багу, не повторяемую локально. Просто потому что забыл, что репозитории на CI/CD только локальные.
Кто-то уже третий день лается с аналитиком пихая задачу на уточнение и получая ее же обратно.
А кому-то наоборот, аналитик такую постановку дал, что по ней в принципе недопустимо разработку вести, но разработчик пытается закодить недетерминированный или потенциально бесконечный алгоритм. Непонятно на что надеясь. Ведь PR все равно не пройдет.
Вы слышали поговорку «не обманешь, не продашь»?
Слышал это ироничное высказывание о нечистоплотных торговцах. Патологические лгуны так себя оправдывают. Вы себя к ним относите?
Вы сильно удивитесь, но заказчику важнее получить код вовремя, пусть и хреновый, чем "вылизанный до идеального состояния", но тогда, когда он ему уже на фиг не нужен.
Да, самому противно такое костылестроение. Особенно если понимаешь, что бюджет на рефакторинг будешь потом год выбивать с неопределенным результатом. Но если что-то должно с условного понедельника работать именно так, а не иначе - вынь да положь.
То есть Вы считаете, что о таком не следует говорить? Пусть и дальше соискатели из-за лжи окажутся отвергнуты?
Я писал это преследуя совсем другие цели. Наоборот, чтобы не патологические лжецы были честны на собеседовании, так как это может легко перевесить какие-то пропуски в знаниях.
соискатель не обязан знать 100% деталей инструмента
А с чего Вы решили, что это кто-то требует? Я вообще написал совершенно обратное.
при оптимизации SQL запросов вы решаете сложные алгоритмические задачи, то либо вы работаете в сфере больших данных / сфере, связанной со сложным анализом данных
Ну по такой же логике можно подумать, что Вы с БД размером свыше терабайта никогда не работали. А это еще далеко от BigData, с которым тоже приходится работать. Но уже не на SQL (даже в ClickHouse - подобие SQL и множество критически важных отличий при внешнем сходстве).
Первый пример. В постановке указано формировать в таблице по записи для каждого периода для каждой аналитики. При этом подавляющее большинство (99%) записей формируются с нулевыми мерами. Если копнуть глубже, то выясняется, что эта таблица используется только парой отчетов и выгрузкой в оптимизационную модель (Gurobi). Таким образом, если выгрузку и отчеты делать не прямо из этой таблицы, а запросом по периодам, аналитикам и уже LEFT JOIN по этой таблице, то записи с нулевыми мерами можно будет формировать динамически. Получили сразу два порядка выигрыша в производительности.
Второй пример. Отчет ищет операции с определенной последовательностью во времени аналитик по таблице, где только в интересующем периоде (с начала прошлого года) миллиард строк. Данная последовательность всегда объединена конкретной аналитикой, значение которой не изменяется в пределах последовательности. Внимательное изучение постановки и предметной части показывает, что данная последовательность может возникнуть только при определенных значениях других аналитик. В итоге, получаем дополнительный срез и вместо всех 30 тыс. значений этой аналитики нам становится интересны только ~30. Три порядка.
Это Ваш выбор. А я предпочитаю строить отношения в команде на честности и доверии. И тогда возможностей защитить свою команду у меня имеется намного больше.
Одно дело, если я сглупил и три дня не спрашивал у сотрудника о том, как продвигается задача. Тогда срыв сроков безусловно моя вина. А совсем другое дело, когда сотрудник лжет, надеясь как-то самостоятельно потом нагнать упущенное.
Да все бывает. Бывает какой-то баг неделю ловишь, хотя думал, что справишься с ним за пару часов. Но врать на хрена?
в некоторых случаях информация что заказ оплачен приходит от платежного провайдера
В адекватных системах никакой документ после разноски не модифицируется. Заказ - это одна финансовая транзакция, инвойс на его основе - другая, платеж - третья, сопоставление платежа с заказом или инвойсом - четвертая, отгрузка или акт по заказу - пятая. В финансовом смысле - это все автономные транзакции. Причем изменить их невозможно. Можно ввести только новую корректирующую финансовую транзакцию (обычно, сторно). А все статусы - это лишь результат связи этих транзакций друг с другом.
Дело в том, что я уже столько раз сталкивался с такой "ложью от отчаяния" на простой вопрос о том, успевает ли сотрудник завершить задачу к сроку, что связываться с такими людьми просто не хочу ни под каким соусом.
Если человек честно говорит, что где-то уперся или завозился, возможность выполнить задачу к сроку всегда есть. А если это выясняется уже по факту, при срыве сроков, достанется уже мне.
причина не в джуне, а в том что на нем будут продолжать пытаться сэкономить даже после того как он перестанет им быть
Это относится ко всем на любых должностях, а не только к джунам. За последние 30 лет мне повышали зарплату без повышения в должности всего 4(!) раза. Вот так и живу. Один-два проекта на стороне интегратора, потом клиент предлагает более выгодные условия. Через год-два у клиента на более выгодные условия переманивают к интегратору на следующий проект. И так по спирали )
Собес сейчас напоминает попытку техлида найти себе собутыльника, а не человека, который завтра же начнëт решать рабочие задачи.
Я регулярно провожу собеседования. При этом я, обычно, и не надеюсь, что человек "завтра же начнëт решать рабочие задачи". Это невозможно, каким бы опытным он ни был. Всегда есть специфика. Важнее всего оценить, какие ресурсы и какое время потребуется для обучения соискателя.
А отказываю соискателям я, чаще всего, за ложь. То есть задаю вопросы "знаете ли вы это?". И, в какой-то момент, после получения утвердительного ответа, вдруг проверяю эти знания. Если соискатель солгал - прощаемся.
оптимизации SQL запросов каждый день, то человек, который не умеет этого делать быстро, зато легко решает логические задачи - это трата денег работодателя
Спорное утверждение. Оптимизацией SQL запросов занимаюсь не каждый день, но часто. И при этом, не редко, оптимизация включает в себя решение логических задач при чтении постановок. Да, я признаю, что этим беру на себя часть работы аналитика, который, строго говоря, не справился с задачей. Но именно таким путём порой достигается оптимизация на два-три порядка.
во многих странах уже давно научились как-то обходиться без этого
Но какой ценой? Я женился и имел двоих детей еще до получения диплома. Понятно, что если бы не надо было содержать семью, то мог бы и не напрягаться. А так спокойно позволили себе потом и третьего ребенка.
А в этих "многих странах" "обходятся без этого" только заключая брак существенно после 30. И, если здоровье еще позволяет, одного ребенка заводят.
А где смайлик? Или Вы искренне считаете, что свежеиспеченные специалисты без опыта там кому-то нужны?
А с опытом, у меня лично, весьма отрицательное отношение к работодателям в США. Такой тупизны, упертости, зашоренности и сверхузкой специализации где-либо еще сложно встретить. Я когда-то только полгода выдержал на code review "индусского" кода, после чего свалил и не жалею. Существенной разницы в доходах минус расходы не наблюдаю.
А Вы попробуйте не лгать. Тогда Вас и не будут доказательно обвинять во лжи )
И не фиг им это знать. Есть стандарт OpenTelemetry и зона ответственности админов начинается разве что начиная с коллектора.
Мне не попадались еще ни разу проекты без специфики. Где то требовались хотя бы поверхностные знания GAAP и российского учета. Где-то - логистики и складского учета. Где-то - особенностей непрерывного производства и интеграции с SCADA. Где-то - энергетики, АСКУЭ и биллинга. Где-то - транспортных оптимизационных задач и прогнозирования.
Я даже не представляю себе нормальный проект без своей специфики. Везде приходится погружаться в проблемную область.
Это уже слишком. На COBOL я еще изредка подработки брал. Но RPG никакой даже по сравнению с COBOL. Да, последний более многословен, но его генератор отчетов ни в чем не уступает RPG, а вот со строками и массивами в COBOL на ЕС ЭВМ было работать намного удобней. Впрочем, последний раз RPG я видел в 1987 году. С этого времени многое могло измениться.
Ну он намного дружелюбней IBM3270 с которым я в свое время вволю пообщался. Так что разобраться недолго. Я думаю, даже быстрее, чем я разобирался когда-то с консолью SVS/TKS
В каких? Впервые такое слышу. Более того, меня чуть ли не заставляли все проекты вписывать на LinkedIn. Даже в которых я принимал непродолжительное и косвенное участие. Интегратор потом на тендерах использует это в качестве демонстрации компетенций своего персонала.
Хватит лгать. Я утверждал прямо противоположное:
"я, обычно, и не надеюсь, что человек "завтра же начнëт решать рабочие задачи". Это невозможно, каким бы опытным он ни был. Всегда есть специфика. Важнее всего оценить, какие ресурсы и какое время потребуется для обучения соискателя."
Это как раз когда контроллер без ПИД регулирования. Послушайте, как эти вентиляторы плавно адаптируют обороты на нормальных серверах. Или на малинке ) https://www.instructables.com/PID-Control-for-CPU-Temperature-of-Raspberry-Pi/
Ссылку на microFFT я Вам дал. Для начала уже кое-что. Ну а на старших STM32 БПФ предоставляет производитель в библиотеке HAL.
На мой взгляд, ссылка в резюме на успешный проект в tadviser стоит немало. И не надо никаких расплывчатых формулировок.
Вы явно что-то перепутали. Речь про оптимизацию запросов касалась собеседования только в части оспаривания утверждения
А вот послушать логику рассуждений соискателя в течении пяти минут - это уже полезно.
Нравится Вам это или нет, но разработчики на удаленке и есть самый натуральный детсад.
Кто-то "забыл" предупредить, что два дня работать не сможет из-за своей любимой бабушки и собирался это отработать в выходные. А в выходные инфраструктурщики сетевые работы затеяли и отрубили доступ.
Кто-то увлеченно ищет несуществующую багу, не повторяемую локально. Просто потому что забыл, что репозитории на CI/CD только локальные.
Кто-то уже третий день лается с аналитиком пихая задачу на уточнение и получая ее же обратно.
А кому-то наоборот, аналитик такую постановку дал, что по ней в принципе недопустимо разработку вести, но разработчик пытается закодить недетерминированный или потенциально бесконечный алгоритм. Непонятно на что надеясь. Ведь PR все равно не пройдет.
Слышал это ироничное высказывание о нечистоплотных торговцах. Патологические лгуны так себя оправдывают. Вы себя к ним относите?
Вы сильно удивитесь, но заказчику важнее получить код вовремя, пусть и хреновый, чем "вылизанный до идеального состояния", но тогда, когда он ему уже на фиг не нужен.
Да, самому противно такое костылестроение. Особенно если понимаешь, что бюджет на рефакторинг будешь потом год выбивать с неопределенным результатом. Но если что-то должно с условного понедельника работать именно так, а не иначе - вынь да положь.
То есть Вы считаете, что о таком не следует говорить? Пусть и дальше соискатели из-за лжи окажутся отвергнуты?
Я писал это преследуя совсем другие цели. Наоборот, чтобы не патологические лжецы были честны на собеседовании, так как это может легко перевесить какие-то пропуски в знаниях.
А с чего Вы решили, что это кто-то требует? Я вообще написал совершенно обратное.
Ну по такой же логике можно подумать, что Вы с БД размером свыше терабайта никогда не работали. А это еще далеко от BigData, с которым тоже приходится работать. Но уже не на SQL (даже в ClickHouse - подобие SQL и множество критически важных отличий при внешнем сходстве).
Первый пример. В постановке указано формировать в таблице по записи для каждого периода для каждой аналитики. При этом подавляющее большинство (99%) записей формируются с нулевыми мерами. Если копнуть глубже, то выясняется, что эта таблица используется только парой отчетов и выгрузкой в оптимизационную модель (Gurobi). Таким образом, если выгрузку и отчеты делать не прямо из этой таблицы, а запросом по периодам, аналитикам и уже LEFT JOIN по этой таблице, то записи с нулевыми мерами можно будет формировать динамически. Получили сразу два порядка выигрыша в производительности.
Второй пример. Отчет ищет операции с определенной последовательностью во времени аналитик по таблице, где только в интересующем периоде (с начала прошлого года) миллиард строк. Данная последовательность всегда объединена конкретной аналитикой, значение которой не изменяется в пределах последовательности. Внимательное изучение постановки и предметной части показывает, что данная последовательность может возникнуть только при определенных значениях других аналитик. В итоге, получаем дополнительный срез и вместо всех 30 тыс. значений этой аналитики нам становится интересны только ~30. Три порядка.
Это Ваш выбор. А я предпочитаю строить отношения в команде на честности и доверии. И тогда возможностей защитить свою команду у меня имеется намного больше.
Одно дело, если я сглупил и три дня не спрашивал у сотрудника о том, как продвигается задача. Тогда срыв сроков безусловно моя вина. А совсем другое дело, когда сотрудник лжет, надеясь как-то самостоятельно потом нагнать упущенное.
Да все бывает. Бывает какой-то баг неделю ловишь, хотя думал, что справишься с ним за пару часов. Но врать на хрена?
В адекватных системах никакой документ после разноски не модифицируется. Заказ - это одна финансовая транзакция, инвойс на его основе - другая, платеж - третья, сопоставление платежа с заказом или инвойсом - четвертая, отгрузка или акт по заказу - пятая. В финансовом смысле - это все автономные транзакции. Причем изменить их невозможно. Можно ввести только новую корректирующую финансовую транзакцию (обычно, сторно). А все статусы - это лишь результат связи этих транзакций друг с другом.
Дело в том, что я уже столько раз сталкивался с такой "ложью от отчаяния" на простой вопрос о том, успевает ли сотрудник завершить задачу к сроку, что связываться с такими людьми просто не хочу ни под каким соусом.
Если человек честно говорит, что где-то уперся или завозился, возможность выполнить задачу к сроку всегда есть. А если это выясняется уже по факту, при срыве сроков, достанется уже мне.
Это относится ко всем на любых должностях, а не только к джунам. За последние 30 лет мне повышали зарплату без повышения в должности всего 4(!) раза. Вот так и живу. Один-два проекта на стороне интегратора, потом клиент предлагает более выгодные условия. Через год-два у клиента на более выгодные условия переманивают к интегратору на следующий проект. И так по спирали )
Я регулярно провожу собеседования. При этом я, обычно, и не надеюсь, что человек "завтра же начнëт решать рабочие задачи". Это невозможно, каким бы опытным он ни был. Всегда есть специфика. Важнее всего оценить, какие ресурсы и какое время потребуется для обучения соискателя.
А отказываю соискателям я, чаще всего, за ложь. То есть задаю вопросы "знаете ли вы это?". И, в какой-то момент, после получения утвердительного ответа, вдруг проверяю эти знания. Если соискатель солгал - прощаемся.
Спорное утверждение. Оптимизацией SQL запросов занимаюсь не каждый день, но часто. И при этом, не редко, оптимизация включает в себя решение логических задач при чтении постановок. Да, я признаю, что этим беру на себя часть работы аналитика, который, строго говоря, не справился с задачей. Но именно таким путём порой достигается оптимизация на два-три порядка.
Но какой ценой? Я женился и имел двоих детей еще до получения диплома. Понятно, что если бы не надо было содержать семью, то мог бы и не напрягаться. А так спокойно позволили себе потом и третьего ребенка.
А в этих "многих странах" "обходятся без этого" только заключая брак существенно после 30. И, если здоровье еще позволяет, одного ребенка заводят.
А где смайлик? Или Вы искренне считаете, что свежеиспеченные специалисты без опыта там кому-то нужны?
А с опытом, у меня лично, весьма отрицательное отношение к работодателям в США. Такой тупизны, упертости, зашоренности и сверхузкой специализации где-либо еще сложно встретить. Я когда-то только полгода выдержал на code review "индусского" кода, после чего свалил и не жалею. Существенной разницы в доходах минус расходы не наблюдаю.
Если написано "транзакция - ACID", то двоякие толкования могут возникнуть только у того, кто в этом вообще не разбирается. )))