Re[21]: Германия -----> Питер
От: elmal  
Дата: 09.11.09 06:10
Оценка: 9 (3)
Здравствуйте, kosmik, Вы писали:

K>So?

А то, что как-то не вяжется то, что пишут на форумах, и то, что наблюдаю в реальной жизни. Да, на форумах все говорят, что никто не знает что такое виртуальный деструктор, а опыта по 10 лет в С++, что никто не знает что такое дерево, не различает никто связанный список и вектор. Ну не верю! Если профильное образование, и это читали, и сколько нибудь опыта есть — базу знать будут. Да, далеко не все знают, как внутри реализовано виртуальное наследование — в это поверю. Относительно дерева, что не все с ходу напишат балансировку дерева, 3 способа обхода дерева — да, поверю. То, что далеко не все скажут, что будет, если в Java переопределить equals, но не переопределить hashCode (и наоборот), и почему их надо переопределять вместе — в это тоже поверю (под сказать понимаю — с ходу привести пример). Что наизусть правила переопределения хеш кода тоже далеко не все помнят — да, это так. И то, что по памяти не все смогут специально дедлок сделать, поверю. Что не все сходу перечислят все типы полиморфизма в конкретном языке, да, это так. И много чего похожего, в это тоже поверю. Поверю потому, что далеко не все с таким сталкивается в работе, и, как результат, могут забыть.
Это я к тому, что говорите, что все козлы, ничего не знают, приводите примеры детских вопросов, но на деле вопросы были немножко другие наверняка, и ответ, уверен, подразумевался исчерпывающий, с перечислением всех возможных граблей — нет?
Re[23]: Германия -----> Питер
От: Vzhyk  
Дата: 09.11.09 09:55
Оценка:
kosmik пишет:
>
> V>Т.е в одной компании, пусть и медлено, но человек и "классы дизайнил и
> V>исключения понимал", а вот как к вам на собеседование сунулся сразу
> V>перестал.
>
> Связаны эти высказывания довольно хорошо. Если в конторе достаточно
> простые продукты, совсем длинные сроки etc, но на аналогичных позициях
> она может позволить себе иметь менее квалифицированных сотрудников,
> которые и классы дизайнить не умеют и не понимают как исключения
> использовать.
"А у меня длинее" == "в конторе достаточно простые продукты". Думаю, не
имеет смscла обсуждать длину продуктов вашей и виртуальной контор. Ты
придумываешь высказывания некое и начинаешь его приписывать оппоненту. С
таким "в сад".

Ели контора делает продукт, а не пилит государево бабло, то содержать
неквалифицированных сотрудников она не может — от них одни убытки. Т.е.
такой сотрудник или родственник ББ, или будет уволен достаточно быстро
(3-6 месяцев), а если родственник, то он не будет менять теплое место.
Posted via RSDN NNTP Server 2.1 beta
Re[24]: Германия -----> Питер
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 09.11.09 17:45
Оценка:
>> Связаны эти высказывания довольно хорошо. Если в конторе достаточно
>> простые продукты, совсем длинные сроки etc, но на аналогичных позициях
>> она может позволить себе иметь менее квалифицированных сотрудников,
>> которые и классы дизайнить не умеют и не понимают как исключения
>> использовать.
V>"А у меня длинее" == "в конторе достаточно простые продукты". Думаю, не
V>имеет смscла обсуждать длину продуктов вашей и виртуальной контор. Ты
V>придумываешь высказывания некое и начинаешь его приписывать оппоненту. С
V>таким "в сад".

Скажем так, я описал то как я вижу ситуацию. Пока что разные требования к сотрудникам в разных компаниях (и как следствие, их квалификацию в-среднем) я могу объяснить тем что:
a) грубо говоря, то что обычно делает один человек там делают два
b) разная сложность продуктов
c) разная агрессивность в смысле сроков

V>Ели контора делает продукт, а не пилит государево бабло, то содержать

V>неквалифицированных сотрудников она не может — от них одни убытки. Т.е.
V>такой сотрудник или родственник ББ, или будет уволен достаточно быстро
V>(3-6 месяцев), а если родственник, то он не будет менять теплое место.

