Здравствуйте, SkyDance, Вы писали:
LM>>Неверно. Большая часть работодателей мыслить приммерно так :"Зачем повышать человеку зарплату, если он и так работает?" А все разговоры о повышение начинаются только после заявления, положенного на столд. SD>ТОЧНО! Все так и есть и все так и БЫЛО! И, боюсь, будет. Меня очень сильно напрягает именно такое отношение. Нужно что-то вроде предварительного обсуждения, в конце концов, составленный план повышений (делаешь то — получаешь это, завершаешь этот проект — получаешь еще такие плюшки). А то — из трех компаний, где довелось плодотворно работать, во всех трех повышение следовало лишь за ультимативным заявлением с демонстрацией конкретного места, где возьмут с удовольствием и на бОльшие деньги. Намеки словами "вот уже год как мои обязанности растут, а зарплата — нет" не помогают. Намёки "я готов делать чуть больше" воспринимаются исключительно прямолинейно и решаются путем добавления обязанностей. SD>Не знаю, наследие ли это совка или просто наши доморощеные менеджеры считают себя самыми умными (по крайней мере, много умнее "рядовых" сотрудников)
Есть и нормальные фирмы... я например никогда и не заикалась, повышение как то само собой происходит
Дааа, долго и нудно читал все ветки этой темы, сколько всего, громких слов, самовлюбленности, опускания на землю с небес, тех кто отрывается
Итог "все" хотя хорошего спеца и за малые деньги, хотя более правильные понимают, что бесплатный сыр только в мышеловке и то для второй мыши! И не гоняются за дешевизной. Что обидно, на собеседовании, такие понты в больгинстве контор разводят, спросят все чего знают и о чем сами хотели бы знать в итоге после устройска "у нас есть куча добра, которую надо перелопатить, вот тебе лопата, экскаватор с собой не приносить, мы им не умеем пользоваться" (с) не помню кто с этого форума, или переводя с русского на русский: на собеседовании попонтовались много интересного рассказали, что все это надо использовать и т.д. в итоге получаешь в "наследство" код ушедшего человека, так как остальным в нем разбираться в лом и копай его, не то чтоб отнаследоваться от чего-то или использовать как кирпичик в своем коде, а тупое "выгибание" сырцов под текущие нужды, при попытке написания чего-то нового, сразу возглас использовать нужно имеющийся код, так как он работает уже и не надо плодить кучу версий с каждой реализацией, даже если все признают явно и об этом говорят тож явно, что предыдущая реализация кривая до безобразия. Это одна сторона. Вторая: работал в одной конторе, была такая постановка ТЗ в устном виде от главного разработчика (который к стати не был IT'шником, но в силу многих причин и положений был главным разработчиком) "вы пишите, пишите, даже если потом переписывать придется", все после этого работать уже не можешь, а в конторе писалось все по непонятным требования, но постоянно писалось и писалось, а потом переписывалось частично или полностью, так одну форму я переписывал 3 раза, так как постоянно менялись требования причем не от заказчика, просто "главного специалиста" перло на идеи, а потом когда всеж написали и на некоторое время забыли как оно работает со своим "хитрым" подтекстовым интелектом, он приходил и спрашивал как этим пользоваться и что вообще должно быть, а кто спрашивается идею толкал! В итоге тупое постоянное лобание кода. Это вторая сторона. Третья: вот те задание, воооот те куууча времени, делай, а больше особо нет работы (ну это по вторичным признакам определяется, явно этого никто не скажет ) код получается красивый, но его мизир, т.е. большую часть времени пытешься выдумать новую позицию на офисном стуле а никто те не собирается повышать зп и давать что-то для твоего развития, так заменимый кубик в процессе, надо сделал, не надо сиди (это в основном для больших компаний, в маленьких за каждым злой дядька с палкой, чтоб кодили и кодили ).
Выше все лирика. Вопрос на сколько реально найти работу с достойной з/п (не говорю большой, но немногоим выше среднерыночной), но под интересные проекты, не тупое лобание кода, мучения от безделия, так чтоб интересно было? Думаю не это очень проблематично Ну или хотябы чтоб после собеседования занимался тем что на нем спрашивали, а не копался в коде ушедшего работника или тупое лобание кода форм к БД с кучей copy/paste кода.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>А вообще, что-бы кто не говорил, практика критерий истины — если у человека, есть реализованные проекты, значит и у вас будут, а если он знает что такое виртуальные функции (вот ведь умора, что там можно не знать) но пректов у него нет... Значит и у вас будет занайка безрукий...
Означает ли это, что студентов на работу брать не надо? Ведь у них еще нет реализованных проектов...
AWW>Вот мне как проффесионалу, вообще по**** на каком языке програмировать... Надо будет на каком-то новом, выучи за пару недель.... AWW>Да кстати, мне вот понравился один ответ на вопрос — "а почему вы меня по языку не спрашивали"... "Вы же профессионал — надо будет выучите..." был ответ...
Тут полностью согласен. Я тоже считаю, что надо владеть не языком программирования, а базовыми знаниями. Кстати, тестируя кандидата на предмет владения базовыми знаниями по языку, я лично предпочитаю не задавание теоретических вопросов, а анализ какого-то имеющегося кода на предмет полученного результата. Ведь, согласитесь, если человек не представляет себе, в какой последовательности вызываются конструкторы и деструкторы с С++, или каким образом передаются параметры различных типов в Java, или чем отличается WHERE от HAVING в SQL, он вряд ли на первых порах сможет эффективно разрабатывать работающий код.
Подобные знания несложно приобрести, и если он профессионал, претендующий на позицию C++ программера, то, готовясь к собеседованию, он вполне в состоянии ознакомиться с ними до начала разговора со мной, а не через две недели после.
ilya_ny пишет: > _>>я говорю, что квадратик порожден от прямоугольничка, на что третий > мужичек сразу и говорит : "а не фига вы, молодой человек, ооп не знаете" > SM>Ну, надо было обсудить обе точки зрения -) С одной стороны, казалось > бы, прямоугольник поддерживает все операции, осуществимые над квадратом, > а вот обратное неверно -> прямоугольник расширяет квадрат. Но вот с > другой — я могу сказать, что для квадрата определена операция > "восстановить размеры из площади", а для прямоугольника — нет... > > SM>Slicer > > прочитай все обсуждения по ссылке, которую я дал — там есть некий > принцип, который нарущается при наследовании квадрата от прямоугольника > > я это так понял: > 1. если у прямоугольника длины сторон независимы, то у квадрата — зависимы > 2. если квадрат порождается от прямоугольника, то он не наследует > поведение/свойства (свойство независимости длин сторон) родителя, а > должен ==> нарущение принципа ооп > 3. изменил у квадрата одну сторону — неявно изменилась другая сорона, > что может быть сюрпризом = тоже, если быть предельно точным — нарущение > > другое дело, что не всегда важно то, что у квадрата стороны зависимы, > поэтому так однозначно сказать, что нельзя порождаться — не совсем верно
IMHO, все немного проще: квадрат — это частный случай прямоугольника...
E>>В данном случае $500 уже ничего не решает.
xog>В данном случае да, но есть и другой вариант: 3500 и 5000 xog>Вот и интересно при каком уровне дохода разница уже не играет роль ?
Это зависит от доходов других членов семьи, решенности квартирного вопроса и наличия желания поменять старенький 21" на плазменную панель, в которой покажут те же самые новости (вариант — шестерку на HumII, чтобы стоять в той же пробке, но с кондиционером). Но гречки вы все равно съедите столько же.
Здравствуйте, egaron, Вы писали:
E>а что, смена БД обязательное условие ? Если такое маловероятное событие произойдет, то да — перепишут провайдеры.
Обычно это называется не маловероятным событием, а расширяемостью. В моей практике, когда проект поставляется различным заказчикам, каждый новый заказчик хочет его подстроить "немножко" под себя. Тут и обнаруживается, что у него давно стоит безлимитно-лицензированный Informix, а вовсе не ORACLE, на который рассчитывали мы как разработчики, и который устроил предыдущих троих заказчиков. И это только БД... и это мы еще не рассматриваем итерационный процесс разработки, когда на второй итерации заказчик, посмотрев на проект, предлагает "чуть-чуть" изменить ТЗ (он по-прежнему готов платить деньги, а вы по-прежнему заинтересованы продвигать ему этот проект). И вот тут-то это самое "чуть-чуть" запросто может вылиться в переписывание половины кода, если ваша архитектура недостаточно гибкая.
АК>>Я с некоторых пор являюсь ярым приверженцем выдачи тестового задания еще до технического собеседования (т.е. после вступительного собеседования, когда примерно понятно, что человек заинтересован у нас работать). При этом от человека в явном виде требуется разработка масштабируемого, расширяемого, надежного, поддерживаемого кода. Сложность задания оценивается примерно в 2-3 часа на фукнционал и еще 2-3 часа на красивое оформление.
E>когда тебя приглашают 10 контор и каждая дает задание на неделю, то кандидат пойдет в ту, где тестовое задание отсутствует или занимает полдня. Поэтому мне и не довелось работать в конторах, раздающих мощное Т.З. E>Для меня приемлемое максимальное время выполнения ТЗ — 8 часов (и то если контора понравилась)
Я рад, что мои задания на 4-6 часов с запасом вписываются в ваши лимиты
АК>>Так вот, любопытнейшие результаты, я вам скажу Примерно 80% решений удается "завалить" парой-тройкой тестовых примеров. Больше половины оставшихся написаны методом "copy-paste" (это если обобщенно). E>У тебя цель завалить или найти сотрудника ? Как говорил наш старшина, прапорщик Гертнер — "юноша, я знаю миллион способов чтобы задрочить солдата"
У меня цель — взять на работу сотрудника, который не будет разрабатывать код таким образом, чтобы за него потом приходилось переделывать. То что я перечислил — это показатель того, что переделывать придется. "Copy-paste" — это неподдерживаемый код, а "завалить парой-тройкой тестовых примеров" (задание-то простое! можно было и предусмотреть все варианты!) — это ненадежный код.
B>Ну уж извините, сортировку пузырем написать должен каждый. Ибо помнить прадедов .
Честно говоря никогда не понимал почему именно пузырёк учат в школе. ИМХО сортировка простым выбором куда проще для понимания, настолько же проста для реализации, да и к тому же лучше по эффективности.
Здравствуйте, Left2, Вы писали:
L>Честно говоря никогда не понимал почему именно пузырёк учат в школе. ИМХО сортировка простым выбором куда проще для понимания, настолько же проста для реализации, да и к тому же лучше по эффективности.
А разве эффективность этих двух алгоритмов не одинакова и не оценивается в n(n+1)/2 сравнений?
Здравствуйте, Sergey Philippov, Вы писали:
SP>IMHO, все немного проще: квадрат — это частный случай прямоугольника...
А я все же считаю, что вопрос был поставлен некорректно: порождать ли одну из этих сущностей от другой вообще, и если порождать — то какую, зависит от решаемой задачи. Если вопрос звучал "что от чего наследовать?", правильный ответ был бы, imho, "для чего?". Если надо их просто закрасить, так и наследование пусть идет лесом =))
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Александр Каширин, Вы писали:
E>>У тебя цель завалить или найти сотрудника ? Как говорил наш старшина, прапорщик Гертнер — "юноша, я знаю миллион способов чтобы задрочить солдата" АК>У меня цель — взять на работу сотрудника, который не будет разрабатывать код таким образом, чтобы за него потом приходилось переделывать. То что я перечислил — это показатель того, что переделывать придется. "Copy-paste" — это неподдерживаемый код, а "завалить парой-тройкой тестовых примеров" (задание-то простое! можно было и предусмотреть все варианты!) — это ненадежный код.
А разве есть однозначная связь между знанием алгоритмов сортировки и порядка вызова конструкторов и способностью писать расширяемый и поддерживаемый код?
Здравствуйте, Дарней, Вы писали:
Д>Компаний много, а я один. На каждую тестовое задание делать — подохнешь от переутомления. Д>Так что я тоже не стал бы делать тестовое задание (ну если только компания выделяется своими неимоверно хорошими условиями работы... тогда я бы подумал )
О! Прекрасное заключение мысли! А разве мы рассматриваем варианты, когда ищем работу в фирме, в которой не очень-то и хотелось бы работать? Я такие предложения фильтрую еще на этапе первого звонка от HR или заменяющего его менеджера
Здравствуйте, Eurispheus, Вы писали:
E>Если в другой компании платят больше/условия лучше, то почему он работает в этой? Из мазохизма?
Из энтузиазма. Сам с таким общаюсь. Если фактически тянешь на себе проект, жаль бывает все бросать, уже выйдя на финишную прямую.
Из интереса. Тоже общаюсь. Чел предпочитает работать интегратором за 5-15 т.р., хотя мог бы, скажем, админить оракл за 20-30...
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Александр Каширин, Вы писали:
АК>О! Прекрасное заключение мысли! А разве мы рассматриваем варианты, когда ищем работу в фирме, в которой не очень-то и хотелось бы работать? Я такие предложения фильтрую еще на этапе первого звонка от HR или заменяющего его менеджера
В пределах досягаемости нет ни одной компании, где "очень хотелось бы работать". А переезжать я пока не собрался
L>>Честно говоря никогда не понимал почему именно пузырёк учат в школе. ИМХО сортировка простым выбором куда проще для понимания, настолько же проста для реализации, да и к тому же лучше по эффективности. АК>А разве эффективность этих двух алгоритмов не одинакова и не оценивается в n(n+1)/2 сравнений?
Таким образом, среднее время работы программы S равно 2.5N2 + 3(N+1) + 3.5N — 11 единиц, т. е. она лишь немногим медленнее простых вставок. Интересно сравнить алгоритм S с сортировкой методом пузырька, так как метод пузырька можно рассматривать как алгоритм выбора, в котором иногда выбирается более одного элемента за раз. По этой причине при сортировке методом пузырька производится меньше сравнений, чем при простом выборе, и она, как может показаться, предпочтительнее. Но в действительности алгоритм пузырьковой сортировки более чем вдвое медленнее алгоритма простого выбора. Сортировка методом пузырька проигрывает из-за того, что в ней выполняется слишком много обменов, в то время как при сортировке простым выбором производится очень мало пересылок данных.
Здравствуйте, Sergey Philippov, Вы писали:
SP>IMHO, все немного проще: квадрат — это частный случай прямоугольника...
ИМХО кажется ничего подобного, у квадрата и прямоугольника общее только то, что они есть класс геометрических фигур. Так что в принципе можно отнаследолвать их от общего абстрактного базового класса Shape. Квадрат не есть частный случай прямоугольника в терминах ООП, да и в математике насколько я помню тоже.
Если бы мне дали такое задание, я бы написал что то вроде этого:
class Shape
{
virtual void Draw() const = 0;
};
class Square : public Shape
{
private:
int left_;
int top_;
int sideSize_;
public:
Square() {}
Square(int left, int top, int sideSize) : left_(left), top_(top), sideSize_(sideSize) {}
Square(const Square &);
void Draw() const;
// ...
};
class Rectangle : public Shape
{
private:
int left_;
int top_;
int width_;
int height_;
public:
Rectangle() {}
Rectangle(int left, int top, int width, int height) :
left_(left), top_(top), width_(width), height_(height) {}
Rectangle(const Rectangle &);
void Draw() const;
// ...
};
Интересно, меня бы с таким решением тоже отправили бы ?
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, landerhigh, Вы писали:
L>Когда в последнее время интервьюировал людей, интересовался только их способностью к командной работе, знанием методов разработки, юнит-тестирования...
Как показывает практика, качественно проведенное юнит-тестирование покрывает не более 10% багов. Остальные не менее 90% приходится на multi-unti стыки... особенно в multi-thread и multi-tier приложениях. Именно поэтому в некоторых крупных западных компаниях юнит-тестирование — это чисто формальный этап, полностью отданный на усмотрение разработчика, к которому не предъявляется конкретных требований, и на который не нормируется время. Потому что все равно баги ловятся на этапе комплексного multi-unit тестирования.
Здравствуйте, Дарней, Вы писали:
Д>я обычно таки использую виртуальные функции. Но и без них можно строить вполне качественный код. Д>Виртуальные функции в статике прекрасно заменяются шаблонами и/или кодогенерацией. Если реально нужен рантайм-полиморфизм, то можно использовать RTTI/reflection. (я не говорю, что так и надо делать. Но, тем не менее, это позволяет делать вполне терпимый по качеству код — тем более, что в большинстве случаев статического полиморфизма вполне достаточно)
Мдаааа, no comments
PS: ничего личного, но тут все орут, да я б таких уволил, да таких надо увольнять, каких это таких ? По мне так вот этого вот товарища я бы в первую очередь уволил бы, если бы он каким то чудом ко мне попал
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, Александр Каширин, Вы писали:
E>>>У тебя цель завалить или найти сотрудника ? Как говорил наш старшина, прапорщик Гертнер — "юноша, я знаю миллион способов чтобы задрочить солдата" АК>>У меня цель — взять на работу сотрудника, который не будет разрабатывать код таким образом, чтобы за него потом приходилось переделывать. То что я перечислил — это показатель того, что переделывать придется. "Copy-paste" — это неподдерживаемый код, а "завалить парой-тройкой тестовых примеров" (задание-то простое! можно было и предусмотреть все варианты!) — это ненадежный код.
L>А разве есть однозначная связь между знанием алгоритмов сортировки и порядка вызова конструкторов и способностью писать расширяемый и поддерживаемый код?
Из приведенной цитаты можно лишь сделать вывод, что я усматриваю связь между результатом выполнения тестового задания и способностью писать расширяемый и поддерживаемый код.
Что же касается остального... Знание порядка вызова конструкторов и деструкторов, очевидно, напрямую связано с умением разрабатывать надежный код с использованием данного языка программирования. А понимание работы основных алгоритмов (не только сортировки), на мой взгляд, напрямую связано с умением разрабатывать код
Ну или хотябы чтоб после собеседования занимался тем что на нем спрашивали, а не копался в коде ушедшего работника или тупое лобание кода форм к БД с кучей copy/paste кода.
