• Программист из геймдева, Godot, Unity и т.д.
• Программист, меняющий стэк из другой области, не геймдев.
• Начинающий программист без какого либо опыта, в том числе с языками программирования.

Во всех трех случаях подход будет разный, однако, основные моменты будут такими же.

Важно понимать, что внутри позиции Unreal Engine / C++ Developer скрыто множество под-областей.

И это далеко не полный список. Можно включить физику, звуки, и даже рендер.

В разных командах вы можете встретить разные подходы к делению обязанностей среди программистов.

В моей компании часто приходиться заниматься всеми перечисленными пунктами.

Ниже я сначала опишу, как каждому типу людей стоит подходить к изучению топика, и далее уже укажу конкретные вещи, которые спрашивают на собеседованиях и полезные ресурсы.

Помимо прочего, я крайней рекомендую всем уделять внимание общедоступным проектам, из которых вы можете подчерпнуть best-practice'ы.

Их можно найти или на гитхабе, или на маркетплейсе Epic Games.

Неопытный

Вы не знакомы с языками программирования и не знаете, что представляет собой Unreal Engine.

Вам я исключительно советую прибегнуть к курсам и/или видео на ютубе, где с нуля пишут какой-то микро проект.

В вашем случае желательно подойти в первую очередь со стороны Blueprints, т.е скриптовым визуальным языком программирования. Он даст вам базовое понимание работы Actor'ов, Component'ов, сцены и т.д.

После освоения базы, можно пытаться переносить код на C++, параллельно вникая в устройство этого языка программирования.

Важно отметить, что в контексте скриптовки игровой логики для движка вам потребуется лишь небольшая часть этого языка. Поэтому так же советую смотреть гайды по нему в контексте Unreal Engine, чтобы не обнаружить себя на cppreference.com, вникающим в какой нибудь локальный ужас, который вас вероятнее всего отпугнет.

Лично я начинал с курса на Udemy и небольшого шутера на ютубе.

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

Также, важно избегать типичных ошибок новичков: пытаться понять все и сразу. Если вам совсем не очевидно как работают Line Trace'ы или Behaviour Tree, и вы несколько часов копаетесь в исходниках или гайдах, стопаря процесс создания игры, то так не долго и выгореть.

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

Как только освоите базовые понятия, указанные, например, в курсе на Udemy и напишете свой проект, можете начинать искать работу для собора фидбека, или устроиться в стартап на бесплатную основу, чтобы получать хоть какой-нибудь опыт.

Бывалый, не геймдев.

Для вас главной проблемой станет иерархия типов и структур в движке, и сама механика работы real-time движков.

Вы можете приступать сразу к языку и его основам. После - писать свой проект на базе того же курса на Udemy.

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

В остальном все так же как и у начинающего: пишете свой первый проект на C++, и с ним можете идти на собеседования.

Бывалый, геймдев.

Советы тут будут похожи на предыдущий пункт, за тем исключением, что поскольку вы знакомы с общей абстракцией в виде Actor'ов, миров, уровней и компонентов, вам стоит в первую очередь ознакомиться с разницей в функциональностях движка, и тем, как с ними работать.

Советую все так же начать писать свой проект, но уже сильно больше внимания обращать на другие проекты, т.к вы найдете много пересечений с другими движками. Возможно даже вам не понадобится курс. Можете сразу скачать готовый проект и разбираться в нем.

Цели

Ниже приведен список компонентов и ключевых сущностей движка, порядочное изучение которых и составит своеобразную Road map'у.

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

Акторы

Самый простой компонент движка, который можно поставить на сцену: AActor и его производные: APawn и ACharacter. Нужно понять их схожести и различия. Как они работают с компонентами и репликацией.

Плюс, уяснить разницу с UObject, помимо того, что его можно поставить на сцену и напрямую уничтожить.

Компоненты

Компоненты являются строительными блоками для всех актеров. Нужно уяснить как они инициализируются, как уничтожаются и реплицируются. Так же у него есть свои наследники, каждый из которых реализует конкретную функциональность: USceneComponent и UPrimitiveComponent. Они являются базовыми классами для большинства компонентов. Их необходимо разобрать.

Важно во время изучения испробовать разных их наследников, вроде USkeletalMeshComponent или UWidgetComponent, чтобы изучить область применения.

Управляющие сущности

APlayerController, APlayerState, AGameMode, AGameState UGameInstance. Все это базовые игровые сущности, которые необходимо понимать. Их время жизни, работа с репликацией, область применения и смысл существования.

События