От неквалицифированных сотрудников никакого _убытка_ обычно нет, есть просто меньший выхлоп.
BTW: пилить бабло можно не только государево, но и частное (некоторое время назад был очень смешной ролик про закрытие Адамант-Мультимедиа).
Re[22]: Германия -----> Питер
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 09.11.09 18:12
Оценка:
E>А то, что как-то не вяжется то, что пишут на форумах, и то, что наблюдаю в реальной жизни. Да, на форумах все говорят, что никто не знает что такое виртуальный деструктор, а опыта по 10 лет в С++, что никто не знает что такое дерево, не различает никто связанный список и вектор. Ну не верю! Если профильное образование, и это читали, и сколько нибудь опыта есть — базу знать будут. Да, далеко не все знают, как внутри реализовано виртуальное наследование — в это поверю. Относительно дерева, что не все с ходу напишат балансировку дерева, 3 способа обхода дерева — да, поверю. То, что далеко не все скажут, что будет, если в Java переопределить equals, но не переопределить hashCode (и наоборот), и почему их надо переопределять вместе — в это тоже поверю (под сказать понимаю — с ходу привести пример). Что наизусть правила переопределения хеш кода тоже далеко не все помнят — да, это так. И то, что по памяти не все смогут специально дедлок сделать, поверю. Что не все сходу перечислят все типы полиморфизма в конкретном языке, да, это так. И много чего похожего, в это тоже поверю. Поверю потому, что далеко не все с таким сталкивается в работе, и, как результат, могут забыть.
E>Это я к тому, что говорите, что все козлы, ничего не знают, приводите примеры детских вопросов, но на деле вопросы были немножко другие наверняка, и ответ, уверен, подразумевался исчерпывающий, с перечислением всех возможных граблей — нет?

Сам я никогда вопросы типа перечислить типа полиморфизма, лично мне по барабану знает это человек теоретически или нет, мне интересно умеет это он использовать или нет. А проверяется это в дизайне классов какой-нибудь простой коллекции: тут же видно понимает ли человек что такое public а что такое private и как это нужно использовать. Не нужно спрашивать что такое инумератор или визитор — нужно посмотреть на то как человек вытащит наружу объекта какой-нибудь простой обход etc. Обход, заодно, и проверит как человек решит в коде простую задачку. Если у человека уже такие вещи вызывают проблемы, то чего ожидать от тех задач, с которыми придется сталкиваться на работе?

На моей памяти был не один случай когда в простейшую структурку тут же клали DbConnection и начинали объяснять каким образом будет устроена соответствующая таблица в базе.
Re[23]: Германия -----> Питер
От: elmal  
Дата: 09.11.09 18:27
Оценка:
Здравствуйте, kosmik, Вы писали:

K>Сам я никогда вопросы типа перечислить типа полиморфизма, лично мне по барабану знает это человек теоретически или нет, мне интересно умеет это он использовать или нет. А проверяется это в дизайне классов какой-нибудь простой коллекции: тут же видно понимает ли человек что такое public а что такое private и как это нужно использовать. Не нужно спрашивать что такое инумератор или визитор — нужно посмотреть на то как человек вытащит наружу объекта какой-нибудь простой обход etc. Обход, заодно, и проверит как человек решит в коде простую задачку. Если у человека уже такие вещи вызывают проблемы, то чего ожидать от тех задач, с которыми придется сталкиваться на работе?

Что могу сказать — очень похвально, побольше бы таких собеседующих.
Re[25]: Германия -----> Питер
От: Vzhyk  
Дата: 10.11.09 09:57
Оценка:
kosmik пишет:
>
> Скажем так, я описал то как я вижу ситуацию. Пока что разные требования
> к сотрудникам в разных компаниях (и как следствие, их квалификацию
> в-среднем) я могу объяснить тем что:
> a) грубо говоря, то что обычно делает один человек там делают два
> b) разная сложность продуктов
> c) разная агрессивность в смысле сроков
Но у кого длинее ты не знаешь, но выше утверждал, что у тебя.

>

> От неквалицифированных сотрудников никакого _убытка_ обычно нет, есть
> просто меньший выхлоп.
Как это? А что они зарплаты не получают? Или деньги у вас из тумбочки
берутся?
Posted via RSDN NNTP Server 2.1 beta
Re[26]: Германия -----> Питер
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 10.11.09 13:34
Оценка:
>> Скажем так, я описал то как я вижу ситуацию. Пока что разные требования
>> к сотрудникам в разных компаниях (и как следствие, их квалификацию
>> в-среднем) я могу объяснить тем что:
>> a) грубо говоря, то что обычно делает один человек там делают два
>> b) разная сложность продуктов
>> c) разная агрессивность в смысле сроков
V>Но у кого длинее ты не знаешь, но выше утверждал, что у тебя.

Одно из объяснений.

>> От неквалицифированных сотрудников никакого _убытка_ обычно нет, есть

>> просто меньший выхлоп.
V>Как это? А что они зарплаты не получают? Или деньги у вас из тумбочки
V>берутся?

