Pull to refresh

Comments 8

Можно просто на gist.github.com выложить.

С этим методом в Google Документах, конечно, знакомы все, но это не самый лучший способ. Публикуя так, вы даете ссылку на живой документ. У этого есть несколько недостатков:

  • Если вы захотите подправить резюме, а читатель случайно откроет документ в этот момент, он или она увидят вашу правку в реальном времени, не профессионально, а может и увидят что лишнее :).

  • Гугл показывает список аватаров людей у кого документ открыт в этот момент (если люди открыли документ будучи залогинены в Гугл). Это нехорошо с точки зрения приватности.

Рекомендую вместо этого воспользоваться функцией File > Share > Publish to web. Это будет просто HTML страничка без недостатков выше.

Можно оставить опцию Automatically republish when changes are made, тогда опубликованный документ по ссылке будет обновляться через несколько минут после редактирования. Шансы увидеть промежуточный результат все еще есть, но довольно низкие. Можно её отключить, тогда после редактирования надо каждый раз не забыть сделать операцию Publish to web снова.

nginx+чтоугодно. и нет проблем. например можно в latex сверстать простенький html/pdf/md/etc

Не соглашусь с пунктом про "быстро исправить опечатку".
HR как правило сохраняет резюме локально, либо перепечатывает в свою стандартную форму. Кто знает, когда ты решишь закрыть своё резюме, а так будет локальная копия.
А вот за обновлением данных HR уже не следит.
Я так один раз обжёгся, когда опечатался в номере телефона. За пару часов все успели сохранить неправильную версию и потом месяц удивлялись, почему не могут до меня дозвониться.

Не совсем понимаю, а зачем оставлять номер?

Есть почта - классика Или тот же телеграм....

А так будут звонить не совсем удобное время

На днях буквально задумывался над тем, где хранить свое резюме разработчика. Требования:
  1. стильно выглядело, а не как экспорт с хх
  2. под системой контроля версия (желательно в текстовом виде), чтобы можно было вести историю и желательно ветки для разных вакансий

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

Google docs удобен, хранит историю, но только линейную без веток. Раньше использовал его.

Сейчас же выбрал формат FODT, хранение в git и деплой PDF/DOCX на gitlab.io (где же еще должно лежать резюме разработчика, как не рядом с кодом?)

P. S. Еще есть jsonresume.org. Идея отличная, но реализация… Схема документа странная, плохо подходит для российских реалий, да и с шаблонами проблемы — ручная разметка часто необходима.

Много лет держу собственный сайт-визитку (в профиле), когда ищу работу - вместе с файлом резюме отправляю и ссылку. Просто ссылку без файла чаще всего HRы игнорируют. Да и заходят по ссылке крайне редко (контролирую по логам веб-сервера).

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

Так что версия со ссылкой в нашем мире как-то не очень работает на практике.

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

Sign up to leave a comment.

Articles