Здравствуйте, Spidola, Вы писали:
S>А вот тут готов поспорить... S>Если хорошо составленное резюме является хорошей предпосылкой к дальнейшей беседе, то плохо составленное резюме может вообще отрезать возможность дальнейшей беседы, что частенько и случается...
Че спорить, я это и говорю — только изложил первую часть поскольку вторая из нее следует
Здравствуйте, AlexEagle, Вы писали:
AE>Здравствуйте, Spidola, Вы писали:
S>>А вот тут готов поспорить... S>>Если хорошо составленное резюме является хорошей предпосылкой к дальнейшей беседе, то плохо составленное резюме может вообще отрезать возможность дальнейшей беседы, что частенько и случается...
AE>Че спорить, я это и говорю — только изложил первую часть поскольку вторая из нее следует
Здравствуйте, AlexEagle, Вы писали:
AE>Здравствуйте, Spidola, Вы писали:
S>>Ну ты это, извини, братан, не дотумкал
AE>Не катит — все плюсики (один) тебе достались
Здравствуйте, Spidola, Вы писали:
S>Здравствуйте, mant21, Вы писали:
M>>Например прочитанную за последний год. Интересно ли это работодателю ?
S>Я тут прикинул — меня лично заинтересовало бы высказывание вроде:
S>"В работе над таким-то проектом применялись технологии и/или методы и/или методики, рассмотренные в такой-то и такой-то литературе с такими-то и такими-то ограничениями."
S>Такая фраза показала бы, что вы: S>1) не читаете всё подряд, забивая себе голову "на будущее"; S>2) умеете читать нужную литературу; S>3) умеете анализировать прочитанное и применять его на практике; S>4) не слепо копируете написанное, а разумно его применяете.
S>Меня бы такой кандидат по крайней мере заинтересовал.
А заинтересует ли тебя такой кандидат, который данные по мере необходимости берет из форума? + МСДН?
Здравствуйте, AlexEagle, Вы писали:
AE>Здравствуйте, Spidola, Вы писали:
S>>Здравствуйте, mant21, Вы писали:
M>>>Например прочитанную за последний год. Интересно ли это работодателю ?
S>>Я тут прикинул — меня лично заинтересовало бы высказывание вроде:
S>>"В работе над таким-то проектом применялись технологии и/или методы и/или методики, рассмотренные в такой-то и такой-то литературе с такими-то и такими-то ограничениями."
S>>Такая фраза показала бы, что вы: S>>1) не читаете всё подряд, забивая себе голову "на будущее"; S>>2) умеете читать нужную литературу; S>>3) умеете анализировать прочитанное и применять его на практике; S>>4) не слепо копируете написанное, а разумно его применяете.
S>>Меня бы такой кандидат по крайней мере заинтересовал.
AE>А заинтересует ли тебя такой кандидат, который данные по мере необходимости берет из форума? + МСДН?
Я всех сотрудников у себя приучаю, что если возникает техническая проблема, которая не решается сразу, то первое, что нужно сделать — это поискать её решение в Интернет и задать вопрос на форуме (в том числе по некоторым вопросам и на RSDN).
Разумеется заинтересует! Ведь это чистая экономия времени + умение напрячь других, чтобы работали тебе на пользу
Здравствуйте, Alex Alexandrov, Вы писали:
AA>Очень спорные утверждения. Есть книги, которые действительно надо месяц читать, но на основную массу 5-10 вечеров вполне достаточно. Как раз практик тем и отличается от теоретика, что он книги начинает гораздо быстрее читать — с приходом опыта учишься быстрее выделять главное, лучше понимаешь ход мыслей автора, многие вещи можешь просто пропустить (пропустить в хорошем смысле слова, т.е. без ущерба для понимания).
Согласен, это действительно так...
AA>А связи между сидением в форуме и "практицизмом" я, извините, вообще не вижу. Совершенно ортогональные понятия.
Объясняю: Зачастую, когда проект лишь поверхностно задевает некоторые неизученные технологии, практичнее будет спросить и реализации конкретной задачи в форуме, нежели читать всю литературу по теме с заметкой "на будущее"
Правда везде есть свои исключения — есть лентяи, неспособные поянть что-либо самостоятельно, потому и паразитируют на форумах, а есть высококвалифицирвоанные программисты, высоко ценящие свое время, и пытающиеся за счет форума его сэкономить. Тут возможно поможет собеседование выявить кто есть кто, иначе на испытательном сроке.
Здравствуйте, Бекетов Роман aka Yaiu, Вы писали:
БРA>Глупого в чтении литературы ничего нет. Я вот знаю человека который написал не один крупный GUI проект не зная что такое MVC
Глупого не в чтении, а в указании в резюме.
ЗЫ. Я вот тоже всю жизнь код рефакторил, а пока книженцию Фаулера не прочитал, так и не знал, как называется написание "красивого" кода.
Здравствуйте, AlexEagle, Вы писали:
AE>М-да, далее можно поговорить о полезных отличиях теоретиков от практиков.
AE>К примеру теоретики читают много литературы что добавляет им некоторые, возможно весьма поверхностные знания. С другой стороны практик зачастую не имеет времени на чтение технической литературы, поскольку практически всегда занят разработкой, ну а нужную информацию достает из статей, форумов!
Полнейшая ботва. Это такой же стереотип как и программист в растянутом свитере, джинах с коленями и сальными волосами, шепчущий под нос "виндоуз сакс". Хороший практик однозначно перелопатил приличное количество литературы.
А хорошо написанная книжка хотя бы страничек на 200-300 по информативности превзойдет любой форум и статьи. Ценность книги не прост ов фактах которые в ней описаны а в системности изложения и способе подачи информации. Дело в том что прочтение некоторой хорошо систематизированной книги может открыть глаза на вещи, прямо в ней не упоминающиеся и ваще очень серъезно расширить кругозор и образ мысли, если человек конечно хоть немного анализирует прочитанное а не тупо запоминает заклинания.
AE>Я бы этому уделял небольшое значение. Да и вообще, прочитать книгу можно за день, а можно и за месяц. В первом случае вероятность освоения нового материала невелика. А иначе я могу в резюме с той же гарантией указать все книги по используемым мною средам разработки из соседнего магазина + некоторые по используемым технологиям. Какой толк?
Да, тут согласен — сам факт прочтения книги еще ни о чем не говорит. Наверное если уж совсем в резюме напедалить нечего, то тогда и пишут такое.
Здравствуйте, Alex Alexandrov, Вы писали:
A>> Я бы этому уделял небольшое значение. Да и вообще, прочитать книгу можно A>> за день, а можно и за месяц. В первом случае вероятность освоения нового A>> материала невелика. А иначе я могу в резюме с той же гарантией указать A>> все книги по используемым мною средам разработки из соседнего магазина + A>> некоторые по используемым технологиям. Какой толк?
AA>Очень спорные утверждения. Есть книги, которые действительно надо месяц читать, но на основную массу 5-10 вечеров вполне достаточно. Как раз практик тем и отличается от теоретика, что он книги начинает гораздо быстрее читать — с приходом опыта учишься быстрее выделять главное, лучше понимаешь ход мыслей автора, многие вещи можешь просто пропустить (пропустить в хорошем смысле слова, т.е. без ущерба для понимания).
На самом деле то что человек чистает книги почти не о чем не говорит. Нужно чтобы он их еще и понимал, т.е. я когда читал "Design Patterns" и "Мифический человеко-месяц" в первый раз (у меня было год опыта) — особого впечатления на меня они не произвели. DP я понял когда уже 3 года занимался программированием, Myth Man-Month только недавно, перечитывал — совсем другое впечатление.
Аналогично Refactoring читал достаточно поздно — ничего нового не узнал. Patterns Of Enterprise App Architecture читаю сейчас — появилось впечатление "вот блин прочитать бы на год раньше, на столько меньше шишек от граблей получил".
Это я все про что — главное не факт чтения, главное опыт полученный от чтения. Для того чтобы читать книжки нужно просто уметь читать, читать в данный момент умеет весьма значительная часть программистов, так что особых бонусов в резюме тебе не дает — а вот правильное понимание книг это достижение. Но в резюме ты этого не напишешь — резюме не место для review на книги.
Я бы рекомендовал в резюме написать "занимаюсь самообразованием(читаю книги по архитектуре, общаюсь в форумах)" и нарваться на данный вопрос на собеседовании, после чего там всех пролечить за правильную литературу.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Бекетов Роман aka Yaiu, Вы писали:
O>>Не стоит. Может сложиться впечатление, что сертификатами и списком литературы просто прикрывается отсутствие реального опыта работы. Для студентов может это и неплохо, а для спеца — глупо, ибо он оценивается совсем по другим критериям.
БРA>Глупого в чтении литературы ничего нет. Я вот знаю человека который написал не один крупный GUI проект не зная что такое MVC
Он этот MVC сам изобрел(я тоже кстати сам изобрел а потом прочитал) или просто GUI как попало писал? Это разные вещи.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, olegkr, Вы писали:
БРA>>Глупого в чтении литературы ничего нет. Я вот знаю человека который написал не один крупный GUI проект не зная что такое MVC
O>Глупого не в чтении, а в указании в резюме.
O>ЗЫ. Я вот тоже всю жизнь код рефакторил, а пока книженцию Фаулера не прочитал, так и не знал, как называется написание "красивого" кода.
И не читай — я так же сначала рефакторил, потом прочитал. Был разочарован и растерян. Ну как можно целую книжку написать про то как из одного вида кода делать другой, при этом не дав четких критериев в каких случаях это делать. А сосредотачиваться на самом процессе как лучше переменную переименовать, чтоб меньше граблей было. Как процесс выполнить помоему даже обезьяна сама додумается.
Тут спорил достаточно давно с одним человеком про дизайн, прося его порефакторить одну херню. Он этим refactoring-ом(книгой) что то увлекся и я показал ему прямо пальцем в книжке refactoring pattern соотвествующий т.к. объяснять теорию дизайна было лень. А он мне показал 3 паттерна которые в последовательном применении делают обратный эффект. Я даже с разбегу не нашелся что сказать. Т.е. человек когда читал ничему не научился — т.к. после чтения книги системы применения паттернов рефакторинга у него не сложилось. Притом в этом не он виноват — в книге ее действительно нету.
Единственная заслуга книги в самой идее рефакторить, но она простая как 3 рубля и ее отнюдь не там придумали. Да и писать для этого книгу в 400 страниц не стоило.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Spidola, Вы писали:
AE>>А заинтересует ли тебя такой кандидат, который данные по мере необходимости берет из форума? + МСДН?
S> Я всех сотрудников у себя приучаю, что если возникает техническая проблема, которая не решается сразу, то первое, что нужно сделать — это поискать её решение в Интернет и задать вопрос на форуме (в том числе по некоторым вопросам и на RSDN).
S>Разумеется заинтересует! Ведь это чистая экономия времени + умение напрячь других, чтобы работали тебе на пользу
Это же косвенно может означать отсутствие problem solving skills.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Anatolix, Вы писали:
A>Здравствуйте, Spidola, Вы писали:
AE>>>А заинтересует ли тебя такой кандидат, который данные по мере необходимости берет из форума? + МСДН?
S>> Я всех сотрудников у себя приучаю, что если возникает техническая проблема, которая не решается сразу, то первое, что нужно сделать — это поискать её решение в Интернет и задать вопрос на форуме (в том числе по некоторым вопросам и на RSDN).
S>>Разумеется заинтересует! Ведь это чистая экономия времени + умение напрячь других, чтобы работали тебе на пользу
A>Это же косвенно может означать отсутствие problem solving skills.
Не согласен.
Объясняю почему.
Размещая вопрос по проблеме на форуме и получая ответ работник:
1) экономит время;
2) в большинстве случаев получает опробированное типовое решение.
В случае сложной нетипичной проблемы на форуме всё равно никто не поможет (много раз испытано) и ему придётся решать проблему самому. Здесь пусть и проявляются его problem solving skills. А типовые проблемы нужно накрывать типовыми решениями и не тратить на это время и не плодить ошибки "от местного Кулибина"...
Здравствуйте, Glоbus, Вы писали:
G>Да, тут согласен — сам факт прочтения книги еще ни о чем не говорит. Наверное если уж совсем в резюме напедалить нечего, то тогда и пишут такое.
Об этом и речь! У меня например резюме с трудом на А4 вмещает набор скилов и проектов + последние 3 места работы. Если мне понадобится искать другую работу, то надо серьезно подумать над рефакторингом (выкинуть маловлияющие на результат данные), да и вообще его надо переписать на др. тему (на должность руководителя). О том куда впихнуть книжки я даже не задумывался, поскольку мне кажется что год программирования в указанной среде разработки пусть даже дома говорит больше чем факт прочтения крутой книжки.
Уж лучше я упомяну технологии применяемые в разработках, и вобщем пофиг что я читал статью из инета (CIT-forem когда то на дисках издавался, там много полезного для начинающих было)
Иными словами, книги — самое малозначимая инфа в резюме, на которую даже не охота выделять место. ну разве что кратко 4-5 самых "must read"-ных
Здравствуйте, mant21, Вы писали:
M>Например прочитанную за последний год. Интересно ли это работодателю ?
Как представитель работодателя с уверенностью могу сказать, что прочитанную литературу ПО СПЕЦИАЛЬНОСТИ стоит указать: это и отличит Вас от других и даст понять, что вы стараетесь развиваться профессионально. Худ литературу указывать не нужно, так как это вроде как к делу не относится. Если работодателю интересно, он сам спросит (мы, например, спрашиваем). Но это потому, что мы принимаем ЧЕЛОВЕКА себе в команду и нам интересно и важно знать не только его профессиональную биографию, но и личностные харакетеристики). Но представьте, что Вас будут собеседовать люди, которые сами книг не читают или им важны только производительные характеристики сотрудника — им эта информация покажется избыточной.
Здравствуйте, VDO, Вы писали:
VDO>На интервью надо упомянуть обязательно VDO>В резюме лучше дать ссылку на список как у меня (извиняюсь за саморекламу )
VDO>http://www.opentask.com/Books.htm
А вот это "Inside the C++ Object Model by Stanley B. Lippman" ты читал в печатном виде или в цифре?
В цифре мне так и не удалось найти.
Здравствуйте, EvilChild, Вы писали:
EC>А вот это "Inside the C++ Object Model by Stanley B. Lippman" ты читал в печатном виде или в цифре? EC>В цифре мне так и не удалось найти.
В печатном. Хочу заметить что все это можно изучить путем рассмотрения ассемблерных листингов VC++ или загрузив программу в WinDbg. Для Linux-дов G++ и GDB
Просто задавать себе вопросы типа как С++ код выглядит на ASM.