А вот так: нетто выхлоп для компании положительный.
Re[27]: Германия -----> Питер
От: Vzhyk  
Дата: 10.11.09 16:50
Оценка:
kosmik пишет:
>
>> > От неквалицифированных сотрудников никакого _убытка_ обычно нет, есть
>> > просто меньший выхлоп.
> V>Как это? А что они зарплаты не получают? Или деньги у вас из тумбочки
> V>берутся?
>
> А вот так: нетто выхлоп для компании положительный.
Можно к вам, я тоже работать не буду, а нетто выхлоп будет положительный.
Posted via RSDN NNTP Server 2.1 beta
Re[28]: Германия -----> Питер
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 10.11.09 17:17
Оценка:
>> А вот так: нетто выхлоп для компании положительный.
V>Можно к вам, я тоже работать не буду, а нетто выхлоп будет положительный.

Нельзя, от неработающего нетто-выхлоп отрицательный.
Re[23]: Германия -----> Питер
От: SkyDance Земля  
Дата: 16.11.09 13:35
Оценка:
K>На моей памяти был не один случай когда в простейшую структурку тут же клали DbConnection и начинали объяснять каким образом будет устроена соответствующая таблица в базе.

Философский вопрос. Это хорошо, или плохо, если с места — в карьер?
Re[24]: Германия -----> Питер
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 16.11.09 13:37
Оценка:
K>>На моей памяти был не один случай когда в простейшую структурку тут же клали DbConnection и начинали объяснять каким образом будет устроена соответствующая таблица в базе.

SD>Философский вопрос. Это хорошо, или плохо, если с места — в карьер?


На мой взгляд — плохо.
Re[25]: Германия -----> Питер
От: SkyDance Земля  
Дата: 16.11.09 14:44
Оценка:
K>На мой взгляд — плохо.

А вот на мой — не все однозначно. Если это sample для KB — может, как раз так оно и нужно, безо всякой шелухи? На собеседовании других вариантов-то и не надо, проверяется-то сферический конь в вакууме. Вот пущай и проверяется.

Зато сразу видно, что человек помнит, как работать с БД. Вот, к примеру, я, позор на мою седую голову, не помню ничего из синтаксиса и прочих классов работы с БД. Хотя вроде бы не так уж и давно пилил JDBC драйвер для нетривиального DB provider'а...
Re[26]: Германия -----> Питер
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 16.11.09 15:08
Оценка:
SD>А вот на мой — не все однозначно. Если это sample для KB — может, как раз так оно и нужно, безо всякой шелухи? На собеседовании других вариантов-то и не надо, проверяется-то сферический конь в вакууме. Вот пущай и проверяется.

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

SD>Зато сразу видно, что человек помнит, как работать с БД. Вот, к примеру, я, позор на мою седую голову, не помню ничего из синтаксиса и прочих классов работы с БД. Хотя вроде бы не так уж и давно пилил JDBC драйвер для нетривиального DB provider'а...


Может быть там где нужна работа с базой это и плюс, однако подход очень странный. Не будешь такому code review постоянный делать, потом обнаружишь что каждая ерунда делается в базе
Re[27]: Германия -----> Питер
От: SkyDance Земля  
Дата: 16.11.09 16:35
Оценка:
K>Лично меня настораживает подход "положу все в базу, потом буду думать что делать" в случае когда задается тривиальный контейнер.

Если вспомнить принципы Agile и постоянный рефакторинг — честно говоря, проблем в таком подходе не вижу. Понадобится — переделаем. Premature optimization is the root of all evils. (С) сами знаете кто.

K>Может быть там где нужна работа с базой это и плюс, однако подход очень странный. Не будешь такому code review постоянный делать, потом обнаружишь что каждая ерунда делается в базе


IMHO (ну, не такое уж и H, скорее IMO), делать code review нужно всегда и всем. Даже гуристым гуру. Причем делать его лучше не шибко продвинутым сотрудникам.
Зачем?
Чтобы они, увидев непонятный или слишком сложный код, задали вопрос "а как это работает".
И гуру переписал бы оный код так, чтобы стало понятно. Или хотя бы расставил комментарии. Схему, на крайняк, нарисовал бы.
Re[28]: Германия -----> Питер
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 16.11.09 17:20
Оценка:
SD>Если вспомнить принципы Agile и постоянный рефакторинг — честно говоря, проблем в таком подходе не вижу. Понадобится — переделаем. Premature optimization is the root of all evils. (С) сами знаете кто.

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

