Из минусов: «швейцарский немецкий». Одного из коллег понимаю процентов на 30, другого процентов на 70. Притом, что немецкий на слух, у меня очень приличный. Можно предложить всем на митингах использовать «хох-дойч» — но это как-то неспортивно. :)

Живу тут 7 років, і в перший раз чую, щоб від іноземців хтось вимагав швіцертюч. Навпаки, його трохи важко вчити, тому, що всі миттєво переходять на хохдойч, як тільки почують акцент — бо думають, що так краще для тебе (хоча ні, я хочу саме вчити ...)

Це міф, ніколи не було ніякої «модерації» YT в РФ-ії. Взагалі в YT є Trust&Safety — контрактори, які сидять в основному в США (але останні роки мабуть десь ще, мабуть в Ірландії, точно не скажу), багато всякого ML (часто з байасом не на користь України, звісно, але такий він вже ML). Ну і бізнес-логіка страйків, яку боти можуть аб’юзити. Я пропрацював в YT 6 років.

Я, кстати, ходил когда-то общаться с Ethics&Compliance с официальным запросом, и знаю много других случаев, когда люди так делали. Можно нарваться как на ответ «нам пох, делай что хочешь» (довольно часто на самом деле), и на ответ «не, ты че, это точно нельзя». Ну, например, нельзя работать с партнерами гугла, даже если это супер хорошо для самого гугла.

С L8+ просто ходить туда обязательно, и скорее всего скажут нет.

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

Почему, ЕС — много стран, Швейцария, и даже США (хотя там чуть сложнее с IRS, которая все норовить приравнять все токены к security, что влечет за собой capital gain tax). Потом Азия — там много возможностей. Одной руки мало все же.

Ну невозможно же применять динамическое программирование, не зная, что это такое.

Давече мне надо было выбрать из иерархических сумм размером в несколько тысяч строк подмножество из 10, максимизирующий сумму. Задача на ДП, сделана тупо в google sheets на AppScript за часик. И никакого рокет саенса.

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

Вітання! Здавав ще старий, цікаво наскільки змінилося.

I думаю, найголовніше це

працюю проєктним менеджером більше шести років

О, вже нова структура екзамену, по PMBOK 7?

Идеально туда идти сразу после универа.

Вопрос не в возрасте, вопрос в уровне/опыте. Я в Гугл запрыгнул с VP Eng стартапов сначала в бизнес сторону, потом в Engineering, и пытаться соответствовать тамошним «job ladders» означало выбрасывать часть своего опыта, что довольно неприятно. До сих пор разгребаю.

Если TL-а зайти сразу на L5, отлично все, не важно какой возраст. А если L6, то вообще круто, но нужно смортеть, чтобы действительно тянуть этот уровень. Там уже тех скилы не так важны, хотя на интервью таки про них спросят.

Розробити схемотехніку і софт для тестування ЖК індикаторів для авіації на 8051 мікроконтроллері. Досить цікаво.

ну protobuf старший за json-rpc, просто всередині гугла був :)

Якщо не хочете protobuf, юзайте XDR. (en.wikipedia.org/...​ernal_Data_Representation) Перевірено поколіннями, і, як бонус, легко можно декодувати очима з hexdump’а в процессі дебага — перевірено на собі років 15 тому :)

Дякую, що так це сприймаєте. Декілька років тому я бачив на UA Pycon проект, який презентували під оплески, як найкращий доклад і т.п. Проект мотивований тим, що люди не хочуть розібратися, що ж їм пропонує операційна система, і пиляють «магічні» рішення щоб це обійти. Проект до-речі був не на пітоні, а саме на голанг.

ну зрозуміло, що затягнути файли в стуркутри даний процесса іноді потрібно і зручно. Але точно не для швидкості сервінгу. Вже років 15-20 є sendfile(2), який із buffer cache зробить dma одразу в мережеву картку, без userspace, напряму в kernel. Так що воно має бути швидше ніж го/раст/та хоч asm.

У каждого проекта по определению есть границы(сроки его исполнения), если их нет — это не проект.

Ок, тогда можно сказать, что лучше работать на «не проекте», а деньги брать в тумбочке :) Серьезно, какой был бюджет и границы у ядра линукса? Или у биткоина?

Я в одной из таких команд был TPM-ом, и за пару недель понял, что там с вопросами по оценке буду послан еще дальше, чем с дедлайнами. Далек мир R&D от стандартной проектной работы, но именно там делаются технологии, на которых потом делают проекты :)

конечно там все есть, но статья-то была об ошибках разработчика

Я знаю несколько команд в Гугле, которые на уровне VP выбили себе правило «никаких дедлайнов», соответсвенно и эстимейтить нечего.

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

UPD: не все проекты коммерческие

Всі на GitLab :)