Comments 166
Если мне приходится делать реализации списков, я обычно сразу закладываю туда счетчик элементов. Если реализован двусвязный список, то любой элемент по номеру можно получить не более чем за length / 2 шагов - если n <= length / 2 - считаем с начала списка, иначе - с конца.
Вообще, двусвязный список предпочитаю делать кольцевым с двумя типами узлов.
Один узел имеет тип HEAD и содержит счетчик элементов и ссылки на первый и последний элементы списка (при необходимости там же могут быть какие-то другие свойства списка). Остальные элементы имеют тип NODE и содержат блок данных и ссылки на следующий и предыдущий элементы (первый в качестве предыдущего ссылается на HEAD, последний, в качестве следующего, аналогично ссылается на HEAD.
Сам объект "список" - это ссылка на HEAD.
Это тоже хороший и полезный способ, но все зависит от самой задачи, если достаточно односвязного списка без доп. данных, то нет смысла добавлять доп. данные, а если для задачи полезно держать какие-то данные в узлах, то делаем так)
Да, конечно от задачи. Иногда вообще ничего не нужно - можно использовать готовые библиотечные реализации.
Тут структура данных неподходящая выбрана) Искать середину полной итерацией - ну такое себе развлечение.
Вариант с 2 указателями хорош для олимпиады - оптимально, изящно. Он приходит в голову сразу, когда читаешь заголовок.
А вот в реальной работе предпочитаю первый, с конвертацией списка в массив... Потому как обычно нахождением среднего элемента обработка данных не ограничивается, памяти сейчас много, а ждать пользователь не любит. ;)
Если мне приходится делать реализации списков
Самое интересное в этом комментарии не озвучено :). Расскажите, пожалуйста, что это были за задачи (во множестве числе!), для решения которых вам приходилось не только использовать связные списки, но и писать свои реализации?
Я спрашиваю без подколок - иногда на тех же собеседованиях спрашивают когда linked list лучше, чем array list - обычно ничего вменяемого придумать не удаётся.
В практических, конечно, задачах, не в литкодных/олимпиадных.
на тех же собеседованиях спрашивают когда linked list лучше, чем array list - обычно ничего вменяемого придумать не удаётся
надо было мне это объяснить на видео.
проблема массивов в том, что когда место заканчивается, тебе надо создать новый массив большего размера, скопировать туда все элементы старого массива и добавить новый элемент уже в новый массив, когда как linked list может расширяться сколько угодно и по одному элементу.
а вот реально применять связный список мне пока не приходилось)
проблема массивов в том, что когда место заканчивается, тебе надо создать новый массив большего размера, скопировать туда все элементы старого массива и добавить новый элемент уже в новый массив, когда как linked list может расширяться сколько угодно и по одному элементу.
Обычно, это не очень большая проблема и если уж стало припекать по объёму занимаемой памяти, то стоит задуматься либо о том, так ли хорошо всё делается или о ручном управлении памятью (насколько это в яве возможно). LinkedList в этом случае о-о-очень сомнительное решение, тк у него офигенный оверхед по памяти, особенно, на небольших целевых объектах, который может сожрать всю "выгоду" от переаллокации массивов.
Из других предложенных вариантов часть тоже весьма сомнительна - какие-то мутные схемы с большими объёмами данных и пересортировками... Особенно пересортировки меня удивили - делать сортировки на связных списках - то ещё развлечение. Ну, и для сортировки таких больших объектов ключ-значение лучше сортировать индексы.
Fifo-Lifo прекрасно делаются на массивах.
Частые дополнения большого количества - я бы тоже подумал о кастомных ArrayList-ах
Про объекты больших размеров - ну, такое,.. смотреть по месту, конечно, надо...
А, вот список поверх другой структуры данных (типа LRU структур) - это да-а! Как раз и список и его реализация. И в яве уже даже есть LinkedHash[Map|Set] - весьма полезная штуковина. В том числе, чтобы на собеседовании сказать если вопрос возникнет ))
а вот реально применять связный список мне пока не приходилось)
Вот, в том-то и дело ))
Свои реализации делаются или когда что-то очень специфическое по данным, или когда готовой нет в наличии (такое тоже бывает в жизни), или когда нужна предельная эффективность вкупе с какой-то спецификой задачи и приспособить готовое получается достаточно коряво.
Список или массив... Нам часто приходится иметь дело с очень большими объемами данных. Память в целом не проблема, можно считать что она не ограничена. Но есть ограничение - 16Мб одним куском (ну можно 2Тб, но там уже приходится "танцевать вприсядку" - это другая модель памяти и, в общем случае, даже другой размер указателя). И вот если нет уверенности что получится выделить массив (даже динамический массив все равно в памяти одним куском будет), то тогда используется список.
Там еще есть варианты - списки ключ-данные с необходимостью поиска по ключу. Можно организовать это массивом, отсортировать его и потом использовать быстрый двоичный поиск (быстрее не бывает). Но тут есть момент - если у нас данные постоянно меняются, то каждый раз пересортировывать массив из хотя бы сотни тысяч элементов (а для нас это не сказать чтобы сильно много) приводит просто к катастрофической потере производительности. И вот тут лучше список ключ-данные.
А если это статика - один раз заполнил, отсортировал и потом 100500 раз ищешь - там сортированный массив по производительности лучше.
Нужен FIFO или LIFO доступ к элементам.
Нужны частые операции добавляения большого количества элементов или объединения списков.
Список состоит из элементов большого размера, может содержать большое колличество элеметнов и при этом все время растет. Использование массивов тут неоптимально по причине часто реаллокации больших объёмов памяти.
Массив состоит из структур и по причине экономии ресурсов или необходимости обеспечения эффекивного многопоточного атомарного доступа нужно, чтобы элементы структур были сразу элементами списка (т.е. отказ от работы с указателями даёт какие-то преимущества). Крайне редкая ситуация.
В практических задачах обычно linked list делается не отдельно, а поверх уже существующей структуры данных, чтобы выстроить в цепочку объекты, которые существуют без него. Как контейнер – не припомню...
linked list делается не отдельно, а поверх уже существующей структуры данных
не понял этот момент, что имеется в виду?
В смысле у вас уже есть какое-то хранилище объектов (массив, дерево, ещё что – что вам диктует задача) и вам понадобилось для каких-то нужд объединить эти объекты в цепочки. Можно хранить отдельно списки указателей на ваши объекты, а можно просто добавить в каждый объект поле next.
ну это как-то не очень, лучше создать LinkedList, чтобы код был чище)
Ага, и фигакнуть на ровном месте по выделению памяти в куче на каждый элемент.
ну значение ноды будет ССЫЛКА на нужный объект, поэтому не вижу в этом проблем) ну или плохо понял идею
Ага, только на N объектов вам придётся выделить N нод. Каждая будет хранить указатель на объект, указатель на следующую ноду + накладные расходы кучи. И затраты времени на выделение/освобождение.
А если вы прямо внутри вашего объекта сделаете поле указателя на следующий – это куда выгоднее.
Если же вам надо очередь делать снаружи, не модифицируя объекты – обычно выгоднее (и по памяти, и по быстродействию) кольцевой буфер.
Например, при реализации LRU кеша. Там при доступе у ключу, он перемещается в конец списка. При переполнении кеша (хеш таблица значений), удаляется элемент из начала списка.
Например, в ситуациях, когда по какой-причине нужно вставлять или удалять элементы внутри цепочки.
Учитывая, что чтобы вставить или удалить элемент, нужно вначале найти его место за O(n) – редко когда linked list в качестве контейнера оправдан.
Простейший случай - идете по цепочке от начала к концу и для каждого элемента принимаете решение - оставить его или удалить. Такой вот play-off алгоритм.
Есть еще очереди. Например, на отправку сообщений. Сообщение для отправки берется из начала очереди. Новые сообщения добавляются в конец. Отправленное (точнее, отправленное на которое получено подтверждение о поиеме) сообщение удаляется из начала очереди.
Очередь обычно делается кольцевым буфером, не linked list. Исключение – когда объекты уже лежат где-то и вы их просто связываете прямо на месте.
Play-off – тот же один проход по массиву (двумя указателями) удаляет всё лишнее за O(n), как и в случае linked list.
Я не говорю, что linked list нигде не пригодится, но его использование в качестве контейнера – лютая экзотика.
В ядре Линукса нередко встречается.
Очередь обычно делается кольцевым буфером, не linked list. Исключение – когда объекты уже лежат где-то и вы их просто связываете прямо на месте.
Кольцевые буфера хороши там, где поток сообщений относительно невелик, а ресурсы сильно ограничены. Например, на промконтроллере.
А вот когда у вас ядро, обеспечивающее связь десятком контроллеров с несколькими интерфейсными клиентами, да еще количество контроллеров (а значит плотность потока сообщений) может варьироваться в широких пределах, тут уже кольцевые буфера сильно неудобны. Хотя бы тем, что вам придется сразу выделить ну очень много памяти в статике.
Помножьте на то, что размер сообщения может быть разным - от десятков байт до килобайт. В статическом буфере вам придется выделять память под максимальный размер сообщения.
Помножьте на то, что могут быть "приоритетные" сообщения, которые помещаются не в конец, а в начало очереди.
А еще сообщение может не получить подтверждения и его нужно передвинуть в очереди на перепосылку через какое-то время...
У поверьте, я с этим много наелся когда занимался разработкой ядра системы мониторинга инженерного оборудования зданий. Начинали с буферов, но достаточно быстро наелись с этим и перешли на очереди. С которыми все стало намного проще.
Сейчас задачи другие, но вот есть параллельная обработка больших объемов данных (десятки и сотни элементов). И там есть такая штука как "конвейер". Тоже на FIFO очередях строится.
Play-off – тот же один проход по массиву (двумя указателями) удаляет всё лишнее за O(n), как и в случае linked list.
Play-Off, как следует из названия, подразумевает многократный проход по списку с удалением элементов на каждом проходе.
В общих чертах - пришло некоторое условие. По нему составляется список элементов, удовлетворяющих этому условию (ну для понимания - 500-600 тысяч элементов). Приходит второе условие - проходим по списку и удаляем все, что не проходит по второму условию. Потом третье, пятое, десятое... Каждый раз список сокращается. Поскольку элементы физически удаляются, то каждый новый проход будет короче предыдущего. С массивом тоже можно, но там придется или два массива делать с перебросом из одного в другой и обратно (менять их местами на каждом проходе), или с одним, но с копированием последнего элемента массива на место очередного выбывшего. Что тоже требует времени.
В результате по скорости (подтверждено PEX статистиками) разницы нет - что связанный список, что два массива, что один. А вот простоте и понятности кода со списком намного проще.
Ничего не мешает держать хеш-таблицу из идентификаторов элементов в указатели/итераторы в list. Популярное применение - LRU cache. Там список навешан сверху на хеш-таблицу и задает порядок элементов, чтобы выбирать, какой элемент самый старый и его надо удалить. При доступе элемент из центра списка будет перемещен в конец.
Хочу поинтеросоваться у автора - каким образом была выбрана задача? Когда я проходил собеседование, мне сказали написать random.randrange (3000) и что выведится в консоль, то и решай.
В первую очередь подбираю задачи, так чтобы объяснить какую-то тему, которая будет полезна на интервью, на примере этой задачи или саму задачу, которая часто встречается на интервью.
У меня на канале идут подряд задачи связанные с какой-то темой(two pointers, sliding window), сейчас перешел на тему fast and slow pointer и на примере этой задачи объяснил, что это такое + объяснил что такое связный список и какие они бывают(на видео).
Мне вот давали Reverse Linked List(фаанг в РФ) и десятки других задач(easy/medium/hard).
Три года назад была эта задача, когда собеседовался на нынешнюю работу. На нервах от собеседования (очень мало на них ходил) решил её каким-то безумным способом с двумя указателями. Нормальное решение пришло минут через 5 после окончания этапа собеседования. Было стыдно, но в итоге работу и так получил.
3 вариант не лучше, чем второй. В 3 варианте за один проход, но в этом 1 проходе нужно двигать 2 указателя, с точки зрения количества операций будет одинаково со 2 вариантом.
Единственное, что в 3 варианте более красивая и элегантная идея.
Но 2 вариант проще в понимании и чтении кода в будущем.
Я бы взял на работу того, кто не усложняет код, где это не требуется, а пишет более просто.
Второй и третий варинаты имеют одинаковое количество сравнений и обращений к памяти.
Но из-за архитектурных ньюансов, сложно сказать, какой будет быстрее.
Третий вариант имеет меньше условных переходов (n/2 в случае одного цикла и n+n/2 в случае двух). Но это хорошо предсказываемые условные переходы на следующую итерацию цикла, поэтому они относительно дешевые.
С другой стороны, во втором варианте циклы короче.
С точки зрения кода второй вариант лучше, я с вами согласен.
Согласен, что третий вариант довольно хитрий и да, второй вариант проще в понимании
Идея 3 варианта довольно проста, только "у кого-то это щёлкает, а у кого-то не щёлкает". Предварить реализацию коротеньким комментарием о том, что происходит и почему это работает, и по лёгкости понимания и чтения оно, на мой взгляд, не только не уступит второму варианту, а даже его превзойдёт.
ну третий вариант, думаю, ненадолго остановит человека, чтобы действительно понять, что происходит, когда как второй вариант более интуитивный
Начнём с того, что сама постановка задачи, возникни она не на интервью, а в реальных условиях, ненадолго остановит человека, чтобы действительно понять: а) зачем нужно находить середину связного списка? б) зачем выбирать именно связный список как упорядоченный контейнер для данных, у которого надо находить серединный элемент. Что-то тут, наверное, придумать можно, как-то обосновать - но ненадолго остановит.
С другой стороны, а зачем человеку действительно понимать, что происходит? Есть функция, возвращает срединный элемент, вот аргумент(ы), вот возвращаемое значение. Работает? Работает. Ну и не трожь, пускай работает. Можно, опять-таки, представить ситуацию, когда понадобилось действительно понять - прошёл, допустим, год, два, три, и почему-то понадобилось переделать. Но не по нескольку же раз на дню человек будет читать именно эту часть кода, каждый раз ненадолго останавливаясь, чтобы понять.
Хорошо было бы добавить голосование, что бы каждый мог выбрать правильный вариант № 3.
Самый оптимальный вариант третий) а две другие лишь подводят к третьему
Быстрый и медленный указатель имеет ровно такую же сложность, как и с подсчетом длины. Оба требует два прохода.
согласен, в случае с быстрым и медленным указателем, проходим каждый элемент 1.5 раз, но в рамках одного цикла
Быстрый и медленный указатель, вероятно, тиснуты из более сложной задачки про кольцевой список :-)
не понял про кольцевой список
Google "поиск цикла в односвязном списке" или "алгоритм черепахи и зайца".
Вкратце: у нас есть односвязный список неизвестной длины, возможно, он с какого-то места зацикливается. Надо узнать, зацикливается ли, и определить длину цикла и точку входа в него.
Проверка списка на "зацикливание". Классически решается через "быстрый" и "медленный" указатели.
По Big-O такую же, одинаковое количество переходов к следующему элементу, но в третьем варианте отсутствуют операции сравнения текущего индекса указателя с вычисленной длиной списка, делённой пополам. Впрочем, выше @wataru, по-моему, уже написал про то же самое.
Если хочется извращений, можно съэкономить половину итераций на втором итераторе: заводим два допонительных итератора i1, i2. Когда основной прохтдит через степень двойки (2, 4, 8, 16,...) сохраняем:
i1 = i2
i2 = i
Теперь когда дойдем до конца списка у нас есть закешированный итератор, который между 1/4 и 1/2 длины.
Но общая сложность все равно линия.
По сабжу вспоминается забавная, но специфичная для С/С++ задачка в жанре "ненормальное программирование". Надо сначала ввести с клавиатуры N чисел (N произвольное, но не слишком большое), потом вывести их в том же порядке. По условию, нельзя использовать массивы и динамически выделяемую память (кучу).
получилось решить?)
Обязательно вывести потом, а не во время ввода? N задается, или читаем до условного перевода строки?
Можно ли исползовать N переменных, раз оно небольшое? Можно ли использовать препроцессор?
Можно ли исползовать N переменных, раз оно небольшое? Можно ли использовать препроцессор?
first_input
second_input
third_input
n_input
это будет довольно интересный подход)
Обязательно вывести потом, а не во время ввода?
Разумеется, в этом и суть ) Сначала читаем N, потом читаем числа N раз, потом выводим тоже N штук.
Это самое N может быть равно несколько тысяч, заваливать переменными не вариант.. По поводу препроцессора не помню, но вполне можно без него. Эта задача явно не о препроцессоре.
Принимается ли хак с рекурсивной функцией и доступом к локальным переменным выше по стеку, эмулируя таким образом массив? Надо только смещение между двумя копиями локальной переменной узнать. Это можно сделать, передав указатель на локальную переменную в рекурсивный вызов.
Еще можно эти локальные переменные организовать в односвязный список. Тогда локальная переменная будет пара число+указатель на предыдущую. В рекурсивный вызов передаем указатель на локальную переменную (которая последняя нода в списке) + указатель на первую локальную переменную. в локальную переменную перед этим читаем и дописываем ее в список. В самом нижнем рекурсивном вызове выводим список.
Еще, кажется, можно было бы написать вариадическую рекурсивную функцию, но пока не понятно, как можно передать дальше все параметры и еще один int в конце.
можно эти локальные переменные организовать в односвязный список.
Я так решал. Это честный вариант без хаков с адресами. Потому и вспомнил задачу в теме про списки.
А зачем вы решаете подобные задачи на собеседовании? Вам там доступ к гугл и чатгпт запрещают? А на работе потом доступ в гугл и чатгпт тоже только по спец пропускам?
P.S. Как в LinkedList найти средний элемент начиная перебирать с head?
Чтобы найти средний элемент в связном списке (LinkedList), начиная с головы (head), можно использовать два указателя: один будет двигаться на один элемент за раз (slow), а другой — на два элемента за раз (fast). Когда указатель fast достигнет конца списка, указатель slow будет находиться на среднем элементе. Вот пример алгоритма на Python:
class Node:
def init(self, data):
self.data = data
self.next = None
class LinkedList:
def init(self):
self.head = None
def find_middle(self):
slow = self.head
fast = self.head
while fast and fast.next:
slow = slow.next
fast = fast.next.next
return slow.data if slow else None
В этом коде метод find_middle возвращает значение среднего элемента. Если список пуст, он вернет None.
Да, на интервью не дают доступа к интернету, ибо проверяют ваши знания и навыки, а не chatgpt.
Потом, chatgpt не заменяет программиста. Он только по самым боянистым, раскопипащеным по всему интернету задачам выдает правильный ответ. Иногда можно чуть-чуть слова в условии поменять и он выдает очень правдоподобный и очень неправильный бред. И вот понять, что оно не работает и почему - это будет посложнее чем эти задачки решать самостоятельно.
>Иногда можно чуть-чуть слова в условии поменять и он выдает очень правдоподобный и очень неправильный бред
Вы или крестик снимите или трусы наденьте. Так чего тогда не даёте людям доступ к чатгпт? Поменяйте слова в условии, если конечно хватит ваших мясных мозгов обойти чатгпт.
>Да, на интервью не дают доступа к интернету, ибо проверяют ваши знания и навыки, а не chatgpt.
Так и на работе запретите гугл и чатгпт. Вы работника наняли или халявщика? Он же в гугл полезет, в чатгпт зайдет и всё скопирует! А вы ему деньги заплатите!
а как тогда проверить того, кого хотят нанимать?) ведь нужен какой-то фильтр
В вузе, когда преподаватель видел, что мне было лень делать лабу и я её позаимствовал у местного ботана, просто просил мне объяснить, что здесь происходит. Я ему объяснял и ко мне претензий не было.
молодец!
но к чему это?)
Спросите у чатгпт, правда я не уверен, что сможете ли вы правильно сформулировать вопрос. Поэтому я сделаю это за вас:
В вузе, когда преподаватель видел, что мне было лень делать лабу и я её позаимствовал у местного ботана, просто просил мне объяснить, что здесь происходит. Я ему объяснял и ко мне претензий не было.
к чему это?)
Это может быть примером ситуации, когда преподаватель хочет убедиться, что студент действительно понимает материал, даже если он использовал чужую работу. Это подчеркивает важность понимания и усвоения знаний, а не просто выполнения заданий. Преподаватель, вероятно, ценит усилия студента объяснить материал, что может свидетельствовать о его понимании, даже если работа была заимствована.
так ты можешь у местного ботана спросить, что там написано, выучить это и рассказать учителю)
>Это было сказано при споре о выполнении алгоритмических заданий при приёме на работу
В таком контексте это может указывать на то, что работодатели ценят не только конечный результат, но и способность кандидата объяснить свои решения и подходы к задачам. Это важно в алгоритмических заданиях, где понимание принципов и логики может быть более значимым, чем просто правильный ответ. Способность объяснить свои действия может свидетельствовать о глубоком понимании темы и умении применять знания на практике.
Вот, например, в футболе вратари 95% времени просто стоят на воротах и ничего не делают. На не очень высоких уровнях до удара по воротам доходит редко. Но когда вы себе в команду вратаря нанимать будете, вы же не будете смотреть, как он на воротах стоит, вы сфокусируетесь только на оставшихся самых сложных 5% его работы и заставите его ловить мяч.
Так и в программировании. Не интересно проверять, как кандидат будет с гуглом и чатботом писать код - это любая макака сможет сделать в болшинстве случаев. Интерес передставляет оставшиеся случаи, когда точно такой же вопрос не нашелся на stackoverflow и код копипастить неоткуда (или gpt выдал очевидный бред). Для простоты интервью этап с неуспешным гуглением или бредовым ответом chatgpt опускают.
Программирование немного сложнее ловли мяча в воротах. До сих пор ни у кого нет правильной идеи как можно собеседовать программиста. То, что гугл задаёт олимпиадные задачки ни как не сказывается на успешности и качестве его конечных продуктов.
>когда точно такой же вопрос не нашелся на stackoverflow и код копипастить неоткуда (или gpt выдал очевидный бред)
В чём проблема задать такой вопрос? Или внезапно выяснится, что чатгпт может ответить на почти любой ваш вопрос? И вы будете выглядеть глупо перед ИИ со своими жалкими мясными мозгами?
В чём проблема задать такой вопрос?
Кому задать вопрос?) как раз тому, у кого есть свои мозги, вместо чатгпт? ну так компании изначально хотят нанять людей с мозгами, а вы предлагаете нанимать тех, кто умеет вопросы задавать ИИ))
Хорошо. Как вы сможете отличить мясные мозги от чатгпт? Я приду со скрытой гарнитурой, может даже в смарточках. Ваши действия (надеюсь видели демку gpt4o?)? Начнёте перед собеседованием обыскивать и проводить в комнату интервью в одних трусах или даже без?
P.S. Вы даже не понимаете на сколько вы смешны в этом плане, когда технологии опережают ваши убогую проторенную дорожку и ни у кого из вас нет ни мозгов, ни таланта что-то изменить.
:D жесть)))
P.S. Вы даже не понимаете на сколько вы смешны в этом плане, когда технологии опережают ваши убогую проторенную дорожку и ни у кого из вас нет ни мозгов, ни таланта что-то изменить.
вот такие мы, жалкие людишки))
>вот такие мы, жалкие людишки
Да, это любопытно. Для меня новый опыт. Я понимал, что ваши представители в силу иных эволюционных стимулов экономят на развитии мыслительного органа. Но не до такой же степени!
Показываешь как пользоваться инструментом, когда смысл сообщения не доходит. Но нет, опять повторные ошибки, переспрашивания с уточнениями. Ну, попробуйте вы чатгпт если не обладаете острым умом для вас же придумали. Судя по всему инструмент ещё нужно упрощать и адаптировать под вашу аудиторию.
Программирование немного сложнее ловли мяча в воротах.
Тем не менее, основной принцип тот же. Стоит на собеседовании проверять по 5% самой сложной работы.
В чём проблема задать такой вопрос?
Нет такой проблемы, я задаю именно такие вопросы. Но давать кандидату чатжпт все равно контр-продуктивно. Зачем тартить время? Потом, если вдруг чатжпт поумнеет и этот конкретный вопрос станет отвечать, то это ничего принципиально не поменяет, кроме того, что мне придется задвать другой вопрос, ведь я же хочу посмотреть, как кандидат думает сам, а не копипастит код из чатика. Опять потеря времени.
И вы будете выглядеть глупо перед ИИ со своими жалкими мясными мозгами?
Я вижу вы тут адепт жпт, но тема-то не об этом. Смиритесь, на данный момент, жпт не заменяет программиста. Поэтому интервью именно такие. Когда станет заменять, эти интервью вообще и не нужны будут, ни про алгоритмы, ни с помощью бота/гугла. Потому что их тупо не будет. Работать будет сам жпт, а мы все пойдем мешки таскать.
>Смиритесь
Боюсь вам придётся смириться, когда на ваши собеседования начнут ходить толпы халявщиков с микрогарнитурой и чатгпт. Это вопрос ближайшего времени. А мне будет смешно наблюдать за вам, когда вы начнёте заглядывать в уши собеседуемым, обшаривать карманы и забирать смартфоны.
Это будет очень смешно, когда кандидат начнет писать полный бред с умным видом, а потом не сможет объяснить, что там происходит. Я проверял, мои задачи ни чатжпт ни всякие "кодерские" сетки не понимают вообще.
Ок, ваша позиция понятна. Вы будете проверять способности чатгпт и формулировать новые задачи при очередных прорывах опенаи. В ухи заглядывать не будете (кстати, бесполезно, я был удивлен современной минитюризации наушников). А что делать другим? Которые не так креативны как вы? Это в том числе касается экзаменов в школах и ВУЗ-ах.
Ок, ваша позиция понятна
по-моему вы не очень поняли, потому что написали вообще нерелевантный ответ, прям как чатгпт)
выше писали о том, что микрогарнитура и прочее не помогут, если ты не понимаешь то, что предлагают чатгпт. предложит ИИ какой-то полный бред, чел напишет и не сможет объяснить, что написал
Экзамены станут устными и нудными. А новые задачи приходится формулировать периодически, потому что старые утекают. Не надо будет отдельно как-то проверять опенаи на прорывы. Еще раз, пока оно не заменяет программиста, будет очень смешно смотреть за галлюцианациями. Когда заменет, просто не будет никаких интервью. Возможно будет короткое окно, когда опенаи уже поумнел, а фирмы еще всех программистов не уволили и даже нанимать продолжают, но о нем не стоит особо беспокоиться.
>будет очень смешно смотреть за галлюцианациями
Я изначально вам привел пример ответа ИИ на вопрос данной статьи. ИИ отработало на 100%. Это статья не нужна, потому что она создаёт только информационный шум.
То, что у вас там где-то есть секретные вопросы, не даёт защиты от 95% остальных вопросов используемых на собеседованиях в различных средних и мелких ИТ конторах, на которые не ответит ИИ со 100% точностью.
Это статья не нужна, потому что она создаёт только информационный шум.
Вот тут у вас есть зерно истины. Эта статья рассказывает очень заезженную, разжеванную везде тему. Прям на хабре такой статьи, по-моему, нет. Поэтому пусть будет. Но именно из-за наличия кучи копий именно этой задачи по всему интернету ИИ с ней отлично справляется. Не потому что умный, а потому что задача - баян.
не даёт защиты от 95% остальных вопросов используемых на собеседованиях в различных средних и мелких ИТ конторах,
Ну так эти конторы - сами себе злобные буратины. Если увлекаются карго-культом, то сами виноваты, что у них интервью не работает. Эти алгоритмические интервью вообще отлично подходят только гигантам.
И надо их правильно готовить: небаянистые задачи, грамотно натренированные интервьюверы. Вы, кстати, в курсе, что для прохождения интервью вообще не обязательно решить задачу? Кандидаты, которые грамотно все объясняют, показвают, что умеют думать, реагируют на подсказки и пишут какой-то хороший код, даже если он имеет какие-то ошибки или вообще не дописан из-за времени, получают больше баллов, чем те, которые молчат 10 минут, а потом выдают идеальный код.
Для мелких контор у таких интервью довольно высокий процент ложных отказов, да и применять их надо с умом, а то лотерея полная получается.
>Для мелких контор у таких интервью довольно высокий процент ложных отказов, да и применять их надо с умом, а то лотерея полная получается.
Очень здорово. Мы возвращаемся к изначальному вопросу. Теперь средние и мелкие конторы будут в ухи заглядывать и отбирать смартфоны у собеседуемых?
>Эти алгоритмические интервью вообще отлично подходят только гигантам.
Вы как-то можете тогда объяснить последние увольнения гигантов: интел, гугл, майкрософт и т.д. Сотни тысяч увольнений за последний год. Это так ваши интервью отлично работают? Или мы внезапно приходим к выводу, что найми эти же гиганты сотни тысяч макак из зоопарка ничего бы не изменилось?
Мы возвращаемся к изначальному вопросу.
Нет средние и мелкие конторы должны что-то другое придумывать. Например, испытательный срок. Или парное программирование. В ухи заглядывать - глупость, ибо проблема даже не в том, что будут жульничать, хоть с ЖПТ, хоть с гуглом, а в том, что интервью тупо не подходит.
Вы как-то можете тогда объяснить последние увольнения гигантов:
При чем тут интервью? Увольняют не плохо работающих сотрудников, а тупо сокращают штат, закрывая целые проекты и направления. Потому что экономический кризис, а инвесторы требуют, чтобы циферки шли вверх, а они как раньше не идут. Плюс, во время ковида все айтишные конторы нанимали, как не в себя (опять же, чтоб инвесторов обрадовать), и штат очень сильно раздулся.
>инвесторы требуют, чтобы циферки шли вверх, а они как раньше не идут
Подождите-подождите, вы ведь наняли лучших из лучших. Почему тогда циферки не идут? Вы ведь для чего людей тогда нанимаете, чтобы на математических вечеринках ботанов тусить красиво? Получается ваши интервью и нанимаемые люди не соотвествуют целям капиталистического гиганта, не? А тогда мы опять приходим "интервью вообще отлично подходят только гигантам". Как это они подходят, если циферки не растут? Что вы за оболтусов нанимаете, которые не способны сделать новые успешные продукты для роста циферок? Которых потом десятками тысяч увольняют.
Да что у вас в голове находится :D
Подождите-подождите, вы ведь наняли лучших из лучших. Почему тогда циферки не идут?
Потому что кризис в эконмике. Инвесторы выводят бабло из акций, вообще не смотря на то, какого качества продукты делают компании.
Причём тут качество продуктов и кризис? Вы и ваши коллеги наняли десятки тысяч человек. Утверждаете, что ваши интервью отлично подходят гигантам. А по факту выясняется, что все нанятые вами люди нахлебники, кормящиеся за счёт прошлых успехов компании (ключевых продуктов перечисляемых на пальцах одной руки, созданные основателями).
По факту мы имеем нанятых нахлебников, которых вы наняли, которые годами протирали штаны, не создав ни одного успешного самоокупаемого продукта. И которых во время кризиса выставили на мороз. Простейшая логика! Но вы продолжаете утверждать, что ваши интервью отлично подходят гигантам. Мне просто уже смешно...
Вы троллите? Я не буду больше тратить время на вашу шизофрению.
Нет, просто взгляд со стороны, по фактам, по результату. Я же не знаю вашу внутреннюю кухню. Возможно вы винтик, которого посадили делать бездумную работу по инструкции и этот винтик и правда считает, что он делает всё отлично, может даже старается и верит в светлое будущее. С винтика как бы спроса нет, с винтиком и правда смысла нет вести беседу. В некотором смысле может и резьбу сорвать, при определенных вопросах...
Да, ваши интервью отлично подходят, чтобы нанинамать нахлебников и увольнять их в очередной кризис. Но вот отличными я бы их не назвал (с точни зрения владельца или акционера компании).
видимо вас сильно обидели на интервью)))
Я предприниматель, поселдний раз на интервью был 20 лет назад, там не обижали. Да, может хоть вы мне объясните (хотя с вами это уже жест отчаяния) про тот же интел, который из-за таких вот отличных интервьюверов как @wataru в очень сильном кризисе, что сео начал молиться в твитере?
да зачем вам мое мнение, лучше спросите у чатгпт))
Ответил почти тоже самое, что и я выше писал, только в более нейтральном тоне:
Текст поднимает важные вопросы о качестве найма и эффективности сотрудников в современных западных компаниях. В условиях кризиса, когда компании сталкиваются с необходимостью оптимизации и сокращения затрат, становится особенно очевидным, насколько важен вклад каждого сотрудника в общий успех.
Критика, выраженная в тексте, указывает на то, что многие нанятые работники могут не соответствовать ожиданиям и не приносить реальной ценности. Это может быть связано с несколькими факторами:
Качество найма: Если процесс интервьюирования не позволяет выявить истинные навыки и потенциал кандидатов, компании рискуют нанимать людей, которые не способны внести значимый вклад.
Культура компании: В некоторых случаях компании могут сосредоточиться на количестве сотрудников, а не на их качестве, что приводит к созданию среды, где неэффективные работники могут оставаться на своих местах.
Экономические условия: В условиях кризиса компании вынуждены пересматривать свои стратегии и сокращать штат, что может выявить слабые места в команде. Это также подчеркивает важность создания самоокупаемых продуктов, которые могут поддерживать бизнес в трудные времена.
Ожидания от сотрудников: Современные компании ожидают от своих сотрудников не только выполнения задач, но и инициативности, креативности и способности адаптироваться к изменениям. Нехватка этих качеств может привести к тому, что сотрудники будут восприниматься как "нахлебники".
Таким образом, текст подчеркивает необходимость более тщательного подхода к найму и управлению талантами, чтобы избежать ситуации, когда компания оказывается с неэффективной командой в условиях кризиса.
и к чему вы пришли из этого текста?)
Изначальный вопрос был риторическим. Но для вас я делаю скидку и попробую сформулировать кратко. То, что работало на малых масштабах, перестаёт работать на больших масштабах. В точности наоборот утверждению waturu. По итогу гугл стал догоняющим в гонке ИИ, интел в затяжном кризисе, у меты нет новых самоокупающихся продуктов и огромные траты на сомнительные идеи. И это я ещё не затронул кризис качества в современных ИТ продуктах.
В этом конечно виноваты не только подобные waturu, проблема комплексная, в частности кто-то этих винтиков поставил на места, вдохновил их на правое дело и выдал инструкции, которым они бездумно или под страхом увольнения следуют.
в частности кто-то этих винтиков поставил на места, вдохновил их на правое дело и выдал инструкции
Вы почти докопались до сути! Что касается процесса интервью, то проблема в том, что всяких ген-директоров, судя-по всему, собеседовать вообще не умеют. А потом, какими-бы гениальными не были программисты, они не могут ничего сделать, если наверху принимают идиотские решения.
Пример из гугла: Stadia. Технология была просто удивительна - можно было запускать игру в дата-центре и играть вообще без лагов в отличном качестве. Прямо из браузера. Даже встроенного в любой смарт-телевизор. Контроллер подключался к сети напрямую для минимизации задержек. Все работало из коробки. Качество сильно выше чем у всех конкурентов. Инженеры проделали отличную работу.
Но проект взяли возглалять Фила Харрисона - человека, который до этого провалил запуск PS3, потом провалил запуск Xbox One. Отличный послужной список! Этого чудика на километр к игровой индустрии подпускать нельзя! Но для корпоратов он свой. Наверно, других свободных экс-директоров с опытом в игровой индустрии не нашлось.
В итоге stadia запустили с идиотской системой монетизации, где надо было покупать игры в гугловом сторе, да еще и платить по подписке сверху за хорошее качество. Все, с кем я ни говорил в компании, и все формы, что я видел, в один голос орали, что это глупость. Что надо делать чисто подписочную модель, потому что люди не будут платить за игру, которую они могут запустить только на этой новой платформе, которая еще и не понятно, а долго ли проживет.
Ожидаемо, Stadia не превлекла людей и по итогу закрылась.
Плохому танцору всегда кое-что мешает. Вы лишь подтвердили мою теорию. Вы типичный ботаник, не видящий дальше своего носа, который не способен охватить картину в целом. Поэтому только по счастливой случайности сможете создать самоокупаемый, успешный продукт. Даже несмотря на огромные финансовые бюджеты и любое дорогое оборудование корпорации. И нанимаемые вами и вашими коллегами люди - вам подстатть. Найми вы зоопарк обезьян в ту же Stadia или лучших математиков - ничего бы не изменилось.
Поэтому вы всегда будете в роли догоняющих и копирующих разработки инноваторов. И это на самом деле здорово, иначе бы в этом мире победившего безумного капитализма было бы совсем грустно жить.
рассуждаете как-будто знаете тонкости всего, но не знаете самого главного - как общаться с людьми)
Все-все, заканчиваю кормить троля.
Поэтому вы всегда будете в роли догоняющих и копирующих разработки инноваторов.
Поинтересуйтесь на досуге, где вообще придумали архитектуру нейросети трансформеров, из которой, собственно и состоит chatgpt. Кто сделал софт, на котором все современные нейросети тренеруют и запускают.
Если бы вы рассказывали, что ваши интервью оптимальны для отбора ученых в университет, я бы прошёл мимо. Вы же рассказываете, что ваши интервью оптимальны для отбора профессионалов в коммерческую корпорацию (да, масло масленное, но для вас нужно выделять жирным), цель которой зарабатывать деньги и торговать акциями на рынке. Поэтому ваши интервью могут быть чем угодно, но только не эффективными для FAANG. Это всё, что я пытаюсь тут сказать.
удивляюсь с вас))
я был удивлен современной минитюризации наушников
С такой штукой можно не только ИИ, а живого чувака-решальщика использовать..
С такой штукой можно не только ИИ, а живого чувака-решальщика использовать..
А ведь у @Fororлогика такая, что людям не надо всего этого учить, надо все у ИИ спрашивать) достаточно умения придумывать правильные промпты )
Учить надо. Но, например, я без чатгпт не смог бы привести оптимальное решение на вопрос в данной статье. Я бы провалил это собеседование. А у меня 20 лет опыта в разработке и решение разнообразных сложных задач.
Чтобы такого не было, надо себя учить, а не надеяться на ИИ)
Если ИИ решает все, то зачем вообще вас нанимать? Наймут человека, который умеет печатать и все
>то зачем вообще вас нанимать?
Затем, что у ИИ нет квантового механизма мышления. А у меня есть https://hightech.fm/2024/08/02/q-brain И на текущий момент это даёт преимущество при решении сложных задач.
Офигеть. Вы после 20 лет не можете ничего придумать в этой задаче? Она, кстати, разогревочная, просто как fizz-buzz, чтобы кандидат хоть какой-то код написал и расслабился.
я без чатгпт не смог бы привести оптимальное решение на вопрос в данной статье
Вы шутите? Ну, допустим, приём из решения 3 не совсем на поверхности, но во втором способе только базовые кодерские навыки, и это по сути решение влоб.
Можно, вопрос лишь в массовости. Ещё найди решальщика, заплати кучу денег. А ИИ вот оно за копейки - plug & play как говорится.
Кстати, используют уже. Люди объединяются и сливают вопросы местных ИИ контор, готовятся сообща. Существуют группы в телеграме. Потому что, этот идиотизм с вопросами всех достал.
Я сам это случайно узнал, пока гуглил микронаушники.
ну разные виды разработок бывают) раньше были Google Driven Development, Stackoverflow Driven Development, а теперь Chatgpt Driven Development. но это все тебе не поможет на собеседовании, там только ты и твой опыт, если ты раньше скопипастил решение откуда-то и не вникал, то это не поможет на интервью)
Я вас не пойму, так доступ с чатгпт даёте или нет?
Чтобы проверить что? ваше умение печатать?) задавать вопрос ИИ?)
Умение задавать вопрос ИИ и гуглить в частности, получая верный ответ очень ценный навык. Если вы этого не понимаете, то вам ещё предстоит долгий путь к этому.
В частности, можете начать развиваться с чтение научной фантастики. Например, Лема Сумма технологий.
удивительно, что у вас за каша в голове)
К сожалению каша у вас в голове, точнее примитивная модель мировосприятия. Но в этом нет ничего страшного это отточенная эволюционная модель поведения в целях экономии ресурсов организма. И она в целом неплохо себя показала.
В этом плане вы даже можете гордиться, что идёте по проторенной дороге ни в чём не сомневаясь. Вам даже можно позавидовать.
Решение задачи с собеседования Middle of the Linked List [+ ВИДЕО]