Врать не буду, сам не проверял, но у меня коллега оптимизировал затычку с производительностью, обнаружил, что find быстрее чем some, чуть менее чем на до хрена. Я был сильно удивлён. Так что константа тоже влияет. если она этак больше 4х. Да, ждать пару секунд, там где можно было ждать полсекунды, более приятно, чем ждать 60 (при достаточно больших n), но это тоже такое.
arr1.map(el1 => arr2.some(el1.id))
a = [1,2,3] (3) [1, 2, 3] a.some(1) VM123:1 Uncaught TypeError: number 1 is not a function at Array.some () at :1:3 (anonymous) @ VM123:1
Имелось ввиду, что some - тут это какое-то линейное действие? Я уж испугался, что не знал чего-то про .some
Да можно тут в Object.assign или присваивание и возврат. Но если в массиве мало - спред хорошая читаемая форма. А если много можно, присваивание в for или .forEach - для меня это оградка, что там реально экшен. Но опять же всё на вкус (и в данном случае на объём). Конечно, если объем неизвестен, лучше предполагать, что он большой.
Мне кажется вся статья скорее для лулзов. Хотя подана довольно серьёзно. Чужую статью каждый обидеть норовит )
Скорее - это значит, что я плохой интервьер, если не смог дотащить до решения. Я там выше в комментах писал, что задача на округление была придумана как развитие идеи задачи x => 7-х, поэтому мне показалось, что это хороший путь к решению. Но, опять же, пример абстрактный)
Во многом я с вами согласен, но идея статью все таки не обязательно о найме только сеньора, и градации кандидатов больше для лулзов, чем как руководство к действию.
Мне интересно смотреть кандидатов, в ситуации когда они сталкиваются с лютой дичью трудностями, а не образцово показательной задачкой.
По поводу some вообще не имею ничего против, как и против спредов в resume. Я знаю что some работает в некоторых случаях почти всегда медленнее, чем find/findIndex, а сред медленнее, Object.assign, или прямое присваивание свойства, если оно не одиночное (и то вкусовщина). Но читается и some и спред лучше, поддерживать проще (по моему мнению, так-то можно спорить). И если у меня нет задачи выжать железку до кровавого пота, то я использую и то и другое). И да, я чаще использую подготовленные маппинги внутри циклов, чем поиски с тем же some. Но опять же я не парюсь и в небольшой выборке воткну some и spred просто чтобы написать на несколько строчек кода меньше.
Ну и если в команде не принято some я не буду писать some ) Я и не в таких извращениях вполне разумных стандартах участвовал.
Часто, когда "затыкаешься" в коде, проблема не в том, куда копаешь. А в том куда надо копать. Но я уважаю и ваше мнение. Тут всё очень тонко. А наводящие вопросы просто экономят время интервью
Обычно я задаю вопросы по реальному коду. И если кандидат не может разобраться, то пусть он хоть крыло боинга в уме спроектировать может, то чем он мне может помочь? И да, если сразу идет туго, я задаю наводящие вопросы. Или подсказываю внешне кейсы, где код используется. Задача просто иллюстрация.
По поводу реального опыта и прочего. Эта статья - спин-офф другой статьи, где я как раз немного подстебываюсь над обобщаю опыт "технической составляющей" собеседований. Пока лежит в черновиках, но планирую в среду четверг дописать и опубликовать
Мне хотелось проиллюстрировать идею и я взял самую простую задачу, в которой можно было показать как можно прийти к результату с помощью наводящих вопросов. Мог бы взять например сортировку вставками - но статья была бы больше, а вопросы "зачем это спрашивать?" всё равно бы были. Задачу на округление я обычно подкидывал людям вне работы. На собесе очень редко и только в качестве доп. вопроса.
По повода проверки округления. Я лучше проверю, что кандидат умеет в округление, чем не проверю. Это пара минут, которые могут сэкономить много времени потом. Да, мне более важно как кандидат проверяет входящие параметры в задачах (с чем люди лажают чаще, чем с округлением), но и бывают люди и не умеющие в округление с вполне приличным резюме. Если бы я с такими не сталкивался, я бы и не проверял, для меня это было откровением.
Я не готовился к собесу Яндекса. Я вообще был удивлён, почему они моё резюме рассматривали, у меня з/п стояла выше рынка. Но на собес сходил, получил удовольствие. Выяснил на след собесе (алгоритмическое я прошёл), что им требовались еще и хорошие скилы девопса. Увы, это пока(?) не ко мне.
Если бы соискатель написал бы % - я бы сказал, что его тоже нельзя ) Мне нужно прийти именно к безтернарному виду. По крайней мере без тернарника вне параметров Math.floor
У меня был начальник, который любил задачу для собеса, в которой надо было работать с остатками. И я сам бы удивлен, что задачка такая простая, когда сам проходил собес. И ещё больше тем, что половина кандидатов на сеньорскую (!) позицию не знала как взять остаток нативно или хотя бы с помощью функций округления.
Но и задавать вопрос соискателю про его, возможно, вопиющую некомпетентность в лоб не очень хорошая идея. Да и практические навыки чего бы не проверить?
Я всегда люблю в оптимизацию, иногда излишне, но часто сталкивался с тем, что мои коллеги не парились. На мой вкус слишком часто. Но в прикладном ПО, по крайней мере на фронте, часто можно реально не заморачиваться. Тупо не те объемы. А если что, то можно и в "помощь зала", отдать что-то внезапно затормозившие старшим товарищам на напильнинг и полировку
Читал статью, согласен )
Врать не буду, сам не проверял, но у меня коллега оптимизировал затычку с производительностью, обнаружил, что find быстрее чем some, чуть менее чем на до хрена. Я был сильно удивлён. Так что константа тоже влияет. если она этак больше 4х. Да, ждать пару секунд, там где можно было ждать полсекунды, более приятно, чем ждать 60 (при достаточно больших n), но это тоже такое.
a = [1,2,3]
(3) [1, 2, 3]
a.some(1)
VM123:1 Uncaught TypeError: number 1 is not a function
at Array.some () at :1:3 (anonymous) @ VM123:1
Имелось ввиду, что some - тут это какое-то линейное действие? Я уж испугался, что не знал чего-то про .some
Да можно тут в Object.assign или присваивание и возврат. Но если в массиве мало - спред хорошая читаемая форма. А если много можно, присваивание в for или .forEach - для меня это оградка, что там реально экшен. Но опять же всё на вкус (и в данном случае на объём). Конечно, если объем неизвестен, лучше предполагать, что он большой.
О! Древность подъехали. В 18году куда не плюнь всюду эта задача. Аж скулы сводило.
PS. Нет там задача про банкомат была)
Скорее - это значит, что я плохой интервьер, если не смог дотащить до решения. Я там выше в комментах писал, что задача на округление была придумана как развитие идеи задачи x => 7-х, поэтому мне показалось, что это хороший путь к решению. Но, опять же, пример абстрактный)
+{}
NaN
+{} >= 18
false
Я не знаю, как ты в мою форму подложим вместо строки объект, но теперь точно никакой порнухи, бро!
Во многом я с вами согласен, но идея статью все таки не
обязательноо найме только сеньора, и градации кандидатов больше для лулзов, чем как руководство к действию.Мне интересно смотреть кандидатов, в ситуации когда они сталкиваются с
лютой дичьютрудностями, а не образцово показательной задачкой.По поводу some вообще не имею ничего против, как и против спредов в resume. Я знаю что some работает
в некоторых случаяхпочти всегда медленнее, чем find/findIndex, а сред медленнее, Object.assign, или прямое присваивание свойства, если оно не одиночное (и то вкусовщина). Но читается и some и спред лучше, поддерживать проще (по моему мнению, так-то можно спорить). И если у меня нет задачи выжать железку до кровавого пота, то я использую и то и другое). И да, я чаще использую подготовленные маппинги внутри циклов, чем поиски с тем же some. Но опять же я не парюсь и в небольшой выборке воткну some и spred просто чтобы написать на несколько строчек кода меньше.Ну и если в команде не принято some я не буду писать some ) Я и не в таких
извращенияхвполне разумных стандартах участвовал.Ну это эпик фейл для конторы. Хотя многих таки встречал )
Часто, когда "затыкаешься" в коде, проблема не в том, куда копаешь. А в том куда надо копать. Но я уважаю и ваше мнение. Тут всё очень тонко. А наводящие вопросы просто экономят время интервью
Блин, почта выглядит, будто я не настоящий хакер. Надо больше цифр и специальных символов в домене. Либо уж hacker.ru
Обычно я задаю вопросы по реальному коду. И если кандидат не может разобраться, то пусть он хоть крыло боинга в уме спроектировать может, то чем он мне может помочь? И да, если сразу идет туго, я задаю наводящие вопросы. Или подсказываю внешне кейсы, где код используется. Задача просто иллюстрация.
По поводу реального опыта и прочего. Эта статья - спин-офф другой статьи, где я как раз немного
подстебываюсь надобобщаю опыт "технической составляющей" собеседований. Пока лежит в черновиках, но планирую в среду четверг дописать и опубликоватьВот не понимаю, зачем
столько ядатак агрессивно?Мне хотелось проиллюстрировать идею и я взял самую простую задачу, в которой можно было показать как можно прийти к результату с помощью наводящих вопросов. Мог бы взять например сортировку вставками - но статья была бы больше, а вопросы "зачем это спрашивать?" всё равно бы были. Задачу на округление я обычно подкидывал людям вне работы. На собесе очень редко и только в качестве доп. вопроса.
По повода проверки округления. Я лучше проверю, что кандидат умеет в округление, чем не проверю. Это пара минут, которые могут сэкономить много времени потом. Да, мне более важно как кандидат проверяет входящие параметры в задачах (с чем люди лажают чаще, чем с округлением), но и бывают люди и не умеющие в округление с вполне приличным резюме. Если бы я с такими не сталкивался, я бы и не проверял, для меня это было откровением.
Джуна я бы точно проверил бы и не стеснялся бы.
Если человек выучил решение задачи - это не значит, что он её решил. И тем более, не факт, что её решил бы.
По мне очень часто используемая идиома. Например, чтобы конвертнуть из string, особенно из форм
А поговорить можно про то, что это на самом деле это краткая форма
и, возможно, в других языках с динамической типизацией оно тоже работает
Я не готовился к собесу Яндекса. Я вообще был удивлён, почему они моё резюме рассматривали, у меня з/п стояла выше рынка. Но на собес сходил, получил удовольствие. Выяснил на след собесе (алгоритмическое я прошёл), что им требовались еще и хорошие скилы девопса. Увы, это пока(?) не ко мне.
Сильно больше я бы сказал
Если бы соискатель написал бы % - я бы сказал, что его тоже нельзя ) Мне нужно прийти именно к безтернарному виду. По крайней мере без тернарника вне параметров Math.floor
Для положительных и отрицательных правильно
А что там считать: примерно 20.6% от стороны люка минус 69% от его толщины.
Вот и я про что. Сперва отбирают алгоритмистов, а потом в коде все равно "и так сойдёт" занимает подавляющую часть)
Магия наверно или даже колдовство
И мне казалось, что люки отливают, а не пилят из болванок, а потом ещё и гравируют...
У меня был начальник, который любил задачу для собеса, в которой надо было работать с остатками. И я сам бы удивлен, что задачка такая простая, когда сам проходил собес. И ещё больше тем, что половина кандидатов на сеньорскую (!) позицию не знала как взять остаток нативно или хотя бы с помощью функций округления.
Но и задавать вопрос соискателю про его, возможно, вопиющую некомпетентность в лоб не очень хорошая идея. Да и практические навыки чего бы не проверить?
Я всегда люблю в оптимизацию, иногда излишне, но часто сталкивался с тем, что мои коллеги не парились. На мой вкус слишком часто. Но в прикладном ПО, по крайней мере на фронте, часто можно реально не заморачиваться. Тупо не те объемы. А если что, то можно и в "помощь зала", отдать что-то внезапно затормозившие старшим товарищам на напильнинг и полировку