Следующим по важности следуют FDelegate и FEvent.

Они, по сути, представляют из себя сущность, на которую вы подписываетесь и ждете когда что-то произойдет (Execute или Broadcast). Кроме того есть Multicast Delegate'ы, Dynamic Delegate'ы и т.д с разными переменными параметрами.

Необходимо поэксперементировать с разными их вариациям для фиксации разных событий при входе в Collision Box'ы, нажатие на мышь/клавиатуру и т.д.

Они создаются через DECLARE_EVENTи DECLARE_DELEGATE.

Мир

Советую вам уделить отдельное внимание таким вещам как ULevelи UWorld. Как они вместе составляют игровое поле, как работать с их Blueprint'ом, классом, и что происходит когда вы переходите с уровня на уровень (UGameplayStatics::OpenLevel).

Базовые классы

Вам необходимо усвоить, что из себя представляет основной класс для всех сущностей движка UObject и UObjectBase. Как при помощи него работает сборщик мусора и, немало важно, как этот класс может работать с репликацией, т.е мультиплеером.

Коллизии

Поскольку вам часто понадобится фиксировать коллизии, то нужно поработать с разными их проявляениям.

1. На уровне компонентов и Actor'ов: каждый UPrimitiveComponent может работать с коллизиями и детектить их, например OnComponentHit, OnComponentBeginOverlap и OnComponentEndOverlap.
2. На уровне кастов: вы можете создавать разные геометрически объекты (Лучи, Сферы и т.д) для фиксации тех или иных сущностей (геометрии). LineTraceSingleByChannel, OverlapMultiByChannel и т.д

Они используются постоянно и являются частью физического движка.

Контейнеры

TMap, TSet, TArray, TList и т.д. Чем отличаются, чем схожи, в том числе с std::unordered_map, std::map и прочими.

На более глубоком уровне советую почитать про TSparseArray.

Рефлексия

Стоит подумать о жизни и смысле существования.

До этого момента вы вероятнее всего уже сталкивались с UCLASS, USTRUCT, UENUM и т.д.

Часто интервьеру, может быть интересно как вы понимаете рефлексию, т.е инструмент, который позволяет анализировать ваш код и генерировать еще больше инструкция для движка.

Те же свойства, прописываемые в UPROPERTY и UCLASS, вроде BlueprintReadOnly являются теми самыми ключевыми словами, по которым создаются дополнительные инструкции для движка.

Сборщик мусора и smart pointer'ы

Концепция эта не нова, однако часто интервьеру может быть интересно в чем вы видите различия std::weak_ptr и TWeakPtr из движка и как они работают со сборщиком мусора. Как последний ведет учет объектов, которые надо уничтожить, можно ли создать TSharedPtr на UObject и т.д.

Тут придется окунуться в стандарт C++ и часть изучить.

Репликация

Не все проекты включают мультиплеерную часть, но на собеседовании часто спрашивают.

Концепция сервера и клиента, RPC вызовы (Server, Client, Multicast), условия репликации переменных и т.д.

Все это важно осмыслить хотя бы на поверхностном уровне.

У меня уже есть статья, с которой очень советую ознакомиться.

Сессии

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

Build Tool и модули

Весь движок состоит из модулей, конфигурации которых прописываются в корневых директориях ваших исходников в файлах .build.cs.

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

Этот топик более узкий и спрашивают его не часто.

Софт и хард ссылки. TSoftObjectPtr, TStrongObjectPtr

Уже более специфическая вещь, связанная с загрузкой и сохранением объектов в памяти.

Нередко интервьюеру интересно, как вы понимаете возможности движка для менеджмента ресурсов, особенно если память устройства сильно ограничена.

Заключение

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

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

Только то, что указано, является необходимой базой (кроме Сессий), в которой важно глубоко разобраться.

Полезные ресурсы

• Официальная документация
• Документация сообщества:
• https://benui.ca/unreal/
• https://ikrima.dev/ue4guide/
• https://vorixo.github.io/devtricks/
• https://unrealcommunity.wiki/
• Мой цикл статей по Unreal Engine.

Собеседование в Nvidia я проходил на позицию Platform Graphics Engineer в ноябре прошлого года.

Судя из описания вакансии менеджером, мне предстояло бы заниматься оптимизацией стриминга GeforceNOW, внося правки в игровые движки, которые предоставляют вендоры.

Подавался я на сайте Nvidia Careers без рефералки, ответ пришел в течение пары недель, что весьма быстро.

