Эх!
Решил эту задачу в 10-м классе путем анализа таблицы.
Вывел предложенную рекурсивную формулу с остатком от деления.
:-)
И потом не мог объяснить, почему оно все-таки считает правильно. :-)
Конечно, истинный разработчик может прочитать код на любом языке, но есть риск ошибиться в нюансах интерпретации. Из-за чего он иногда испытывает дискомфорт при чтении кода на незнакомом языке.
В нашей стороне часто пытаются запугать особенностями транзакционного взаимодействия.
Причем начиная с уровня JPA, а кончая в дебрях БД а-ля Oracle.
Причем как правило в таких местах если нормально писать, то всех этих «особенностей», с которыми большинство народа не знакомо, аккуратно обходятся, т.к. простота поддержки в большинстве случаев весит намного больше, чем хитрая магия lock'ов для небольшого выигрыша в производительности, которую, к тому же, никто не мерил…
У меня было один раз.
Экзамен. Заваливаю (ну, не подготовился, с кем не бывает).
Препод смотрит на это дело, дает задачу и говорит: «У тебя 15 минут. Решишь — будет 3, не решишь — пересдача».
Сначала — паника, потом около 5 минут приходил в себя, и буквально за 5 оставшихся минут решил.
Без ошибок.
Паника — это состояние, когда мозг зациклен на эмоциональном состоянии, и отвергает любые призывы к беспристрастному анализу. Часто наблюдается при сильном ограничении во времени, когда чувствуешь, что не успеваешь уложиться в сроки, и за это будет что-то плохое. При этом мозг склонен идти по пути наименьшего сопротивления — чем сильнее эмоция, тем больше ей уделяется внимания.
При выхода из состояния паники необходимо переключить внимание на что-либо другое, кроме эмоций.
Очень хорошо помогают физические способы, например, прежде чем что-либо делать в панике, медленно вдохните и выдохните несколько раз. Чем медленнее, тем лучше — мозг начинает концентрироваться на недостатке кислорода, и это действует практически на уровне рефлексов. Тем самым возвращаем себе контроль — и начинаем решать происходящую ситуацию.
Меня лично эта тактика не один раз выручала — на восстановление тратится всего несколько минут, после этого проблема часто решается также за несколько минут.
Плюсую ссылку на книжку. :-)
Я как раз ее дочитываю.
Очень хорошо раскрывает особенности взаимодействия между участниками команды и менеджерами.
Особенно антипаттерны :-)
Используйте разные термины, например, «Дизайн интерфейса пользователя» и «Архитектурный дизайн». Не уверен, что корректно использую термины, но зато понятно.
100% зависит от собеседующего и его целей.
А в цели входят не только технические знания, но и человеческие качества.
Которые также проверяются подобными вопросами.
Так что если Вам задают подобный вопрос — вряд ли интересуются техническими знаниями.
Скорее — самооценкой, внимательностью и т.д.
Коммуникация помогает преодолевать барьеры различного трактования одних и тех же символов.
Лично я как разработчик еще пять лет назад сделал неутешительный для себя вывод, что большинство проблем адекватнее решать на уровне коммуникации, а не на техническом уровне.
На техническом уровне уже нет пространства маневра, и приходится делать хаки.
В Enterprise-разработке самая большая проблема — постановка задачи.
И попытка решать эту задачу путем технической гибкости — IMHO, слишком большая цена.
Самые большие проблемы в жизни вовсе не в теории относительности.
И уж тем более не в квантовой физике.
:-)
Наиболее интересна с этой точки зрения психология, но там пока все неоднозначно и расплывчато, мало конкретных ответов, которые можно брать и использовать.
Этого часто ой как сложно добиться :-)
Решил эту задачу в 10-м классе путем анализа таблицы.
Вывел предложенную рекурсивную формулу с остатком от деления.
:-)
И потом не мог объяснить, почему оно все-таки считает правильно. :-)
Неплохо бы позаботиться об их обновлении и резервных копиях.
Лучше бы псевдокодом описали — и понятнее, ближе к математическому описанию, и не привязано к специфике языка.
Причем начиная с уровня JPA, а кончая в дебрях БД а-ля Oracle.
Причем как правило в таких местах если нормально писать, то всех этих «особенностей», с которыми большинство народа не знакомо, аккуратно обходятся, т.к. простота поддержки в большинстве случаев весит намного больше, чем хитрая магия lock'ов для небольшого выигрыша в производительности, которую, к тому же, никто не мерил…
Экзамен. Заваливаю (ну, не подготовился, с кем не бывает).
Препод смотрит на это дело, дает задачу и говорит: «У тебя 15 минут. Решишь — будет 3, не решишь — пересдача».
Сначала — паника, потом около 5 минут приходил в себя, и буквально за 5 оставшихся минут решил.
Без ошибок.
Паника — это состояние, когда мозг зациклен на эмоциональном состоянии, и отвергает любые призывы к беспристрастному анализу. Часто наблюдается при сильном ограничении во времени, когда чувствуешь, что не успеваешь уложиться в сроки, и за это будет что-то плохое. При этом мозг склонен идти по пути наименьшего сопротивления — чем сильнее эмоция, тем больше ей уделяется внимания.
При выхода из состояния паники необходимо переключить внимание на что-либо другое, кроме эмоций.
Очень хорошо помогают физические способы, например, прежде чем что-либо делать в панике, медленно вдохните и выдохните несколько раз. Чем медленнее, тем лучше — мозг начинает концентрироваться на недостатке кислорода, и это действует практически на уровне рефлексов. Тем самым возвращаем себе контроль — и начинаем решать происходящую ситуацию.
Меня лично эта тактика не один раз выручала — на восстановление тратится всего несколько минут, после этого проблема часто решается также за несколько минут.
Я как раз ее дочитываю.
Очень хорошо раскрывает особенности взаимодействия между участниками команды и менеджерами.
Особенно антипаттерны :-)
На востоке тоже так думают :-)
Иногда об этом уже некому рассказать.
На этот раз — компьютерная графика (всегда хотел написать свой Doom :-)
А в цели входят не только технические знания, но и человеческие качества.
Которые также проверяются подобными вопросами.
Так что если Вам задают подобный вопрос — вряд ли интересуются техническими знаниями.
Скорее — самооценкой, внимательностью и т.д.
Лично я как разработчик еще пять лет назад сделал неутешительный для себя вывод, что большинство проблем адекватнее решать на уровне коммуникации, а не на техническом уровне.
На техническом уровне уже нет пространства маневра, и приходится делать хаки.
В Enterprise-разработке самая большая проблема — постановка задачи.
И попытка решать эту задачу путем технической гибкости — IMHO, слишком большая цена.
И уж тем более не в квантовой физике.
:-)
Наиболее интересна с этой точки зрения психология, но там пока все неоднозначно и расплывчато, мало конкретных ответов, которые можно брать и использовать.
А вообще размер — нехороший показатель.
Короткий код часто оказывается неподдерживаемым.