Здравствуйте, __kot2, Вы писали:

__>да потому что программист не смог в уме оценить время выполнения этой операции.
Отвалилось совсем не по этому, а по тому, что экономили на тестировании. Не прогоняли тесты на реальных данных и под нормальной нагрузкой.
Уж крайний точно не разработчик. Выпуск в продакшен непроверенной версии это всегда риск. И надеяться на то, что разработчики гарантированно не налажают — глупо, независимо от их квалификации. Они могут не налажать 100 раз, на в 101 кто нибудь на секунду потеряет концентрацию и допустит подобную ошибку. Если ошибка реально критична — то виноват менеджер. Если не критична, и быстро поправили и откатили — то ничего страшного и не произошло.

Здравствуйте, Denis, Вы писали:

D>1) есть прописные истины собеседования: сортировки, бинарный поиск. если их знал — то поднять их стоит минут 10-15 перед собеседованием. все-таки обычно ожидается некоторая подготовка перед собеседованием, это ж тот же экзамен.
Собеседование — это не экзамен. Так могут думать только недавние студенты. Для которых программирование сводится к знанию конструкций языка, а также того, что они еще по молодости не забыли из институтской программы.
Открою секрет. Адекватное собеседование — это разговор двух умных людей. Один из которых рассказывает о своем опыте решения задач, а также о проблемах и граблях, с которыми встречался, а другой слушает, и рассказывает, как подобные проблемы решают у них. Точнее даже так — собеседующий рассказывает о типичных задачах, которые встречаются на практике, спрашивает как кандидат бы их реил, сталкивался или нет, потом рассказал бы свое решение и тому подобное.
А когда о квалификации кандидата смотрят по умению на бумажке написать сортировку (причем с выводом и вводом элементов, от начала до конца, то есть требуется не краткий алгоритм, а реализацию) — это ни хрена не адекватное собеседование.
Увы, адекватных собеседований очень и очень немного. Вообще, ну неужели не о чем поговорить, как о сортировках, хешкодах, отличии интерфейсов от абстрактных классов, перечислении видов джоинов и отличие inner join от outer и тому подобном? Неужели не можете припомнить ни одной реальной практической задачи, которую стоило бы обсудить? Ведь про ту же самую сортировку можно задать вопросы:
1) Приходилось ли вам в практической деятельности реализовывать сортировку и почему;
2) Если не приходилось — дать задачу из своей практики, когда самому приходилось реализовывать сортировку, и спросить, как бы вы ее реализовали, какой алгоритм бы использовали, насколько важна в этом случае скорость и тому подобное;
3) В конце концов можно дать задачу (реальную, которую приходилось самому решать), сводящуюся к сортировке, причем очень не очевидно сводящуюся.
И это все в том случае, если сортировка действительно для вас важна.
Сортировки, поиск — это все инструменты, и ничего более. А реальная задача — это как забить гвоздь! И надо уметь пользоваться этими инструментами именно для решения задачи, а не ради осознания того, что умеешь сам сделать молоток. Молодец конечно, что можешь молоток сам сделать, молодец, что в памяти держишь знания о весе, материале и тому подобного известных молотках разных производителей. Вот только на практике надо не молотки делать, а забивать гвозди! Причем даже не так, на практике надо не забивать гвозди, а надо прикрепить доску. А крепить ее можно не только гвоздем, но и шурупом, например, или винтом. А крепить доску нужно для того, чтобы мебель сделать. Важна на практике задача, а не инструмент! Можно закрепить доску вообще без единого гвоздя или шурупа, вариантов куча. Так вам кто нужен то, мастер по созданию мебели или молотковед?
Я конечно понимаю, что если проверять реальные нужные при работе навыки, то отсеется еще большее количество кандидатов (кстати, в местах, где собеседование проходило с моей точки зрения адекватно — как раз и жаловались, что слишком мало народа в состоянии пройти собеседование). Но ведь здесь то как раз плюс будет, если вы возьмете человека, вы возьмете нужного, а не просто профильтруете кучу народа, и возьмете абы кого, как это делается обычно на практике.

Здравствуйте, elmal, Вы писали:
__>>да потому что программист не смог в уме оценить время выполнения этой операции.
E>Отвалилось совсем не по этому, а по тому, что экономили на тестировании. Не прогоняли тесты на реальных данных и под нормальной нагрузкой.
E>Уж крайний точно не разработчик.
я как раз сторонник обратной теории. самый навороченный QA все равно однажды пропустит лажу. ну типа например той истории с текстами смс в публичном доступе. возникают такие ситуации о котороых просто раньше и не думали даже. качество определяется девелоперами, а не QA, хотя QA дешевле и многие компании убедили себя, что для увеличения качества нужно вкладываться в QA.