На позицию требовались знания графических API, устройства CPU/GPU. Кроме того желателен опыт с игровыми движками, в особенности Unreal Engine.

Я на тот момент не был силен в графике, но менеджер успокоил, сказав, что будет возможность наверстать.

Стоит отметить, что по моим наблюдениям в крупных компаниях первый же созвон состоится с техническим менеджером, который расскажет про вакансию и проведет скрининг. Поэтому ваши заготовленные вопросы HR'ам почему вы заинтересовались компанией <<Рога и Копыта>> вам не понадобятся.

В моем случае, спрашивали азы об устройстве GPU, попросили набросать кода на С++, который профайлит обычный цикл for.

Далее мне было назначено аж 4 часовых интервью в разные дни по схеме ниже, поэтому особой нагрузки я не почувстовал. Вместе с письмом были приложены ссылки на hackerrank, посему стало понятно - будет литкод.

Собеседования

После небольшого интродакшена мне сразу дали рандомную задачку из пула на сайте. Там оказалась задача на интервалы медиум уровня, которую я решал раз 100. Проблем абсолютно не возникло, а даже если я где-то что-то забывал, интервьюер любезно, почти сразу, мне на это указывал.
Оставшюуся часть интервью мне показывали графики производительности и просили проанализировать узкие горлышки в программе, где и почему, как я думаю, игра тормозит. Там я тоже нашел что рассказать так как был знаком с подобными процессами после курса по CUDA.

Так же интро, и простые вопросы по графике, пайплайны, и что, например, делает шейдер тесcеляции. После последовали вопросы easy и medium уровня - связные списки и деревья. На второй задаче я споткнулся, т.к. перенервничал и долбился в одно и тоже не правильное решение.

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

Интро, и сразу hackerrank. Там, на удивление, не было литкода, вместо него попросили распарсить CSV-файл и посчитать частоту кадров с разными условиями ссылаясь на данные. Я набросал простой парсер на питоне, и интервьюера это вполне устроило, если конечно не считать того, что я минут 10-15 распрашивал про условие задачи, и что конкретно дано в CSV-файле.

Достаточно продолжительное интро, где интервьюер копал в те задачи на оптимизацию, которыми я занимался, и далее один литкод вопрос на графы medium уровня.

Результат

После всех интервью я был уверен процентов на 70 что я их прошел. Вопросы были не сложные, касались они оптимизации, с которой я уже работал. Литкода я к тому моменту нарешал в районе 230 задач, поэтому размышления были как нельзя правильными (если не считать небольшой фейл на 2-ом интервью), плюс я каждый раз в конце интервью интересовался, доволен ли интервьюер моими размышлениями, и ни разу не получал отрицательного ответа.

Хотя, быть может, меня обманули...

Ответ я ждал мучительные 4 дня. Каждый день все больше и больше сомневаясь в том, что на любимую вакансию я прохожу.

Ответ пришел - отказ.

Почему, чего не хватает, и где я накосячил, мне не объяснили, а следующее письмо с проcьбой об оном - проигнорировали, обойдясь:

We have found someone who better fits the position.

Выводы

Никогда не бойтесь ходить на интервью в крупные компании. Они бывают разного уровня сложности, но чаще всего это easy-medium задачи и детали из вашей конкретной области, которые вы встретите повсюду.

Никогда не питайте ложных надежд, даже когда лично вам кажется, что все прошло идеально.

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

Вероятнее всего, мне отказали не потому, что я плохо показал себя, а потому, что пришел человек, который знает DX12 или Vulkan. И даже если он хуже меня решил литкод, он все еще остается более подходящим кандидатом.

Удачи!

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

Зачем решать задачи на алгоритмы?

Споры о нужде алгоритмов не утихают до сих пор.

Одни с пеной у рта доказывают, что на работе в них нет никакого смысла, другие топят за улучшение алгоритмического мышления в решении вымышленных задач.

В действительности, решая алгоритмы, мы делаем следующее:

И часто ли вам на работе приходилось выполнять больше двух-трех пунктов из этого списка? Часто ли вы встречались с проблемами, для которых необходим долгий, вдумчивый анализ для составления сложного алгоритмически эффективного решения?

Пример из жизни

Однако, это не значит, что знание основ вам никогда не понадобится. Пример из моей работы:

Язык: C++.

Дан массив каких то структур. Необходимо вызывать определенную функцию у каждого элемента этой структуры, после чего массив почистить. Код будет выглядеть примерно так:

container<Type> elems;
...
for (auto& elem : elems)
{
	elem->Finalize();
}
elems.clear();

