Честно не прочитал все комменты, но после первой смены работы (как говорится отработал 6 лет на одной галере полез на другую) ты начинаешь что-то подозревать
Первое и самое главное - разница между тобой и условным стажёром всего лишь в нескольких вещах: 1. Написании читабельного кода (и это зависит от тоего языка и опыта рзработки, но в целом опять же по опыту выпрямляется бувально в течении месяца на ревью внутри команды) 2. Не писать где не надо алгоритмы квадратичной сложности - ну тут вам как раз и нужны алгоритмы и вся эта фигня с алгоритмами и стреляет. Да в основном нужно представлять разницу между мапой и массивом, но много кто и этого не умеет 3. Задавать правильные вопросы - это уже навык сложнее. Я бы сказал что отчасти он проверяется на интервью по системной архитектуре, но там вопросы вполне себе тоже можно выучить, потому что 90% попадает в диапазон - а сколько тут rps, а есть ли геораспределённость, а какая задержка и т.п. А вот задавать правильные вопросы по задаче - это про то что нужно изучить документацию, почитать код и прийти с реально важными вопросами, которые до этого были не проработаны 4. Доводить продукт до конца - выяснить откуда получить данные или что их неоткуда получить, продумать как продукт будет работать от первого запроса до последнего, поймать тонкие моменты. Что-то можно проверить на алгоритмах, но в целом тоже до реальной работы фиг проверишь.
В итоге - как отличить синьора от стажёра фиг его поймёшь... Зато за 3 месяца испытательного срока отсеят на раз два.
Если вы дошли до знакомства с командой, то это даже близко не гарантирует оффер. Я так был практически уверен, что у меня будет оффер в Авито, было 4 команды, с которыми я был на встрече и в итоге - извините вы нам не подходите. Лично для это было в какой-то степени шоком.
Ещё веселее было, когда месяца через 3 ко мне пришёл их ректрутёр в linked in и предложил ещё раз пройти собес) (да-да он не знал что я там был вот буквально недавно)
у вас в одной табличке 300 миллионов записей, а теперь добавьте колонку к этой табличке без даунтайма, при условии того, что это таблица из которой постоянно читаются и пишутся данные. И даже не хайлоад - всего то под сотню рпс. Я вам скажу - это нереально. Буквально неделю назад словил такой кейс.
А дальше ещё интереснее - у вас там могут быть не 1:1, а 1:0...1 и тут вы ещё и в объёме можете выиграть, потому что у вас основная таблица не будет лишнее место занимать.
А если вам ещё и не для всех запросов нужны данные из дополнительной таблицы, то это вообще вам на руку.
Мягко говоря спорный пунктик... И уверен на хайлоаде с хотя бы 1к рпс там добавится своих аргументов
Некоторые моменты спорные - в угоду масштабируемости сейчас можно принести многое. В частности внешние ключи. Иногда и нормализацию.
Проектирование хорошей БД как раз обычно учёт текущих запросов и некоторое прогнозирование будущих. То что хорошо для базы с 100 rps может быть катастрофически для базы с 100k rps. И это даже не учитывая профиль нагрузки.
В итоге - правила хорошо проектирования это взвешивание плюсов и минусов каждого решения.
не - зачем заливать просто как обычно - потерпите чуть-чуть при этом будут и зп повышать, но только по сравнению с тем сколько надо влить в зп другим людям, которые бы рулили всем этим - это две копейки
По моему опыту работу в РЖД в IT коротко - всё очень печально И печально не из-за айтишников как таковых - тупо не хватает квалифицированных управленцев. Причём когда буквально расписываешь эту проблему перед начальством, что вот оно - это решать надо, то и денег нет, и сами знаем лучше и т.д.
А это может помочь в случае, если в проекте есть один большой package? Резать на отдельные его нельзя, к сожалению т.к. получается всё устройство кодгеном Интересует как раз тоже ускорение тестов и сборки, особенно на локальных машинах, потому что сейчас запустить тесты этого проекта на локальных машинах не всегда возможно
Статья реально крутая. Круче только, когда всё сломано совсем и бизнес в целом отказывается брать ответственность за что-то. Вот есть срок - надо сделать и ваши проблемы нас не волнуют. Есть какие-то предложения - идите лесом, нам они не нравятся. Но думаю такое лечится только кем-то адекватным на уровне генерального директора(
Рабочий код писать достаточно несложно. Ну на мой взгляд. Рабочий с той точки зрения, что он будет как-то выполняться и условно в 90% случаев выдавать желаемый результат. А вот дальше начинаются как раз те навыки, которые нужны и важны для развития и понимания: как это спроектировать, чтобы было удобно поддерживать дальше как спроектировать, чтобы было удобно тестировать как написать код, который будет затрачивать минимальное/оптимальное количество ресурсов как написать код, который будет интегрироваться с существующим кодом
и это если не опускаться до каких-то управленческих вещей типа понимания, а собственно как же вообще работают процессы разработки в командах, какие инструменты там применяются, их плюсы и минусы. А такие вещи чаще всего статьями не наработаешь - нужна практика, опыт, чтобы "задачки к пальцам прилипли", как говорила моя преподавательница по матстату.
Хз конечно, но разве навыки работы с чужим кодом не поднимает твою стоимость в глазах работодателя, да и вообще готовность с ним работать. На мой взгляд накатать свой какой-то (ещё неизвестно какого качества) код сможет каждый, а вот разобраться в чужом, понять что он делает, понять почему он так делает и исправить в соответствии с новыми реалиями - вот это приличная ценность.
а когда вся компания такая - это же тихий ужас Приходишь, пытаешься это разгрести, довести необходимую бюррократию до конца, а в ответ - у нас на это нет ресурсов...
Так иногда все эти параметры прям дико зависят от управления и процессов в компании. Условно один программист работал в компании, где постановки тщательно обдумывались, обсуждались и т.д. прежде чем отдаваться в разработку - у такого разработчика и код будет чаще писаться быстро с минимумом ошибок, ненужных абстракций, проверок и т.д. (в большинстве, но не всегда). А есть другой программист - в его компании постановки делалис на тяп-ляп, ни с кем никогда не согласовывались, после решения задачи по десять раз переделывались, в процессе постоянно всплывали проблемы - такой программист хошь не хошь, а начнёт везде перестраховываться, чтобы иметь возможность потом достаточно быстро ввести самые параноидальные изменения.
Поэтому я бы сказал, что на то каким становится программист очень сильно влияет компания. Да, думаю после 10-20 лет стажа может быть уже достаточно тяжело изменить стиль, но раньше всё вполне себе решают процессы и организация в компании.
Честно не прочитал все комменты, но после первой смены работы (как говорится отработал 6 лет на одной галере полез на другую) ты начинаешь что-то подозревать
Первое и самое главное - разница между тобой и условным стажёром всего лишь в нескольких вещах:
1. Написании читабельного кода (и это зависит от тоего языка и опыта рзработки, но в целом опять же по опыту выпрямляется бувально в течении месяца на ревью внутри команды)
2. Не писать где не надо алгоритмы квадратичной сложности - ну тут вам как раз и нужны алгоритмы и вся эта фигня с алгоритмами и стреляет. Да в основном нужно представлять разницу между мапой и массивом, но много кто и этого не умеет
3. Задавать правильные вопросы - это уже навык сложнее. Я бы сказал что отчасти он проверяется на интервью по системной архитектуре, но там вопросы вполне себе тоже можно выучить, потому что 90% попадает в диапазон - а сколько тут rps, а есть ли геораспределённость, а какая задержка и т.п. А вот задавать правильные вопросы по задаче - это про то что нужно изучить документацию, почитать код и прийти с реально важными вопросами, которые до этого были не проработаны
4. Доводить продукт до конца - выяснить откуда получить данные или что их неоткуда получить, продумать как продукт будет работать от первого запроса до последнего, поймать тонкие моменты. Что-то можно проверить на алгоритмах, но в целом тоже до реальной работы фиг проверишь.
В итоге - как отличить синьора от стажёра фиг его поймёшь... Зато за 3 месяца испытательного срока отсеят на раз два.
Ну вообще в озон я давно хотел попасть - так что можно сказать это избавило от мук выбора
Озон забрал раньше)
Если вы дошли до знакомства с командой, то это даже близко не гарантирует оффер. Я так был практически уверен, что у меня будет оффер в Авито, было 4 команды, с которыми я был на встрече и в итоге - извините вы нам не подходите. Лично для это было в какой-то степени шоком.
Ещё веселее было, когда месяца через 3 ко мне пришёл их ректрутёр в linked in и предложил ещё раз пройти собес) (да-да он не знал что я там был вот буквально недавно)
Вообще согласен - чем вы лучше того же CloudFlare на бесплатном тарифе? на минимальном платном?
у вас в одной табличке 300 миллионов записей, а теперь добавьте колонку к этой табличке без даунтайма, при условии того, что это таблица из которой постоянно читаются и пишутся данные.
И даже не хайлоад - всего то под сотню рпс.
Я вам скажу - это нереально. Буквально неделю назад словил такой кейс.
А дальше ещё интереснее - у вас там могут быть не 1:1, а 1:0...1 и тут вы ещё и в объёме можете выиграть, потому что у вас основная таблица не будет лишнее место занимать.
А если вам ещё и не для всех запросов нужны данные из дополнительной таблицы, то это вообще вам на руку.
Мягко говоря спорный пунктик... И уверен на хайлоаде с хотя бы 1к рпс там добавится своих аргументов
Некоторые моменты спорные - в угоду масштабируемости сейчас можно принести многое. В частности внешние ключи. Иногда и нормализацию.
Проектирование хорошей БД как раз обычно учёт текущих запросов и некоторое прогнозирование будущих. То что хорошо для базы с 100 rps может быть катастрофически для базы с 100k rps. И это даже не учитывая профиль нагрузки.
В итоге - правила хорошо проектирования это взвешивание плюсов и минусов каждого решения.
не - зачем заливать
просто как обычно - потерпите чуть-чуть
при этом будут и зп повышать, но только по сравнению с тем сколько надо влить в зп другим людям, которые бы рулили всем этим - это две копейки
По моему опыту работу в РЖД в IT коротко - всё очень печально
И печально не из-за айтишников как таковых - тупо не хватает квалифицированных управленцев. Причём когда буквально расписываешь эту проблему перед начальством, что вот оно - это решать надо, то и денег нет, и сами знаем лучше и т.д.
От компаний зависит
где-то есть младший разраб, миддл, старший разраб и ведущий
В итоге старший это сеньор, а ведущий по факту тех лид
А это может помочь в случае, если в проекте есть один большой package?
Резать на отдельные его нельзя, к сожалению т.к. получается всё устройство кодгеном
Интересует как раз тоже ускорение тестов и сборки, особенно на локальных машинах, потому что сейчас запустить тесты этого проекта на локальных машинах не всегда возможно
Только вопрос как это помогает всему этому автоматически из коробки работать
Если есть какой-то инструмент для такого автоматического шардирования в Postgres с удовольствием бы изучил
Статья реально крутая. Круче только, когда всё сломано совсем и бизнес в целом отказывается брать ответственность за что-то. Вот есть срок - надо сделать и ваши проблемы нас не волнуют. Есть какие-то предложения - идите лесом, нам они не нравятся. Но думаю такое лечится только кем-то адекватным на уровне генерального директора(
Вот я сейчас примерно также с интересом хожу на собеседования и спрашиваю как у кого проходят собеседования)
Рабочий код писать достаточно несложно. Ну на мой взгляд. Рабочий с той точки зрения, что он будет как-то выполняться и условно в 90% случаев выдавать желаемый результат. А вот дальше начинаются как раз те навыки, которые нужны и важны для развития и понимания:
как это спроектировать, чтобы было удобно поддерживать дальше
как спроектировать, чтобы было удобно тестировать
как написать код, который будет затрачивать минимальное/оптимальное количество ресурсов
как написать код, который будет интегрироваться с существующим кодом
и это если не опускаться до каких-то управленческих вещей типа понимания, а собственно как же вообще работают процессы разработки в командах, какие инструменты там применяются, их плюсы и минусы. А такие вещи чаще всего статьями не наработаешь - нужна практика, опыт, чтобы "задачки к пальцам прилипли", как говорила моя преподавательница по матстату.
Хз конечно, но разве навыки работы с чужим кодом не поднимает твою стоимость в глазах работодателя, да и вообще готовность с ним работать. На мой взгляд накатать свой какой-то (ещё неизвестно какого качества) код сможет каждый, а вот разобраться в чужом, понять что он делает, понять почему он так делает и исправить в соответствии с новыми реалиями - вот это приличная ценность.
А когда пофиксят проблему с тем, что любимых треков может быть только 10к и в плейлисте снаружи написано 9923, а внутри 10к...
а когда вся компания такая - это же тихий ужас
Приходишь, пытаешься это разгрести, довести необходимую бюррократию до конца, а в ответ - у нас на это нет ресурсов...
Так иногда все эти параметры прям дико зависят от управления и процессов в компании.
Условно один программист работал в компании, где постановки тщательно обдумывались, обсуждались и т.д. прежде чем отдаваться в разработку - у такого разработчика и код будет чаще писаться быстро с минимумом ошибок, ненужных абстракций, проверок и т.д. (в большинстве, но не всегда). А есть другой программист - в его компании постановки делалис на тяп-ляп, ни с кем никогда не согласовывались, после решения задачи по десять раз переделывались, в процессе постоянно всплывали проблемы - такой программист хошь не хошь, а начнёт везде перестраховываться, чтобы иметь возможность потом достаточно быстро ввести самые параноидальные изменения.
Поэтому я бы сказал, что на то каким становится программист очень сильно влияет компания. Да, думаю после 10-20 лет стажа может быть уже достаточно тяжело изменить стиль, но раньше всё вполне себе решают процессы и организация в компании.
А в чём прикол с покупкой через компанию без НДС? Разве в итоге этот НДС не должна как-то сама компания уплатить или что-то в этом духе?