Здравствуйте, __kot2, Вы писали:

__>я как раз сторонник обратной теории. самый навороченный QA все равно однажды пропустит лажу. ну типа например той истории с текстами смс в публичном доступе. возникают такие ситуации о котороых просто раньше и не думали даже. качество определяется девелоперами, а не QA, хотя QA дешевле и многие компании убедили себя, что для увеличения качества нужно вкладываться в QA.
Пусть без QA, ладно, но один черт если результат важен, надо перед релизом протестировать систему в условиях, приближенных к боевым. Если пропуск бага не важен — можно и сэкономить, но если это критично — виновато однозначно начальство.

26.07.2011 18:34, __kot2 пишет:

> E>Уж крайний точно не разработчик.
> я как раз сторонник обратной теории.
Вот такие теоретики и довели приличную контору RESIF (тот что роботы
делает) однажды до банкротства.
Так что все в ваших руках (я будущее конторы вашей имею в виду, если
таких как ты большинство на конторе).

Здравствуйте, Vzhyk, Вы писали:
V>26.07.2011 18:34, __kot2 пишет:
>> E>Уж крайний точно не разработчик.
>> я как раз сторонник обратной теории.
V>Вот такие теоретики и довели приличную контору RESIF (тот что роботы
V>делает) однажды до банкротства.
а я всегда думал что тому виной были проклятые Троцкисты и враги родины

Здравствуйте, elmal, Вы писали:
E>Здравствуйте, __kot2, Вы писали:
__>>я как раз сторонник обратной теории. самый навороченный QA все равно однажды пропустит лажу. ну типа например той истории с текстами смс в публичном доступе. возникают такие ситуации о котороых просто раньше и не думали даже. качество определяется девелоперами, а не QA, хотя QA дешевле и многие компании убедили себя, что для увеличения качества нужно вкладываться в QA.
E>Пусть без QA, ладно, но один черт если результат важен, надо перед релизом протестировать систему в условиях, приближенных к боевым. Если пропуск бага не важен — можно и сэкономить, но если это критично — виновато однозначно начальство.
QA лишь дает заключение о качестве. среднее, хреновое, отличное, никакое. хреновое называют бетой. среднее называют релизом. отличное называют стабильным релизом. или там версия 1.5 final.
но я знаю случаи когда буквально все что делает контора тянет разве что на бету. и это не QA вина. само качество создает не QA, он лишь оценивает качество

Здравствуйте, __kot2, Вы писали:

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

А вот мой жизненный опыт говорит совершенно противоположное. Например был проект в котором код долгое время не тестировался, но писался очень тщательно, вычитывалась каждая запятая и не по одному разу. Перекрестное ревью проводили несколько человек, никто никого не торопил итд, те все было сделано, чтобы выявить все проблемы на стадии девелопмента.
В итоге первое же тестирование выявило такую кучу проблем, что вера в QA сразу подскочила до потолка и выше.

Здравствуйте, elmal, Вы писали:

E>Открою секрет. Адекватное собеседование — это разговор двух умных людей.

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


E>И это все в том случае, если сортировка действительно для вас важна.

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

ну хоть кто-нибудь взял бы на работу математика неспособного решить квадратное уравнение?

27.07.2011 7:02, __kot2 пишет:

> V>Вот такие теоретики и довели приличную контору RESIF (тот что роботы
> V>делает) однажды до банкротства.
> а я всегда думал что тому виной были проклятые Троцкисты и враги родины
Хорошо сказал.

27.07.2011 11:10, genre пишет:

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

Здравствуйте, genre, Вы писали:
G>А вот мой жизненный опыт говорит совершенно противоположное. Например был проект в котором код долгое время не тестировался, но писался очень тщательно, вычитывалась каждая запятая и не по одному разу. Перекрестное ревью проводили несколько человек, никто никого не торопил итд, те все было сделано, чтобы выявить все проблемы на стадии девелопмента.
G>В итоге первое же тестирование выявило такую кучу проблем, что вера в QA сразу подскочила до потолка и выше.
значит, девелоперы были хреновые.
QA конечно же нужен, но он не определяет качество продукта. качество продукта определяют девелоперы.
Возьмем акробат. казалось, простая читалка. а сколько гемора она приносит людям! тонны и тонны. QA виноват? нет, конечно. уязвимости нулевого дня они не смогут написать. и дурацкое автообновление у них протестировано и работает. это девелоперам надо по башке надавать

Б>Жуткий офис какой на фото. Не хватает ещё крепкого мужика с кнутом который между рядами бы прогуливался