SD>IMHO (ну, не такое уж и H, скорее IMO), делать code review нужно всегда и всем. Даже гуристым гуру. Причем делать его лучше не шибко продвинутым сотрудникам.

SD>Зачем?
SD>Чтобы они, увидев непонятный или слишком сложный код, задали вопрос "а как это работает".
SD>И гуру переписал бы оный код так, чтобы стало понятно. Или хотя бы расставил комментарии. Схему, на крайняк, нарисовал бы.

Может быть это и имеет смысл, хоть я придерживаюсь другого мнения. Фишка в том что когда появляется проблема с коммуникацией (а ситуация когда у человека первая итерация абсолютно неправильна) Вы предлагаете нейтрализовывать ее эффект через code review. На мой взгляд гораздо эффективнее решать саму проблему — если ход мыслей у человека таков что он выбирает плохие решения, не нужно его брать.
Re[29]: Германия -----> Питер
От: SkyDance Земля  
Дата: 17.11.09 06:27
Оценка:
K>Абсолютно лишняя итерация. Эквивалент тому что человек никогда не понимает с первого раза и не спрашивает. Это довольно дорого, особенно в ситуации когда сотрудника не майкроменеджат.

Лишняя? А если этот код вообще потребуется выкинуть? Например, он был временным, для обхода какого-нибудь бага в тестовом фреймворке, или, что проще, чисто для демонстрации чего-либо на коротком собеседовании. В общем, если только вам не удастася доказать, что код потенциально опасен (к примеру, если это С++ и структура не noncopyable, а dbconnection при deep copy имеет проблемы — как, #$%^&, имеет проблемы любой вызов Carbon'а после fork() процесса без exec() в MacOS). И то, если заранее известно, как, где и зачем код будет применяться, — комментаний полечит проблему.

K>Может быть это и имеет смысл, хоть я придерживаюсь другого мнения. Фишка в том что когда появляется проблема с коммуникацией (а ситуация когда у человека первая итерация абсолютно неправильна) Вы предлагаете нейтрализовывать ее эффект через code review. На мой взгляд гораздо эффективнее решать саму проблему — если ход мыслей у человека таков что он выбирает плохие решения, не нужно его брать.


Видите ли, вы (может, подсознательно) приняли его решение как "плохое". Причем, я так понимаю, с этим бессмысленно спорить, т.к. ваше решение уже для вас аксиоматично. Соответственно, вы ищете не людей с хорошими решениями, а людей с _вашими_ решениями.

Скажу честно — это _очень правильный подход_ !!! Он позволяет создавать слаженные коллективы. Которые, возможно, делают и не самый гениальный софт. Но уж точно делают его последовательно, и, что еще важнее, предсказуемо.

Так что —
Re[30]: Германия -----> Питер
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 18.11.09 10:51
Оценка:
SD>Лишняя? А если этот код вообще потребуется выкинуть? Например, он был временным, для обхода какого-нибудь бага в тестовом фреймворке, или, что проще, чисто для демонстрации чего-либо на коротком собеседовании. В общем, если только вам не удастася доказать, что код потенциально опасен (к примеру, если это С++ и структура не noncopyable, а dbconnection при deep copy имеет проблемы — как, #$%^&, имеет проблемы любой вызов Carbon'а после fork() процесса без exec() в MacOS). И то, если заранее известно, как, где и зачем код будет применяться, — комментаний полечит проблему.

Лишняя итерация — та, выхлоп которой в районе нуля. Даже если код выбрасывается целиком есть два случая:
a) мы поняли что какой-то способ, который считали хорошим на самом деле плох
b) мы изначально написали очевидный бред

А комментарии человек сам должен вытрясать. Или спрашиваешь или будь добр угадывать

Вариант (b) опасен. Это все равно что нанимать в дикторы заику, а в журналисты — человека, не владеющего письменной речью. Может быть с 10 попытки они что-то и родят, но смысл в такой потере времени?

SD>Видите ли, вы (может, подсознательно) приняли его решение как "плохое". Причем, я так понимаю, с этим бессмысленно спорить, т.к. ваше решение уже для вас аксиоматично. Соответственно, вы ищете не людей с хорошими решениями, а людей с _вашими_ решениями.

SD>Скажу честно — это _очень правильный подход_ !!! Он позволяет создавать слаженные коллективы. Которые, возможно, делают и не самый гениальный софт. Но уж точно делают его последовательно, и, что еще важнее, предсказуемо.

SD>Так что —


Да нет, человек может объяснить почему его решение имеет право на жизнь. Только если объяснение состоит в том "я так привык думать" — в сад.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.