Спасибо Loriowar за приглашение на Хабр. Я уже давно почитываю, но никогда не писала. Я сама IT рекрутер из Канады, и мне очень прикольно читать, как программеры воспринимают процесс рекрутмента и hr-ов. Я сама когда-то пыталась стать программистом, прошла весь угар поиска работы да еще в чужой стране, на чужом языке, да и в момент обвала рынка dotcom-ов. Потом мне надоело извиваться как угорь на сковородке перед тупыми рекрутершами, и я решила стать одной из них. Я думала, что никогда не буду вести себя как они, но пришлось, сама логика найма принуждает к этому. Так что я знакома с претензиями обеих сторон к друг другу.

Я несколько дней мылилась, не знала с чего начать. Специфика североамериканского рекрутмента мне знакома досконально, но что будет интересно Хабру не совсем уверена. Я просто решила начать с описания агентской кухни, а дальше как пойдет. Если интересно, сами темы задавайте.

Кстати, рекрутмент в Штатах и в Канаде устроен одинаково, кроме некоторых аспектов, вызванных различиями в законодательстве и иммиграционной политике. А так, методы, подходы, инструменты все одинаковые.

Вот, кстати, и первое отличие — в Штатах до сих пор существуют агентства называемые Employment Services/Placement Consultants/Job Placement Agency и т.п. Они берут оплату с кандидатов за факт трудоустройства. В России такие фирмы, кажется, называются кадровыми агентствами. В Канаде, и по-моему в Англии, данный вид деятельности запрещен законодательно т.к. считается неэтичным.

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

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

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

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

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

Страшилка № 1: кандидата отвергли из-за фреймворка

На позицию фронтенд-разработчика в агентстве я передал инженера, который участвовал в разработке ECMAScript и сделал значительный вклад в некоторые другие проекты open source. Мне понадобилось несколько недель, чтобы найти этого человека, и несколько часов для его правильной оценки, включая видеоинтервью (мы любим такое делать на coderfit.com). Его кандидатуру отверг программист из агентства после 10-минутного просмотра примеров кода. С ним даже не пообщались лично, а просто прислали «консерву» — шаблонное письмо по электронной почте:

«[…]Хотя ваше резюме и сопроводительное письмо очень конкурентоспособны, наши специалисты по найму рассмотрели вашу заявку и не выбрали её для дальнейшего рассмотрения. […]»

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

Вот как я готовился к этим собеседованию и чему я научился на этом пути.

Мой многолетний путь в Кремниевую долину

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

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

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

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

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

Здравствуйте!

Недавно я наткнулся на запись очень интересного выступления Саймона Пейтона-Джонса(ведущий разработчик языка Haskell) в Microsoft Research Cambridge. В нём он рассказывает студентам, как проводить научные исследования и писать статьи по Computer Science. Его мысли мне показались очень интересными, причем применимыми не только для области CS.



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

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



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

Итак, знакомьтесь, Кипр. Солнечный остров в составе Евросоюза, обладающий рекордным количеством чистейших пляжей на квадратный метр площади. Остров, где практически всегда лето, где буквально на каждой улице растут апельсиновые, гранатовые, абрикосовые и оливковые деревья. Остров, где местные жители беззаботны, открыты и дружелюбны. Где компания, в которой я тружусь, предоставляет бесплатное жилье в 10 минутах пешком от офиса плюс своевременно выплачивает денежку.

Пришло время написать файловую систему. Файловая система сама себя не напишет. В этой половинке лабы мы таки реализуем файловую систему FAT32, прикрутим к ней драйвер SD-карты и чуть-чуть повзаимодействуем с ней через нашу интерактивную оболочку.

Нулевая лаба

Первая лаба: младшая половина и старшая половина

Младшая часть. Продолжение под катом.

Дачная электрика – известная проблема, отношение к ней в большинстве случаев наплевательское, если не сказать хуже. Если есть возможность подключить что-то не так и не туда — это, конечно, будет сделано.

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

Вопрос ограничения доступа к данным встает при разработке многопользовательских систем почти всегда. Основные сценарии следующие:

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

Сценарии 1-3 хорошо описаны и обычно решаются с помощью встроенных средств фреймворков, например role-based или claim-based авторизации. А вот ситуации, когда авторизованный пользователь может по прямому url получить доступ к данным «соседа» или совершить действие в его аккаунте случаются сплошь и рядом. Происходит это чаще всего из-за того что программист забывает добавить необходимую проверку. Можно понадеяться на код-ревью, а можно предотвратить такие ситуации применив глобальные правила фильтрации данных. О них и пойдет речь в статье.

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

Текст объемный и рассчитан на:

• начинающих разработчиков, которые только знакомятся с платформой .NET Core;
• опытных разработчиков, выполняющих роль DevOps-инженеров в produсtion-окружении.

