Несколько неточностей в предисловии лучше поправить:
1. Переводом кода с одного ЯП на другой занимается транслятор (иногда применяют термин "транспилятор"). Компилятор - частный случай транслятора: компилятор переводит код с высокоуровневого языка (обычно ЯП) в машинный \ объектный код. 2. "передним/задним планом" фронтэнд и бэкэнд азывать не принято. 3. Сегодня (начиная с llvm) компилятор делят на frontend / middleend / backend 4. Лексер + парсер - малая часть фронтэнда. Основная часть фронтэнда - построение AST и специфические (обычно глобальные) оптимизации над AST.
Также добавлю вопрос от себя: Лексер (в лексере-парсере) нужен для того, чтобы ваш парсинг был устойчив к разделителям и форматированию пользователя. 5. С peco (и вообще парсерами в python) не работал - а что у вас обеспечивает эту фунциональность?
Так да - нормальная проверка на наличие мозга у кандидата-джуна.
Я думаю что теория графов - самый востребованный раздел математики для чистых прогеров (для DS - теорвер + статистика, для ML - линейная алгебра + методы оптимизации).
то написать правильное окончание у слова с числительным (2 ракетки, но 5 ракеток, и вам нужно в автоматическом режиме подставить окончание);
Вы осетра-то урежьте. В склонениях \ спряжениях список исключений такой, что делается или сторонними средствами или с таким количеством ошибок, что лучше не начинать.
Статья норм (за исключением всяких нюансов - например в leetcode заранее пишут, что дана ASCII строка).
Найм действительно сломан - т.к. выпускники курсов обмануты дезинформированы рекламой платных курсов. После выпуска программистами они не являются и подают по 100 заявок на любую приличную вакансию, обманывая дописывая опыт в резюме.
Проблема почему к вам не идут приличные кандидаты - ну у вас максимально безотрадный стек (с одной стороны он не модный и бесперспективный, с другой IMHO скучный и унылый). Но тут уже ничего не сделать.
а зп теперь меньше раскладывателя баночек в магазине у дома.
Мск, ЖК 2017 года постройки магазин у дома. На двери объявление: "ищем продавца ЗП 2000р/смена" (* смена там 12 часов к стати).
Да и где вообще там сколько-нибудь значимые требования? Меня поражает сюр вообще всей этой ситуации.
Я вот на прошлом месте работы пытался заняться наймом джунов (системное программирование) - через неделю уже выпускников курсов просто не рассматривал. Программистов, даже junior-программистов среди той дюжины, что я прособеседовал не было (я бы сказал, что там ни одного приличного trainee не было).
В любой (невырожденный для вашей задачи) граф A->B, B-C -- можно вписать дугу A->C и получить треугольник.
Если же вопрос про геометрическую (а не топологическую) интерпретацию треугольников - то сильно сомневаюсь что задачу можно достаточно хорошо сформулировать, чтобы не играть в игру "угадай что я имел в виду".
Имеем: два талантливых джуна после университета, которые не просто на парах сидели, а ещё и пытались реально копать индустрию, которые пылесосят вакансии как не в себя, по всей стране (это что за дичь написана - не парсится).
Два талантливых джуна - уже на 4 курсе универа работают на пол-ставки ровно у тех, кто пылесосит вакансии по всей стране. По окончанию универа переходят на ставку.
Тем более, если они пытались реально копать индустрию. Если нет - обычно выясняется, что не такие уж они талантливые и трудолюбивые (пытались копать).
Update: Кажется я и сам неясно выразился (и закономерно могут возникнуть те же недопонимания) - я не предлагаю "изучить qsort vs mergesort", я пишу о том, что: а) заранее неизвестно что у вас под капотом и что нужно изучать б) существуют нестандартные случаи, когда вам надо посмотрев на perf понять, что здесь что-то не так. в) нестандартных случаев много разных классов. Некоторые из них неочевидные, некоторые иногда важны иногда нет. Поэтому нужна или огромная насмотренность "что может пойти неправильно" или хорошее понимание "как in thumb-rule правильно". г) Понять "как правильно в теории" - путь которым идёт универ, и это куда быстрее чем отстмотреть все "неправильные" варианты или хотя бы сложить картину "неправильных ваниантов".
======================================
-есть Y а также я обычно использую Х - но Y неправлиьно - я же написал "обычно"
Ну вообще будем считать misunderstanding.
> А теперь задайте себе вопрос: в чём смысл тестирования merge sort'а? .... > И для каждого класса по отдельности вы берёте минимум, например. > ... branch predictions
(во-вторых: вы же про BP не серьёзно - пальцем в небо ткнули, да?) Так это обычно совсем не так выглядит. Вы половину факторов-то не знаете (про ту половину факторов что вы знаете - как раз проще) поэтому заряжаете какую-то выборку на тест и смотрите статистику - нормальная она или нет. И вот попалось вам что-то с поведением а-ля qsort (или key-collision в хэшмапе или экспонента в regexp или....) или наоборот логнормальное распределение (пальцем в небо - размеры файлов в директории). Отличия от гауссианы могут быть разными. Главное понимать где есть причина насторожиться.
> Непроверяемое утверждение. Ох... как хочется закончить с вами разговор. Кажется это называется докопаться до столба - при таком подходе вся наука непроверяема -- однако гипотеза + фальсифицируемость + верифицируемость таки работает. Феноменологически - это работает на мне. Если обобщать на прикладном уровне - выпускники универов, особенно хороших и приходят с более разумно рассуждают "сразу" (приходят с более разумными гипотезами) и код "здесь и сейчас" в мало-мальски нестандартной ситуации пишут лучше и растут быстрее.
А программистов "от сохи", которые в минимально нестандартной ситуации плывут - вдоволь насмотрелся, спасибо более не надо.
... Я явно написал «по умолчанию» (решать задачу а или а && b) в даже процитированном вами куске. Сколько магистрво CS нужно....
Писать бессвязную ерунду (путая собираемую статистику с целью исследования), грубить - выберите одно. Будем считать, что вы оба раза случайно описались.
Так вот условные "слияния" имеет смысл тестировать на разных данных ((*) внизу коммента вы прочитали разумеется) получим скорее всего гауссиану, а условных qsort - нет.
Однако чтобы понять где можно срезать углы (уменьшив объём тестирования в sqrt раз), а где надо брать N выборок данных и каждую из них гонять M раз - надо или сразу видеть, что perf запусков "странно расползся от запуска к запуску" либо вляпываться в эту проблему прежде. Проблема в том, что видов проблем бывает очень много и иметь опыт вляпывания в каждую из них - надо потратить очень много времени. А институт вам даёт "общую картину" обладая которой вы гораздо лучше ориентируетесь в том, что вообще происходит out of the scope того, что вы здесь и сейчас щупаете ручками.
Я бы сказал, что для технического специалиста есть (ок, 4 года назад был) довольно явный, хоть и субъективный milestone - тебе выгоднее, с учётом пользы и затрат времени прочитать (скажем за 2 часа) статью 2024 года, чем за час статью 2020 года.
С этого момента технический язык становится самоподдерживающимся и целенаправленно "учить" его можно прекращать.
Вам надо понимать: а) как данные в запросе влияют на производительность (*). б) как внутренний (и ненаблюдаемый) стейт системы влияет на производительность на тех же данных.
речь очевидно, о [пункт б]
Сводить задачу исключительно к пункту "б" не только не очевидно, но и противоестественно.
*) при фиксированных каких-то количественных характеристиках - например размерах запроса
В универе вас 5 лет учат "вширь" или "как оно бывает в принципе". А на работе вы хотите-не-хотитеучитесь вглубь "как оно вот здесь и сейчас у нас".
В итоге за исключением каких-то уникальных случаев "хорошее высшее образование => способность к обобщению => скорость самостоятельного обучшения" очень хорошо кореллируют.
Я бы это сформулировал так: чтобы посмотреть "out of the scope" надо быть или гением или знать, что за пределами рамки что-то есть (и желательно примерно понимать что есть).
II. В теоревре: Из теории вероятностей - разные интуитивные оценки условных вероятностей (и ошибок 1 \ 2 рода) прям тяжело не ошибиться если не знаешь что оно так бывает и не пробовал это оценивать.
под термином "матан" понимают "высшая математика нужная в профессия-нэйм Так просто сложилось исторически, т.к. матан читают всем студентам, в отличии от других разделов высшей математики.
Из того, что нужно прогерам / аналитикам / МЛ-щикам: - Мат.статистика (и теор-вер) - теория графов - линейная алгебра. 4. мат.анализ
Собственно по этой причине расшифровывать разговоное "матан" как "математический анализ" категорически неправильно.
но пока сколько я с профессиональными синоптиками не общался - никто из них в него особо не верит.
Несмотря на общую полезность комментария - вот это вот весьма ненадёжный признак. Мало кто имеет смелость, хотя бы себе признать "ну всё в моей профессии хх% рабочих мест больше не нужно скорее всего включая моё".
Рубль отрицательно вырос за эти самые 10 лет с 40р за доллар до 110р, но зато не до 200!
Во вторых 108 когда вы писали комментарий и 106 прямо сейчас.
А во первых - ну давайте возьмём округлённые в выгодную вам сторону данные - такой курс $ за 10 лет соотвеетствует "инфляции доллара в рублях" 10.6% годовых. Это примерно равно превышению ставки рублёвых вкладов над долларовыми. Т.е. просто положив деньги в банк и перекладывая их раз в девять месяцев вы вообще ничего не теряли.
Несколько неточностей в предисловии лучше поправить:
1. Переводом кода с одного ЯП на другой занимается транслятор (иногда применяют термин "транспилятор"). Компилятор - частный случай транслятора: компилятор переводит код с высокоуровневого языка (обычно ЯП) в машинный \ объектный код.
2. "передним/задним планом" фронтэнд и бэкэнд азывать не принято.
3. Сегодня (начиная с llvm) компилятор делят на frontend / middleend / backend
4. Лексер + парсер - малая часть фронтэнда. Основная часть фронтэнда - построение AST и специфические (обычно глобальные) оптимизации над AST.
Также добавлю вопрос от себя:
Лексер (в лексере-парсере) нужен для того, чтобы ваш парсинг был устойчив к разделителям и форматированию пользователя.
5. С peco (и вообще парсерами в python) не работал - а что у вас обеспечивает эту фунциональность?
Так да - нормальная проверка на наличие мозга у кандидата-джуна.
Я думаю что теория графов - самый востребованный раздел математики для чистых прогеров (для DS - теорвер + статистика, для ML - линейная алгебра + методы оптимизации).
Вы осетра-то урежьте.
В склонениях \ спряжениях список исключений такой, что делается или сторонними средствами или с таким количеством ошибок, что лучше не начинать.
Статья норм (за исключением всяких нюансов - например в leetcode заранее пишут, что дана ASCII строка).
Найм действительно сломан - т.к. выпускники курсов
обманутыдезинформированы рекламой платных курсов. После выпуска программистами они не являются и подают по 100 заявок на любую приличную вакансию,обманываядописывая опыт в резюме.Проблема почему к вам не идут приличные кандидаты - ну у вас максимально безотрадный стек (с одной стороны он не модный и бесперспективный, с другой IMHO скучный и унылый). Но тут уже ничего не сделать.
Мск, ЖК 2017 года постройки магазин у дома.
На двери объявление: "ищем продавца ЗП 2000р/смена" (* смена там 12 часов к стати).
Да и где вообще там сколько-нибудь значимые требования?
Меня поражает сюр вообще всей этой ситуации.
Я вот на прошлом месте работы пытался заняться наймом джунов (системное программирование) - через неделю уже выпускников курсов просто не рассматривал. Программистов, даже junior-программистов среди той дюжины, что я прособеседовал не было (я бы сказал, что там ни одного приличного trainee не было).
В любой (невырожденный для вашей задачи) граф A->B, B-C -- можно вписать дугу A->C и получить треугольник.
Если же вопрос про геометрическую (а не топологическую) интерпретацию треугольников - то сильно сомневаюсь что задачу можно достаточно хорошо сформулировать, чтобы не играть в игру "угадай что я имел в виду".
Два талантливых джуна - уже на 4 курсе универа работают на пол-ставки ровно у тех, кто пылесосит вакансии по всей стране. По окончанию универа переходят на ставку.
Тем более, если они пытались реально копать индустрию.
Если нет - обычно выясняется, что не такие уж они талантливые и трудолюбивые (пытались копать).
А то трезвый врач или учитель (я уже не говорю про юриста или финансиста) - вам правду о своей профессии напишет.
Доли в чужом непубличном бизнесе - выглядят как "последняя рука - рука дурака", об которые закрывают убытки реальные владельцы.
Update:
Кажется я и сам неясно выразился (и закономерно могут возникнуть те же недопонимания) - я не предлагаю "изучить qsort vs mergesort", я пишу о том, что:
а) заранее неизвестно что у вас под капотом и что нужно изучать
б) существуют нестандартные случаи, когда вам надо посмотрев на perf понять, что здесь что-то не так.
в) нестандартных случаев много разных классов. Некоторые из них неочевидные, некоторые иногда важны иногда нет. Поэтому нужна или огромная насмотренность "что может пойти неправильно" или хорошее понимание "как in thumb-rule правильно".
г) Понять "как правильно в теории" - путь которым идёт универ, и это куда быстрее чем отстмотреть все "неправильные" варианты или хотя бы сложить картину "неправильных ваниантов".
======================================
Ну вообще будем считать misunderstanding.
> А теперь задайте себе вопрос: в чём смысл тестирования merge sort'а? ....
> И для каждого класса по отдельности вы берёте минимум, например.
> ... branch predictions
(во-вторых: вы же про BP не серьёзно - пальцем в небо ткнули, да?)
Так это обычно совсем не так выглядит.
Вы половину факторов-то не знаете (про ту половину факторов что вы знаете - как раз проще) поэтому заряжаете какую-то выборку на тест и смотрите статистику - нормальная она или нет.
И вот попалось вам что-то с поведением а-ля qsort (или key-collision в хэшмапе или экспонента в regexp или....) или наоборот логнормальное распределение (пальцем в небо - размеры файлов в директории). Отличия от гауссианы могут быть разными. Главное понимать где есть причина насторожиться.
> Непроверяемое утверждение.
Ох... как хочется закончить с вами разговор. Кажется это называется докопаться до столба - при таком подходе вся наука непроверяема -- однако гипотеза + фальсифицируемость + верифицируемость таки работает.
Феноменологически - это работает на мне.
Если обобщать на прикладном уровне - выпускники универов, особенно хороших и приходят с более разумно рассуждают "сразу" (приходят с более разумными гипотезами) и код "здесь и сейчас" в мало-мальски нестандартной ситуации пишут лучше и растут быстрее.
А программистов "от сохи", которые в минимально нестандартной ситуации плывут - вдоволь насмотрелся, спасибо более не надо.
Писать бессвязную ерунду (путая собираемую статистику с целью исследования), грубить - выберите одно. Будем считать, что вы оба раза случайно описались.
Так вот условные "слияния" имеет смысл тестировать на разных данных ((*) внизу коммента вы прочитали разумеется) получим скорее всего гауссиану, а условных qsort - нет.
Однако чтобы понять где можно срезать углы (уменьшив объём тестирования в sqrt раз), а где надо брать N выборок данных и каждую из них гонять M раз - надо или сразу видеть, что perf запусков "странно расползся от запуска к запуску" либо вляпываться в эту проблему прежде.
Проблема в том, что видов проблем бывает очень много и иметь опыт вляпывания в каждую из них - надо потратить очень много времени.
А институт вам даёт "общую картину" обладая которой вы гораздо лучше ориентируетесь в том, что вообще происходит out of the scope того, что вы здесь и сейчас щупаете ручками.
Я бы сказал, что для технического специалиста есть (ок, 4 года назад был) довольно явный, хоть и субъективный milestone - тебе выгоднее, с учётом пользы и затрат времени прочитать (скажем за 2 часа) статью 2024 года, чем за час статью 2020 года.
С этого момента технический язык становится самоподдерживающимся и целенаправленно "учить" его можно прекращать.
Вам надо понимать:
а) как данные в запросе влияют на производительность (*).
б) как внутренний (и ненаблюдаемый) стейт системы влияет на производительность на тех же данных.
Сводить задачу исключительно к пункту "б" не только не очевидно, но и противоестественно.
*) при фиксированных каких-то количественных характеристиках - например размерах запроса
Вам, простите qsort уже приводили?
I. В принципе:
В универе вас 5 лет учат "вширь" или "как оно бывает в принципе".
А на работе вы хотите-не-хотитеучитесь вглубь "как оно вот здесь и сейчас у нас".
В итоге за исключением каких-то уникальных случаев "хорошее высшее образование => способность к обобщению => скорость самостоятельного обучшения" очень хорошо кореллируют.
Я бы это сформулировал так: чтобы посмотреть "out of the scope" надо быть или гением или знать, что за пределами рамки что-то есть (и желательно примерно понимать что есть).
II. В теоревре:
Из теории вероятностей - разные интуитивные оценки условных вероятностей (и ошибок 1 \ 2 рода) прям тяжело не ошибиться если не знаешь что оно так бывает и не пробовал это оценивать.
под термином "матан" понимают "высшая математика нужная в
профессия-нэймТак просто сложилось исторически, т.к. матан читают всем студентам, в отличии от других разделов высшей математики.Из того, что нужно прогерам / аналитикам / МЛ-щикам:
- Мат.статистика (и теор-вер)
- теория графов
- линейная алгебра.
4. мат.анализ
Собственно по этой причине расшифровывать разговоное "матан" как "математический анализ" категорически неправильно.
Несмотря на общую полезность комментария - вот это вот весьма ненадёжный признак. Мало кто имеет смелость, хотя бы себе признать "ну всё в моей профессии хх% рабочих мест больше не нужно скорее всего включая моё".
Ну то есть 2014 я условно не помню. А вот последние года 4 - помню, что ставка по $ была 2-2.5% (ставка по Евро была 0.5-0%)
Во вторых 108 когда вы писали комментарий и 106 прямо сейчас.
А во первых - ну давайте возьмём округлённые в выгодную вам сторону данные - такой курс $ за 10 лет соотвеетствует "инфляции доллара в рублях" 10.6% годовых.
Это примерно равно превышению ставки рублёвых вкладов над долларовыми.
Т.е. просто положив деньги в банк и перекладывая их раз в девять месяцев вы вообще ничего не теряли.
Ну и вот через 10 дней нашего разговора пришла статья - человек работал "1.5 года по ночам админом, а днём на пол-ставки QA, пока не сменил стек".
Я к тому, что реалии вот такие. Из этих реалий и следует исходить.
https://habr.com/ru/companies/sberbank/articles/861442/