Как стать автором
Обновить
0
0

Пользователь

Отправить сообщение

Со мной такое не случалось. Кто-то из бывших американских коллег рассказывал.
К сожалению, знакомые юристы работают в других сферах и ничего не подсказали.
Вот что смог нагуглить.
https://www.nolo.com/legal-encyclopedia/lawsuits-based-the-hiring-process.html

Нет. Обычно это решается на совещании до интервью или рекрутер описывает какую часть знаний надо проверить.
Говорю на собственном опыте и опыте друзей в роли интервьюера. И как соискатель. Даже видна разница и усложнение заданий. У нас если на первых двух онсайт сессиях кандидат плохо показывает себя — да остальных отменят.
Не знаю отменяют ли в Амазоне, но там нарастает сложность. Первое задание будет на простой алгоритм и умение писать код. Потом дизайн на уровне приложения, потом взаимодействие сервисов.
Но есть и исключения. Когда-то в VMware, второй интервьюер задал проблему, а я даже не стёр её с доски

Не хватает варианта виртуальной рабочей машины. Например, Amazon WorkSpaces

Тоже когда пользовался n810.
Но от перехода на 900 остановило отсутствие хорошиего навигационного ПО.

А вы и тут есть :) Приятная внезапность

Насчёт прогноза согласен. Меня тоже точка берет, когда я вижу пустой экран Echo show.
На ум приходит один древний метод — генерить картинки сторонней софтиной и показывать этот альбом.
Но хотелось бы встроенного

Скажу, что я хотел бы возможность более удобного отображения устройств, даже в виде трехмерной модели дома. Но я не уверен, что это надо обычному пользователю. Думаю, что такое больше интересно энтузиастам.
Во-первых, это не очень красиво. Гораздо приятнее показывать гостям красивые фото, чем включен ли свет в туалете. А то супруга скажет, что пойдет искать старый семейный альбом, но все увидят где она была на самом деле так долго.
Плюс добавить такой экран — дополнительные расходы. А если есть в комнате термодатчик и обогреватель — скорее всего выгоднее повесить термостат, который умеет показывать температуру и изменять настройки. Хотя в умном доме ожидается, что температура будет регулироваться сама.
Выключение света гораздо проще повесить на выключатель.
Плюс, сейчас уже у каждого есть в кармане 5" панель, где можно запустить Home и контролировать с дивана, пола, не вставая к столу. А там всё сгруппировано по комнатам. К сожалению, у меня нет отдельного термометра, чтоб проверить показывает ли он температуру. Nest thermostat не делает это на общей панели. По крайней мере на данный момент.
С погодой на улице, видимо, недоработка. Может рассчитывают, что пользователь нажимает при необходимости.
А частые действия можно настроить в рутину и говорить "Hey Google, good morning" и т.д.
Надо будет купить и поиграться с их экраном всё-таки

Отсутствие SSH & API для большей защищённости.
Общая тенденция IOT — уход в облако, а хороших автономных систем как-то не наблюдается.
Может что-то можно найти для хабов наподобие Wink, SmartThings… Но они тоже рассчитаны на облако.
Предложенный вами экран хорош, но помещается там не много. У среднего американца, который готов потратить приличную сумму на автоматизацию, скорее всего будет 3 спальни, кабинет, гостиная-столовая-кухня (большое пространство, разделенное по зонам, но могут быть и отдельные комнаты), гараж, иногда и подвал, 2 ванных, прихожая, веранда.
Обогреватель у него будет один и панель у него будет своя. И скорее всего там будет поддержка постоянной температуры, расписание или умное что-то от Nest thermostat с учётом привычек и температуры за бортом. По сути к нему и подходить не надо будет никогда.
Ламп по разным зонам будет много. У меня счас на кухне 3 выключателя на разные приборы. А в гостиной могут быть и напольные лампы. И у каждой лампы будет выключатель. Ещё можно повесить групповой выключатель на весь этаж, который программно управляет остальными — у меня так сделано и это удобно
Ну и такие панели управления по всему дому не расставишь — проще голосом давать команды.

А ещё внутренние БД нативно поддерживают протобафы и можно спокойно эти данные туда сохранить.
Мне этот подход показался наиболее удобным

У Pivotal свой бизнес и он спланирован.
Разработчики там пишут с учётом интересов компании. Компания решает, что надо поддерживать Kafka — пишут. Надо депрекейтить RestTemplate — будут трогать только для критических уязвимостей.
И сеньор знает, что компания через год выпускает новую библиотеку, и ему надо писать текущий код с оглядкой на будущий релиз.

