Если речь идет о SWE, то собеседование на «интересные» и «не интересные» позиции не сильно отличаются и в подготовке нет большой разницы. Вы сначала проходите собеседование, а только уж потом происходит team matching, когда вы выбираете себе менеджера и команду. И там есть из чего выбрать.
По поводу скукоты и того что нужно формочки делать — это может быть правдой на определенных проектах, но если вы достаточно умный, чтобы эту скукоту автоматизировать и придумать, как это превратить в «не скукоту», то в Google есть такая возможность. Именно поэтому такие сложные собеседования, чтобы найти людей, которые потенциально могут не только «редирект настроить», но и придумать что-то получше.
Еще такого формата собеседования — это не только в Google, это стандарт по индустрии среди топ компаний (FAANG). По поводу убитого месяца времени, еще как стоит того. Ко всем остальным плюсам, при устройстве в FAANG можно легко получить бонус $15k-$30k (а иногда и выше) за подписание контракта. Вполне себе может покрыть месяц подготовки + значительное повышение зарплаты по сравнению со многими другими компаниями. levels.fyi вам в помощь — там цифры достаточно правдивые.
Я уже почти 2 года работаю в Google и скучно не стало. Нетривиальных задач хватает и с формочками работать не приходится. Все вышесказанное является моим личным мнением, а не позицией компании.
Послушайте, я специально в скобках описал что значит слово «карпул» какраз потому, что не знаю в русском языке аналога этого слова. Я конечно мог бы использовать вместо этого в тексте 7 раз выражение «выделенная полоса для машин, в которых едет 2 и более человек или же машина является достаточно экологичной», но я сомневаюсь, что если бы я это повторил 7 раз, то читать мой комментарий стало бы проще. Знаете аналог в русском — напишите в личку и я скажу Вам спасибо и в следующий раз буду использовать новое слово в своем словарном запасе, а если не знаете — так не срите, пожалуста, в комментариях.
Езжу на этом участке дороги каждый день и знаю этот участок очень хорошо и видел эту аварию, когда в очередной раз там проезжал. Там 2 полосы карпула (ездить там можно только если в машине 2+ пассажира или если машина экологичная), а соответственно в этих 2 полосах машин меньше и ехать получается значительно быстрее (остальные полосы в час пик как правило ели двигаются, а карпул едет с нормальной скоростью). Так вот, в левом карпуле движение еще более быстрое, потому что он уходит в город, а второй карпул идет прямо и многие этим пользуются чтобы всех обогнать и в последний момент вернуться в правый карпул и буквально каждый день вижу такие околоаварийные ситуации, когда машина за 10 метров до этого отбойника на скорости 120 км\ч перестраивается из левого в карпула в правый, еще и заставляя всех в правом карпуле резко тормозить чтобы не врезаться в того кто перестраивается.
P.S. Знаки и разметка на дороге там хорошая и можно заранее понять что дорога будет уходить в другом направлении.
doc.ai — это стартап из США, а не из России. Могу это точно утверждать, т.к. сам там работаю. На самом деле диалоговая система — это только одна из технологий, которую мы разрабатываем. На ICO собирали деньги именно на Neuron — это платформа, на которой пользователи смогут предоставлять свои медицинские данные для машинного обучения, но это совсем в общих словах. Более подробно можно почитать в нашей документации (англ.) или в брошуре (рус.). Есть еще видео с русскими субтитрами.
Кстати, один из наших небольших проектов уже давно доступен публично — Inclusive AI — мы умеем определять пол, возраст, вес и рост человека по селфи.
Тоже думал об этом некоторое время назад. На мой взгляд, не будет такого четкого понятия как передняя и задняя часть автомобиля. Сейчас это есть, т.к. в передней части сидит водитель, если же водителям не будет, а будут только пассажиры, то, думаю, спереди и сзади автомобиль будет выглядеть одинаково и ему будет все-равно в какую сторону ехать. Кроме того, нужно будет делать меньше маневров при парковке, т.к. автомобиль сможет, например, заехать в гараж, а потом из него выехать и поехать дальше без необходимости разворачиваться.
Насколько я помню, Apple уже патентовала что-то вроде touch экрана, который мог бы становится рельефным динамически. К сожалению, найти соответствующую статью на Хабре не удалось.
Я так понял, что в случае с блокчейном дело не столько в способе генерации числа, сколько в том, что любой желающий потом сможет проверить, был ли результат получен правильно.
Перешел как раз с IDEA на Atom по причине крайней тормознутости IDEA. Может для некоторых языков и есть смысл использовать IDEA, т.к. получаешь кучу полезных утилит и автодополнение кода, но для разработки на JavaScript мне от IDEA было больше вреда, чем пользы. В свою же очередь Atom у меня имеет только то что я реально использую и работает субъективно шустрее. К слову, на моем ноутбуке всего лишь 4 ГБ оперативы, Атом в рабочем режиме использует около 1ГБ памяти, PhpStorm же на том же проекте 850 МБ памяти, но при этом PhpStorm во времена индексации загружает процессор под завязку. В обычном режиме PhpStorm использует процессор чуть-чуть сильнее, чем Атом. Ну и в дополнение Атом намного более расширяем, чем PhpStorm.
Есть и более-менее современные редакторы, которые при этом и не совсем IDE и не умеют так умно прыгать по коду, как WebStorm, например. Лично я пользуюсь Atom, в котором вроде бы как и можно эту штуку добавить отдельным плагином, но он работает чуть хуже, чем в WebStorm. Кроме того, иногда приходится код читать онлайн, на гитхабе, к примеру, и тогда хорошо, когда код легко читается сам по себе.
Бывало тоже приходилось писать подобный код, но я все-таки предпочел тот вариант, который вы назвали не очень удобным. Я согласен, что это и правда не самый удобный вариант, однако, мне такой вариант показаля более очевидным. Думаю больше дело вкусов и привычек.
В-четвертых, (не самое главное) определив функцию обычным образом function sayHappyNewYear(year) {… }, например, в глобальном окружении, функцию можно использовать где угодно, хоть после определения, хоть до определения. Переменные, определенные через let, доступны для использования лишь после определения.
Я бы сказал, что такое ограничение очень даже полезно, потому что, как по мне, такой код читать и использовать удобнее, когда есть определенный порядок. Если же функция может быть определена где-то ниже, то, иногда, это не очень удобно.
Использую практически такой же подход, только я для своих нужд написал loader (gulp-task-loader-recursive) для gulp тасков, который, к тому же, загружает их рекурсивно и проставляет каждому файлу с таском красивое имя в зависимости от имени файла и папок, где он находится. В результате gulpfile.js состоит всего из 2 строк (можно и в 1 вместить), а сами задачи лежат в отдельных файликах. Кроме того, очень легко подключается Babel, который потом можно использовать в этих task файлах. Такие отдельные файлики уже гораздо проще копировать между проектами.
В целом, почему мне Gulp нравится больше, чем запуск задач через npm тем, что Gulp позволяет автоматизировать достаточно сложные вещи в достаточно читаемом и понятном виде.
1) Как раз из-за пункта №2. Ведь именно NodeJS добавляет те вещи, которые в других языках есть изначально.
2) Стоит понимать, что JS просто не может развиваться так же быстро, как и остальные языки, т.к. чтобы добавить новую фичу в язык производители самых популярных браузеров должны договориться, нужна ли эта фича и как она будет выглядеть. В других языках, например, выкатили новую версию и можно пользоваться. NodeJS можно считать немного отдельным языком. Сейчас наоборот, фичи из NodeJS добавляют в клиент-сайд (require, например) и библиотеки делают такими, что использовать их можно и на сервере и на клиенте.
3) Так можно же. Если я правильно понимаю, то Вы имеете ввиду это, это, это и это? Все это есть, но для десктоп приложений сейчас именно активнее всего развивается nw.js, о котором уже упоминали выше. Все дело в том, что как раз намного проще писать веб приложения для десктопа, т.к. опять же можно переиспользовать код с сервера или с сайта. Кроме того, дизайн приложения в таком случае можно делать очень гибким и делать его могут верстальщики, а не только программисты.
Я не считаю JS узкоспециализированым. Он и правда универсальный. Например, мне всегда не нравилось, что для валидации данных нужно по сути описывать одну и ту же логику на клиенте и на сервере (чтобы проверять все что можно не обращаясь к серверу и чтобы сам сервер не пропускал не правельные данные, если что). И в случае с JS на клиенте и на сервере это реально возможно и реально удобно. Одну и ту же систему валидации можно использовать и там и там.
Я ожидал, что Google сделают то же самое, не знаю, почему Google не стала развиваться в этом направлении и почему эту нишу заняла сторонняя компания. Да, я понимаю, что у Google есть ChromeOS, но ведь Google часто развивает несколько проектов, которые могут конкурировать друг с другом.
По поводу скукоты и того что нужно формочки делать — это может быть правдой на определенных проектах, но если вы достаточно умный, чтобы эту скукоту автоматизировать и придумать, как это превратить в «не скукоту», то в Google есть такая возможность. Именно поэтому такие сложные собеседования, чтобы найти людей, которые потенциально могут не только «редирект настроить», но и придумать что-то получше.
Еще такого формата собеседования — это не только в Google, это стандарт по индустрии среди топ компаний (FAANG). По поводу убитого месяца времени, еще как стоит того. Ко всем остальным плюсам, при устройстве в FAANG можно легко получить бонус $15k-$30k (а иногда и выше) за подписание контракта. Вполне себе может покрыть месяц подготовки + значительное повышение зарплаты по сравнению со многими другими компаниями. levels.fyi вам в помощь — там цифры достаточно правдивые.
Я уже почти 2 года работаю в Google и скучно не стало. Нетривиальных задач хватает и с формочками работать не приходится. Все вышесказанное является моим личным мнением, а не позицией компании.
P.S. Знаки и разметка на дороге там хорошая и можно заранее понять что дорога будет уходить в другом направлении.
Кстати, один из наших небольших проектов уже давно доступен публично — Inclusive AI — мы умеем определять пол, возраст, вес и рост человека по селфи.
Я бы сказал, что такое ограничение очень даже полезно, потому что, как по мне, такой код читать и использовать удобнее, когда есть определенный порядок. Если же функция может быть определена где-то ниже, то, иногда, это не очень удобно.
В целом, почему мне Gulp нравится больше, чем запуск задач через npm тем, что Gulp позволяет автоматизировать достаточно сложные вещи в достаточно читаемом и понятном виде.
2) Стоит понимать, что JS просто не может развиваться так же быстро, как и остальные языки, т.к. чтобы добавить новую фичу в язык производители самых популярных браузеров должны договориться, нужна ли эта фича и как она будет выглядеть. В других языках, например, выкатили новую версию и можно пользоваться. NodeJS можно считать немного отдельным языком. Сейчас наоборот, фичи из NodeJS добавляют в клиент-сайд (require, например) и библиотеки делают такими, что использовать их можно и на сервере и на клиенте.
3) Так можно же. Если я правильно понимаю, то Вы имеете ввиду это, это, это и это? Все это есть, но для десктоп приложений сейчас именно активнее всего развивается nw.js, о котором уже упоминали выше. Все дело в том, что как раз намного проще писать веб приложения для десктопа, т.к. опять же можно переиспользовать код с сервера или с сайта. Кроме того, дизайн приложения в таком случае можно делать очень гибким и делать его могут верстальщики, а не только программисты.
Я не считаю JS узкоспециализированым. Он и правда универсальный. Например, мне всегда не нравилось, что для валидации данных нужно по сути описывать одну и ту же логику на клиенте и на сервере (чтобы проверять все что можно не обращаясь к серверу и чтобы сам сервер не пропускал не правельные данные, если что). И в случае с JS на клиенте и на сервере это реально возможно и реально удобно. Одну и ту же систему валидации можно использовать и там и там.