Comments 40
да, мало того, я еще и финишировал в женском паке, т.е., считай, девочки меня тащили :) в свое оправдание могу сказать, что у меня серьезная травма колена и последние два круга все было очень плохо.
Как же вдохновляют подобные истории! Я будто сам всё вышепрочитанное пережил! Спасибо=)
«до работы мне ехать 5-7 мин, но я растягиваю удовольствие до 12 часов» долго думал как можно 5-7 минут на 12 часов растянуть))
Есть только одно место, где тебя не понимают и не хотят понимать – почта Чехии. Я больше чем уверен, что это филиал почты России. Зато это такой кусочек Родины, с той лишь разницей, что тебе хамят по-чешски.
Хм, интересно почему такая разница со словацкой почтой. Здесь и в Братиславе и в Банской-Быстрице всё очень вежливо и с улыбками, даже в самый первый день, когда мы с женой словацкий совсем не знали.
Никаких проблем с Česká pošta у меня, например, не было. Возможно зависит от района Праги.

Странно, на счет почты. Как раз с почтой ни разу проблем не возникало. Я ее сначала опасался, как и наверное каждый приехавший из СНГ, а сейчас это моя основная служба доставки. Быстро и под домом. А вот где действительно отказались говорить на любом языке кроме чешского, и даже показали пальцем на распечатанную выдержку из закона, это в отделении муниципалитета заведующего заменой водительских прав ( на Вышеграде). Кстати, хотя права и меняют без переэкзаменовки еслииподал вовремя, в случае с Украиной это может занять до года. Они шлют официальный запрос в Украину за подтверждением. Я вот пол года жду, пока глухо :)

Можете поподробнее расписать про получение визы? (можно мне в личку или отдельным постом, у меня тоже наклевывается трудоустройство в CR, но после прочтения форумов о том, что рабочую визу можно получить и за 2 месяца, а можно ждать 4-6, а можно и вообще не получить, хотелось бы пообщаться с кем-то кто недавно через это прошел..) Скажите, у вас трудовая карта или синяя? Как думаете, по какой проще и быстрее?
Есть также огромный аутлет, где можно купить по настоящим скидкам брендовые шмотки.

Где и как он называется? Из дешевых брендовых аутлетов знаю только TKMaxx, которого нет в Чехии, к сожалению.

Нет никакого языкового барьера в 21 веке: любое мобильное устройство говорит и понимает на любом языке.

а на улице как общаться будете, а на работе? А если под рукой не будет мобильного устройства? Барьер есть и он очень остро стоит. Так как за последние 15-20 лет благодаря развитию интернета международные проекты/команды стали обыденным делом. И сейчас без разговорного английского и я имею ввиду нормального, а не типа — май нейм из Вася, в ИТ особо делать нечего, имхо
речь идет о барьере психологическом, который сильно мешает в изучении языка. Язык нужно учить обязательно, а если ты еще и перехал жить в другую страну, то уж, будь любезен, изучай язык и ассимилируйся.
Если говорить о продуктовых магазинах, то я не заметил разницы ни в цене, ни в выборе.

не согласен, был этой зимой в Праге и цены очень даже отличаются (ну как минимум от Украинских, сравниваю в контексте Харьковских цен). Ну если конечно для вас зайти перекусить в обычное кафе на двоих за 3000 рублей не является обыденным делом.
UFO landed and left these words here
Вообще тут вся молодежь очень хорошо говорит на английском, а люди старше 40 кое-как, но говорят на русском.

извините, но очень громкое заявление. По моему опыту — русский практически никто не знает, даже за 40. Разве что редкие исключения. Первое время тоже пытались обращаться к людям пожилого возраста, так как гид сказала они скорее всего будут знать русский. Потом просто забили и перешли на англ.

Английский — ну каждый 3й-4й и то ломанный. Конечно тебе криво-косо объяснят, как добраться туда то или где купить это, но называть это «очень хорошо говорит на английском» я бы ну никак не стал. Единственное где я общался без проблем на англ — отель, но там им положено.
Спасибо за максимум информации в минимуме текста. Похоже на философию ваших продуктов =)))
Раз уж пошла такая пьянка, то можно поинтересоваться, кто придумывал требования к вашему тестовому заданию? Я конечно понимаю, что разработчик должен знать внутреннюю кухню .Net в принципе, а для вашей специфики, multi-thread в частности, но запрещать использовать не то, что async-await (а ведь уже лет пять прошло, не меньше), но и даже ThreadPool — это какой-то нонсенс. Плюс требование к производительности на уровне коммерческой разработки в, минимум, пару дней. То есть 16-20 человеко-часов полного погружения. Ну, и вишенка на торте — знание глубин определенного формата. Всё это в сумме ну никак не тянет на тестовое задание!
Да ладно, чего вы. Нормальное тестовое задание. В неспешном режиме спокойно делается за вечер + полчаса утром для оценки свежим взглядом.

Мое частное ИМХО тут следующее:

