Программистка, архитекторка, ахахахка
По мотивам своих собеседований, а также собеседований коллег и mentee, составил список вопросов от тимлида к компании, что стоит прояснить на собеседовании — что спросить собеседующего.
Вопросы подойдут, возможно, не только тимлиду, но были придуманы для него.
Каковы финансовые показатели компании?
Является ли компания прибыльной или тратит деньги инвесторов? Или даже до инвесторов ещё не дошло, и основатели пока платят из своего кармана? Как выглядит бизнесовый план развития?
Если компания имеет представительство в РФ, официальное ли (по ТК РФ) трудоустройство и полностью ли "белая" зарплата?
Даже сейчас некоторые компании порой используют "серые" схемы выплат зарплат. Также иногда бывают сотрудники, сознательно просящие "серую" схему.
Расскажите про ваше понимание «хорошего тимлида»
У собеседника должно быть четкое и непротиворечивое понимание, что он вкладывает в понятие «тимлид» и какие критерии используются для оценки работы тимлида.
Возможно, это понимание даже прописано в должностных инструкциях.
Где-то тимлид должен быть разработчиком (то есть, писать код) с минимальной общественной нагрузкой, где-то руководителем, где-то пытаться совместить.
Всем привет! Меня зовут Александр, я уже более 5 лет работаю с Unreal Engine, и почти все это время — с сетевыми проектами.
Поскольку сетевые проекты отличаются своими требованиями к разработке и производительности, нередко необходимо работать с более простыми объектами, такими как классы UObject, но их функциональность изначально урезана, что может создать сильные рамки. В этой статье я расскажу о том, как активировать различные функции в базовом классе UObject в Unreal Engine 4.
На самом деле, статью я написал скорее как справочник. Большую часть информации крайне сложно найти в документации или сообществе, а тут можно быстро открыть ссылку и скопировать нужный код. Решил заодно поделиться и с вами! Статья ориентирована на тех, кто уже немного знаком с UE4. Будет рассмотрен С++ код, хотя знать его не обязательно. Можете просто следовать инструкциям, если вам нужно то, о чем пойдет речь. Более того, не обязательно копировать все, вы можете вставить код из раздела с нужными свойствами и он должен работать.
Когда я только начинал инженерную деятельность разработкой пеленгаторов, в головах опытных товарищей, называемых нами, молодыми, за глаза "дедами", бродила мечта о “пеленгаторе на пупке”. “Это — говорили они — такой маленький пеленгатор, который можно носить с собой и пеленговать украдкой. Вот, дескать, нам приходится таскать на себе такие тяжести на крышу и обратно (хотя таскала, конечно, молодежь), а они, молодежь, никак не разработают такую вещь”. Смотря на стоящие на столе огромные железяки, мы считали их немного не в себе.
Со временем техника уменьшалась в размерах, конечно не настолько, чтобы можно было носить за пазухой. Но несколькими годами позднее, познав немного проектирование антенной техники, я уже не относился к этим мечтам старших товарищей, как к бредням.
Затем буря экзистенциального кризиса вынесла меня из уютного офиса прославленной в узких кругах организации в жестокий океан народного хозяйства. Но молодость не отпускает, она въедается в наш мозг и я обнаружил — что бы я ни взялся делать, у меня почти всегда выходил пеленгатор. По крайней мере, так говорят мои товарищи.
Ужасный рок! Но я осмотрелся и увидел, что пеленгаторы могут быть нужны обычным людям. Это давало надежду!
Примечание: статья написана исключительно в ознакомительных целях, и не является призывом к повторению подобных экспериментов дома ввиду потенциального риска причинения вреда физическому здоровью (в случае использования в приборах Li-ion аккумуляторов и фоторезисторов).
Здравствуй, Хабр! Хочу предложить вашему вниманию немного магии для часов на Wear OS.
Здравствуйте, меня зовут Дмитрий Карловский, и я — профессиональный велосипедист. За всю свою карьеру я сделал кучу велосипедов: больших и маленьких, быстрых и удобных, кривых и прямых. Поэтому для меня довольно дико видеть толковых программистов, делающих большие и сложные приложения, но при этом подключающих к проекту очередной leftpad, вместо того, чтобы написать пару простых строк своими руками. Всему виной сформировавшаяся в среде программистов и поддерживающая сама себя боязнь велосипедов в продакшене.
Каждый раз, когда приходит время искать работу, кандидат садится обновлять резюме, и попутно смотрит более опытным взглядом на свой прошлый опыт. И все переписывает, снова и снова. И каждый раз думает, что найдет вакансию мечты, а дальше станет уже настолько опытным, что на новое место его будут звать без каких-то действий с его стороны. А потом история повторяется, снова и снова.
Для тех, кому не интересна лирика, и кто хочет сразу перейти к делу — то вперед на github. А для тех, кому важна механика и история проекта — собственно и посвящена статья.
С появлением специализированных ресурсов биржы труда, таких как LinkedIn, HeadHunter и др., казалось бы, ситуация должна была улучшиться — заполняем весь опыт в одном месте, и больше прошлое не ворошим. Но не тут-то было — заполнили в одной системе, нельзя просто по клику мышки выгрузить ее в другую. Нету единой БД, на которую можно линковать свою учетную запись. Оно и понятно — подобные компании заинтересованы вытеснить других, а не заниматься интеграцией друг с другом, а простым кандидатам в итоге становится только хуже.
