Comments 45
В чем смысл статьи? Дело не в цифрах, дело в подходе. Автор того поста получил кучу резюме, на собеседовании по дурацким вопросам отсеял всех и взял явно недооцененных работников. Это он молодец, это выгодно для компании. Но сетовать на то, что быдлокодеры на PHP требуют 2000$, ориентируясь на тех 2-3 человек, которые с гораздо большим опытом согласились у вас за эти же $2k работать — не умно. Если 90% рынка требует $2000, а ты знаешь и умеешь в 3 раза больше их, то и требуй $6000.
Смысл статьи в том, что нужно анализировать причины и делать корректировки, даже в таком деле, как найм персонала.
Прям как по циклу Plan-Do-Check-Analyze.
Я лишь, подсказал, что неплохо бы было провести анализ сложившейся ситуации и предложил возможные корректировки.
Еще хотел бы заметить, что корреляция между уровнем ваших знаний и вашей зарплатой далеко не линейна.
Например, согласно Исследования Pruffi:
1. Успешный опыт работы в Highload — 20%
2. Успешный опыт работы в крупном портале — 15%
3. Успешно реализованные коммерческие проекты — 20%
(мы сейчас говорим только про знания, без привязки к продолжительности работы в качестве программиста)
Итого: отличный спец будет получать на 40-60 % больше… это не как не в 3 раза.
Прям как по циклу Plan-Do-Check-Analyze.
Я лишь, подсказал, что неплохо бы было провести анализ сложившейся ситуации и предложил возможные корректировки.
Еще хотел бы заметить, что корреляция между уровнем ваших знаний и вашей зарплатой далеко не линейна.
Например, согласно Исследования Pruffi:
1. Успешный опыт работы в Highload — 20%
2. Успешный опыт работы в крупном портале — 15%
3. Успешно реализованные коммерческие проекты — 20%
(мы сейчас говорим только про знания, без привязки к продолжительности работы в качестве программиста)
Итого: отличный спец будет получать на 40-60 % больше… это не как не в 3 раза.
Странное дело, на большинстве собеседований, ищут что человек НЕ УМЕЕТ делать, вместо того, чтоб спросить, что человек делать умеет. И исходя из того, что человек делать не умеет определяют его цену. А что до требований к работе — в большинстве случаев они скопированны с другого обьявления, или названы по принципу «какие у тебя ассоциации вызывает фраза программист?»
Только на одном собеседовании меня спросили — «у нас есть такие вот проблемы, чем ты нам можешь помочь?» Это было круто, хотя вопрос был явно неожиданным (я то думал меня опять будут по теории гонять).
Только на одном собеседовании меня спросили — «у нас есть такие вот проблемы, чем ты нам можешь помочь?» Это было круто, хотя вопрос был явно неожиданным (я то думал меня опять будут по теории гонять).
UFO just landed and posted this here
ответить на вопрос, зачем с ним заморачиваться, если есть процедуры и функции
А что, на этот вопрос есть правильный ответ? Или все данные претендентами ответы вам субъективно не нравились? Или претенденты вообще не могли вымолвить ни слова в ответ на этот вопрос?
UFO just landed and posted this here
А как бы вы ответили на вопрос «Зачем нам ООП»?
UFO just landed and posted this here
Я вопрос прочитал полностью. Это не отменяет моего вопроса.
Более того, я действительно считаю что ответы на вопросы «Зачем использовать ООП?», «Зачем нам ООП?», «Почему используют ООП?» должны быть похожими и заключается в описании сильных сторон ООП.
В вашем же ответе, только ваше субъективное «Мы на ООП пишем лучше чем при процедурном подходе». Это как ответ на вопрос «В чём сильные стороны сюрреализма?» отвечать «Я плохой художник-импрессионист».
Ядро GNU/Linux содержит более тринадцати миллионов строк процедурного кода (взято тут). Если бы они не смогли управлять сложностью этого кода, он не был бы так популярен сейчас.
Более того, я действительно считаю что ответы на вопросы «Зачем использовать ООП?», «Зачем нам ООП?», «Почему используют ООП?» должны быть похожими и заключается в описании сильных сторон ООП.
В вашем же ответе, только ваше субъективное «Мы на ООП пишем лучше чем при процедурном подходе». Это как ответ на вопрос «В чём сильные стороны сюрреализма?» отвечать «Я плохой художник-импрессионист».
Ядро GNU/Linux содержит более тринадцати миллионов строк процедурного кода (взято тут). Если бы они не смогли управлять сложностью этого кода, он не был бы так популярен сейчас.
UFO just landed and posted this here
В том что ООП работает медленно и не всегда оправданно в highload, и что требование «все использовать только ООП» глупо.
UFO just landed and posted this here
«медленно» и «highload» понятия из совершенно разных областей.
bazhenov.me/blog/2009/06/28/performance-versus-scalability.html
blgo.ru/blog/2010/09/01/optimization-etc/
bazhenov.me/blog/2009/06/28/performance-versus-scalability.html
blgo.ru/blog/2010/09/01/optimization-etc/
Ну почему сразу убеждаю. Просто интересно, задавая этот вопрос, как понимаете это вы. Со стороны интервьюера так сказать.
Ядро GNU/Linux содержит более тринадцати миллионов строк процедурного кода
Немалая часть из которого, кстати, использует ООП.
Ядро GNU/Linux содержит более тринадцати миллионов строк процедурного кода
Когда-то давно я писал на сях. Потом перешёл на языки с ООП. Потом пришлось немного на Си вернуться и я заметил, что мне теперь на порядок лучше с ним работается. ООП головой по другому думать заставляет и не важно, есть ли в языке соответствующие конструкции.
обязательной составляющей адекватного ответа является упоминание резкого возрастания сложности поддержки проекта, созданного с использованием исключительно процедурного подхода, при росте его объема. Для многих это неочевидно
И для меня это не очевидно. Эта штуку (разделение на куски и скрывание кода и данных) в ООП называют инкапсуляцией. Но это никак не является брендом исключительно ООП. С помощью процедур (функций) и их вложения друг в друга прекрасно скрывается код. Разбиение на отдельные модули, тоже хорошо инкапсулирует. И без ООП.
ООП разве что соответствует мозгам среднего человека в моделировании какой-то предметной области. Моделирование зависит от самого мышления. ООП — это такой гуманитарный подход в моделировании. Близкий большинству людей.
>А что, на этот вопрос есть правильный ответ?
Конечно есть — наследование / инкапсуляция / полиморфизм.
Ну а здесь уже можно разговаривать на сколько у вас времени хватит.
Конечно есть — наследование / инкапсуляция / полиморфизм.
Ну а здесь уже можно разговаривать на сколько у вас времени хватит.
Попробуйте просто спросить людей, что они умеют. Что они делали и как. Вдруг человек не знает ООП, но гений SQL запросов. А вы об этом никогда и не узнаете.
Подбирать персонал тоже нужно уметь. Если чел. не работал с NoSQL — это не значит, что он плохой специалист и плохо будет выполнять свою работу.
Если Вы готовы брать джуниора и учить, то да. А если человека в проект, идущий полным ходом, то времени на изучение может и не быть.
Если чел работал с SQL и имеет представление о реляционных данных, то изучение NoSQL займет 1-2 дня, а то и меньше. Это не джуниор. Просто не на то смотрите…
Если я работал с Amazon SimpleDB, Azure Table Storage, Google BIgTable, но ничего не знаю о MongoDB — работал ли я с NoSQL? Могу сказать, что при изучении этих трех я практически НИЧЕГО нового не узнал. Чтобы разобраться ушло часа 2-3, потом работал в стандартном режиме.
Если я работал с Amazon SimpleDB, Azure Table Storage, Google BIgTable, но ничего не знаю о MongoDB — работал ли я с NoSQL? Могу сказать, что при изучении этих трех я практически НИЧЕГО нового не узнал. Чтобы разобраться ушло часа 2-3, потом работал в стандартном режиме.
Я с Вами согласен по сути. Но Вы судите по себе, другим же может понадобиться и больше времени на новую технологию. Время же стоит денег.
Но Вы судите по себе, другим же может понадобиться и больше времени на новую технологию. Время же стоит денег.
Верно. Вот именно определить сколько человеку потребуется времени и насколько он эффективен — и является целью собеседующего.
Встречаются еще кадры, которые имет немало сертификатов и много знают. Однако работать не любят. Могут, но не хотят. Все делают намеренно в 5 раз медленее чем на тестовом задании. Вот от таких никакого спасения нет.
Тут тоже ситуация не однозначная, расскажу историю. От одного моего друга, раньше работали вместе, человек феноменальной работоспособности, мне бы столько энергии. Предложили ему работу и условия хорошие и печеньки есть и рабочее место приличное, перешел. Работал первые пару месяцев даже больше чем нужно, в личное время, закрывал рабочие проекты, все как обычно, втягивался. И тут попадается проект чисто по его профилю, другие сотрудники компании в данной технологии ни ухом ни рылом и закрыть надо вчера. Шеф ему: «Ну ты постарайся, поработай в выходные, а если справишься с меня премия ну и вообще ты же понимаешь надо.» Надо так надо, работает ночью и в выходные, проект закрывается в срок, заказчик счастлив, а как же премия? А премии нет, ну заказов других мало было и еще 100500 причин. Потом за 3 месяца еще пара таких случаев, но поменьше. И товарищ просто забил, работает самый минимум, в остальное время книги по специальности читает, другие технологии учит, а работа так, пока другую не найдет. Вот и вопрос можно ли его в этом винить?
Пару лет назад, меня взяли в большой проект. Который существовал уже несколько лет и активно рос и развивался. При этом, я до этого писал только на пхп и работал с фреймворками пхп. А проект был на питоне и под джангой. Изучить питон и джангу, мне хватило где-то недели. И ещё недели три я вникал во все те тонны кода, написанные до меня и никак не документированные (даже комменты к классам и функциям не везде были, не говоря о строках кода).
Через год, я уже сам проводил собеседования и последующее обучение нового программиста.
Лично мне было проще(быстрее) выучить новые технологии, принципы работы, язык,… Чем понять логику реализованного функционала.
Через год, я уже сам проводил собеседования и последующее обучение нового программиста.
Лично мне было проще(быстрее) выучить новые технологии, принципы работы, язык,… Чем понять логику реализованного функционала.
Есть одна проблем с соотношением резюме/вакансия. Хозяева большинства резюме, если говорить об опытных сотрудниках, уже где-то работают и ищют новую работу имея одной из целей повысить з/п. В то время как количество вакансий — это абсолютно свободные места. Не понимаю о чем может говорить соотношение этих показателей.
>Как вам такая задача? По силам?
Конечно, нет. Большинство программистов знают один язык, одну базу данных, один какой-то способ графического представления интерфейса — и этого хватает чтобы получать «среднюю по рынку зарплату» (ну пусть будет 2к$). А те, кто глубоко изучает всякие там NoSQL, высокие нагрузки и отличия разных видов деревьев — делают это не ради +500$, а ради того, чтобы свалить в Европу или Америку и получать там в каком-нибудь Гугле +8к$.
Конечно, нет. Большинство программистов знают один язык, одну базу данных, один какой-то способ графического представления интерфейса — и этого хватает чтобы получать «среднюю по рынку зарплату» (ну пусть будет 2к$). А те, кто глубоко изучает всякие там NoSQL, высокие нагрузки и отличия разных видов деревьев — делают это не ради +500$, а ради того, чтобы свалить в Европу или Америку и получать там в каком-нибудь Гугле +8к$.
Поверьте, «Можно даже денег давать за хорошую рекомендацию.» это не новшество и не тонкий ход. В настоящее время это нормальный и распространенный подход к хантингу. Человек, который порекомендовал хорошего работника, получает денежное вознаграждение после испытательного срока кандидата.
Из первой статьи вывод такой: по всей видимости, спрос на IT-специалистов в Украине выше чем в России и в то же время там есть некоторый дефицит кадров. Планка по ЗП в Украине не намного ниже Москвы, так что выводы делайте сами.
Из первой статьи вывод такой: по всей видимости, спрос на IT-специалистов в Украине выше чем в России и в то же время там есть некоторый дефицит кадров. Планка по ЗП в Украине не намного ниже Москвы, так что выводы делайте сами.
Вот лично для меня, компетенция человека на вопросах «знает ли он SQL» и «знает ли он C++», только начинается. У нас тонна вопросов, которые приходится решать на VBA. Лично я ненавижу VBA. Но — увы. Так надо. Означает ли это, что нам жизненно необходим специалист по VBA?
Я, конечно, утрирую, но, на мой взгляд, компетенция программиста чисто на знании конкретных средств перевода с человеческого на машинный не заканчивается. Надо, как минимум, и человеческий знать неплохо.
Я, конечно, утрирую, но, на мой взгляд, компетенция программиста чисто на знании конкретных средств перевода с человеческого на машинный не заканчивается. Надо, как минимум, и человеческий знать неплохо.
Sign up to leave a comment.
У вас много денег? Мы все равно к вам не пойдем!