А раньше как отличали? Беседой. И никто не умирал при этом, и кандидаты успешно находились. Как же это как, интересно? Потому что это было собеседование, а не вступительный экзамен, как сейчас. Но да, собеседование в таком режиме требует от интервьювера соответствующих навыков и опыта, а не сравнивания ответов задач.
> Как быть для инженеров — хз, не моя тематика
Программист — это в первую очередь инженер (как инженер-механик). Есть программисты-ученые (это как физики), которые занимаются computer science. Написание продакшн-кода — это почти несвязанный с этим процесс. Но многие этого не понимают и продолжают нанимать физиков для проектирования трансмиссий.
Если вы не можете отличить балабола от опытного специалиста — вы плохой собеседующий. Если пытаетесь сделать это с помощью литкода — вдвойне. Потому что литкод не показывает умения проектировать архитектуру, не показывает умения грамотно структурировать проект и декомпозировать задачу. Литкод — это алгоритмическое задротство.
Вы — не гугл. Вы не можете пользоваться этой методикой. Гугл ее использует, потому что богат и может себе позволить найти задротов, нанять их, а потом спустя год работы отсеять тех, кто не имеет инженерных навыков. Вы за год работы этих самородков потеряете деньги и получите малоподдерживаемое глючное дерьмо в продакшне.
> от «инженера» требуется, скажем, умение крутить гайки.
Вы точно понимаете, что именно делает инженер? Подсказка: он не крутит гайки. Ну, может, крутит немного, но разве что на прототипе.
> Как понять, что я инженер, а не токарь Вася с завода?
Пообщайтесь по предметной области, коснитесь углубленно каких-то тем, попросите показать, над чем он работал раньше. Конечно, это будет проблемой, если вы сами плаваете в теме. Тогда да, задачки с литкода — ваш выбор.
> молоть языком горазды
Как отсеять болтуна-физика, прикидывающегося инженером?
Почему нужно брать инженера, а не физика, чтобы разрабатывал трансмиссию для автомобиля?
Инженерное искусство состоит в умении хорошо скомпоновать готовые решения, сделать конечный продукт поддерживаемым и простым в расширении, а так же в умении видеть необходимость оптимизации, когда нужно делать что-то новое. Если готового решения не существует, пойти и разработать свое собственное. Если не хватает экспертизы — посоветоваться с кем-то.
> В смысле, нельзя распараллелить?
Имелся в виду один кадр
> один кадр — один поток
Верно, а потом склеивать их, но с сохранением очередности. Или дропать фрейм, если поток не успел в отведенное время и уже был закодирован следующий. Ответ, которого я ждал.
> Но в любом случае, можно после одной непараллельной части для построения таблицы хаффмана, кодировать все параллельно.
Можно. Или так, как в предыдущем варианте. Но тут бы надо производительность замерить, потому что может быть не слишком большой выигрыш. То есть это не полностью параллельный алгоритм, стадия reduce тоже довольно тяжелая. Плюс мы получаем огромное количество переключений контекста на одну картинку. Так что сжимать фреймы целиком все-таки лучше.
> Начну с изучения бизнес-требований.
Все правильно, но давайте попробуем решить именно техническую задачу. Предположим, что от вас хотят получить пачку жопегов в реальном времени с задержкой не более 200ms и максимальным fps.
> На одной стороне суперопытный инженер, который при этом не написал самостоятельно ни одного алгоритма сортировки, на другой — суперопытный олимпиадник, который годами только сортировку и пишет, ни на что более не отвлекаясь :)
Бинго. При этом поклонники собеседования на senior sortirovatel developer считают, что достаточно искать именно вторых, а остальное как-нибудь приложится.
> Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить
Пожалуйста, задачка из моей практики. Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?
> на которой запнулся реальный чувак, который не умел писать алгоритмы
Почему вы вообще противопоставляете алгоритмы реальному программированию? Программирование — оно целиком про алгоритмы, сюрприз. Если вы берете инженера, а не кодо-макаку, у него не возникнет проблемы увидеть необходимость разработки алгоритма.
Главный навык — это проектирование, а не задроство литкода. Задротство литкода не даст вашему гению списков знаний об RFC или том как правильно проектировать протоколы или плагиновую архитектуру. Зато результат работы этих гениев видео невооруженным взглядом: уродливые библиотеки и бесконечные велосипеды.
Программист — это в первую очередь инженер (как инженер-механик). Есть программисты-ученые (это как физики), которые занимаются computer science. Написание продакшн-кода — это почти несвязанный с этим процесс. Но многие этого не понимают и продолжают нанимать физиков для проектирования трансмиссий.
Если вы не можете отличить балабола от опытного специалиста — вы плохой собеседующий. Если пытаетесь сделать это с помощью литкода — вдвойне. Потому что литкод не показывает умения проектировать архитектуру, не показывает умения грамотно структурировать проект и декомпозировать задачу. Литкод — это алгоритмическое задротство.
Вы — не гугл. Вы не можете пользоваться этой методикой. Гугл ее использует, потому что богат и может себе позволить найти задротов, нанять их, а потом спустя год работы отсеять тех, кто не имеет инженерных навыков. Вы за год работы этих самородков потеряете деньги и получите малоподдерживаемое глючное дерьмо в продакшне.
Вы точно понимаете, что именно делает инженер? Подсказка: он не крутит гайки. Ну, может, крутит немного, но разве что на прототипе.
> Как понять, что я инженер, а не токарь Вася с завода?
Пообщайтесь по предметной области, коснитесь углубленно каких-то тем, попросите показать, над чем он работал раньше. Конечно, это будет проблемой, если вы сами плаваете в теме. Тогда да, задачки с литкода — ваш выбор.
> молоть языком горазды
Как отсеять болтуна-физика, прикидывающегося инженером?
Инженерное искусство состоит в умении хорошо скомпоновать готовые решения, сделать конечный продукт поддерживаемым и простым в расширении, а так же в умении видеть необходимость оптимизации, когда нужно делать что-то новое. Если готового решения не существует, пойти и разработать свое собственное. Если не хватает экспертизы — посоветоваться с кем-то.
Имелся в виду один кадр
> один кадр — один поток
Верно, а потом склеивать их, но с сохранением очередности. Или дропать фрейм, если поток не успел в отведенное время и уже был закодирован следующий. Ответ, которого я ждал.
> Но в любом случае, можно после одной непараллельной части для построения таблицы хаффмана, кодировать все параллельно.
Можно. Или так, как в предыдущем варианте. Но тут бы надо производительность замерить, потому что может быть не слишком большой выигрыш. То есть это не полностью параллельный алгоритм, стадия reduce тоже довольно тяжелая. Плюс мы получаем огромное количество переключений контекста на одну картинку. Так что сжимать фреймы целиком все-таки лучше.
> рок-звезда
Выберите что-то одно.
Все правильно, но давайте попробуем решить именно техническую задачу. Предположим, что от вас хотят получить пачку жопегов в реальном времени с задержкой не более 200ms и максимальным fps.
> На одной стороне суперопытный инженер, который при этом не написал самостоятельно ни одного алгоритма сортировки, на другой — суперопытный олимпиадник, который годами только сортировку и пишет, ни на что более не отвлекаясь :)
Бинго. При этом поклонники собеседования на senior sortirovatel developer считают, что достаточно искать именно вторых, а остальное как-нибудь приложится.
Надо только понимать, что по большей части эти крутые коллеги пришли еще до того, как начался этот театр абсурда с собеседованиями.
// тоже бывший яндексоид
Пожалуйста, задачка из моей практики. Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?
> на которой запнулся реальный чувак, который не умел писать алгоритмы
Почему вы вообще противопоставляете алгоритмы реальному программированию? Программирование — оно целиком про алгоритмы, сюрприз. Если вы берете инженера, а не кодо-макаку, у него не возникнет проблемы увидеть необходимость разработки алгоритма.
Главный навык — это проектирование, а не задроство литкода. Задротство литкода не даст вашему гению списков знаний об RFC или том как правильно проектировать протоколы или плагиновую архитектуру. Зато результат работы этих гениев видео невооруженным взглядом: уродливые библиотеки и бесконечные велосипеды.