Всем привет!

Меня зовут Кирилл, я Android-разработчик. Сейчас я уже привык к тому, что живу и работаю в Лондоне, но год назад и представить себе такого не мог. В этой статье я расскажу, как мне выпал шанс устроиться в международную компанию, о чём спрашивали на интервью, какие этапы нужно пройти, чтобы уехать в Великобританию с семьёй и собаками, и какой он, Лондон.

Заголовок статьи звучит как epic fail, но на самом деле все не так однозначно. Да и в общем и целом эта история закончилась весьма позитивно, хоть и не в Google. Но это уже тема для другой статьи. В этой же статье я расскажу о трех вещах: каким образом проходил мой процесс подготовки, каким образом проходили интервью в Google и почему же на мой взгляд все не так однозначно, как может показаться.

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

Предполагается. что вы знакомы с многими функциями из Java SE, поэтому в основном информация дается кратко. Конечно, можно использовать эту статью и просто для обучения основам Java SE платформы (но в этом случае, после чтения статьи вам скорее всего придется обратиться к другим источникам).



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

Внимание: я не буду касаться вопросов по самому языку Java (вроде для чего нужно слово final или чем overriding отличается от overloading), это потребует отдельной статьи, это вопросы именно по Java SE (6-9) платформе.

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

Однажды задался вопросом — а как в целом в разных странах, ну и в первую очередь в России, защищаются от этой беды?

Про неконкуренцию

Вообще, уход сотрудника — это 3 «полярные лисички», а не одна.

Ушедший сотрудник:

1. создает свою компанию или устраивается к конкурентам (даже не знаю, что хуже);
2. уносит с собой голову, в которой хранится куча конфиденциальной информации и наработок;
3. уводит сотрудников, как правило, наиболее ценных, чем делает «лисичку» еще полнее.

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

О них и поговорим.

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

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

На Хабре да и вообще в русскоязычном Интернете есть немало инструкций о том, как перебраться в Нидерланды. Я и сам немало полезного почерпнул из одной статьи на Хабре (ныне, видимо, скрытой в черновике уже нет, вот она). Но я все-таки расскажу о своем опыте поиска работы и переезда в эту европейскую страну. Помнится, и когда я только собирался рассылать резюме, и когда уже проходил собеседования, мне было очень интересно почитать об аналогичном опыте других коллег по цеху.



В общем, если вам интересен рассказ о том, как C++ программист из Подмосковья искал работу в Европе, желательно в Великобритании, а нашел-таки в Нидерландах, переехал туда сам и привез жену, все это с непогашенной ипотекой в России и с небольшими приключениями — добро пожаловать под кат.

Вступление

В стандарте SQL описывается четыре уровня изоляции транзакций — Read uncommited (Чтение незафиксированных данных), Read committed (Чтение зафиксированных данных), Repeatable read (Повторяемое чтение) и Serializable (Сериализуемость). В данной статье будет рассмотрен жизненный цикл четырёх параллельно выполняющихся транзакций с уровнями изоляции Read committed и Serializable.

Для уровня изоляции Read committed допустимы следующие особые условия чтения данных:

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

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

Что же касается Serializable, то данный уровень изоляции самый строгий, и не имеет феноменов чтения данных.

В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.

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

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

Так что мы подготовили для вас следующие материалы:

• Специальный контест, содержащий задачи, похожие на те, что мы даём на интервью.
• Этот пост. В нём рассказывается, почему нужно проводить такие секции, а также разбираются все задачи контеста.
• Два видео, в которых разбираются задачи из контеста: в первом — задача попроще, во втором — две задачи посложнее. Из этих видео вы узнаете о типичных ошибках, допускаемых и при прохождении алгоритмических секций, и при написании продакшен-кода.

Асинхронное программирование за последнее время стало не менее развитым направлением, чем классическое параллельное программирование, а в мире JavaScript, как в браузерах, так и в Node.js, понимание его приемов заняло одно из центральных мест в формировании мировоззрения разработчиков. Предлагаю вашему вниманию целостный и наиболее полный курс с объяснением всех широко распространенных методов асинхронного программирования, адаптеров между ними и вспомогательных проемов. Сейчас он состоит из 23 лекций, 3 докладов и 28 репозиториев с множеством примеров кода на github. Всего около 17 часов видео: ссылка на плейлист.

В первой части моей истории про собеседование в Booking.com я рассказал лишь половину, а именно все, что касалось удаленного общения из Москвы. Я остановился на том, что получил письмо от рекрутера с заголовком, который гласил «Interview Invitation To Amsterdam!». Это значило, что скоро мне предстояла поездка в Нидерланды, чтобы лично встретиться с кем-то из компании и пообщаться с глазу на глаз.

Наш отдел разработки и управления проектами как-то раз решил поехать куда-нибудь на ТМ-билдинг. Каждый ткнул пальцем в карту и так получилось, что все попали в Амстердам. В целом всё прошло прекрасно, мы отлично провели время, а заодно заглянули в гости в офис Booking.com — компании, услугами которой пользуются многие сотрудники ТМ. Там же работают многие хабрапользователи, в числе которых и CurlyBrace, благодаря которому мы смогли посетить офис.



