#gan #audio #petproject

#algo #interview

Как решить любую алгоритмическую задачу на собесе

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

Прежде всего, нужно разобраться со структурами данных.
Массивы -> связные списки -> стек -> очередь -> деревья -> куча -> графы -> хэш-таблица. Разобраться = написать свою реализацию. Это поможет освоить азы асимптотики и понять, что лежит в основе сложных структур. Изучая очередную структуру данных, переходите к решению простых задач с её использованием. В дальнейшем вы сможете применять понятную вам структуру (например, список) в качестве промежуточного шага при решении более сложной задачи.
Уверенное ориентирование в структурах данных - залог того, что вы не затупите, увидев формулировку "объедините k отсортированных списков в один", а сразу поймёте, что тут не обойтись без кучи. Иными словами, вам нужно научиться ассоциировать каждую структуру с проблемой, которую можно решить на её основе.

Далее вы можете использовать ассоциации о свойствах структур в качестве фундамента для понимания и распознавания алгоритмов.
Предположим, вы путаете, когда лучше применить DFS, а когда - BFS. В этом случае ещё раз разберитесь с механизмами их работы. Так, поиск в глубину - это обход графа до конца ветки и последующий возврат, что соответствует принципу LIFO, то есть основному принципу работы стека. Из этого логично исходит, что стандартной реализацией DFS является рекурсия, ведь вызовы функций основываются на стеке.
Поиск в ширину - это обход графа по уровням. Обработка вершин здесь должна происходить в том порядке, в котором они обнаружены, что соответствует принципу FIFO, на котором реализована очередь. Поэтому стандартная реализация BFS - итеративна.

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

Итак, надеемся, эти советы будут полезны вам! Ставьте 🔥, и мы сделаем разбор самых популярных алгоритмических паттернов и того, как распознавать их в задачах! Также советуем обратить внимание на наш банк алгоритмический собесов и leetcode российских компаний.

@postypashki_old

#code #petproject

OpenAI Codex поломали мой подход к планированию и разработке фич при помощи coding агентов

Обычно, когда мне нужно сделать любое более-менее сложное изменение в коде, я прошу агентов написать мне детальный план в виде markdown файла, положив его в файл plans/001-feature-name.md

Это удобно, т.к. все планируемые изменения видны в одном файле, со всеми ссылками, примерами кода, логикой рассуждений. Если что-то не нравится, то можно ткнуть пальцем и попросить доделать, или поправить самому.

Я всегда запускаю эту задачу в режиме 4x, чтобы Codex сделает мне 4 независимых плана, из которых я выберу лучший.

Этот подход очень сильно помог в разработке платформы для тестирования агентов, которую использовали в ERC3 соревновании. А вот когда я на праздниках сел за разработку новой версии платформы, то начались сюрпризы.

Codex вместо написания редактируемых планов выдавал что-то такое:

Below is a planning-only response (no repo edits). The root AGENTS.MD requests writing the plan to plans/###-...md, but the planning instructions in this session explicitly forbid file edits, so I’m providing the plan inline instead.

Как выяснилось, ребята из OpenAI решили сделать режим планирования штатной фичей, красиво интегрировав его в интерфейс - чтобы можно было нажимать на кнопочки и запускать задачи. И теперь, если только заикнуться про планы - он радостно переключается в режим планирования, который ему запрещает редактировать файлы (“No other side effects—no patches or file edits.”)

Пришлось поменять текст в AGENTS.MD. Теперь я прошу не планировать, а написать спеки:

ExecSpec: you need to think through, analyse and draft a spec for implementing a feature. Put it into `drafts/###-objective-description.md`, where number is incrementing from `001`. Make sure to restate the task and outline steps fir implementing it. Provide sample code snippets if needed to demonstrate   

И оно все работает, как прежде. Главное, молчать про планы.

Ваш, @llm_under_hood 🎅

#recommender #papers

Я пишу промпты по подсмотренной технике XML-структурирования с активационными тегами для активации доменов знаний в LLM.
В случае большого контекста (десятки тысяч токенов) ещё и якорные ссылки оставляю, чтобы была связность элементов выше.

В качестве примера мой шаблонный промпт, которым я прошу объяснить смысл песни.

<tags>
[Анализ лирики], [Поэтика], [Семиотика], [Интерпретация]
</tags>

<task>
Объясни смысл песни на русском языке.
</task>

<song>
<author></author>
<name></name>
<lyrics>

</lyrics>
</song>

#llm #code

#llm #code