Как мне кажется, обучение с учителем всё-таки больше подходит для распознования правильно ли посажена картошка. Или оаспознать севок.
Т.е. входные данные — ответ.

Вот в комментах потом было добавлено:
Вы выкопали картошку и складываете её в погребе — каждый сорт отдельно. Если по ошибке ваша картошка попадёт не на ту полку, прибежит ваш дед и начнет вас бить палкой.

Это вот с учителем

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

Да, он отлично подходит для развертывания в k8s.
По идее и к более сложным вещам можно приспособить. Например, проекты генерируют артефакты и отправляют их в репозиторий.
А отдельно есть проект, который вытягивает готовые артефакты и последовательно развёртывает их, проверяя совместимость.
Но не уверен, что это не будет обходным путём в силу ограниченности gitlab

Судя по всему тут разные подходы. С Jenkins сильно глубоко работать не доводилось — довольно простые пайплайны делал.
Для Gitlab, получается, ближе концепция "Fail fast". Что-то не так — человек разбирайся. На Jenkins, похоже, можно ненароком всё переусложнить — скрипт за тебя решит проблему, но правильно ли он её решит? Вдруг это что-то новое, что ненароком уйдёт в прод?
В giltab тоже можно вынести скрипты пайплана в другой репозиторий (я сейчас про платную версию — с бесплатной не работал и не могу полностью ручаться за функционал). И можно использовать якоря для повторяющегося кода и, с недавних пор, наследование.
Ручное подтверждение тоже есть. Джобы могут передавать данные через артифакты и Registry.


Можно прикрутить всякие Helm/jsonnet/… Может он и не предназначен для сложных, ветвистых пайплайнов — я не искал. ИМХО пайплайн должен быть прям и прост: собрать новый код, проверка качества кода, тесты, развертывание на dev environment (если надо), слияние с master, создание контейнера-кандидата-в-релиз, развертывание его, тестирование, развертывание в прод.
Чуть что не так — упасть и требовать новых изменений.

Если я правильно понял проблему — тестовые стэнды можно создавать на основе веток, используя предустановленные переменные окружения gitlab'a.
Т.е. у нас есть 2 кластера: прод и непрод, — и на непрод разворачиваются приложения, имена и метки pod, deployment, service у которых содержит название ветки.
Потом это всё сливается в master, из которого развёртывается стабильная непрод версия, а потом и развертывание в прод.
Чтоб не повторять код и скрипты, можно использовать якоря, а с недавних пор и наследовать "ступени" (хотя последнее мне не сильно пока нравится).
Ещё можно использовать helm or jsonnet для более гибкого развёртывания. Плюс можно импортировать gitlab-ci из внешнего проекта.
Но я не уверен, что это доступно в бесплатной версии — с ней работать не пришлось.

Если вы про тесты которые «выберите правильный вариант из предложенного» — я никогда не предлагал такого делать.

Что значит не тестируют — они решают задачи у доски. Свежие и незнакомые.

Тестирование ПО — это часть разработки, это надо обсуждать на интервью
зачем? целый стартап по нано-юнит-тестированию
В нашей не гигантской компании я проводил по 3 интервью в неделю на протяжении нескольких месяцев.
2 телефонных и 1 онсайт. Это были интервью только в наш отдел. Я не говорю про интервью в гиганты как Амазон, Фейсбук, Гугл.
И из где-то 50 человек мы взяли только 2.
Так что это вполне реальные цифры.
Более того, Амазон устраивает иногда hiring events. Это когда они приезжают в какой-то город или страну и проводят кучу интервью в течении недели. Потом устраивается обсуждение и кандидатов приглашают на работу.

Любые специалисты проходят интервью. По крайней мере до сеньора (по американским меркам). Архитекторов и выше не приходилось интервьюировать.

Если человек не протестировал написаный код — это минус балл
люди пишут юнит тесты
Тесты — это unit tests

Может в РФ стажировка ещё работает, в США нет — я слышал, что только механиков самолётов нанимают с испытательным сроком.
Возможно особенности рынка. Если есть стажировка — хорошо. Но не всем подходит. И при прочих равных кандидат предпочтёт предложение без стажировки.

ну и есть плохие интервьюеры — ничего не поделаешь, надо идти готовым к тому, что начнут спрашивать глупости. Просто потом туда не идти и никому не советовать

Информация

В рейтинге
Не участвует
Откуда
Seattle, Washington, США
Зарегистрирован
Активность