Проблема заключается в том, что метод Finalize() может удалить элемент из elems при определенных условиях, и мы получим краш на изменении размера массива в range-based` цикле.

container<Types> elems;
...
void Type::Finalize()
{
	...
	if(...)
	{
		elems.remove(this);
	}
}

Простой подход для решения проблемы - скопировать исходный массив в другой, и пройтись по элементам копии.

На мой взгляд это неэффективно и некрасиво. Без опыта решения задач я бы так и поступил.
В итоге, лаконичное решение пришло через некоторое время:

container<Type> elems;
...
while (!elems.is_empty())
{
	auto elem = elems.pop();
	elem->Finalize()
}

Вам может показаться этот пример глупым и очень простым. По сути так и есть, однако...

Матерые, опытные синьеры на моем проекте копировали массив.
Значит ли это, что решение не так очевидно...?

И это с учетом того, что алгоритмически сложные задачи у нас бывают очень редко.

Почему именно ты сможешь подготовиться к интервью

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

Кроме того, единственное, что я читал это Грокаем Алгоритмы от Бхаргава А. Поэтому никакой академической подготовки у меня нет.

У меня, спустя 250 задач, при открытии очередной medium - hard задачи сразу всплывают знакомые паттерны, на которых строится та или иная задача.

Паттерны

Давайте на конкретных примерах.

Возьмем две на первый взгляд никак не связанные задачи: LRU Cache и Two Sum.

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

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

Опытный алгоритмист на основании требований задачи сразу видит в ней какие-то паттерны.

Самый первый из них, исходя из требований в этих задачах - скорость поиска. Она должна быть константна, а значит тут подойдет только hash map в разных вариацих.

Второе - способ хранения данных.

В первой задаче нужна упорядоченность, которой нет в hash map.

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

Таким образом, суммарно в этих задачах есть 4 паттерна - оба разделяют использование hash map для скорости поиска, только в первой требуется еще и связный список для контроля последовательности, а во второй специфический способ хранения для удобства поиска.

Имеются и другие способы решения, базирующиеся на других шаблонах.

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

Вам нужно научиться эти паттерны отсеивать на самом раннем этапе из возможных, но об этом ниже.

Тогда возникает закономерный вопрос:

И появляется не менее закономерный ответ:

Опытный алгоритмист эту идею быстро отсеит и не будет тратить слишком много времени. После чего возьмет следующую и после нее. Спустя некоторое время сортировки он начнет развивать ту, с hash map, в правильном направлении, прямо как ожидает интервьюер, накидывая на нее мяса в виде дополнительных возможных функциональностей и способов хранения данных.

Из этого следует простой вывод:

Тут возникает следующая ошибка: новички сидят за решением Easy-Medium задач несколько часов, пытаясь подобрать паттерн, о котором даже не знают.

Чтобы эту ошибку не допускать, я рекомендую отводить на задачу любого уровня максимум 45 минут. Этого с лихвой хватает для составляения решения и написания кода. Если вы не укладываетесь, значит вы ничего не придумаете и за 2 часа.

Собеседование

Важно понимать:

Там редко спрашивают что то сложнее Medium, однако, случаи такие бывают.

Чаще всего, если задача easy-medium, то предполагается, что вы должны решить ее практически без подсказок и по сути самостоятельно.

Если вам выпадет Hard, то вероятнее всего интервьюер жаждет с вами побольше поговорить, увидеть как можно больше ваших попыток подобрать решение, и что не менее важно - это решение с интервьюером обсудить.

Для полноты понимания о чем я говорю очень рекомендую посмотреть лайв кодинг интервью в разные компании.

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

Очень часто, если интервьюер видит, что вы неплохо справляетесь, может самостоятельно помочь, указав на какую-то деталь, которую вы не заметили, или намекнуть, если застряли. И это нормально.

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

Заключение

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

Лично я на момент написания статьи решил 126 задач на Leetcode, и ровно столько же на AlgoExpert. Некоторые задачи были похожи, единицы были точной копией и большинство представляли из себя по сути уникальные кейсы.

В процессе подготовки я перед работой я нарешивал в среднем 2-3 Medium задачи или 3-6 Easy или 1 Hard. И так на протяжении трех с небольшим месяцев каждый день по 1.5 - 2 часа.

Надеюсь, вы что-то вынесли из этой статьи, и так же надеюсь, что вам потребуется потратить сильно меньше времени и сил для устройства на позицию мечты.

Спасибо за внимание!

Я распишу что указывать нужно, что нельзя, и на что в первую очередь обращает внимание HR.

Начнем с того, что рекрутер может проверять в день десятки и сотни резюме, посему, считайте, что на вашей анкете он будет задерживаться секунд на 15-30. Если в нем он ничего не увидит за отведенное время, то проще будет скипнуть и приступить к следующему, чем сидеть и разбираться. Из этого следует два вывода:

1. Каждое слово, написанное в вашем резюме, должно иметь смысл.

2. Этих слов должно быть как можно меньше, а смысла в них должно быть как можно больше.

Как правило, если у вас менее 10 лет опыта и меньше пяти компаний, то резюме должно помещаться на одну страницу A4, если этого не происходит, тогда оптимизируйте пространство и умещайте как можете.

Описанное выше - одна из причин, почему я отказался от всех резюме билдеров: они абсолютно неэффективно расходуют пространство.

Ниже - это лучшее к чему я смог прийти на том же resume.io:

И то, что получилось в итоге:

Чтобы собрать пазл о сотруднике уже небходимо идти на следующую страницу. Если было бы больше компаний или пет проектов, то могло бы выйти и на 3 страницы.

Что не нужно писать:

• Дата рождения - Эйджизм никто не отменял. Никогда не светите возрастом пока никто не явно не спросит.
• Город/страна - Бессмысленная информация. Если вы подаетесь в Москву, значит вы или готовы к релокации, или живете в Москве. Если вы подаетесь в US - on site, но не собираетесь переезжать, то просто потратите и свое, и время HR'а в пустую.
• Отдельная графа для скиллов: абсолютно бесполезна. Каждый скилл там ничем не подкреплен. Если хотите аргументировать почему вы это умеете, пишите в секции с местами работы, пет проектами или сертификатами. (У меня на первых итерациях резюме - колонка слева).
• О себе - мне рекомендовали вообще вырезать, я оставил чтобы хоть как то обрисовывать опыт. Допустимо до 200 символов, я бы рекомендовал максимум пару строк.
• Локация места работы - бесполезная информация, советую не указывать.
• Фотография - бесполезная информация - вырезаем.
• Язык - можно указать, если считаете, что это даст вам преимущество на вакансиях и/или есть свободное место.

Что нужно писать:

• Чем занимались на каждой работе по паттерну: ЧТО СДЕЛАЛ/ЧЕМ ЗАНИМАЛСЯ - ЧТО ПОЛУЧИЛ. Это так зываемые bullet point'ы. Их, обычно, указывают от 3 до 5 штук. Я урезал, чтобы поместились все проеты
• Образование - указывать желательно, если есть. Я писал без лет, только бакалавриат. Так же, все ваши сертификаты, имеющие отношения к работе, курсы английского и т.д т.п есть смысл указывать, если только это не олимпиада Кенгуренок за 2 класс.
• Стэк, задействованный в работе - нужно дать понять HR'у чем вы пользовались, однако мне советовали вставлять технологии в bullet point'ы. Это оказалось весьма проблематично и я вынес в отдельный список ниже позиции.
• Опционально - в конце можно добавить ваши хобби, увлечения и пр., но сомневаюсь что хоть кто-то на это посмотрит. Исключением могут выступать ваши блоги/юпуп каналы и прочее, но даже так, я бы оставил ссылку вверху и в первом блоке постарался бы это выделить.

Теперь конкретно по моему резюме:

1. О Себе - заголовок отнимает место и бесполезен - убираем, оставляем только нужный текст. Интуинтивно и так понятно что там и о чем.
2. Профессиональный опыт. В теории там тоже можно было бы убрать заголовок, но место было, и я решил оставить. На первых двух местах работы по 2-3 bullet points с конкретными цифрами и стэком. Так же вставил небольшое описание что за продукт делал и прилинковал сайты.
3. Пэт проекты. Там в любом случае надо писать заголовок, иначе не будет ясно о чем блок. Там по точно такой же схеме - описание проекта в одну строку и 3 bullet points в каждой.
4. Образование - т.к места не хватало, я объединил в один блок и бакалавриат, и сертификаты. Для вуза так же указал стэк, но можно этого и не делать. Почти всем все равно чем ты в вузе занимался.

Так же важно понимать, что ваши резюме прогоняются через Applicant Tracking systems (ATS) разбивая на ключевые слова. Если в вашем резюме ATS не найдет кейвордов на нужную позицию, то его просто выкинут.

Результат по кейвордам, который выдала ATS после сканирования самой первой версии резюме:

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

Так же предлагаю брать мой вариант, и переписывать под себя.