А что на перегородки денег не хватило? Смотреть в лицо коллег во время работы как то мало приятного... вызывает дискомфорт и вытягивать ноги под столом, когда тебе на встречу ноги другого человека тоже мало приятного... Столы можно было вообще поставить по другому, что бы не мешало никому...

Здравствуйте, genre, Вы писали:

G>уж сколько раз твердили миру, что вопрос на написание простейшей сортировки это не вопрос на знание алгоритмов сортировки. это проверка умения придумать простейший алгоритм.
Относительно придумать простейший алгоритм. Лично я в 50% случаев его на собеседовании придумываю, а в 50% на собеседовании лажаю (вообще, на самом деле при придумывании алгоритмов я практически не лажаю, лажаю я при его реализации на бумажке, именно набросать алгоритм редко спрашивают). И придумываю его через 15 минут после собеседования, по дороге домой. Итого, в одном случае я суперкандидат, а в другом случае слабоумный, которому место только в черном списке. Ладно, я действительно слабоумный, и меня ни в коем случае нельзя брать никуда, даже на 1000р в месяц. Но в этом случае есть 50% вероятность того, что работодатель ошибется, и меня возьмет, так как задание я решил. Как то не очень хороший фильтр, не кажется?
Тем более я имею наглость к собеседованиям не готовиться. А если я готовиться начну, я ж тогда вообще лажать перестану, это ж вообще ахтунг будет !

Здравствуйте, __kot2, Вы писали:

__>значит, девелоперы были хреновые.

люблю я такие утверждения.
ну конечно хреновые, все хорошие тут на рсдн сидят.

__>QA конечно же нужен, но он не определяет качество продукта. качество продукта определяют девелоперы.

качество продукта определяют и девелоперы и тестеры. каждый со своей стороны.

__>Возьмем акробат. казалось, простая читалка. а сколько гемора она приносит людям! тонны и тонны. QA виноват? нет, конечно. уязвимости нулевого дня они не смогут написать. и дурацкое автообновление у них протестировано и работает. это девелоперам надо по башке надавать

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

Здравствуйте, Vzhyk, Вы писали:

V>Вот только хотелось уточнить, что это за заказчик был, что над ним так
V>измывались.

вот мне интересно, что надо написать в сообщении, чтобы ни одного желающего написать "вы все тут дураки" не нашлось?

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

V>Вообще-то должно быть все и тестирование и разработка и менеджмент, без
V>этих 3 составляющих (думаю вес каждой равен) ничего хорошего обычно не
V>выходит.

Вес разнится от проекта к проекту, но в целом конечно.

Здравствуйте, elmal, Вы писали:

G>>уж сколько раз твердили миру, что вопрос на написание простейшей сортировки это не вопрос на знание алгоритмов сортировки. это проверка умения придумать простейший алгоритм.
E>Относительно придумать простейший алгоритм. Лично я в 50% случаев его на собеседовании придумываю, а в 50% на собеседовании лажаю (вообще, на самом деле при придумывании алгоритмов я практически не лажаю, лажаю я при его реализации на бумажке, именно набросать алгоритм редко спрашивают). И придумываю его через 15 минут после собеседования, по дороге домой. Итого, в одном случае я суперкандидат, а в другом случае слабоумный, которому место только в черном списке. Ладно, я действительно слабоумный, и меня ни в коем случае нельзя брать никуда, даже на 1000р в месяц. Но в этом случае есть 50% вероятность того, что работодатель ошибется, и меня возьмет, так как задание я решил. Как то не очень хороший фильтр, не кажется?

почему не очень? ты же придумал алгоритм? или я не понял твою мысль.

Здравствуйте, Vzhyk, Вы писали:

V>Вот только хотелось уточнить, что это за заказчик был, что над ним так
V>измывались.

заказчика не было. в силу определенных обстоятельств был именно такой цикл разработки, сначала весь девелопмент (медленно и очень аккуратно), потом тестирование.

Здравствуйте, __kot2, Вы писали:

__>готовое решение сортировки это что-то из серии "еда мужская 20 кг".

Именно.

__>например на хабре была статья в этом духе — прикрутили показ самого активного участника и все отвалилось. почему? да потому что программист не смог в уме оценить время выполнения этой операции.

Точно? А может потому, что очередной гений, помнящий все алгоритмы на память переизобрёл велосипед, а колёса оказались немного квадратными, потому что на практике всё немного не так, как в теории?

27.07.2011 12:07, genre пишет:

>
> заказчика не было. в силу определенных обстоятельств был именно такой
> цикл разработки, сначала весь девелопмент (медленно и очень аккуратно),
> потом тестирование.
Учитывая, как ты тут обижаешься на замечания и советы, и предполагая,
что понимаешь полную ошибочность подхода выше, говорить что-то по
данному подходу не уверен, что нужно.