1. Ограничения на используемые технологии даны не по причине старперства, а только потому, что от соискателя хочется уловить понимание некоторых основополагающих вещей, а не просто умение сложить готовые кубики в нужном порядке. На Dataflow, например, весь алгоритм вообще строчек в 15 укладывается, 10 из которых — настройка конвейера.

2. Требование к производительности очень простое: либо вы умеете parallelism & concurrency — и у вас работает достаточно быстро, либо не умеете — и оно работает как работает. От коммерческих же требований тествое задание ой как далеко…

3. А за формат у вас вообще стрим отвечает — так что знать, как оно работает, совершенно без надобности.

PS. Андрюха, привет. Поздравляю с продолжением цикла (надеюсь, цикла) статей. :)
  1. Много Вы встречали программистов, которые знают что такое Dataflow как архитектура или хотя бы слышали о ней? Если же речь идет об реализации её в TPL -то вообще-то этой библиотекой так же запрещено пользоваться! И замете, я так же упомянул, что
    разработчик должен знать внутреннюю кухню .Net в принципе, а для вашей специфики, multi-thread в частности
    , что все равно не снимает настолько жестких ограничений. На худой конец, потом на собеседовании можно поспрашивать как на самом деле это работает внутри.
  2. Все-таки у меня сложилось впечатление, что требование больше к реализации, чем к быстроте. Ясно,
    что если все совсем криво и косо — это одно, а если просто проигрывает на один такт процессора за каждую итерацию — то возможно это и не плохое отставания от идеала. И что все-таки в итоге важнее красота кода или скорость работы? В смысле, (здесь конечно так не выйдет, но все же) если это будет один огромный метод main с не говорящими названиями переменных, но работать будет быстрее вашего гипотетического идеала, это хорошо или плохо?
  3. То есть, Вы не знаете как правильно сжимать данные по кускам Stream'ом? В принципе, если задача разжатия не стоит, то да, думать совсем не надо. Иначе же, надо покопаться в zip-формате и понять что куда дополнительно писать и как потом читать.

В сумме, это никак не тянет на
В неспешном режиме спокойно делается за вечер + полчаса утром для оценки свежим взглядом.
, если конечно Вы это уже однажды не реализовали, а сейчас по памяти написали.
1.1. Основной шаблон использования Dataflow — это реализация паттерна Producer-Consumer. Как разработчик, позиционирующийся не на джуниора (для джунов, по-моему, другое тестовое), о паттерне вы знать, в общем-то, должны. А то, что Dataflow — это реализация этого паттерна в .NET — подсказывает элементарный гугловый запрос, ведущий на страничку msdn вот прям сразу.
1.2. Далее, вы немножко не уловили мою мысль про Dataflow. Я его приводил как пример того, почему вызывающие у вас праведный гнев ограничения в ТЗ имеют место — без них задача скатывается от интересной (ручной менеджмент потоков) к совершенно элементарной (настройка конвейера). Использование async/await находится где-то посередине, этих двух границ, но ближе к правому краю.
1.3. «потом на собеседовании можно поспрашивать как на самом деле это работает внутри». Вы удивитесь, но есть такой класс людей, которые на словах могут чуть ли не ОС за неделю наклепать с Косынкой и браузером, а на практике у них даже hello world затруднения вызывает. Потому, собственно, и существует такой формат, как ТЗ.

2. Тут вопрос, скорее, философский. И для ответа на него нужно держать в уме ответы на такие вещи как «что мы хотим получить, задействовав параллелизм?» и «для каких целей обычно используется C#?». На первый вопрос ответ, в общем-то, очевиден: получить ускорение, примерно пропорциональное числу задействованных вычислительных устройств (для педантов см. закон Амдала). Если мы запустили идеально параллелящуюся задачу на одном ядре, и она выполнилась за 1 минуту; а затем запустили ее на 8 ядрах, и она отработала за, допустим, 50 секунд, то как бы вы ни доказывали правильность своего решения, очевидно, что поставленную задачу вы не выполнили — не показали умения правильно жонглировать потоками, да и саму суть внедрения параллелизма не улавливаете.
Ответ на второй вопрос более субъективен, но лично для меня C# — язык описания сложной бизнес-логики продуктов, поэтому код на нем не обязан быть таким же быстрым, как, например, C++, но должен быть читабельным. И с этой точки зрения, если мы возьмем две реализации ТЗ в равных условиях, одна из которых выполняется 13 секунд и при этом понятно написана, а другая — 12.5 секунд, но изобилует магическими приемами и понятна только автору (и то только пару часов после написания) — я б голосовал за первый вариант. Другое дело, что «быстро» и «красиво» — вещи зачастую не противоположные, а просто перпендикулярные.
Мне удалось ответить на ваш вопрос?

