Size: a a a

2020 November 18

s

saksonov 👀 in Scala Jobs
источник

MG

Mikhail Golubtsov in Scala Jobs
Andrey Korzinev
Такой ответ уже лучше чем "зачем вы это спрашиваете". Но можно ещё лучше, конечно 🙂
зачем вы это спрашиваете кстати хороший вопрос (даже если знаешь как ответить), варианты ответов:
1. нужно решить вот такую бизнес-задачу
2. надо отсеять 90% кандидатов по некоторому признаку и мы выбрали вот такой
3. нужно придать ореол элитарности этой позиции
источник

В

Вадим in Scala Jobs
Andrey Korzinev
Ну давай так, если вы воспринимаете volatile как кейворд - то в Scala есть @volatile.

Но вообще это же целая концепция, которая в итоге прорастает в то, как процессор будет обращаться к памяти.
Да не, вопрос был скорее "где ты еще видел volatile с такой же семантикой как в jvm"
источник

AK

Andrey Korzinev in Scala Jobs
Вадим
Да не, вопрос был скорее "где ты еще видел volatile с такой же семантикой как в jvm"
Ну а какая разница если позиция подразумевает разработку под JVM? 🙂
источник

Oℕ

Oleg ℕizhnik in Scala Jobs
saksonov 👀
чому?
Я в этой связи вспоминаю одного из лучших преподов в моей жизни . Звали его Михаил Александрович Колодий.
Он рассказывал, что с практикой письменных экзаменов у него появился скил. Посмотрев на письменный ответ, он точно знал, какие доп вопросы задать человеку, чтобы тот не ответил.
Он долго думал, что делать с таким скилом, потому что если бы он им пользовался, 95% просто бы получали двойки после одного-двух доп вопросов.
Поэтому он сказал, что действует очень формально. Доп. вопросы строго ограничиваются тематикой вопроса. Если собеседуемый может защитить свой ответ без доп. вопросов из пред. тем, ответ засчитывается.

Почему мне кажется формализация таких опросов хорошей идеей?
Потому что некоторое число собеседующих и экзаминаторов проходят этап, когда им чудится, будто они понимают, как человеческий разум работает.
Как шестерёнки крутятся, как решения мутятся.
И они приобрели уже вот тот замечательный скилл "деления человеков на два типа", и могут брать только людей правильного типа.
Часто оказывается, что этот их когнитологический талант - это всего лишь рефлексия. Талантливыми и умными им кажутся люди, которые прошли примерно такой же путь как они, использующие в решении задач примерно те же приёмы, что они.
Людей, которые не знают чего-то, что знают они, но знают и умеют применять что-то совсем другое, они с большой вероятностью отсеют.

Такой собеседователь будет преимущественно брать человеков, похожих на себя. Так в чём же проблема? Ну вот талантливый инженер наберёт примерно таких же талантливых инженеров, только на другой стадии развития.
Но к несчастью, такой подход приведёт к тому, что команда будет довольно однородная, люди будут, вероятнее всего, хорошо справляться с задачами одного типа и плохо с задачами другого.
Когда, кажется, довольно много довольно хороших исследований на тему того, что разнородные, или "сбалансированные" команды эффективнее.
В последнем слайде график, на котором видно, что: "В среднем трудно решаемая задача чаще приводит к не очень качественным решениям, с обоснованностью которых согласятся все "клоны" собеседущего, и эти проблемы будут постепенно копиться, в итоге понижая качество и повышая стоимость владения продуктом"

Т.е. более правильной тактикой я считаю набор строго сформулированных задач, и оценка исключительно измеримых качеств решения.
источник

AK

Andrey Korzinev in Scala Jobs
Mikhail Golubtsov
зачем вы это спрашиваете кстати хороший вопрос (даже если знаешь как ответить), варианты ответов:
1. нужно решить вот такую бизнес-задачу
2. надо отсеять 90% кандидатов по некоторому признаку и мы выбрали вот такой
3. нужно придать ореол элитарности этой позиции
Вот у меня на сервис прилетает 35k RPS. И ВНЕЗАПНО эти знания очень полезны, чтобы он и дальше их нормально тащил 🙂
источник

s