В статье не упоминается процесс создания приложений при помощи SDK (dotnet CLI), однако эта информация будет полезной для понимания, как работает SDK, а именно её основной компонент (ядро) — «драйвер» dotnet.dll, поскольку эта библиотека является управляемой сборкой и выполняется на .NET Core.

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

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



Итак, кто заинтересовался — прошу под кат.

Disclaimer: Эту статью я начал писать достаточно давно и закончил только сейчас, так как не было времени. За это время было опубликовано еще 2 аналогичные статьи: вот эта и вот эта. Часть информации в статье повторяет информацию из этих двух статей. Однако, так как всё описанное в статье я рассматриваю через призму собственного опыта, я решил оставить ее без изменений.

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

Всем привет!

Ни для кого не секрет, что интерес к машинному обучению и искусственному интеллекту растет в лучшем случае по экспоненте. Тем временем мой Яндекс Диск превратился в огромную свалку пейперс, а закладки в Google Chrome превратились в список, длина которого стремится к бесконечности с каждым днем. Таким образом, дабы упростить жизнь себе и вам, решил структурировать информацию и дать множество ссылок на интересные ресурсы, которые изучал я и которые рекомендую изучать вам, если вы только вначале пути (буду пополнять список постоянно).

Путь для развития новичка я вижу примерно так:

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

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

Далее, я часто занимаюсь анализом трудоемкости алгоритмов. Размеры наборов данных, подвергаемые обработке в наши дни, просто колоссальны. В 2010 году на конференции Techonomy Эрик Шмидт сказал, что объем данных, создаваемых сегодня человечеством всего за два дня, равен объему всех существовавших в мире данных по состоянию на 2003 год. Мне важно уметь обрабатывать большие сегменты этих объемов и извлекать из них пользу. И в этом смысле понимание пространственно-временной сложности операций, применяемых нами к данным есть ключ к определению того, возможны ли те или иные вычисления в принципе. В отличие от более традиционных видов O-анализа или тета-анализа постоянные множители в таких масштабах оказывают существенное влияние: множитель 2 не меняет асимптотическую временную сложность алгоритма, но потребует увеличения количества процессоров с 10 тыс. до 20 тыс., и такая разница в потреблении ресурсов будет ощутима. В результате вычисления становятся более изощренными. Примеры: могу ли я взять некое линейное вычисление и снизить его в силе до логарифмического? Можно ли снизить потребление памяти в три раза? И так далее.

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

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

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



О спикере: Илья Космодемьянский CEO и консультант в компании Data Egret, специалист по базам данных PostgreSQL, Oracle, DB2. А кроме того, отвечает за продвижение Postgres-технологий, выступает на конференциях и рассказывает людям, как с ними работать.

Ниже материал по докладу Ильи на РИТ++ 2017, который не был связан с какой-то конкретной базой данных, но охватывал многие основные аспекты.

Недавно мой знакомый Karl (имя изменено) проходил собеседование на должность DevOps и обратился ко мне с просьбой проверить его решение. Я почитал условие задачи и решил, что из нее бы вышел неплохой тест, поэтому немного расширил задачу и написал свою реализацию, а заодно попросил коллегу Alex подумать о своей реализации. Когда все три варианта были готовы, я сделал еще две сравнительные версии на C# и сел писать эту статью. Задача довольно проста, а соискатели находятся на неких ступенях эволюции из админов в программисты, которые я и хотел оценить.

Кому интересны грязные детали, необъективные тесты и субъективные оценки — прошу под кат.

Принципы SOLID — это стандарт программирования, который все разработчики должны хорошо понимать, чтобы избегать создания плохой архитектуры. Этот стандарт широко используется в ООП. Если применять его правильно, он делает код более расширяемым, логичным и читабельным. Когда разработчик создаёт приложение, руководствуясь плохой архитектурой, код получается негибким, даже небольшие изменения в нём могут привести к багам. Поэтому нужно следовать принципам SOLID.

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

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

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

Привет Всем! Я недавно запустил на GitHub проект JavaScript Algorithms and Data Structures, который содержит примеры классических алгоритмов и структур данных написанных на JavaScript с объяснениями, примерами и ссылками для дальнейшего изучения (в частности на соответствующие YouTube видео).

Основная задача проекта — помочь программистам в изучении и применении алгоритмов и сделать это на JavaScript-е.

Здравствуйте, в эфире Радио SQL!

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

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

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

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

26 апреля 2018 года компания ИНФОРИОН провела конференцию для студентов МГТУ им. Баумана SMARTRHINO-2018. Специально для конференции было подготовлено небольшое устройство на базе микроконтроллера STM32F042.

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

Первая часть статьи составлена по мотивам проведённого мастер-класса и рассчитана на начинающих — уделяется внимание базовым подходам к реверсу прошивок и особенностям работы с дизассемблером IDA.

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

Осторожно, под катом мигающий носорог и его прошивка!