Хороший видос, спасибо за запись, ещё только на первых началах изучения frontend разработки, но встретил вопросы, которые читал в документации/курсах недавно. Продолжай делать подобные видео!)
Друзья, кому интересно, авторы подобных каналов не являются программистами. Интервью записано с другом который задает заранее обговоренные вопросы. Вся суть в том, чтобы заманить новичков и продать им "коучинг перед собеседованием". Надеюсь не поведетесь.
я хз кто автор, но на видео прекрасно видно чела, который 100% работает в озоне и уже провел кучу собесов. Его даже можно чисто по голосу узнать, если проходил с ним собес.
Можно по идее отсортировать, потом перевести в строку и сравнить, если заведомо знаем, что только числа. Запись будет самая короткая, но возможно не самая эффективная
100% не самая эффективная, алгоритмическая сложность будет выше из-за сортировки, решение в видео эффективнее, хоть можно было и поменьше раз ходить по массивам
@@K1appy согласен, просто в основном всегда пытаюсь найти самое быстрое и топорное решение, а потом оптимизировать. Особенно на интервью :) А то можно погнаться за самым оптимальным вариантом и обмануть самого себя, не успев доделать.
@@K1appy Зачем программисты используют sort() если он повышает сложность алгоритмов ? Мне казалось что чем меньше кода, тем лучше, и не зря же sort() создали (не с претензией, сам новичок)
Я бы добавил два каунтера в момент наполнения мапы, на первом цикле. И перед тем как начинать второй, проверил бы суммы - если не сходятся выход с false.
Чёт задачку как то сложно решил. Можно было просто отсортировать и сравнить либо приведя к строке, либо одним циклом. Подозреваю про KISS он ничего не слышал
KISS не пропагандирует простоту в угоду увеличения алгоритмической сложности, что ты сейчас и предлагаешь. KISS подразумевает упрощение там, где излишняя сложность используется с заделом на будущее, и без которой в рамках текущих требований можно обойтись.
@@АлексейВолков-ь2в3з за уменьшением алгоритмической сложности гонятся везде. И даже при использовании принципов KISS погоня за уменьшением алгоритмической сложности никуда не девается.
@@Boortwint это я понимаю, но изначально первый комментатор пренебрегает алгоритмической сложностью в угоду KISS, а я сказал что нам важнее сейчас не чистота кода, а решить задачу так, чтобы его алгоритмической сложность была как можно ниже
спасибо. Только я не расслышал про некий параметр куки "pass" вроде и нагуглить его не могу. Что за параметр в итоге?)) Для того, чтобы не всегда рефреш токен отправлять
хорошая задачка, так бы в тупую сортировал и строками сравнивал, но если стоит вопрос о сложности алгоритма итд, то конечно такой вариант предпочтительнее
+1 к вопросу, а то такое чувство, что собеседующий сразу после этой задачки решил не тратить время (в плохом смысле), потому что подумал, что "if key in object" придает алгоритму сложность O(N^2), а это не так - там примерно O(1)
Задачку проще через new Set решать Два сета и два цикла проверок с выходом на тру Вопрос по сетям нравится / всегда смеюсь, собес фронтовый, но что там браузер делает не интересно пошли смотреть транспортные протоколы На второй этап позвали?
неее какой сет, сортируеш массивы по возрастанию/убыванию, переводиш в строку и сравниваеш строки, return arr1.sort().join() === arr2.sort().join(); на этом все)
По задаче я бы сначала сравнил размеры, затем сделал sort или toSorted, чтобы не мутировать исходные массивы (если они не отсортированные приходят и/или если это требуется). Затем в одном цикле по одним и тем же индексам сравнил каждые элементы обоих массивов. Первое не совпадение -> возврат false. Может я не допонял задачу?
в твоём варианте сложность алгоритма будет линейно логарифмическая + линейно логарифмическая + линейная, если использовать сортироку слиянием, а у автора линейная + линейная + линейная. Чтобы было понятно сколько тактов процессор выполнит, берём массив длиной 1000 элементов, в твоём варинате к-во тактов = 10000 + 10000 + 1000 = 21000, а у автора видео 1000 + 1000 + 1000=3000, что в 7 раз быстрее, но во втором варианте от 3-цикла можно избавится и у нас выходит 2000 тактов, 2-вариант теперь 10.5 раз быстрее при длине массив равной 1000
@@wickedtorpedo75 хороший был бы комментарий при условиях, если не знать, что сложность так не складывется и поиск (проверка наличия) ключа в объекте это O(n)
@@simplethai с каких пор сложность О(n) хуже O(nlogn)? C каких пор проход по массивам будет худшим алгоритмом по памяти, чем использование метода toSorted, который создаёт дополнительный отсортированный массив в памяти?
если смотреть на тест-кейсы, которые изначально даны - то да возможно) Но, если начать накидывать дополнительные тест-кейсы, то код начнет отрабатывать некорректно. Например, [1, 1, 2] и [1, 2, 2] Если изначально дан ограниченный список, тест-кейсов от интервьюера, то это не значит, что он не захочет пополнить этот список, после того как напишешь подобное решение.
@@ne_frontend эт понятно, дополнительные вопросы вроде - а что вы будете делать если в стандартной библиотеке нет метода includes - это классика, просто кажется нет смысла усложнять с самого начала. Есть простой вопрос и кажется разумным давать на него максимально короткий правильный ответ. А так это не критика ни в коем разе, просто я бы совсем не такое решение ожидал )
Хороший видос, спасибо за запись, ещё только на первых началах изучения frontend разработки, но встретил вопросы, которые читал в документации/курсах недавно. Продолжай делать подобные видео!)
Классный собес, ждём некст серий)
Про cookies полезно было узнать новые детали, спасибо!
Для сравнения массивов можно сделать на обоих массивах .sort(), а потом .toString(). И сравнить строки.
Друзья, кому интересно, авторы подобных каналов не являются программистами. Интервью записано с другом который задает заранее обговоренные вопросы. Вся суть в том, чтобы заманить новичков и продать им "коучинг перед собеседованием". Надеюсь не поведетесь.
Ага, так и есть
я хз кто автор, но на видео прекрасно видно чела, который 100% работает в озоне и уже провел кучу собесов. Его даже можно чисто по голосу узнать, если проходил с ним собес.
@@vitaly- хахахахаха вот и друг отписался
@@Губдалан ты еще заплачь)
@@vitaly- Так я вроде только что смеялся, с чего бы мне плакать
Стек протоколов TCP/IP - куда без этого. Я каждый день js код пишу и об этом думаю 😂
Можно по идее отсортировать, потом перевести в строку и сравнить, если заведомо знаем, что только числа. Запись будет самая короткая, но возможно не самая эффективная
100% не самая эффективная, алгоритмическая сложность будет выше из-за сортировки, решение в видео эффективнее, хоть можно было и поменьше раз ходить по массивам
@@K1appy согласен, просто в основном всегда пытаюсь найти самое быстрое и топорное решение, а потом оптимизировать. Особенно на интервью :) А то можно погнаться за самым оптимальным вариантом и обмануть самого себя, не успев доделать.
@@K1appy Зачем программисты используют sort() если он повышает сложность алгоритмов ? Мне казалось что чем меньше кода, тем лучше, и не зря же sort() создали (не с претензией, сам новичок)
Я бы добавил два каунтера в момент наполнения мапы, на первом цикле. И перед тем как начинать второй, проверил бы суммы - если не сходятся выход с false.
Видос заслуживает большего и канал тоже, а то просмотров немного, зачем же впустую снимать,заюзайте ютифай, может вам подойдет.
Чёт задачку как то сложно решил. Можно было просто отсортировать и сравнить либо приведя к строке, либо одним циклом. Подозреваю про KISS он ничего не слышал
Если будешь сортировать, то сложность nlogn будет по времени
KISS не пропагандирует простоту в угоду увеличения алгоритмической сложности, что ты сейчас и предлагаешь. KISS подразумевает упрощение там, где излишняя сложность используется с заделом на будущее, и без которой в рамках текущих требований можно обойтись.
@@Boortwint Да, но как правило в алгоритмических задачах гонятся не за KISS, а уменьшением алгоритмической сложности
@@АлексейВолков-ь2в3з за уменьшением алгоритмической сложности гонятся везде. И даже при использовании принципов KISS погоня за уменьшением алгоритмической сложности никуда не девается.
@@Boortwint это я понимаю, но изначально первый комментатор пренебрегает алгоритмической сложностью в угоду KISS, а я сказал что нам важнее сейчас не чистота кода, а решить задачу так, чтобы его алгоритмической сложность была как можно ниже
А какой грейд? Мидл? Ответы не супер, кстати, много погрешностей
спасибо. Только я не расслышал про некий параметр куки "pass" вроде и нагуглить его не могу. Что за параметр в итоге?)) Для того, чтобы не всегда рефреш токен отправлять
path, установив его ты настроишь отправку куки только на определенный маршрут
хорошая задачка, так бы в тупую сортировал и строками сравнивал, но если стоит вопрос о сложности алгоритма итд, то конечно такой вариант предпочтительнее
зачем вообще показывать что-то, если все видео заблюрили?
Зато на 144p смотреть можно!) А если серьёзно - интервьюер не блещет дикцией, так можно читать по губам
если это первый, то след. какой этап бывает ?
еще как минимум 1 секция техническая с лайвкодингом
@@ne_frontend алгоритмы ? ждем продолжение
на 350к не того собеседующего поставили ))) как всегда в своем репертуаре - отправили на собес кого попало и кто не смог отбиться ))
Так ты прошёл первый этап?
да прошел :) вторую часть позже планирую выкладывать
Странные вопросы для фронта
Поясните пожалуйста зачем делается +1 в (counterMap[arr1[i]] || 0) + 1 ?
Для увеличения количества цифер в countMap
Прошёл?)
+1 к вопросу, а то такое чувство, что собеседующий сразу после этой задачки решил не тратить время (в плохом смысле), потому что подумал, что "if key in object" придает алгоритму сложность O(N^2), а это не так - там примерно O(1)
@flowcsgo804 @Justfunandchill да, позвали на следующие этапы :) Их можно будет увидеть чуть позже, на этом канале или в телеге.
@@ne_frontend ждем
собеседующий слабоват, даже вопросы нормально не может задать.
Задачку проще через new Set решать
Два сета и два цикла проверок с выходом на тру
Вопрос по сетям нравится / всегда смеюсь, собес фронтовый, но что там браузер делает не интересно пошли смотреть транспортные протоколы
На второй этап позвали?
Поможет ли Set в таком случае ? [1, 2, 2] и [1, 1, 2]?
@@Alexchtch согласен
неее какой сет, сортируеш массивы по возрастанию/убыванию, переводиш в строку и сравниваеш строки, return arr1.sort().join() === arr2.sort().join(); на этом все)
@@ЕвгенийКузнецов-щ1ювидимо для вас сложность алгоритмов не знакомая тема
По задаче я бы сначала сравнил размеры, затем сделал sort или toSorted, чтобы не мутировать исходные массивы (если они не отсортированные приходят и/или если это требуется). Затем в одном цикле по одним и тем же индексам сравнил каждые элементы обоих массивов. Первое не совпадение -> возврат false. Может я не допонял задачу?
в твоём варианте сложность алгоритма будет
линейно логарифмическая + линейно логарифмическая + линейная, если использовать сортироку слиянием, а у автора линейная + линейная + линейная.
Чтобы было понятно сколько тактов процессор выполнит, берём массив длиной 1000 элементов, в твоём варинате к-во тактов = 10000 + 10000 + 1000 = 21000, а у автора видео 1000 + 1000 + 1000=3000, что в 7 раз быстрее, но во втором варианте от 3-цикла можно избавится и у нас выходит 2000 тактов, 2-вариант теперь 10.5 раз быстрее при длине массив равной 1000
@@wickedtorpedo75 Повнимательнее посмотрел. Согласен. Хорошее решение. Последний цикл можно убрать и вообще красота.
@@wickedtorpedo75 хороший был бы комментарий при условиях, если не знать, что сложность так не складывется и поиск (проверка наличия) ключа в объекте это O(n)
@@ЕгорТишко́-ш9у твое решение лучше и по сложности и по памяти. лайк
@@simplethai с каких пор сложность О(n) хуже O(nlogn)? C каких пор проход по массивам будет худшим алгоритмом по памяти, чем использование метода toSorted, который создаёт дополнительный отсортированный массив в памяти?
const isEqual = (arr1, arr2) => {
if (arr1.length !== arr2.length) return false;
const map = new Map();
for (let index = 0; index < arr1.length; index++) {
const item1 = arr1[index];
const item2 = arr2[index];
if (map.has(item1)) {
map.set(item1, map.get(item1) + 1);
} else {
map.set(item1, 1);
}
if (map.has(item2)) {
map.set(item2, map.get(item2) - 1);
} else {
map.set(item2, -1);
}
}
for (const [key, value] of map.entries()) {
const value = map.get(key);
// console.log(`[${key}]`, value);
if (value !== 0) {
return false;
}
}
return true;
};
```
function isSimular(arr1, arr2) {
if (arr1.length !== arr2.length ){
return false;
}
for (current of arr1) {
if (!arr2.includes(current)){
return false;
}
}
return true;
}
```
Не?
если смотреть на тест-кейсы, которые изначально даны - то да возможно) Но, если начать накидывать дополнительные тест-кейсы, то код начнет отрабатывать некорректно. Например, [1, 1, 2] и [1, 2, 2]
Если изначально дан ограниченный список, тест-кейсов от интервьюера, то это не значит, что он не захочет пополнить этот список, после того как напишешь подобное решение.
@@ne_frontend эт понятно, дополнительные вопросы вроде - а что вы будете делать если в стандартной библиотеке нет метода includes - это классика, просто кажется нет смысла усложнять с самого начала. Есть простой вопрос и кажется разумным давать на него максимально короткий правильный ответ. А так это не критика ни в коем разе, просто я бы совсем не такое решение ожидал )
@@ДокторЗойдберг-й4д к includes в цикле, скорее всего вопросы будут
@@ДокторЗойдберг-й4д чел, тебе за короткий скажут молодец и сделай нам по-другому. Так всегда
У такого решения высокая сложность O(n2)
const isSimilar = (arr1, arr2) => {
if (arr1.length !== arr2.length) return false;
if (arr1.includes(...arr2)) {
return true;
}
return false;
}
Боюсь .includes не примет в себя массив, пусть даже "развернутый" с ...
@@XTANCE принимает. проверил