All streams
Search
Write a publication
Pull to refresh
0
0
Send message

Отписал выше: в моем примере кандидат не смог и алгоритм нормально написать, а синтаксис был уже вишенкой на торте. Сомневаюсь что вы при всем перечисленном не можете написать алгоритм поиска максимального числа в массиве.


Можно написать не сортировку, можно бинарный поиск, обход дерева, что угодно.
Кандидат пишет крайне сложный проект с тысячей языков и технологий, не может отсортировать массив не только предложенным, но и любым вообще способом, и говорит что эта задача его недостойна, т.к. он занимается гораздо более важными и сложными вещами? Это тоже информация, причем даже не столько о уме и умении решать сложные задачи, сколько о soft-skills.

Да я тоже как бы немало языков повидал, понимаю что "на кончиках пальцев" у каждого свое. В том примере что я привел соискатель и логику алгоритма построить правильно не смог, а синтаксис — то уже была вишенка на тортике.


Можно сказать "сорри, с циклами сто лет не работал, поэтому не ручаюсь за синтаксис" но написать правильный алгоритм, хоть на псевдокоде — это будет совершенно ок. Сказать "давно не работал с циклами, давайте сделаю через функциональщину", — тоже ок, еще и показывает что человек умеет договариваться и предлагать альтернативные решения. Можно через цикл, можно через reduce, можно даже через map, хоть это и семантически не очень корректно, можно через стримы, можно рекурсией, можно через фабрику алгоритмов поиска максимальных чисел. Конечно же каждая задача — это только повод к разговору, а не бездумный маркер прошел/не прошел.


А вот если просишь написать выбор максимального числа, а тебе говорят "на практике таких задач никогда не возникает, я решал другие задачи, и эту решать не буду. А если будет надо — погуглю две минуты и найду готовую функцию или скачаю пакет" — ну что ж, это тоже важная информация о кандидате.

Я тут описал сортировку выбором, пузырьковая менее интуитивная, не знаю кстати почему именно ее во всех учебниках и на собеседованиях приводят в пример как самую простую :) Сортировка выбором, я бы сказал, самая эффективная из "наивных" — тех, что можно придумать из головы прямо на ходу. Для того чтоб придумать более эффективный QuickSort нужен большой талант на грани с гениальностью.
И, кстати, умение сравнивать эффективность алгоритмов (О-нотация, вот это вот все) — тоже отличный навык, а то бывают случаи когда народ потом пишет пять вложенных циклов и удивляется почему же все тормозит.


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


Кроме того, другие задания в рамках собеседования и придумать-то трудно, не будет же фронтэндщик на бумажке писать мне верстку или компоненты реакта. Тут только тестовое задание поможет, но в моей конторе, например, тестовые задания не приняты.

Меня немного пугает когда сортировку пузырьком/выбором называют "табличной информацией", или что это оторванное от реальности задание. Тут же не просят написать реализацию хеш-таблиц, сжатие рядами Фурье или кодирование Хаффмана. Даже быструю сортировку не просят написать, в которой действительно надо более-менее помнить принцип.


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


У меня бывают случаи когда я человека который пришел собеседоваться на мидла прошу написать алгоритм поиска максимального числа в массиве, а он без IDE не может вспомнить как цикл правильно написать. С одной стороны да, он без этого прекрасно участвовал в проектах, да, эта задача решается стандартной библиотекой, и да, редко когда возникает на практике. Но камон ребят! — не уметь написать цикл — это днище даже для человека с полугодом опыта работы.

Через javascript, c3.js например

(оффтоп) Как нечто среднее между обычными офисными пакетами для презентаций и презентациями в виде программного кода могу посоветовать reveal.js


Разметка презентаций в HTML, соответственно если умеете верстать, то можно добиться отличных результатов гораздо быстрее и удобнее чем в PowerPoint. И плюс плагины, highlight-js подсветка кода, markdown-разметка, можно дополнительно написать свой js-код.


В свое время пришлось готовить много лекций, и reveal просто спас.

А причем Angular 2 к современному JS? Angular это штука которую надо учить отдельно, со своим синтаксисом и правилами.
Мне он, кстати, тоже совершенно не нравится, из-за того что при таком высоком пороге входа он предоставляет слишком мало удобных абстракций и структуры. Но это проблемы ангуляра, не JS. Ну, и к сожалению наши проблемы тоже, потому что толпы хомячков теперь ВНЕЗАПНО обнаружили что angular 1 плох, и ломанулись разрабатывать на angular 2.


Тем не менее, JS как язык сам по себе, начиная с ES-2015, весьма неплох, и при соблюдении минимальной гигиены (всегда использовать === вместо ==, использовать явное приведение типов, писать es-2015 классы непример) на нем можно писать очень хороший и выразительный код.


Какой JS фреймворк хороший? Конечно же тот который напишу я! Не забудьте поставить мне звездочку на гитхабе :)

Прошу прощения, разметку съел парсер почему-то.

Ничего не мешает сделать обработчики событий асинхронными, но в коде примеров в статье этого ведь не сделано.
Сказано что с помощью событий можно реализовать асинхронный код, а в примерах вместо этого написан синхронный (тут наверное уместно было бы подколоть автора что дескать сам не знает node.js — а все туда же :) )
Чтобы справиться с адом callback’ов, или пирамидой погибели (pyramid of doom), применяются эмиттеры событий. С их помощью можно реализовать асинхронный код с использованием событий.
nodejs.org/api/events.html#events_events
When the EventEmitter object emits an event, all of the Functions attached to that specific event are called synchronously.
То есть какой-то неправильный способ борьбы с callback hell предлагается, разве нет?

Information

Rating
Does not participate
Registered
Activity