Все кто распространяют информацию о якобы лишении гарантии распространяют заведомую ложь
Возможно, вы и правы. Вопрос в том, что если вам откажут в гарантийном ремонте, пойдете ли вы судиться, или проглотите?
Тут мог бы быть сказ о том, как я в РФ носил на ремонт жесткий диск (у которого полетела прошивка контроллера из-за признанного производителем бага), и брать по гарантии его отказались потому что на корпусе была еле-заметная царапина ("механические повреждения").
Почитав о ваших открытиях, которые вы сделали, очень советую вам взять хороший учебник по C# и паттернам, особенно если вы и дальше планируете разрабатывать на C# / Unity.
Сегодня Unity это такой php образца 2005ых годов, с крайне низким порогом вхождения, но при этом он напичкан антипаттернами и прививает абсолютно отвратные практики программирования. Результат — 90% программистов Unity не знают основ языка и программируют на какой-то своей версии C# (которая у них в голове сильно искажена).
Просто оставлю это здесь, что бы вы не писали больше ерунды: РКН рассылает предупреждения на русском языке по email'ам, которые они берут из whois.
По крайней мере раньше точно так делали.
Можете сами напрячь воображение и представить штатного сотрудника первой линии поддержки support@amazon.com, который получает в хелпдеск интернет-мазагина тикет сомнительного содержания на каком-то непонятном восточноевропейском языке от непонятно кого.
А даже если они проявят инициативу и переведут это гугл транслейтом и поверят в домен gov.ru, и отправят ответ, то РКН принципиально на английском общаться отказывается, ведь их логика простая — «хотите работать в России, учите русский язык». Их не волнует амазон это или гугл.
В той же поддержке Cloudflare несколько лет назад мне говорили что они знают о ситуации и много раз пытались связаться с РКН, но на контакт на английском языке РКН не выходит принципиально.
Терпеть не могу вопросы про двоичные деревья, но в данной ситуации я был на стороне гугла.
Во-первых, Гугл заранее предупреждает, о чем будет интервью и что в нем будут задачи на алгоритмы и структуры данных. Это указывается как в письме, так и во многих туториалах от самого гугла.
То есть если человек не знает о двоичных деревьях, это значит он вообще не готовился к интервью, от слова совсем.
А во-вторых, когда я проходил интервью в гугле, мне уже на этапе phone screen задавали такие задачи (например, нестандартные алгоритмы работы с графами), по сравнению с которыми инверсия двоичного дерева это детский лепет.
Во многих странах так. Государственные учреждения — не частные компании, там работают совсем другие правила. В том числе совсем другие требования к прозрачности зарплатам.
Если кто-то из руководства назначил своего сыночка на неадекватную зарплату — в частной компании пострадает владелец (который ошибся с руководством), а в гос. учреждении пострадают налогоплательщики.
Для того, что бы расти — необязательно знать зарплату своего коллектива, и уж тем более не обязательно рассказывать направо и налево, за сколько вы себя (свои услуги) продали работодателю.
Есть гораздо более эффективные способы узнать о возможностях роста (поспрашивать у других сотрудников, например).
Так или иначе, зарплаты будут у всех разные, ситуации у всех разные, одинаковых зарплат в нормальной компании не бывает. Все складывается из того, сколько хочет человек получать за свои услуги, и сколько компания ему готова предложить.
Кто-то хочет больше из-за опыта работы в крупных компаниях, кому-то накинули потому, что на предыдущем месте платили много, а вот именно этого специалиста нужно и надо было его "перетянуть", кому-то добавили за ускоренное вступление в должность, а кто-то только после колледжа с синдромом "самозванца", соображает быстрее чем большинство сеньоров, но готов работать за гроши.
Все по-разному, но, конечно, в пределах разумного.
Советская в том плане, что "запретить, нарушителей — наказать". Нужно выстраивать систему мотивации так, что сотрудникам самим будет не выгодно рассказывать о своей зарплате.
Любые отношения работодателя и сотрудника, это в любом случае бизнес-отношения. Считать иначе, рассчитывать на "честность" и "прозрачность" — это очень наивная позиция. Обе стороны пытаются договориться об условиях на максимально выгодных для себя.
Логика Лебедева о том, что бы "запрещать, а если разболтал — увольнять" — это абсолютно советская логика. Разумный человек и так и так не будет направо и налево рассказывать о своей зарплате, понимая все последствия владения конкурентами (т.е. вашими коллегами) этой информации.
Неправильный. Крупные компании, в основном, задают такие вопросы на этапе phone screen / skype interview, потому что они не могут позволить себе возить к себе в офис всех за свой счет, и им нужно отсеять 90%. Они отсеивают тех ребят, которые умеют быстро за ограниченное время решать сложные логические задачи.
В небольшой компании в таких вопросах смысла нет, гораздо лучше спросить то, с чем необходимо иметь дело в работе (особенности языка, паттерны, boxing / unboxing, итд).
Возможно потому, что знание теории computer science и типов данных (вроде всяких односвязных-двусвязных списков, двоичных деревьев итд) не имеет отношения к прикладному программированию, только если вы не разрабатываете свой ЯП или свою базу данных.
И человек может это знать, только если у него в университете был CS101 (чего в российских реалиях ожидать глупо), либо если он готовился к собеседованиям по книгам.
А вот что такое Boxing/Unboxing при разработке на C# знать надо, но джуниорам не знать это простительно.
Не проходил собеседования в Tesla / Apple, но проходил в других больших компаниях, и советую книжку "Cracking the Coding Interview by Gayle Laakmann McDowell". Автор работала в Google, Microsoft, и Apple, и вопросы в больших компаниях в основном очень похожи.
Один способ — это иметь отдельную БД типа Redis в которой хранить исключительно список отозванных токенов. Таких токенов в реальности будет совсем немного, т.к. после даты истечения токена (максимум минут 10) его можно будет из этой БД удалить, соответственно нагрузка на такую БД будет меньше. Это, конечно, не идеальный вариант, но он гораздо лучше, чем "простая" модель аутентификации.
Система с refresh/access токенами крайне удобна, если ваша архитектура состоит из микро-сервисов.
Например, у вас есть облако тип AWS, которое состоит из микросервисов типа хранилища (S3), сервиса управления серверами, бэкапы, итд.
Вы, конечно, можете сделать все это одним большим монстро-приложением, но рано или поздно вам прийдется делить его на части. И вот тут вариантов у вас будет не много — вам прийдется либо дублировать код с БД и аутентификацией, либо выносить его в отдельный пакет. О безопасности тут уже и говорить нечего — каждый модуль будет требовать доступа к БД с пользовательскими сессиями.
Access/refresh токены элегантно решают эту проблему. У вас есть один сервер аутентификации, который проверяет в БД логин/пароль, и выдает вам какой-нибудь jwt токен с информацией о юзере/правах, подписанный приватным ключем сервера аутентификации. Такой токен нельзя отозвать, но зато у него крайне короткий срок жизни, например 5 или 10 минут. Вместе с ним выдается refresh токен, который используется пользователем для "обновления" access токена через тот же сервер аутентификации.
Собственно, задача решена. Все, что потребуется остальным микросервисам — проверить токен с публичным ключом и убедиться, что юзер имеет доступ к заданному. Никакой работы с БД, никакой интеграции с сервисом аутентификации, единственная зависимость — это библиотека для работы с токенами (JWT).
Вы даже можете использовать разные ЯП/стэки технологий для написания ваших микросервисов (например, сервис чата с техподдержкой вы можете написать хоть на C++, если так уж хочется) — все что нужно это возможность расшифровать токен и проверить его валидность.
С безопасностью тут тоже все впорядке — БД аутентификации находится за семью файерволлами, ни у кого кроме сервера утентификации к ней доступа нет, как и к приватному ключу, которым подписывается токен.
Единственный минус такой системы — это невозможность мгновенно отозвать access токен. Но это как правило и не нужно, т.к. срок жизни такого токена крайне короткий (несколько минут).
ДТП — типичная ситуация, и по идее женщина виновата.
С другой стороны, если на перекрестке много автомобилей и плохая видимость, лично я всегда стараюсь слегка сбросить скорость, так как несколько раз вот такие вот «умники» поворачивали налево, не видя меня и не убедившись в безопасности маневра, и приходилось резко долбить по тормозам.
Честно говоря, так и не понял, в чем инновация. На внутренних рейсах США у гейтов уже давно ничего не нужно предъявлять, что бы пройти на посадку нужно просто приложить к сканеру посадочный талон или QR-код в телефоне.
ID (вод. права) нужно показать только один раз при прохождении security. В этот момент человек просто проверяет внешность и сравнивает ваше имя с тем что указано в посадочном.
Если использовать свою карту (со своим дизайном итд), то доказать, что была использована чужая карта и нарушены авторские права очень трудно.
Во времена бумажных карт и путеводителей, американские компании добавляли на свои карты фейковые города и улицы, что бы потом в суде можно было доказать что их информация была скопирована.
Зубрить — не надо. Готовиться к интервью нужно, при чем готовиться должен как работодатель, так и соискатель.
Отвечая на ваш вопрос, "почему результат собеседования зависит от того насколько человек к нему подготовился".
Лучшие интервью, которые у меня были — это были интервью из серии "рассказите о проекте X из вашего резюме, какой стэк технологий применялся, какие были трудности в этом проекте, как вы их решили, что бы вы сделали по другому если бы решали эту задачу сегодня". У меня была пара таких интервью, результатом обоих был job offer. Никто не ставил под сомнение моё умение программировать.
Но тут надо быть реалистом и понимать, что гугл не может себе позволить такие интервью без изначального просева кандидатов. Что бы попасть в гугл, люди могут написать и придумать в резюме что угодно.
В связи с этим их политика заранее предупреждать, какие задачки будут задавать на интервью, по мне звучит наиболее логичным способом. По крайней мере, все кандидаты имеют возможность подготовиться. Это гораздо лучше, чем если бы они задавали случайные задачи, и люди участвовали бы в лотерее "умею ли я решать задачу на эту тему".
Отдельная история начинается тогда, когда веб-студии из 10 человек начинают задачать вопросы по двоичным деревьям, поленившись даже прочитать твое резюме. Есть тут такие компании на Хабре.
Одно дело, когда спрашивают написать двоичный поиск или инвертировать двоичное дерево (вопрос, на который не смог ответить Макс Хауэлл). Это действительно, элементарная задачка на рекурсию, весь код займет 5-10 строк. И не знать как ее решать действительно странно. Тем более что в гугле предупреждают о том, что там спрашивают такие задачки. Т.е. если человек не смог инвертировать двоичное дерево, это значит что он вообще не готовился к интервью, от слова совсем.
Другой разговор — задачки вроде "напишите балансировку красно-черного дерева на доске". Это ни 2й и не 3й и не 5й курс. Если вы в университете зубрили как балансировать RB-деревья, то у вас был странный университет.
Я уверен, что ни один нормальный человек не сможет сам такие алгоритмы придумать или по памяти это воспроизвести, если он специально для интервью не зубрил это.
Не совсем, поскольку это не совсем создание нового документа. Вам открывается страница с пустым шаблоном, который вы потом уже можете сохранить.
Т.е. само открытие страницы не приводит к созданию или изменению чего-либо.
Возможно, вы и правы. Вопрос в том, что если вам откажут в гарантийном ремонте, пойдете ли вы судиться, или проглотите?
Тут мог бы быть сказ о том, как я в РФ носил на ремонт жесткий диск (у которого полетела прошивка контроллера из-за признанного производителем бага), и брать по гарантии его отказались потому что на корпусе была еле-заметная царапина ("механические повреждения").
Почитав о ваших открытиях, которые вы сделали, очень советую вам взять хороший учебник по C# и паттернам, особенно если вы и дальше планируете разрабатывать на C# / Unity.
Сегодня Unity это такой php образца 2005ых годов, с крайне низким порогом вхождения, но при этом он напичкан антипаттернами и прививает абсолютно отвратные практики программирования. Результат — 90% программистов Unity не знают основ языка и программируют на какой-то своей версии C# (которая у них в голове сильно искажена).
По крайней мере раньше точно так делали.
Можете сами напрячь воображение и представить штатного сотрудника первой линии поддержки support@amazon.com, который получает в хелпдеск интернет-мазагина тикет сомнительного содержания на каком-то непонятном восточноевропейском языке от непонятно кого.
А даже если они проявят инициативу и переведут это гугл транслейтом и поверят в домен gov.ru, и отправят ответ, то РКН принципиально на английском общаться отказывается, ведь их логика простая — «хотите работать в России, учите русский язык». Их не волнует амазон это или гугл.
В той же поддержке Cloudflare несколько лет назад мне говорили что они знают о ситуации и много раз пытались связаться с РКН, но на контакт на английском языке РКН не выходит принципиально.
Терпеть не могу вопросы про двоичные деревья, но в данной ситуации я был на стороне гугла.
Во-первых, Гугл заранее предупреждает, о чем будет интервью и что в нем будут задачи на алгоритмы и структуры данных. Это указывается как в письме, так и во многих туториалах от самого гугла.
То есть если человек не знает о двоичных деревьях, это значит он вообще не готовился к интервью, от слова совсем.
А во-вторых, когда я проходил интервью в гугле, мне уже на этапе phone screen задавали такие задачи (например, нестандартные алгоритмы работы с графами), по сравнению с которыми инверсия двоичного дерева это детский лепет.
Во многих странах так. Государственные учреждения — не частные компании, там работают совсем другие правила. В том числе совсем другие требования к прозрачности зарплатам.
Если кто-то из руководства назначил своего сыночка на неадекватную зарплату — в частной компании пострадает владелец (который ошибся с руководством), а в гос. учреждении пострадают налогоплательщики.
Для того, что бы расти — необязательно знать зарплату своего коллектива, и уж тем более не обязательно рассказывать направо и налево, за сколько вы себя (свои услуги) продали работодателю.
Есть гораздо более эффективные способы узнать о возможностях роста (поспрашивать у других сотрудников, например).
Так или иначе, зарплаты будут у всех разные, ситуации у всех разные, одинаковых зарплат в нормальной компании не бывает. Все складывается из того, сколько хочет человек получать за свои услуги, и сколько компания ему готова предложить.
Кто-то хочет больше из-за опыта работы в крупных компаниях, кому-то накинули потому, что на предыдущем месте платили много, а вот именно этого специалиста нужно и надо было его "перетянуть", кому-то добавили за ускоренное вступление в должность, а кто-то только после колледжа с синдромом "самозванца", соображает быстрее чем большинство сеньоров, но готов работать за гроши.
Все по-разному, но, конечно, в пределах разумного.
Советская в том плане, что "запретить, нарушителей — наказать". Нужно выстраивать систему мотивации так, что сотрудникам самим будет не выгодно рассказывать о своей зарплате.
Любые отношения работодателя и сотрудника, это в любом случае бизнес-отношения. Считать иначе, рассчитывать на "честность" и "прозрачность" — это очень наивная позиция. Обе стороны пытаются договориться об условиях на максимально выгодных для себя.
Логика Лебедева о том, что бы "запрещать, а если разболтал — увольнять" — это абсолютно советская логика. Разумный человек и так и так не будет направо и налево рассказывать о своей зарплате, понимая все последствия владения конкурентами (т.е. вашими коллегами) этой информации.
Неправильный. Крупные компании, в основном, задают такие вопросы на этапе phone screen / skype interview, потому что они не могут позволить себе возить к себе в офис всех за свой счет, и им нужно отсеять 90%. Они отсеивают тех ребят, которые умеют быстро за ограниченное время решать сложные логические задачи.
В небольшой компании в таких вопросах смысла нет, гораздо лучше спросить то, с чем необходимо иметь дело в работе (особенности языка, паттерны, boxing / unboxing, итд).
Возможно потому, что знание теории computer science и типов данных (вроде всяких односвязных-двусвязных списков, двоичных деревьев итд) не имеет отношения к прикладному программированию, только если вы не разрабатываете свой ЯП или свою базу данных.
И человек может это знать, только если у него в университете был CS101 (чего в российских реалиях ожидать глупо), либо если он готовился к собеседованиям по книгам.
А вот что такое Boxing/Unboxing при разработке на C# знать надо, но джуниорам не знать это простительно.
Не проходил собеседования в Tesla / Apple, но проходил в других больших компаниях, и советую книжку "Cracking the Coding Interview by Gayle Laakmann McDowell". Автор работала в Google, Microsoft, и Apple, и вопросы в больших компаниях в основном очень похожи.
Один способ — это иметь отдельную БД типа Redis в которой хранить исключительно список отозванных токенов. Таких токенов в реальности будет совсем немного, т.к. после даты истечения токена (максимум минут 10) его можно будет из этой БД удалить, соответственно нагрузка на такую БД будет меньше. Это, конечно, не идеальный вариант, но он гораздо лучше, чем "простая" модель аутентификации.
Система с refresh/access токенами крайне удобна, если ваша архитектура состоит из микро-сервисов.
Например, у вас есть облако тип AWS, которое состоит из микросервисов типа хранилища (S3), сервиса управления серверами, бэкапы, итд.
Вы, конечно, можете сделать все это одним большим монстро-приложением, но рано или поздно вам прийдется делить его на части. И вот тут вариантов у вас будет не много — вам прийдется либо дублировать код с БД и аутентификацией, либо выносить его в отдельный пакет. О безопасности тут уже и говорить нечего — каждый модуль будет требовать доступа к БД с пользовательскими сессиями.
Access/refresh токены элегантно решают эту проблему. У вас есть один сервер аутентификации, который проверяет в БД логин/пароль, и выдает вам какой-нибудь jwt токен с информацией о юзере/правах, подписанный приватным ключем сервера аутентификации. Такой токен нельзя отозвать, но зато у него крайне короткий срок жизни, например 5 или 10 минут. Вместе с ним выдается refresh токен, который используется пользователем для "обновления" access токена через тот же сервер аутентификации.
Собственно, задача решена. Все, что потребуется остальным микросервисам — проверить токен с публичным ключом и убедиться, что юзер имеет доступ к заданному. Никакой работы с БД, никакой интеграции с сервисом аутентификации, единственная зависимость — это библиотека для работы с токенами (JWT).
Вы даже можете использовать разные ЯП/стэки технологий для написания ваших микросервисов (например, сервис чата с техподдержкой вы можете написать хоть на C++, если так уж хочется) — все что нужно это возможность расшифровать токен и проверить его валидность.
С безопасностью тут тоже все впорядке — БД аутентификации находится за семью файерволлами, ни у кого кроме сервера утентификации к ней доступа нет, как и к приватному ключу, которым подписывается токен.
Единственный минус такой системы — это невозможность мгновенно отозвать access токен. Но это как правило и не нужно, т.к. срок жизни такого токена крайне короткий (несколько минут).
С другой стороны, если на перекрестке много автомобилей и плохая видимость, лично я всегда стараюсь слегка сбросить скорость, так как несколько раз вот такие вот «умники» поворачивали налево, не видя меня и не убедившись в безопасности маневра, и приходилось резко долбить по тормозам.
ID (вод. права) нужно показать только один раз при прохождении security. В этот момент человек просто проверяет внешность и сравнивает ваше имя с тем что указано в посадочном.
Если использовать свою карту (со своим дизайном итд), то доказать, что была использована чужая карта и нарушены авторские права очень трудно.
Во времена бумажных карт и путеводителей, американские компании добавляли на свои карты фейковые города и улицы, что бы потом в суде можно было доказать что их информация была скопирована.
Зубрить — не надо. Готовиться к интервью нужно, при чем готовиться должен как работодатель, так и соискатель.
Отвечая на ваш вопрос, "почему результат собеседования зависит от того насколько человек к нему подготовился".
Лучшие интервью, которые у меня были — это были интервью из серии "рассказите о проекте X из вашего резюме, какой стэк технологий применялся, какие были трудности в этом проекте, как вы их решили, что бы вы сделали по другому если бы решали эту задачу сегодня". У меня была пара таких интервью, результатом обоих был job offer. Никто не ставил под сомнение моё умение программировать.
Но тут надо быть реалистом и понимать, что гугл не может себе позволить такие интервью без изначального просева кандидатов. Что бы попасть в гугл, люди могут написать и придумать в резюме что угодно.
В связи с этим их политика заранее предупреждать, какие задачки будут задавать на интервью, по мне звучит наиболее логичным способом. По крайней мере, все кандидаты имеют возможность подготовиться. Это гораздо лучше, чем если бы они задавали случайные задачи, и люди участвовали бы в лотерее "умею ли я решать задачу на эту тему".
Отдельная история начинается тогда, когда веб-студии из 10 человек начинают задачать вопросы по двоичным деревьям, поленившись даже прочитать твое резюме. Есть тут такие компании на Хабре.
Тут надо понимать, о чем конкретно идет речь.
Одно дело, когда спрашивают написать двоичный поиск или инвертировать двоичное дерево (вопрос, на который не смог ответить Макс Хауэлл). Это действительно, элементарная задачка на рекурсию, весь код займет 5-10 строк. И не знать как ее решать действительно странно. Тем более что в гугле предупреждают о том, что там спрашивают такие задачки. Т.е. если человек не смог инвертировать двоичное дерево, это значит что он вообще не готовился к интервью, от слова совсем.
Другой разговор — задачки вроде "напишите балансировку красно-черного дерева на доске". Это ни 2й и не 3й и не 5й курс. Если вы в университете зубрили как балансировать RB-деревья, то у вас был странный университет.
Я уверен, что ни один нормальный человек не сможет сам такие алгоритмы придумать или по памяти это воспроизвести, если он специально для интервью не зубрил это.