3 пасхалки под катом.

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


, — cпросили меня. «Да не вопрос! Конечно, смогу», — ответил я, но голос предательски задрожал. «А, еще и на Unity?», — и мне стало понятно, что впереди очень много работы.

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

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

Вот только почти все статьи не про разработку — в них нытье про мою депрессию. Я-то рад, что мне больше не надо никому ничего доказывать. Но вы что, с ума сошли котировать разрабов за такую чушь? Я думаю, сошли, и вижу тревожные симптомы этого везде.

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



А еще год назад у меня в жизни была вроде бы похожая, но в то же время совсем другая ситуация — времени на хобби не хватало, задач было много, но они не приносили мне никакого удовольствия. В итоге я решилась на перемены. На самом деле, эта позиция в Яндексе не была первой, которую я рассматривала. За то время, которое прошло до моего первого рабочего дня, я освежила в голове очень много тем. И перед финальным собеседованием мне пришлось взяться ещё за несколько. Сейчас я понимаю, какие ошибки совершила в этом процессе, поэтому хочу поделиться своим опытом с вами. Буду рада, если кому-то это будет полезно. Хочу сказать, что это не официальные рецепты от рекрутеров Яндекса, а только мои собственные выводы. В конце поста я поделюсь списком литературы, которая мне помогла в подготовке, и еще добавлю те источники, которые считаю полезными, оглядываясь назад.

Вспомним, что такое автоматизация. Возьмем, например, определение из Википедии.

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

Ключевую фразу я выделил жирным шрифтом. Проще говоря, автоматизация нужна для того, чтобы освободить человека от каких-то обязанностей. Что это такое – освобождение человека от обязанностей? Вы ведь слышали фразу «освобожден от исполнения обязанностей»? Это – увольнение.

Если вы занимаетесь автоматизацией, то скажите честно – много ли людей были освобождены от обязанностей благодаря вашей работе? Только здесь важны факты, а не домыслы.

Чем вы занимаетесь большую часть своего рабочего дня? Скорее всего, создаёте или редактируете информацию. И у многих из вас эта информация — тексты: программный код, конфигурационные файлы, письма, строчки чатов и всё тому подобное.
Хотите создавать их быстрее и при этом расходовать на ввод текста меньше внимания? Я расскажу вам несколько эффективных способов увеличить производительность при работе с главным инструментом в этом деле — QWERTY-клавиатурой.

Сомневаетесь, стоит ли тратить на это время? Вспомните — за 30 лет в мире ПК изменилось всё, но клавиатура осталась такой же. Альтернативные способы ввода текста — распознавание речи, письма, жестов, «птичьих» языков (привет, граффити!), аккордные клавиатуры — не сработали и не стали популярными — и, вероятнее всего, ещё очень долго вы будете всё так же вводить тексты с клавиатуры.

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

Карл Дженсен испытал то, что он называет «пробуждением», примерно в 2012-м году.

Он работал программистом в пригороде Денвера, писал код для медицинского оборудования. Работа была напряжённой: ему приходилось документировать каждый шаг для Управления по санитарному надзору за качеством пищевых продуктов и медикаментов США (FDA), а ошибка в коде могла навредить или даже убить пациента.

Дженсен зарабатывал порядка $110 000 в год, у него был определённый соцпакет, но, казалось, что всё это не окупает стресса. Он не мог расслабиться с семьёй после работы; бывало, что целые дни он проводил, обнимаясь с унитазом. Он похудел на 5 кг.

После одного особенно брутального рабочего дня, Дженсен погуглил вопрос «как мне рано уйти на пенсию?», и глаза его открылись. Он посовещался с женой и составил план: в следующие пять лет они экономили значительную часть доходов, серьёзно урезали расходы, пока не собрали порядка $1,2 млн.

Во вторник 10 марта 2017 года Дженсен позвонил своему боссу и предупредил об увольнении после 15 лет работы в компании. Однако он не увольнялся, а уходил на пенсию. Ему было 43.

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

В математике чрезвычайно редко случается, чтобы учёный старше 40 лет опубликовал первую серьёзную научную работу. Ещё реже бывает, чтобы эта работа имела большую научную ценность. Именно такой редчайший случай представляет из себя доцент университета Нью-Гэмпшира Итан Чжан (Yitang Zhang), который до сих не имеет ни должности профессора, ни веб-странички со списком научных работ. Тем не менее, ему удалось совершить серьёзный шаг к решению одной из старейших математических проблем — гипотезе о простых числах-близнецах.

Когда журнал “Annals of Mathematics” получил 17 апреля 2013 года научную работу Чжана, они восприняли её скептически. Заявка на прорывное исследование от неизвестного учёного? Это слишком банально и часто встречается, чтобы оказаться правдой. На удивление редколлегии, несколько научных экспертов подробно изучили работу Чжана — и нашли доказательство гипотезы о расстоянии между парными простыми числами предельно ясным, чётким и бесспорным.

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