Да нет, конечно. Тестирует нагрузку сам кандидат, а я смотрю — как. Из вот из того, как тестирует, в совокупности с тем, что написано в коде — делаю вывод про уровень квалификации.
Да нет, конечно. Тестирует нагрузку сам кандидат, а я смотрю — как. Из вот из того, как тестирует, в совокупности с тем, что написано в коде — делаю вывод про уровень квалификации.
Я так понял, что обидел Дмитрия своим коротким ответом. Мне жаль, что обидел, обижать не хотел совсем. Мне стоило более подробно поговорить с Дмитрием, прежде, чем принимать решение.
Из комментариев Дмитрия выше мне видно, что мы с ним не сработались бы, а это очень важный фактор при найме, тем более в стартап. Увидев, как Дмитрий сформулировал свой отказ делать тестовое задание (он его запостил выше), я решил именно, что мы не сработаемся. Оказывается, я не ошибся, но это все-таки случайность, надо такие вещи перепроверять, разговаривая более подробно.
Если бы мне казалось, что нет, я бы не давал задание :) Мне кажется, что есть. И по факту отказались делать задание пара человек. Возможно, они, конечно, и были самыми подходящими, но по форме отказов я предполагаю, что мы бы с ними не сработались в любом случае :)
Там такие условия: дано описание примитивного REST API на три эндпоинта, его надо реализовать и развернуть где угодно, чтобы было доступно из интернета и держало 100 RPS, протестировать нагрузку и корректность. Технологии можно использовать любые, какие бы стали использовать в продакшене.
Я такие скрипты не проверяю, просто запускаю нагрузочный тест.
Там такие условия: дано описание примитивного REST API на три эндпоинта, его надо реализовать и развернуть где угодно, чтобы было доступно из интернета и держало 100 RPS, протестировать нагрузку и корректность. Технологии можно использовать любые, какие бы стали использовать в продакшене.
Это было техническое интервью. Позиция, на которую я тебя собеседовал, предполагает сильные технические навыки. Тимлидское собеседование я провожу только с теми, кто прошёл технические этапы. Ты отказался их проходить, на чем все и закончилось.
Там написано, что я делаю: высказываю своё мнение после остальных, долго-долго задавать вопросы, чтобы все подумали — это педагогика, имеет право на существование, но довольно редко.
Если нельзя объяснить, почему одно лучше другого, бывает по-разному. Есть ситуации, когда делаем, как хотят остальные, есть ситуации, когда я скажу: одно решение не лучше другого, но я чую неладное, поэтому принимаю решение делать вот так. Важно это явно проговорить, мне кажется, и это довольно сложно не забыть сделать
Планируется ли закладывать мультиплатформенность в плагины для компилятора, чтобы плагином можно было генерировать/изменять именно котлин код и не привязываться к конкретной платформе в виде JVM, Native, JS и наоборот, чтобы можно было влиять на компиляцию для конкретной платформы если потребуется?
Скорее да, чем нет, но пока это довольно расплывчатые планы.
Я понимаю, что сейчас это больше теоретический разговор, но хотелось бы, чтобы комьюнити могло повлиять на дизайн решения до того, как вы потратите кучу ресурсов на первую реализацию и будет сложно что-то менять :(
Мы как всегда обязательно всем все расскажем перед тем как непоправимо облажаться :)
Кстати, kotlin-reflect можно попробовать аккуратно пошринкать через ProGuard
Самый-самый толстый protobuf-java весит немного больше 500К, так что я сомневаюсь, что дело в нем :) Наш рефлекшен требует на рантайме большой кусок компилятора, который умеет работать с типовой информацией, вот он и весит так много. Мы будем работать над его уменьшением, конечно, но это потребует какого-то времени.
Все вопросы снимаются, портируемость компайлтайм инспекции кода и кодогенерации на JS и Kotlin Native платформы, имхо, важная часть языка, осталось понять насколько это в планах команды Kotlin, особенно с учетом того, что разработчики на native платформах любят макросы cc abreslav?
Макросов как таковых мы делать не хотим. Нормальный тулинг для статически типизированного языка с макросами написать крайне сложно (какие-то более-менее успешные примеры есть, но их мало, и они весьма непросты по реализации). Наш Scala-плагин к IDEA, например, использует черта в ступе и черную магию для этих целей, причем получает не 100% результат, насколько мне известно. Мы так не хотим :)
Однако это не значит, что у нас не будет никакого метапрограммирования. Во-первых, мы рассматриваем возможность поддержать что-то вроде expression trees, как в C#, но это все-таки рантаймовый механизм. Во-вторых, для compile time мы постепенно будем развивать инфрастурктуру плагинов к компилятору. То есть можно будет написать свой наикрутейший фреймворк, который порождает наихитрейший код во время копиляции, но не на макросах, а в виде compiler plugin. Чем это лучше макросов? Тем, что код, выполняемый в процессе компиляции, не является частью самого компилируемого проекта, поэтому тулинг не должен сойти с ума, чтобы его понять. Плюс, API таких плагинов можно сделать таким, чтобы они одновременно работали и в компиляторе, и в IDE, что, опять же, гарантирует качественную инструментальную поддержку.
Пользуясь случаем хотелось бы обратить внимание на такие возможности:
Вводить такие ключи и прагмы — это крайняя мера, мы пока попробуем без них. (Аннотации на файл в Котлине есть, но их для таких целей мы использовать пока не хотим.)
В данном случае, как в аббревиатуре RTFM, ругательная часть просто является обозначением, а не моим отношением :)
Неприятнее всего было, конечно, не название, а то отношение к нам, которое выражено в тексте.
Слово internal означает "доступно внутри модуля". Ваш main в том же модуле.
Мы не разрешаем ссылки и inline функций на приватные декларации, потому что это нарушает главный принцип работы с ними: изменения приватных деклараций не должно ломать клиентский бинарный код. Там выше подробно объяснили, почему код сломается, если разрешить ссылку на private.
Мы разрешаем ссылки на internal-декларации со специальной аннотацией, чтобы была возможность что-то не показывать клиентам из другого модуля. Лучше сделать не можем, к сожалению.
Я понимаю, что писать возмущенные тексты приятно :) Не могу сказать того же о чтении таких текстов. Постараюсь по существу ответить на ту часть, которая не покрывается документацией.
Про тернарный оператор (?:): многим не нравится, мы посмотрим, что можно сделать.
Про литералы для коллекций: тоже сделаем.
Объявления новых типов, а не алиасов тоже сделаем.
Неявные преобразований числовых типов у нас действительно нет. Есть перегрузки для арифметических операций. Мы думаем над тем, как сделать поменьше явных приведений типов, но с этим пока есть некоторые сложности.
Done: https://bit.ly/abreslav-keep-quiet
Done: https://bit.ly/abreslav-keep-quiet
Повторю свой комментарий выше:
Да нет, конечно. Тестирует нагрузку сам кандидат, а я смотрю — как. Из вот из того, как тестирует, в совокупности с тем, что написано в коде — делаю вывод про уровень квалификации.
Я так понял, что обидел Дмитрия своим коротким ответом. Мне жаль, что обидел, обижать не хотел совсем. Мне стоило более подробно поговорить с Дмитрием, прежде, чем принимать решение.
Из комментариев Дмитрия выше мне видно, что мы с ним не сработались бы, а это очень важный фактор при найме, тем более в стартап. Увидев, как Дмитрий сформулировал свой отказ делать тестовое задание (он его запостил выше), я решил именно, что мы не сработаемся. Оказывается, я не ошибся, но это все-таки случайность, надо такие вещи перепроверять, разговаривая более подробно.
Если бы мне казалось, что нет, я бы не давал задание :) Мне кажется, что есть. И по факту отказались делать задание пара человек. Возможно, они, конечно, и были самыми подходящими, но по форме отказов я предполагаю, что мы бы с ними не сработались в любом случае :)
Дублирую комментарий выше:
Я такие скрипты не проверяю, просто запускаю нагрузочный тест.
Там такие условия: дано описание примитивного REST API на три эндпоинта, его надо реализовать и развернуть где угодно, чтобы было доступно из интернета и держало 100 RPS, протестировать нагрузку и корректность. Технологии можно использовать любые, какие бы стали использовать в продакшене.
Если есть время, согласился бы. Если времени нет, отказался бы без обид.
Это было техническое интервью. Позиция, на которую я тебя собеседовал, предполагает сильные технические навыки. Тимлидское собеседование я провожу только с теми, кто прошёл технические этапы. Ты отказался их проходить, на чем все и закончилось.
Прямо "что бы ты спросил_а на моем месте?" не пробовал, но собираюсь. Пока спрашивал: "что еще стоило бы у тебя спросить?"
Там написано, что я делаю: высказываю своё мнение после остальных, долго-долго задавать вопросы, чтобы все подумали — это педагогика, имеет право на существование, но довольно редко.
Если нельзя объяснить, почему одно лучше другого, бывает по-разному. Есть ситуации, когда делаем, как хотят остальные, есть ситуации, когда я скажу: одно решение не лучше другого, но я чую неладное, поэтому принимаю решение делать вот так. Важно это явно проговорить, мне кажется, и это довольно сложно не забыть сделать
Пока не планировал, но идея интересная :)
Он до этого был инженером, потом побыл у нас Product Marketing Manager, теперь снова хочет побыть инженером
Скорее да, чем нет, но пока это довольно расплывчатые планы.
Мы как всегда обязательно всем все расскажем перед тем как непоправимо облажаться :)
Уже :)
Самый-самый толстый protobuf-java весит немного больше 500К, так что я сомневаюсь, что дело в нем :) Наш рефлекшен требует на рантайме большой кусок компилятора, который умеет работать с типовой информацией, вот он и весит так много. Мы будем работать над его уменьшением, конечно, но это потребует какого-то времени.
Макросов как таковых мы делать не хотим. Нормальный тулинг для статически типизированного языка с макросами написать крайне сложно (какие-то более-менее успешные примеры есть, но их мало, и они весьма непросты по реализации). Наш Scala-плагин к IDEA, например, использует черта в ступе и черную магию для этих целей, причем получает не 100% результат, насколько мне известно. Мы так не хотим :)
Однако это не значит, что у нас не будет никакого метапрограммирования. Во-первых, мы рассматриваем возможность поддержать что-то вроде expression trees, как в C#, но это все-таки рантаймовый механизм. Во-вторых, для compile time мы постепенно будем развивать инфрастурктуру плагинов к компилятору. То есть можно будет написать свой наикрутейший фреймворк, который порождает наихитрейший код во время копиляции, но не на макросах, а в виде compiler plugin. Чем это лучше макросов? Тем, что код, выполняемый в процессе компиляции, не является частью самого компилируемого проекта, поэтому тулинг не должен сойти с ума, чтобы его понять. Плюс, API таких плагинов можно сделать таким, чтобы они одновременно работали и в компиляторе, и в IDE, что, опять же, гарантирует качественную инструментальную поддержку.
Вводить такие ключи и прагмы — это крайняя мера, мы пока попробуем без них. (Аннотации на файл в Котлине есть, но их для таких целей мы использовать пока не хотим.)
Неприятнее всего было, конечно, не название, а то отношение к нам, которое выражено в тексте.
Слово internal означает "доступно внутри модуля". Ваш main в том же модуле.
Мы не разрешаем ссылки и inline функций на приватные декларации, потому что это нарушает главный принцип работы с ними: изменения приватных деклараций не должно ломать клиентский бинарный код. Там выше подробно объяснили, почему код сломается, если разрешить ссылку на private.
Мы разрешаем ссылки на internal-декларации со специальной аннотацией, чтобы была возможность что-то не показывать клиентам из другого модуля. Лучше сделать не можем, к сожалению.
Не вижу там ссылки на реквест в трекере
Я понимаю, что писать возмущенные тексты приятно :) Не могу сказать того же о чтении таких текстов. Постараюсь по существу ответить на ту часть, которая не покрывается документацией.
Про тернарный оператор (?:): многим не нравится, мы посмотрим, что можно сделать.
Про литералы для коллекций: тоже сделаем.
Объявления новых типов, а не алиасов тоже сделаем.
Неявные преобразований числовых типов у нас действительно нет. Есть перегрузки для арифметических операций. Мы думаем над тем, как сделать поменьше явных приведений типов, но с этим пока есть некоторые сложности.
C++ для JVM не сделаем. У нас другие задачи :)