3. Правильный вариант использования стрима — однопоточно загнать в него данные, получить выхлоп, сохранить. Всё. Что происходит внутри стрима — зипование, рар-ание, поиск индекса по PiFS — для данной задачи не важно от слова «совсем». Но обратный процесс, конечно, тоже надо поддержать. Тут просто нужно немножко подумать, а не бросаться грудью на спецификацию формата.
1.1. Ну, я как раз примерно про это и говорил.
1.2. Ага, теперь мысль ясна.
1.3. А вот тут — не понял. Что же это за спецы проводят собеседования, если не могу разглядеть человека который много о себе мнит, но по факту ничего не знает? Я в свой жизни провел конечно не очень много собеседований, но ошибся лишь однажды и то не в уровне знаний, а в уровне ответственности и исполнительности. С моей точки зрения, тестовое задание можно списать в интернете или попросить написать другого разработчика. А вот собеседование — уже не подделаешь.

2. Тут наши мнения сходятся.

3. А Вы что тогда, извините за дерзость, собрались распараллеливать? Чтение файла с диска? Тогда, в случае обычного HDD Вы вообще потеряете в производительности. С SSD — никакого прироста не будет. И только в случае RAID с зеркалированием…
Единственный процесс в задании, который можно параллелить — сжатие. А значит разобраться в формате все же придется, иначе разжать не получится.
1.3. Есть очень большая пропасть между «знать» и «уметь». Если вы, например, выучите содержимое всех книг по медицине, и сможете мне процитировать из любой из них «страница 15, параграф 3, третье слово» — на операцию я к вам все равно не лягу, пока свои знания вы не подкрепите практикой.

На собеседовании очень хорошо проверяются знания: «Расскажите нам про SOLID», «Какова сложность у алгоритма быстрой сортировки», немножко проверяется соображалка «А как бы вы, любезнейший, решили вот такую задачку» и что-то среднее между знанием и жизненным опытом: «А что будет, если нагнуть C# вот в таком направлении — чего, конечно, на практике лучше не делать». Причем вопросы зачастую однотипные от конторы к конторе, что, в пределе, проверяет навык прохождения технических собеседований, а не реальные компетенции соискателя.

ТЗ же больше приближено к реальной работе, когда в спокойной и комфортной обстановке под кофеек человек ваяет задачу. И тут можно гораздо больше вещей оценить: не только знанния и опыт, но и аккуратность, подходы к написанию и структурированию кода. + все-таки исключается стрессовый фактор, что меня, например, как соискателя, радует.

Попросить написать — можно. Тут как со сдачей лабораторных в вузе — если смог на защите рассказать, что тут и как — молодец. Не можешь объяснить, что ты тут «написал» — ну, извини…

3. Я подсказывать не буду, т.к. это, в первую очередь, нечестно по отношению к вам. Но что-то мне кажется, что к исходному тестовому заданию вы добавили от себя некоторый пункт, и теперь пытаетесь его победить. :)
1.3. Мы уже далеко отошли от изначальной темы, но вопрос мне интересен, так что еще немного пооффтопим.
Я нигде не говорил, что тестовое задание (ну, не могу я его до ТЗ сократить, ибо для меня это техническое задание) не нужно. Просто не надо делать его слишком сложным и ждать, что его толпами побегут решать Senior Developer'ы и Team Lead'ы. Обычно, это довольно занятые люди чтобы отвлекаться от повседневном работы, а по вечерам и выходным дням у них уже расписаны какие-то личные дела. Для Jubior'ов, как Вы уже заметили, задание вообще другое. По мне, тестовое задание на такие позиции — это именно
аккуратность, подходы к написанию и структурированию кода
Дальше уже на собеседовании проверяете проверяете знания по позиции (ну смешно же, когда приходишь собеседование на позицию Senior, а тебя спрашивают чем отличаются Value типы от Reference, уж спросите хотя бы в чем отличия Class от Struct и убьете двух зайцев сразу).

3. А мы точно говорим об одном и том же задании?
В любом случае, решение мне известно, ибо я его описал в приложении к заданию, где уточнил, что считаю его наиболее подходящим, но слишком сложным для тестового задания. Ответ же был: "Именно такого решения мы и ждали.". Однако, просто чтобы сразу расставить все точки над i, согласился я его решать больше из-за интереса самого процесса решения, так как тема мне интересна, а не потому, что жаждал эту работу.
На интервью мне сказали, что тестовое задание отражает уровень реальных задач, которые встают перед разработчиком. Если кандидат не может справиться с тестовым заданием, то скорее всего в работе ему будет слишком тяжело.
Хм, искать достаточно сильного разработчика, который может потратить пару рабочих дней на выполнение тестового задания вместо прямых обязанностей? Ну-ну!
Ну в Питере обещают заморозить цены на ОТ до 20го года. Так что возможно скоро и здесь будет такое счастье.
Жена тоже работает в IT? Как вообще сложилось с трудоустройством второй половинки? Спасибо
Расскажите, пожалуйста, поподробнее про зарплаты программистов в Чехии и сколько конкретно стоит жилье. Я был 2 раза в Праге как турист, сам живу и работаю в Германии, хотелось бы сравнить.
Ну вот ни разу не программировал ничего для мира бэкапов, но в дыру за кроликом Прагу я бы нырнул.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

10 November 2006

Location

Швейцария

Website

veeam.com

Employees

1,001–5,000 employees

Registered

27 August 2012