Go - язык придуманный чтобы люди перестали заваливать друг друга на собеседованиях вопросами типа Какой порядок инициализации статических блоков, если в классе есть статик-блок, статические поля и статические методы с сайд-эффектами?
или
Что будет, если создать циклическую ссылку в del в Python и забыть про неё?
Чтобы перестали писать в продакшен коде остроумные однострочники типа [(lambda f: f(f))(lambda f: (lambda x: 1 if x == 0 else x * f(f)(x - 1)))(n) for n in range(5)]
Собеседовался во многие перечисленные тут компании на тимлидские позиции, в некоторые и не один раз. В частности в Магнит (оффер), в Озон (оффер), в Т-Банк (оффер), в 2ГИС (отказ), в МТС (отказ), в Яндекс (много-много раз, были и офферы и отказы), в Mindbox (отказ).
Хочется сказать что в комментариях и в статье есть одна когнитивная ошибка - обобщение, представление компании в виде некоего монолитного супер-разума. Что опыт одного трека собеседований можно переложить и экстраполировать. Это безусловно так, но лишь отчасти. Можно примерно понять как принято собеседовать, но это лишь поможет не совершать очевидных ошибок. Но не защитит больше ни от чего. Ни от произвола интервьюера, ни от перекосов.
А перекосы эти идут из самой природы корпоративных практик. Довольно часто в компаниях приняты некие "практики". Но они приняты наверху "кем-то", и "навязаны" вниз. Они могут быть составлены "умными" людьми, по их собственным субъективным мнениям о том или ином грейде, или роли, которые могут не совпадать ни с вашим мнением, ни даже с мнением того кто хотел бы взять вас в команду.
Например встречается практика нескольких интервью когда по технике собеседуют одни, по систем дизайну другие, потом идет фит с командой. На этом фите команда (ее тимлид на самом деле) прочитав неопределенного качества отзывы о предыдущих собеседованиях, и поговорив с вами полчаса (и полчаса рассказывая о себе) должны понять подходите вы им или нет. Это защищает компанию глобально от того что тимлид будет нанимать за красивые глаза, но в то же время подставляет тимлида под то что нанимать людей по очень очень короткому впечатлению. И тут люди ведут себя по разному. Кто-то предпочитает не рисковать и брать только при 120% уверенности (глаза красивые и голос бархатистый, и погода в этот день хорошая).
И что самое печальное - в результате таких практик в процессе интервью участвуют много людей которые не заинтересованы в найме (точнее он им безразличен). Им ничего не стоит поставить отказ или грейд ниже за мелкий недочет, просто из чувства душевного снобизма, и потому что не им потом с этим человеком работать. Они как бы "охраняют" компанию от плохих кандидатов, и в этом видят свою миссию.
К этому добавляется еще один слой сложности. Довольно часто внутри компании формируется какая-то подсознательная субкультура, которая может быть не выражена в каких-то формальных стандартах или регламентах. Какие-то мемы, предпочтения (как например отказ от ОРМ в Озон, который я люто поддерживаю и продвигал пока там работал). Такие факторы часто работают как система свой-чужой, и значат иногда больше чем формальные ответы на формальные вопросы из методички. Сразу видно кто "наш" а кто "какой-то не такой". А оправдание этому решению можно подогнать постфактум.
Получал отказ например потому что осторожно говорил что "мне лично Канбан нравится больше чем Скрам, хотя безусловно у того и другого есть плюсы и минусы, просто это мой личный опыт". Отказ был разумеется объяснен тем что ребята работают по Скраму. Хотя казалось бы - при чем тут это? Тимлид должен уметь работать с разными методологиями, адаптироваться к контексту команды и проекта. Но нет - не подошел по "культуре".
Ну и наконец, человеческий фактор никто не отменял. Бывает что те кто собеседует (этот конкретный индивид) совсем не хотят этим заниматься в данный момент, делают это не из любви к собеседованиям, и это отрывает их от важных задач. Но надо. Тут вступают в игру всякие когнитивные искажения когда задача повторенная миллион раз кажется очевидной даже самому тупому дебилу. А если именно вам она не встречалась, то значит вы сами знаете кто вы. А другой интервьюер будучи в ресурсе сделал бы всё по другому.
В итоге получается что любое собеседование - это лотерея. Слишком много переменных, слишком много субъективных факторов, слишком много людей которым до вас нет дела но которые могут поставить крест на вашем найме. Можно готовиться, можно изучать практики компании, но в конечном счете многое зависит от того на кого вы попадете, в каком они настроении, и насколько вы случайно попадете в их картину мира о том каким должен быть хороший кандидат. Не стоит воспринимать отказы как приговор своим навыкам - возможно просто не сложилось.
Я конечно так и сделал, просто не написал об этом длинный комментарий. =) Термукс конечно тоже тот еще молодец, и чтобы заставить его работать надежно, а не в режиме (ой я из памяти выгрузился потому что иди нафиг), надо проделать много итераций тестирования.
Я себе купил девайс с этой штукой и сильно разочаровался. Если вам нужен телефон на линуксе, то это не он. Это по сути не линукс, это что-то вроде супер-продвинутого лаунчера. Он работает поверх андроида, используя его для связи с устройством. В нём не работает apt get (!!!), нет возможности работать с железом из командной строки. Я вот хотел делать фотографии по крону. Я не нашел ни одного гиковского сценария использования, который бы на нем работал. Приложений на нем кот наплакал, тоесть как смартфон его тоже нельзя использовать. Разве что как звонилка с камерой и браузером.
Затем что по CQRS (и любой другой фигне) пишут книги, статьи и комментарии. В которых скорее всего описаны подходы и решены проблемы, которые в вашей домашней реализации не предусмотрены. Это как "Я уже 10 лет пишу button1.onclick, и оказывается использую ООП. Ну и дебильное название". ООП гораздо шире чем вызов метода у объекта.
Поздравляю с выходом в большой мир! Отлично понимаю твои переживания — сам проходил через это лет 10 назад, но тогда всё было совсем иначе.
Просто поясню: компания VK ≠ социальная сеть VK и уж точно не то, что про неё писали на Хабре десять лет назад. По сути, VK — это mail.ru, а внутри него миллион команд, многие из которых вообще не связаны с оригинальным VK.
Что касается KPHP — учить его не было необходимости. Внутренние языки компаний редко спрашивают на собеседованиях, потому что внешние кандидаты априори их не знают и не обязаны знать.
А вопросы про DNS и O-нотацию — это классика собеседований в крупные (и уже не только крупные) компании. В этот же список входят вопросы про массивы, хеш-мапы, указатели, сборщик мусора и всякие тонкости языка программирования, с которым ты работаешь. Это просто стандартный фильтр на входе.
То, что ты успешно решаешь бизнес-задачи в своей компании — без сомнений. Но если есть планы попасть в бигтех, стоит уделить больше времени подготовке к собеседованиям и лучше разобраться в том, как устроен рынок труда.
Очень интересно, но в голову вообще не приходит, для чего это можно применить. Разве что какое-то приложение похожее на торрент. У вас нет каких-то более пракических, менее выдуманных юзкейсов?
Очень интересное начинание, но статья совсем недописанная. Я знаю что такое AndroidAPS и XDRip, но не понял что конкретно вы сделали. Что у вас за сенсор? Я пользуюсь Freestyle Libre 2, через Patched LibreLink. Кажется такой набор по вашей схеме не заработает. Или есть такая вероятность?
Никто видимо, включая автора, не пробовал запускать скрипт. Скачивается один и тот-же трек, не имеющий никакого отношения к тому, что у меня в плейлисте. Пришлось покопаться в коде, и даже удалось найти ошибку.
Вместо
r = requests.get(audio["url"])
должно быть
r = requests.get(i["url"])
Автор молодец, спасибо ему, но надо бы тестировать прежде чем выкладывать =)
Добро пожаловать в 2007 год и web apps для iPhone OS 1.0.
Тогда тоже были всякие JS-API для интеграции с осью, хотя конечно не такой богатый функционал.
Простите, а почему бы не сделать один бинарник на Golang, и вызывать нужную вам функцию через параметр?
Например:
<binary-name> config args.json res.json
Тогда как минимум вам не нужно будет дублировать весь рантайм и библиотеки в каждом бинарнике.
Go - язык придуманный чтобы люди перестали заваливать друг друга на собеседованиях вопросами типа
Какой порядок инициализации статических блоков, если в классе есть статик-блок, статические поля и статические методы с сайд-эффектами?или
Что будет, если создать циклическую ссылку вdelв Python и забыть про неё?Чтобы перестали писать в продакшен коде остроумные однострочники типа
[(lambda f: f(f))(lambda f: (lambda x: 1 if x == 0 else x * f(f)(x - 1)))(n) for n in range(5)]а занялись делом.
Перекладывали JSON в SQL и обратноСобеседовался во многие перечисленные тут компании на тимлидские позиции, в некоторые и не один раз. В частности в Магнит (оффер), в Озон (оффер), в Т-Банк (оффер), в 2ГИС (отказ), в МТС (отказ), в Яндекс (много-много раз, были и офферы и отказы), в Mindbox (отказ).
Хочется сказать что в комментариях и в статье есть одна когнитивная ошибка - обобщение, представление компании в виде некоего монолитного супер-разума. Что опыт одного трека собеседований можно переложить и экстраполировать. Это безусловно так, но лишь отчасти. Можно примерно понять как принято собеседовать, но это лишь поможет не совершать очевидных ошибок. Но не защитит больше ни от чего. Ни от произвола интервьюера, ни от перекосов.
А перекосы эти идут из самой природы корпоративных практик. Довольно часто в компаниях приняты некие "практики". Но они приняты наверху "кем-то", и "навязаны" вниз. Они могут быть составлены "умными" людьми, по их собственным субъективным мнениям о том или ином грейде, или роли, которые могут не совпадать ни с вашим мнением, ни даже с мнением того кто хотел бы взять вас в команду.
Например встречается практика нескольких интервью когда по технике собеседуют одни, по систем дизайну другие, потом идет фит с командой. На этом фите команда (ее тимлид на самом деле) прочитав неопределенного качества отзывы о предыдущих собеседованиях, и поговорив с вами полчаса (и полчаса рассказывая о себе) должны понять подходите вы им или нет. Это защищает компанию глобально от того что тимлид будет нанимать за красивые глаза, но в то же время подставляет тимлида под то что нанимать людей по очень очень короткому впечатлению. И тут люди ведут себя по разному. Кто-то предпочитает не рисковать и брать только при 120% уверенности (глаза красивые и голос бархатистый, и погода в этот день хорошая).
И что самое печальное - в результате таких практик в процессе интервью участвуют много людей которые не заинтересованы в найме (точнее он им безразличен). Им ничего не стоит поставить отказ или грейд ниже за мелкий недочет, просто из чувства душевного снобизма, и потому что не им потом с этим человеком работать. Они как бы "охраняют" компанию от плохих кандидатов, и в этом видят свою миссию.
К этому добавляется еще один слой сложности. Довольно часто внутри компании формируется какая-то подсознательная субкультура, которая может быть не выражена в каких-то формальных стандартах или регламентах. Какие-то мемы, предпочтения (как например отказ от ОРМ в Озон, который я люто поддерживаю и продвигал пока там работал). Такие факторы часто работают как система свой-чужой, и значат иногда больше чем формальные ответы на формальные вопросы из методички. Сразу видно кто "наш" а кто "какой-то не такой". А оправдание этому решению можно подогнать постфактум.
Получал отказ например потому что осторожно говорил что "мне лично Канбан нравится больше чем Скрам, хотя безусловно у того и другого есть плюсы и минусы, просто это мой личный опыт". Отказ был разумеется объяснен тем что ребята работают по Скраму. Хотя казалось бы - при чем тут это? Тимлид должен уметь работать с разными методологиями, адаптироваться к контексту команды и проекта. Но нет - не подошел по "культуре".
Ну и наконец, человеческий фактор никто не отменял. Бывает что те кто собеседует (этот конкретный индивид) совсем не хотят этим заниматься в данный момент, делают это не из любви к собеседованиям, и это отрывает их от важных задач. Но надо. Тут вступают в игру всякие когнитивные искажения когда задача повторенная миллион раз кажется очевидной даже самому тупому дебилу. А если именно вам она не встречалась, то значит вы сами знаете кто вы. А другой интервьюер будучи в ресурсе сделал бы всё по другому.
В итоге получается что любое собеседование - это лотерея. Слишком много переменных, слишком много субъективных факторов, слишком много людей которым до вас нет дела но которые могут поставить крест на вашем найме. Можно готовиться, можно изучать практики компании, но в конечном счете многое зависит от того на кого вы попадете, в каком они настроении, и насколько вы случайно попадете в их картину мира о том каким должен быть хороший кандидат. Не стоит воспринимать отказы как приговор своим навыкам - возможно просто не сложилось.
По моему опыту все сервера на которых я запускал socks5 прокси были забанены по айпи в течении месяца. Даже ssh работать переставал.
Я конечно так и сделал, просто не написал об этом длинный комментарий. =) Термукс конечно тоже тот еще молодец, и чтобы заставить его работать надежно, а не в режиме (ой я из памяти выгрузился потому что иди нафиг), надо проделать много итераций тестирования.
Статью стоило написать только из-за упоминания TRMNL. Фантастическая на вид штука, обязательно закажу
Я себе купил девайс с этой штукой и сильно разочаровался. Если вам нужен телефон на линуксе, то это не он. Это по сути не линукс, это что-то вроде супер-продвинутого лаунчера. Он работает поверх андроида, используя его для связи с устройством. В нём не работает apt get (!!!), нет возможности работать с железом из командной строки. Я вот хотел делать фотографии по крону. Я не нашел ни одного гиковского сценария использования, который бы на нем работал. Приложений на нем кот наплакал, тоесть как смартфон его тоже нельзя использовать. Разве что как звонилка с камерой и браузером.
Затем что по CQRS (и любой другой фигне) пишут книги, статьи и комментарии. В которых скорее всего описаны подходы и решены проблемы, которые в вашей домашней реализации не предусмотрены. Это как "Я уже 10 лет пишу button1.onclick, и оказывается использую ООП. Ну и дебильное название". ООП гораздо шире чем вызов метода у объекта.
Поздравляю с выходом в большой мир! Отлично понимаю твои переживания — сам проходил через это лет 10 назад, но тогда всё было совсем иначе.
Просто поясню: компания VK ≠ социальная сеть VK и уж точно не то, что про неё писали на Хабре десять лет назад. По сути, VK — это mail.ru, а внутри него миллион команд, многие из которых вообще не связаны с оригинальным VK.
Что касается KPHP — учить его не было необходимости. Внутренние языки компаний редко спрашивают на собеседованиях, потому что внешние кандидаты априори их не знают и не обязаны знать.
А вопросы про DNS и O-нотацию — это классика собеседований в крупные (и уже не только крупные) компании. В этот же список входят вопросы про массивы, хеш-мапы, указатели, сборщик мусора и всякие тонкости языка программирования, с которым ты работаешь. Это просто стандартный фильтр на входе.
То, что ты успешно решаешь бизнес-задачи в своей компании — без сомнений. Но если есть планы попасть в бигтех, стоит уделить больше времени подготовке к собеседованиям и лучше разобраться в том, как устроен рынок труда.
Очень интересно, но в голову вообще не приходит, для чего это можно применить. Разве что какое-то приложение похожее на торрент. У вас нет каких-то более пракических, менее выдуманных юзкейсов?
Вот тут ссылка на оргинальные релиз-ноты. Много интересного написано, что не упомянуто в статье. Например weak-поинтеры, synctest модуль
https://tip.golang.org/doc/go1.24
Очень интересное начинание, но статья совсем недописанная. Я знаю что такое AndroidAPS и XDRip, но не понял что конкретно вы сделали. Что у вас за сенсор? Я пользуюсь Freestyle Libre 2, через Patched LibreLink. Кажется такой набор по вашей схеме не заработает. Или есть такая вероятность?
Вместо должно быть
Автор молодец, спасибо ему, но надо бы тестировать прежде чем выкладывать =)
Тогда тоже были всякие JS-API для интеграции с осью, хотя конечно не такой богатый функционал.
Например:
<binary-name> config args.json res.json
Тогда как минимум вам не нужно будет дублировать весь рантайм и библиотеки в каждом бинарнике.