saksonov 👀 in Scala Jobs
Oleg ℕizhnik
Я в этой связи вспоминаю одного из лучших преподов в моей жизни . Звали его Михаил Александрович Колодий.
Он рассказывал, что с практикой письменных экзаменов у него появился скил. Посмотрев на письменный ответ, он точно знал, какие доп вопросы задать человеку, чтобы тот не ответил.
Он долго думал, что делать с таким скилом, потому что если бы он им пользовался, 95% просто бы получали двойки после одного-двух доп вопросов.
Поэтому он сказал, что действует очень формально. Доп. вопросы строго ограничиваются тематикой вопроса. Если собеседуемый может защитить свой ответ без доп. вопросов из пред. тем, ответ засчитывается.

Почему мне кажется формализация таких опросов хорошей идеей?
Потому что некоторое число собеседующих и экзаминаторов проходят этап, когда им чудится, будто они понимают, как человеческий разум работает.
Как шестерёнки крутятся, как решения мутятся.
И они приобрели уже вот тот замечательный скилл "деления человеков на два типа", и могут брать только людей правильного типа.
Часто оказывается, что этот их когнитологический талант - это всего лишь рефлексия. Талантливыми и умными им кажутся люди, которые прошли примерно такой же путь как они, использующие в решении задач примерно те же приёмы, что они.
Людей, которые не знают чего-то, что знают они, но знают и умеют применять что-то совсем другое, они с большой вероятностью отсеют.

Такой собеседователь будет преимущественно брать человеков, похожих на себя. Так в чём же проблема? Ну вот талантливый инженер наберёт примерно таких же талантливых инженеров, только на другой стадии развития.
Но к несчастью, такой подход приведёт к тому, что команда будет довольно однородная, люди будут, вероятнее всего, хорошо справляться с задачами одного типа и плохо с задачами другого.
Когда, кажется, довольно много довольно хороших исследований на тему того, что разнородные, или "сбалансированные" команды эффективнее.
В последнем слайде график, на котором видно, что: "В среднем трудно решаемая задача чаще приводит к не очень качественным решениям, с обоснованностью которых согласятся все "клоны" собеседущего, и эти проблемы будут постепенно копиться, в итоге понижая качество и повышая стоимость владения продуктом"

Т.е. более правильной тактикой я считаю набор строго сформулированных задач, и оценка исключительно измеримых качеств решения.
"качества решения" подвержены ровно той же проблеме
источник

s

saksonov 👀 in Scala Jobs
речи про оценку правильно/неправильно вообще не идет
источник

AK

Andrey Korzinev in Scala Jobs
Oleg ℕizhnik
Я в этой связи вспоминаю одного из лучших преподов в моей жизни . Звали его Михаил Александрович Колодий.
Он рассказывал, что с практикой письменных экзаменов у него появился скил. Посмотрев на письменный ответ, он точно знал, какие доп вопросы задать человеку, чтобы тот не ответил.
Он долго думал, что делать с таким скилом, потому что если бы он им пользовался, 95% просто бы получали двойки после одного-двух доп вопросов.
Поэтому он сказал, что действует очень формально. Доп. вопросы строго ограничиваются тематикой вопроса. Если собеседуемый может защитить свой ответ без доп. вопросов из пред. тем, ответ засчитывается.

Почему мне кажется формализация таких опросов хорошей идеей?
Потому что некоторое число собеседующих и экзаминаторов проходят этап, когда им чудится, будто они понимают, как человеческий разум работает.
Как шестерёнки крутятся, как решения мутятся.
И они приобрели уже вот тот замечательный скилл "деления человеков на два типа", и могут брать только людей правильного типа.
Часто оказывается, что этот их когнитологический талант - это всего лишь рефлексия. Талантливыми и умными им кажутся люди, которые прошли примерно такой же путь как они, использующие в решении задач примерно те же приёмы, что они.
Людей, которые не знают чего-то, что знают они, но знают и умеют применять что-то совсем другое, они с большой вероятностью отсеют.

