Хорошо справились с собеседованием, оставили положительное впечатление.
Поэтому рада пригласить вас на следующий этап. Он будет посвящен уже Аналитике.
Подскажите, когда было бы удобно пройти?)
2 Добрый день)
Результаты получила и они оказались смешанными. Поэтому мы ещё их обсудим с руководителем и уже тогда я к вам вернусь с решением. Скорее всего завтра.
3 Из отзывов интервьюера, не проявляли достаточно критического мышления и мало генерировали гипотезы (то есть те гипотезы что придумывали - не находили в них изъяны ) + опыта продуктовой аналитики нет.
Из плюсов есть понимание и интерес к статистике, в этом плане видно что сами прокачивались, что является позитивным сигналом.
Но в любом случае, все зависит от многих факторов, так что предложу другим, возможно еще что-то допроведем)
4 Здравствуйте, Владимир)
Хорошо справились с прошедшим собеседованием, поздравляю вас!
И в эту команду необходимо пройти последнее собеседование, если с ним справитесь, то дальше финал.
Собеседование проверяет знание алгоритмов, нужно будет решить задачу на алгоритмы. Насколько для вас это сложно? Как оцениваете справитесь, будете проходить?)
5 На самом деле с алгоритмом получилось неплохо, но по формальным критериям не уложились во время
Да, подумайте. На том же финале вам, если что больше расскажут) Но я не уговариваю)
6 Владимир, здравствуйте
Я к вам со смешаными новостями.
Команде вы понравились, но нужно ещё одно собеседование
Если его пройдете так же, как проходили те, которые хорошо получались, тогда мы наконец сделаем вам оффер.
Подскажите, готовы будете на последний этап?
7 Владимир, здравствуйте!
Я к вам с плохими новостями, к сожалению, с этим собеседованием не получилось и формально мы не можем вас пока к нам нанять
Возможно раз мы столько пробовали, но все таки нет, то пока не время идти к нам.
Но вы нам очень понравились и мы были бы рады видеть вам у себя через время!)
8 Владимир, привет!
Хочу вернуться с обратной связью, мы рады пригласить тебя на следующий этап интервью, проектирование процессов, подскажи, на какой день и время было бы удобно запланировать?
9 Ну тут такой фидбэк:
Кандидат приятный в общении, хорошо знает python и pandas. Гуглил достаточно много, но по делу, на замечания хорошо реагировал, ошибки исправлял сам. С графиками было сложновато. Предложил простое правило определения выбросов и аномалий. Немного не хватило знаний статистики, чтобы быстро определить выбросы. Неосновательно подумал над другими сезонностями, трендами, кроме дневной.
По баллам - ок) Пока не на супер выскоий грейд, но есть шанс затащить на Матстате
10 Владимир, по матстату не очень удачно вышло, к сожалению (
Задачу на логику (монетка с двумя равновероятными исходами) решить удалось, про эксперементы в целом тоже неплохо получилось ответить, с теорией вероятности и матстатом (распределение pvalue) хуже все вышло.
Дальше, к сожалению, не смогу предложить собеседования, хоть по этой секции не отказ, но по совокупности двух не сможем в итоге сделать нормального предложения
11 привет!
в роботы пока, к сожалению, не готовы если не против, могу пошерить на другие команды яндекса
В: Да, было бы неплохо
В: Интересно, вроде все задачи решил
там по аналитике-математике старая секция не очень хорошо пройдена а тех вот эта хорошо
Если хочешь, можем аналитику перепройти попробовать
в sicp и в этой статье описано в точности "символьное дифференцирование" (symbolic differentiation), у вас в статье по ссылке оно тоже упоминается. а вот чем от него отличается автоматическое, я что-то сходу из статьи на вики не понял. там видимо что-то среднее между численным и символьным
Не возьмусь воспроизвести позицию дословно. Но что-то из этого:
С высокой степенью вероятности получится что-то, что очень неэффективно использует бд. И при этом с этим будет очень сложно работать, а тем более оптимизировать. Приносит новый уровень сложностей с транзакциями, кроме особенностей вашей бд. А специалисты по вашей бд не смогут вам помочь со всеми этими проблемами.
Простые вещи делаются примерно так же просто, как и без всей этой мишуры, а сложные даже сложнее. При этом это всё заметно тормозит даже в простейших случаях
Уже минимум лет 10 наверное в сумме разрабатываю на Java без использования JPA и прочих Хибернейтов. Когда же это чудо попадалось (суммарный опыт несколько больше 10), то справлялся с ним не хуже остальных. Поработал в том числе в разных крупных российских компаниях. На текущем месте, например, у нас есть общая рекомендация избегать подобного рода ORM-ов.
Если бы php внутри компаний, занимающихся разработкой, был бы так же распространён, как JPA среди джава проектов, то для того, чтобы работать программистом, php был бы ключевым навыком.
Про PHP я сказал к тому, что можно с тем же успехом сказать:
Потому, что PHP сейчас практически везде. Куда бы вы не пришли, там с высокой вероятностью где-то будет сайтик на PHP.
Далеко не факт правда, что вам придётся им заниматься). Так-то, куда ни пойди, везде в компаниях ещё 1C есть. Но меня из-за того, что я его не знаю, никто на выход не просит) Да и вообще, про JPA спрашивали вроде только в Люксофте, остальные даже если и используют, то не распрашивают про него на собесах
бинарный поиск по постоянно поддерживаемому сортированному набор строк
какая по вашему будет сложность вставки в такой список? и устроит ли она вас? мне кажется, что вас хоть и не поняли, но вариант вы предложили так себе. хотя и возможно, что если уточнить задачу и ваше предложение, то окажется, что всё хорошо
"Ниспадающее программирование" - это какое-то изобретение докладчика или нестандартное написание для "разработки сверху-вниз"? А то гугление по этому сочетанию приводит только к этому анонсу в разных местах
Почитал, что у них под контролем, и оказалось, что российским аккаунтом или виртуальной картой конечно же никакие зарубежные сервисы оплатить не получится. Это наверное возможно с казахской виртуальной карты (хотя явно это не написано, или я не нашёл), но не понятно, как её выпустить, находясь в РФ (похоже, что никак)
Вы так говорите, как будто успех на рынке не зависит (или слабо зависит) от различного рода случайностей. К тому же более эффективная по совокупности компания вполне может проигрывать в какой-то из областей, в т.ч. и по технической части. Например, аналогичный продукт может требовать значительно больше ресурсов на поддержку и развитие, но быть лучше разрекламирован и пр.
Ну, начальство поступило, по-моему, самым разумным способом в этой ситуации: просто заизолировало его проект и не лезло к нему.
Так это худшее, что можно сделать! Теперь у них есть проект, в котором разобраться может только один человек. Что будет, когда он уволится? Почему нельзя было на этот проект, раз он такой крупный, выделить ещё хотя бы одного человека? Чтобы они работали вместе, друг-друга ревьювили, обсуждали технические решения и пр.
Вы невнимательно читали. У меня нет под рукой самой книги, но вот цитата из вики, которая хорошо соответствует тому, что я запомнил после прочтения:
..., то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N, рост числа программистов замедляет выполнение проекта.
В вики точного числа не приведено, но емнип Брукс говорил о пределе около 7 разработчиков в команде. Так что даже если сделать двойное резервирование и назначит на сервис трёх человек, то это всё ещё будет полезно и для скорости его разработки. К тому же это позволит применять такие полезные практики, как code review.
Вообще, "концентрировать усилия" и "останавливаться на одном" обычно предлагают люди, которые вообще не понимают, как работает open source (и социум в целом), какая у людей бывает мотивация и пр. Довольно глупо думать, что если есть две чем-то похожих разработки и одну из них как-то насильственно свернуть, то все её разработчики тут же бросятся работать над второй. А подобные ребята обычно предполагают что-то такое у себя в голове.
Когда у тебя не монолитная система с gui, а просто набор компонент, то проблемы будут вылазить из этого
Это голословно, необоснованно и неверно. Выделение ортогональных ответственностей в разные модули является признанной полезной практикой в разработке. Не слышали классическую мантру про "low coupling and high cohesion"? Если на пальцах, то монолит имеет тенденцию к возникновению в нём связей между частями, между которыми связей быть не должно (классический пример из области web разработки - это поход в БД из кода, который рендерит страницу), которые приводят к повышению хрупкости всей системы (меняешь что-то в GUI, а ломается что-то в ядре) и увеличению количества багов. У Linux несомненно много проблем (как и любого другого крупного программного продукта), и есть недостатки по сравнению с Windows в роли десктопа (лично для меня преимущества перевешивают, но я хорошо осознаю, что у других людей другие потребности и приоритеты), но разделение графической подсистемы и ядра - это бесспорно архитектурное преимущество Linux. Да и не только архитектурное: под Windows практически отсутствуют альтернативные DE или WM.
К тому же, в первых версиях Windows GUI был интегрирован с ядром для оптимизации, и они даже уже от этого ушли.
Не совсем так. Считать, что программист, который пишет меньше кода, работает хуже — это уже очень вредно и в корне неправильно (выше в комментариях подробно про это написано). А то, что в команде не нашлось людей, кто смог бы это объяснить — это и вовсе очень плохой знак. Можно надеяться только на то, что автор статьи просто поигрался с графиками, ни на какие решения не влияет, а метрику "количество кода" никто из управленцев на самом деле не использует.
О. Нашёл как картинки делать
Скрытый текст
Скопировал кое-как текст:
Скрытый текст
1 Владимир, здравствуйте.
Я к вам с обратной связью, вы молодец.
Хорошо справились с собеседованием, оставили положительное впечатление.
Поэтому рада пригласить вас на следующий этап. Он будет посвящен уже Аналитике.
Подскажите, когда было бы удобно пройти?)
2 Добрый день)
Результаты получила и они оказались смешанными. Поэтому мы ещё их обсудим с руководителем и уже тогда я к вам вернусь с решением. Скорее всего завтра.
3 Из отзывов интервьюера, не проявляли достаточно критического мышления и мало генерировали гипотезы (то есть те гипотезы что придумывали - не находили в них изъяны ) + опыта продуктовой аналитики нет.
Из плюсов есть понимание и интерес к статистике, в этом плане видно что сами прокачивались, что является позитивным сигналом.
Но в любом случае, все зависит от многих факторов, так что предложу другим, возможно еще что-то допроведем)
4 Здравствуйте, Владимир)
Хорошо справились с прошедшим собеседованием, поздравляю вас!
И в эту команду необходимо пройти последнее собеседование, если с ним справитесь, то дальше финал.
Собеседование проверяет знание алгоритмов, нужно будет решить задачу на алгоритмы. Насколько для вас это сложно? Как оцениваете справитесь, будете проходить?)
5 На самом деле с алгоритмом получилось неплохо, но по формальным критериям не уложились во время
Да, подумайте. На том же финале вам, если что больше расскажут) Но я не уговариваю)
6 Владимир, здравствуйте
Я к вам со смешаными новостями.
Команде вы понравились, но нужно ещё одно собеседование
Если его пройдете так же, как проходили те, которые хорошо получались, тогда мы наконец сделаем вам оффер.
Подскажите, готовы будете на последний этап?
7 Владимир, здравствуйте!
Я к вам с плохими новостями, к сожалению, с этим собеседованием не получилось и формально мы не можем вас пока к нам нанять
Возможно раз мы столько пробовали, но все таки нет, то пока не время идти к нам.
Но вы нам очень понравились и мы были бы рады видеть вам у себя через время!)
8 Владимир, привет!
Хочу вернуться с обратной связью, мы рады пригласить тебя на следующий этап интервью, проектирование процессов, подскажи, на какой день и время было бы удобно запланировать?
9 Ну тут такой фидбэк:
Кандидат приятный в общении, хорошо знает python и pandas. Гуглил достаточно много, но по делу, на замечания хорошо реагировал, ошибки исправлял сам. С графиками было сложновато. Предложил простое правило определения выбросов и аномалий. Немного не хватило знаний статистики, чтобы быстро определить выбросы. Неосновательно подумал над другими сезонностями, трендами, кроме дневной.
По баллам - ок) Пока не на супер выскоий грейд, но есть шанс затащить на Матстате
10 Владимир, по матстату не очень удачно вышло, к сожалению (
Задачу на логику (монетка с двумя равновероятными исходами) решить удалось, про эксперементы в целом тоже неплохо получилось ответить, с теорией вероятности и матстатом (распределение pvalue) хуже все вышло.
Дальше, к сожалению, не смогу предложить собеседования, хоть по этой секции не отказ, но по совокупности двух не сможем в итоге сделать нормального предложения
11 привет!
в роботы пока, к сожалению, не готовы если не против, могу пошерить на другие команды яндекса
В: Да, было бы неплохо
В: Интересно, вроде все задачи решил
там по аналитике-математике старая секция не очень хорошо пройдена а тех вот эта хорошо
Если хочешь, можем аналитику перепройти попробовать
12 привет!
интересно было бы пофиналиться по этой вакансии?
https://yandex.ru/jobs/vacancies/analitikrazrabotchik-v-komandu-robototehniki-26277
Вакансия «Аналитик-разработчик в команду робототехники» в Яндексе - работа в компании Яндекс для ІТ-специалистов
Работа в компании Яндекс для специалиста
«Аналитик-разработчик в команду робототехники» с уровнем квалификации от
«Младший» до «Специалист» - Высокая заработная плата и социальные гарантии в ІТ-компании России
В: Привет. Боюсь вчера мне сделали очень заманчивый офер, поэтому перебить его врядли получится
В: спасибо за уделенное время)
и в конце мем про 43 этапа, разговорный драконий, его замену на квадроберство и тарологов
Я, чтобы прочитать, заскринил. Но прикрепить к комментарию не осилил(
в sicp и в этой статье описано в точности "символьное дифференцирование" (symbolic differentiation), у вас в статье по ссылке оно тоже упоминается. а вот чем от него отличается автоматическое, я что-то сходу из статьи на вики не понял. там видимо что-то среднее между численным и символьным
Не возьмусь воспроизвести позицию дословно. Но что-то из этого:
С высокой степенью вероятности получится что-то, что очень неэффективно использует бд. И при этом с этим будет очень сложно работать, а тем более оптимизировать. Приносит новый уровень сложностей с транзакциями, кроме особенностей вашей бд. А специалисты по вашей бд не смогут вам помочь со всеми этими проблемами.
Простые вещи делаются примерно так же просто, как и без всей этой мишуры, а сложные даже сложнее. При этом это всё заметно тормозит даже в простейших случаях
Уже минимум лет 10 наверное в сумме разрабатываю на Java без использования JPA и прочих Хибернейтов. Когда же это чудо попадалось (суммарный опыт несколько больше 10), то справлялся с ним не хуже остальных. Поработал в том числе в разных крупных российских компаниях. На текущем месте, например, у нас есть общая рекомендация избегать подобного рода ORM-ов.
Про PHP я сказал к тому, что можно с тем же успехом сказать:
Далеко не факт правда, что вам придётся им заниматься). Так-то, куда ни пойди, везде в компаниях ещё 1C есть. Но меня из-за того, что я его не знаю, никто на выход не просит) Да и вообще, про JPA спрашивали вроде только в Люксофте, остальные даже если и используют, то не распрашивают про него на собесах
какая по вашему будет сложность вставки в такой список? и устроит ли она вас? мне кажется, что вас хоть и не поняли, но вариант вы предложили так себе. хотя и возможно, что если уточнить задачу и ваше предложение, то окажется, что всё хорошо
DO залочили аккаунт при попытке оплаты этой картой или кто кого? paywithmoon как вообще работает? можно пользоваться?
"не рекомендую" что?
"Ниспадающее программирование" - это какое-то изобретение докладчика или нестандартное написание для "разработки сверху-вниз"? А то гугление по этому сочетанию приводит только к этому анонсу в разных местах
Почитал, что у них под контролем, и оказалось, что российским аккаунтом или виртуальной картой конечно же никакие зарубежные сервисы оплатить не получится. Это наверное возможно с казахской виртуальной карты (хотя явно это не написано, или я не нашёл), но не понятно, как её выпустить, находясь в РФ (похоже, что никак)
Т.е. php таки надо тоже было подучить?;)
Потому что "Один я умный в белом пальто стою красивый". По ссылке есть попытка разбора, почему так получается, а в комментах хорошая фраза:
Вы так говорите, как будто успех на рынке не зависит (или слабо зависит) от различного рода случайностей. К тому же более эффективная по совокупности компания вполне может проигрывать в какой-то из областей, в т.ч. и по технической части. Например, аналогичный продукт может требовать значительно больше ресурсов на поддержку и развитие, но быть лучше разрекламирован и пр.
Так это худшее, что можно сделать! Теперь у них есть проект, в котором разобраться может только один человек. Что будет, когда он уволится? Почему нельзя было на этот проект, раз он такой крупный, выделить ещё хотя бы одного человека? Чтобы они работали вместе, друг-друга ревьювили, обсуждали технические решения и пр.
Но ведь можно сходить в Википедию и найти там соответствующее предложение с парой сносок на источники!
иметь запас денег - это в принципе полезная стратегия)
Вы невнимательно читали. У меня нет под рукой самой книги, но вот цитата из вики, которая хорошо соответствует тому, что я запомнил после прочтения:
В вики точного числа не приведено, но емнип Брукс говорил о пределе около 7 разработчиков в команде. Так что даже если сделать двойное резервирование и назначит на сервис трёх человек, то это всё ещё будет полезно и для скорости его разработки. К тому же это позволит применять такие полезные практики, как code review.
Вообще, "концентрировать усилия" и "останавливаться на одном" обычно предлагают люди, которые вообще не понимают, как работает open source (и социум в целом), какая у людей бывает мотивация и пр. Довольно глупо думать, что если есть две чем-то похожих разработки и одну из них как-то насильственно свернуть, то все её разработчики тут же бросятся работать над второй. А подобные ребята обычно предполагают что-то такое у себя в голове.
Это голословно, необоснованно и неверно. Выделение ортогональных ответственностей в разные модули является признанной полезной практикой в разработке. Не слышали классическую мантру про "low coupling and high cohesion"? Если на пальцах, то монолит имеет тенденцию к возникновению в нём связей между частями, между которыми связей быть не должно (классический пример из области web разработки - это поход в БД из кода, который рендерит страницу), которые приводят к повышению хрупкости всей системы (меняешь что-то в GUI, а ломается что-то в ядре) и увеличению количества багов. У Linux несомненно много проблем (как и любого другого крупного программного продукта), и есть недостатки по сравнению с Windows в роли десктопа (лично для меня преимущества перевешивают, но я хорошо осознаю, что у других людей другие потребности и приоритеты), но разделение графической подсистемы и ядра - это бесспорно архитектурное преимущество Linux. Да и не только архитектурное: под Windows практически отсутствуют альтернативные DE или WM.
К тому же, в первых версиях Windows GUI был интегрирован с ядром для оптимизации, и они даже уже от этого ушли.
Не совсем так. Считать, что программист, который пишет меньше кода, работает хуже — это уже очень вредно и в корне неправильно (выше в комментариях подробно про это написано). А то, что в команде не нашлось людей, кто смог бы это объяснить — это и вовсе очень плохой знак. Можно надеяться только на то, что автор статьи просто поигрался с графиками, ни на какие решения не влияет, а метрику "количество кода" никто из управленцев на самом деле не использует.