Такой собеседователь будет преимущественно брать человеков, похожих на себя. Так в чём же проблема? Ну вот талантливый инженер наберёт примерно таких же талантливых инженеров, только на другой стадии развития.
Но к несчастью, такой подход приведёт к тому, что команда будет довольно однородная, люди будут, вероятнее всего, хорошо справляться с задачами одного типа и плохо с задачами другого.
Когда, кажется, довольно много довольно хороших исследований на тему того, что разнородные, или "сбалансированные" команды эффективнее.
В последнем слайде график, на котором видно, что: "В среднем трудно решаемая задача чаще приводит к не очень качественным решениям, с обоснованностью которых согласятся все "клоны" собеседущего, и эти проблемы будут постепенно копиться, в итоге понижая качество и повышая стоимость владения продуктом"

Т.е. более правильной тактикой я считаю набор строго сформулированных задач, и оценка исключительно измеримых качеств решения.
Истина здесь, как всегда - где-то посередине. Одна тактика смещает ответственность на собеседущего, другая - на собеседуемого.
источник

s

saksonov 👀 in Scala Jobs
ну и да, речь ни в коем случае не идет на зацикливании на одной метрике
источник

s

saksonov 👀 in Scala Jobs
знает - хорошо, не знает, но рассуждает - тоже хорошо. вот плохо когда не знает и не рассуждает
источник

s

saksonov 👀 in Scala Jobs
+ консенсус двух разных собеседующих
источник

AK

Andrey Korzinev in Scala Jobs
saksonov 👀
знает - хорошо, не знает, но рассуждает - тоже хорошо. вот плохо когда не знает и не рассуждает
не знает, но рассуждает - как правило даже лучше, потому что даёт больше полезного сигнала
источник

Oℕ

Oleg ℕizhnik in Scala Jobs
Поэтому и суть в том, чтобы дать формальную задачу, пусть Антон Дегузло решит её на СТМ, а алаев решит на волатайлах и синхронизируемых массивах.
Пусть Алаев расскажет про ЖММ, а Дегузло про сепарационку, если решения не уступают друг другу формально - в команду из-за естественного хаоса попадут оба, будут часто сраться поначалу.
Но в итоге будут иметь лучшее покрытие суммарно, чем два Дегузла или два Алаева
источник

В

Вадим in Scala Jobs
Oleg ℕizhnik
Поэтому и суть в том, чтобы дать формальную задачу, пусть Антон Дегузло решит её на СТМ, а алаев решит на волатайлах и синхронизируемых массивах.
Пусть Алаев расскажет про ЖММ, а Дегузло про сепарационку, если решения не уступают друг другу формально - в команду из-за естественного хаоса попадут оба, будут часто сраться поначалу.
Но в итоге будут иметь лучшее покрытие суммарно, чем два Дегузла или два Алаева
подход хороший. Вот только, берут обычно тех, с кем из личных соображений, будет работать "комфортнее"
источник

VM

V. M. in Scala Jobs
нет смысла идти на собес со своими порядками. у компании есть сформированная культура, чем больше и старее компания тем устойчивее культура.
эта культура подразумевает те или иные вопросы на собесе которые один человек/команда/компания считает важными для себя другие считают  ненужной инфой.
более того крупные организации существуют только в формальных, четко прописанных рамках.
сюда кроме стека и кишок можно дописать придирки в стиле "зачем ходить в офис", "зачем одевать костюм" и т.д. их компания их бабки хотят и спрашивают потому что могут.
Более того крупные компании обладают огромным запасом прочности и инженеры которые работают в них в меньшей мере влияют на их устойчивость и результативность. Если говорить аналогиями то на маленькой лодке важен практический скилл матроса т.к. его навык == выживание в океане, а на трансатлантическом лайнере тебя могут просто ебать регламентами полдня и от этого корабль не утонет.
источник

Oℕ

Oleg ℕizhnik in Scala Jobs
Вадим
подход хороший. Вот только, берут обычно тех, с кем из личных соображений, будет работать "комфортнее"
ну это тоже имеет смысл
источник

DS

Danila Shtan in Scala Jobs
Вадим
подход хороший. Вот только, берут обычно тех, с кем из личных соображений, будет работать "комфортнее"
Ну это же не противопоставлено, правда?
источник

DS

Danila Shtan in Scala Jobs
А так - да. Я лично сильно больше на софт- часть человека смотрю и волнуюсь, как он в команду впишется.
источник

AK

Andrey Korzinev in Scala Jobs
Danila Shtan
А так - да. Я лично сильно больше на софт- часть человека смотрю и волнуюсь, как он в команду впишется.
Скалистов очень тяжело искать, правда?
источник