Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 607
Очень похожая и история, и ситуация :) Правда «Микрошу» родители купили в 89-м, а МК-61 года за три до того.
Состоятельные у Вас были родители, ибо «Микроша» тогда стоила 500 руб, как высококачественный катушечник.
Помню, году в 1995, когда контора на Дмитровском Шоссе, которая выдавала «Микроши» напрокат, собиралась закрываться из-за отсутствия спроса на них, я туда поехал и скупил пяток «Микрош» — отыгрался за своё испорченное детство!
Помню, году в 1995, когда контора на Дмитровском Шоссе, которая выдавала «Микроши» напрокат, собиралась закрываться из-за отсутствия спроса на них, я туда поехал и скупил пяток «Микрош» — отыгрался за своё испорченное детство!
Уверен что в конце концов вы выбрали какое-то «дорогое» направление и смогли в нем достаточно хорошо «продвинуться». Ваш профессиональный и жизненный опыт позволяет решать весьма сложные задачи по этому направлению т.к. зачастую требуются синтезированные решения на основе знаний и опыта полученных ранее из предыдущих направлений вашей деятельности. Вы умеете самостоятельно достаточно быстро обучаться по любой требуемой теме. Ваш возраст — гарантия стабильности, человек в районе сорока весьма стабилен т.к. к этому возрасту успевает приобрести необходимый бытовой минимум и лишиться многих недостатков присущих молодым. Возможно вы делаете все не так быстро как молодежь, но ваш результат гораздо «более» предсказуем. Ваш нынешний работодатель научился это понимать и ценить. Поздравляю — вы стали «труднозаменимым» и хорошо оплачиваемым сотрудником!
Я не выбрал «дорогое» направление. Я за чистую и незамутнённую идеологию. «Дорогие» направления для меня — это 1С и SAP. Но они противоречат моим убеждениям. Посмотрите, сколько 1С-ники получают и сколько Python-овцы и сколько «плюсовики» за совершенно различные по сути скилы (ох, ща на меня набросятся все скопом и закидают чем-то...).
Ну тогда хотя бы намекните — чем таким «недорогим» вы сейчас занимаетесь?
Последние 3 года программирую в основном на Python — вот на нём, так сказать, и «фигачу». Могу и на C++, но его последние 3 года почти не использовал и начал забывать.
Ну вот уже понятнее — питонистов сейчас на рынке примерно вчетверо меньше чем пхпешников к примеру, т.е. это уже чуть более «дорогой» язык для работодателей. Python — ЯП общего назначения, что именно вы на нем «фигачете», какой тип задач чаще всего решаете, какие фреймворки используете?
PHP не признаю из-за идеологии, хотя он так коммерчески успешен.
Ну что именно? Сайты пишем, естественно. Сейчас вынужденно перешел на django. Тип задач пока один: как «вправить мозги» этому django и заставить его делать то, что мне нужно, а не то, что он хочет.
Ну что именно? Сайты пишем, естественно. Сейчас вынужденно перешел на django. Тип задач пока один: как «вправить мозги» этому django и заставить его делать то, что мне нужно, а не то, что он хочет.
Просто интересно — что за идеология?
до сих пор не признаю ЖК
PHP не признаю из-за идеологии, хотя он так коммерчески успешен.
Слишком много «не признаю». Это показатель агрессивности, что ли. Упёртости? Вы можете не использовать инструмент, он вам может не нравиться, вы можете с ним принципиально не работать, а вот признание эти инструменты уже получили во всём мире.
Для работодателя это может быть показателем того, что когда по корпоративным стандартам нужно будет использовать какой либо инструмент, вы можете вдруг отказаться, ибо «не признаю».
Тем более про PHP вы сами написали, что уже всё изменилось. А для простого народа именно этот язык стал возможностью программировать в принципе из-за своей простоты. И он создавался не ради кода, а ради решения простых проблем на простых домашних страничках, с чем он великолепно справляется. Зачем ему тогда были потоки и объекты?
Подумайте, вы бы «признали» PHP, если бы рассматривали его в том контексте, в котором я его описал?
поддерживаю. Это один из моих тестов человека при приеме на работу :)
А я считаю совершенно правильным, когда человек занимается тем, что ему нравится, и старается не устраиваться на работу, которая ему не нравится.
И насчет PHP я с ним полностью согласен. PHP — большая помойка, благодаря этому он, кстати, и стал успешен.
И насчет PHP я с ним полностью согласен. PHP — большая помойка, благодаря этому он, кстати, и стал успешен.
обоснуете?)
Что конкретно нуждается в обосновании?
ваша странная позиция по поводу одно из самый мейнстримовых языков современности, например. Каждый раз вижу ваши комментарии и лезу минусовать, жаль что лишь однажды это можно сделать :)
Да, мой основной язык за последние 10+ лет большая помойка :) Нет целостности, нет даже формального описания синтаксиса (если не считать за него исходники транслятора). Десятилетие может прикручиваться элементарная для других языков фича, и то работать будет в строго определенном контексте.
В исходники его транслятора, как и (большинства) библиотек лучше не заглядывать во имя сохранения душевного спокойствия :)
А Вам почему бы не сделать форк и всё не исправить? Сделать свой PHP, который лучше?
Почему как обычно, куча ругающих, а желающих всё исправить так мало? Потому и продолжаем есть кактус?
Почему как обычно, куча ругающих, а желающих всё исправить так мало? Потому и продолжаем есть кактус?
А зачем плодить диалекты? Кроме того, если из текущей реализации PHP выбросить все те костыли и странности, которые в нем есть — получим язык, несовместимый с, собственно, тем, что сейчас подается, как PHP.
Зачем делать fork? Надо просто сделать бесплатную замену PHP->Python, и проблема решена. Сэкономим десятки человеко-лет.
надуюсь меня не полезете минусовать ;) если отвечу на вопрос «чем php плох?» ссылкой: habrahabr.ru/post/142140/
А я, как говорится, просто оставлю это здесь: habrahabr.ru/post/142140/
(Ой, выше, видимо, уже дали эту ссылку. Прошу прощения. Просто статья великолепна и отлично запомнилась многим)
(Ой, выше, видимо, уже дали эту ссылку. Прошу прощения. Просто статья великолепна и отлично запомнилась многим)
имхо сарказм(){ половина зарплаты 1С-ников — это возмещение морально-психологического ущерба программисту (с САПками, кажется, тоже самое, только компенсация выше)} (сам мурыжил Комплексную 1С год как админ, потом как программист).
В случае саперов там ещё вопрос в том, что на нашем рынке грамотный сапёр — зверь редкий, причем зачастую вложившийся в свое обучение. И высокая зарплата — суть компенсация оплаты редкости и отбивка затрат на образование.
Долго вкуривал, о каких «сапёрах» идет речь))
Ну если так уж и посудить, действительно грамотный 1С-ник — это тоже вещь нечастая. Чтобы и с пониманием своих действий, с толком, с расстановкой, с «обычными» программистскими навыками (мат., алгоритмы, БД этц), со знанием БУ и НУ (не только, где эти галки ставить, но и с пониманием законодательства), чтоб мог разобраться с этими желтыми книжками, в которых черт ногу сломит. Ну и плюс — это тоже всегда курсы, сертификаты на каждую конфу, курсы, обучения, повышения квалификаций, а тут и новая платформа… И снова курсы…
Ну и все в свободное время пишут собственную конфигурацию :-D
Ну если так уж и посудить, действительно грамотный 1С-ник — это тоже вещь нечастая. Чтобы и с пониманием своих действий, с толком, с расстановкой, с «обычными» программистскими навыками (мат., алгоритмы, БД этц), со знанием БУ и НУ (не только, где эти галки ставить, но и с пониманием законодательства), чтоб мог разобраться с этими желтыми книжками, в которых черт ногу сломит. Ну и плюс — это тоже всегда курсы, сертификаты на каждую конфу, курсы, обучения, повышения квалификаций, а тут и новая платформа… И снова курсы…
Ну и все в свободное время пишут собственную конфигурацию :-D
Я впитал за свою многолетнюю практику принцип того, что всего знать невозможно. Зато можно научиться быстро искать и обрабатывать/использовать информацию. Технологии меняются как слайды, и за ними никогда не угнаться. А работа всегда найдётся!
Общий смысл понятен (возраст аналогичный).
Мне не кажется правильным плясать от «мне нужно найти работу» (такую идею я вижу в вашем тексте). Если заниматься тем, что нравится и/или интересно, вопросы с работой обычно решаются сами в том или ином виде. Чего вы хотите от жизни? Зачем вам карьера?
Мне не кажется правильным плясать от «мне нужно найти работу» (такую идею я вижу в вашем тексте). Если заниматься тем, что нравится и/или интересно, вопросы с работой обычно решаются сами в том или ином виде. Чего вы хотите от жизни? Зачем вам карьера?
Ну смотрите, уважаемый frog. Мне, например, прям сейчас хочется делать один стартап, но он не принесёт денег (ну разве что небольшую прибавку к пенсии), и никому, кроме меня он не нужен. Кушать, тем не менее, хочется. Что делать? Правильно, искать работодателя, который занимается успешным стартапом, и у которого я мог бы работать, используя аналогичные технологии. Работаю на него и делаю своё в свободное от работы время. «Карьера» нужна, чтобы заработать немного денег на пропитание. Вот и всё.
Сначала зарабатываете (хоть на несчастной 1С :) за ограниченный промежуток времени (месяцы) сумму, которая позволит кушать следующие несколько месяцев. После этого уменьшаете объем работ за деньги и начинаете параллельно заниматься стартапом (либо осваивать новую технологию, которая затем позволит вам меньше работать и при этом получать больше денег. Или другим способом повышаете свою ценность).
На следующем цикле тоже самое, но с еще большем перекосом в сторону стартапа/самообразования. И т.д.
На следующем цикле тоже самое, но с еще большем перекосом в сторону стартапа/самообразования. И т.д.
Хм… хорошая идея, но 1С у меня на грани тошноты… не могу забыть, как она съела весь софт на access в одной конторе, где я работал. Эта мерзостная глюкалка, под которую еще можно до сих пор «программировать». Помню, какой у нее был язык программирования в 1997 году. Гадость. А SAP и остальные странные вещи, которые потенциально принесут деньги — я даже туда лезть не хочу, этот весь банковский софт…
Про 1С это просто пример. К стоматологу ходите, когда зуб заболит? Ну вот считайте, что это тоже самое. Появится резерв на несколько месяцев, сможете разорвать круг по которому ходите. Но всё-таки я не случайно выше спросил, чего вы хотите от жизни. Обычно всё упирается в это. Кто-то хочет красивую жизнь, кому-то пофиг на комфорт и интереснее себя менять — вариантов много, соответственно рецепты разные.
Не друг, у меня та же история жизни, почти 95% совпадение. Только я пошел в банковский бизнес. Так вот это трясина!!! Нечего в ней делать.
SAP не банковский софт, если уж на то пошло
1C как платформа сильно эволюционировала с тех пор в лучшую сторону.
То что вы описали — НЕ СТАРТАП!
А «мне нужно интересную работу» нормально? :) Но вообще мне кажется, что рассчитывать на то, что вопросы с работой решатся сами несколько наивно.
з этого списка внятно могу объяснить только «тупик», он же deadlock, потому что часто имею с ним дело
простите — но программист должен знать что такое машина тьюринга. пока же вы слишком хорошо описываетесь поговоркой
«Специалист подобен флюсу — его выпуклость однобока»
Я знаю, что такое «машина Тьюринга» — проходил в ВУЗе. Честн говоря, и что такое «конечный автомат» — знаю. Загнул немного.
Кому должен-то? Будет необходимость — всегда можно досконально разобраться.
к сожалению за это не платят. есть два человека — и один говорит «я это знаю», а второй «всегда можно разобраться» то как вы думаете — кого возьмут?
Вы так говорите, будто ответ очевиден и однозначен. ИМХО, человек, который может с чем угодно быстро разобраться, гораздо ценнее человека, который в ВУЗе выучил определение машины Тьюринга, но не может и шагу ступить за рамки того, что ему преподавали.
Честно скажу: ни разу не программировал под машину Тьюринга после ВУЗа, и лично с Тьюрингом не знаком и у него не работал.
Возможно, это и к лучшему, что вы с ним не знакомы, учитывая известные о Тьюринге факты из личной биографии.
Минусующим неплохо было бы ознакомиться с биографией Тьюринга сначала.
Кстати, Тьюринг был неплохим марафонцем.
Вы так говорите, как будто его личные предпочтения влияли на его профессиональную деятельность. Человек может быть талантливым в одном, а может быть талантливым и в двух. :-)
Вы не поверите, но тут многие знают его биографию
Может быть, минусуют как раз потому, что знают его биографию?
Тут вам не гос.дума, тут люди приличные сидят, на оскорблении других очков не заработаешь :)
Возможно, минусующие (меня, если что, среди них не было — прошу не обижаться) как раз знают те факты из биографии Тьюринга, на которые вы намекаете и просто огорчены вашей нетолерантностью.
Вопрос некорректный. Хороший руководитель принимает решение не по таким простым критериям.
По-моему, всё-таки важнее не знание машины Тьюринга, а умение очень быстро решать не совсем тривиальные задачи. Тут может помочь знание алгоритмов. Я тренировался на contest.yandex.ru/, пока не затошнило… слишком сложно.
Решать не совсем тривиальные задачи — это, безусловно, очень хорошо. Но вот странно в этом отношении читать про вопрос номер 10. Я ни разу не программист, но и то почти с ходу придумал какой-то вариант — похоже, даже рабочий. Возможно, именно это и хотел работодатель? Но тогда странно считать нормальным ответ «можно посмотреть в интернете»
>есть два человека — и один говорит «я это знаю», а второй «всегда можно разобраться» то как вы думаете — кого возьмут?
Вот есть два человека, один говорит «Да, я знаю А, Б и В», а второй говорит «Не знаю ничего из этого, но могу разобраться». Но когда понадобится Г, Д, Е, а потом еще немного от У, Ф и Х, то первый скажет «О-о-о, не-ет, я это не знаю», а второй скажет «Да не вопрос, могу разобраться» — и таки разберется, ибо этот скилл у него прокачан годами.
Вот есть два человека, один говорит «Да, я знаю А, Б и В», а второй говорит «Не знаю ничего из этого, но могу разобраться». Но когда понадобится Г, Д, Е, а потом еще немного от У, Ф и Х, то первый скажет «О-о-о, не-ет, я это не знаю», а второй скажет «Да не вопрос, могу разобраться» — и таки разберется, ибо этот скилл у него прокачан годами.
А это не факт, что у первого скилл «разобраться» тоже не прокачен. Просто так жизнь сложилась, что на момент собеседования он А, Б и В знал и даже помнил :)
Бывают такие программисты, с плохой памятью. Наступают на одни и те же грабли, приходят с вопросом, по которому месяц назад был ликбез. Возможно, они читали про А, Б, В, но в памяти не осталось ничего. Другой же программист, всё что прочитал, помнит. Может пересказать и применить.
Ой ли… вы можете «всегда разобраться при необходимости», только если у вас есть фундаментальные знания, понимание что где и как применяется, но вы слегка плаваете или забыли.
А если о какой-то области вы даже не слышали, то как говорят в наших краях «you don't know what you don't know». Посыл такой, что если вы не знаете какую-то область и где она примененяется, то встретив задачу, легко решаемую с помощью методов из этой области, вы будете выдумывать что-то свое и скорее всего гораздо менее эффективное, а иногда совершенно некорректное решение.
А если о какой-то области вы даже не слышали, то как говорят в наших краях «you don't know what you don't know». Посыл такой, что если вы не знаете какую-то область и где она примененяется, то встретив задачу, легко решаемую с помощью методов из этой области, вы будете выдумывать что-то свое и скорее всего гораздо менее эффективное, а иногда совершенно некорректное решение.
Когда вам в последний раз в практической работе помогло знание что такое машина Тьюринга?
А зачем? Вот, например, я в университете проходил МТ чуть ли не в первом семестре, потом, за прошедшие с того момента 19 лет, она мне не понадобилась. Зачем мне про неё помнить? С другими дисциплинами аналогично — я потихоньку забываю то, что не использую — в памяти остаются лишь какие-то общие моменты, без деталей.
Очень знакомо. Но на самом деле типичная ситуация для «пограничников».
Т.е. людей, которые можно сказать стояли у истоков компьютеров, в таком виде, в каком мы знаем их сейчас.
Которые начинали лет 20-25 назад. Прошли с DOS до Windows 8, и с ASM до JS.
И помнят времена, когда интернета еще не было)
Много опыта в самых разных вещах, но пройти собеседование при этом тяжело.
Как мне кажется, хорошим вариантом будет копать «долгоиграющие» технологии, вроде java.
С таким багажом опыта, знания будут набираться очень быстро. И востребованность рынком будет.
Т.е. людей, которые можно сказать стояли у истоков компьютеров, в таком виде, в каком мы знаем их сейчас.
Которые начинали лет 20-25 назад. Прошли с DOS до Windows 8, и с ASM до JS.
И помнят времена, когда интернета еще не было)
Много опыта в самых разных вещах, но пройти собеседование при этом тяжело.
Как мне кажется, хорошим вариантом будет копать «долгоиграющие» технологии, вроде java.
С таким багажом опыта, знания будут набираться очень быстро. И востребованность рынком будет.
Я не только помню времена, когда в России интернета ещё не было, я помню времена, когда в ФИДО нереально было попасть, и я не мог этого сделать несколько лет!!! Туда можно было попасть только через очень хороших знакомых и по большому блату! И я несколько лет сидел в «левых» сетках под названием Draftnet, еще какой-то net…
Соглашусь с первым абзацом. Я лично не прошёл бы ни одно типовое собеседование, про которые на хабре постоянно пишут. Но почему-то меня это не волновало и сейчас не волнует.
У меня похожий послужной список. Правда я поняла, что computer science — важная штука, нашла программы нескольких буржуйских вузов и по ним добирала и продолжаю добирать недостающие знания. Алгоритмы, особенно сложные, мне ещё предстоит осваивать. :)
Я думаю, что в статье вырисовывается проблема отсутствия фокуса и структуры — как в знаниях, так и в профессии — классическая ситуация самоучки.
Выход достаточно прост: выбрать конкретную область приложения усилий — все знать невозможно, да и не нужно. Почитать требования в вакансиях, ибо от питонистов на веб требуют одно, для сишников на железо требуют совсем другое, а для сапы — третье. И прочитать базисные книги по теме. Обычно после этого оказывается — «о, вот как называется то, что я использую много лет».
Для исчерпывающих ответов на те 13 вопросов, что приведены выше, нужно прочитать всего три книги (по протоколам инторнета, основным понятиям ООП-подхода, взаимодействие процессов) и пару статей (оптимизация запросов, алгоритмы сортировки).
А computer science нигде, по сути, не учат. Из того, что могут дать даже в самом хорошем учебном заведении на практике 90% не будет использовано, ибо в этой области все очень быстро меняется, и каким именно направлением кто займется — в вузе не знают. Поэтому один из основных скиллов программиста — быстрое самостоятельное обучение тому, что нужно.
Выход достаточно прост: выбрать конкретную область приложения усилий — все знать невозможно, да и не нужно. Почитать требования в вакансиях, ибо от питонистов на веб требуют одно, для сишников на железо требуют совсем другое, а для сапы — третье. И прочитать базисные книги по теме. Обычно после этого оказывается — «о, вот как называется то, что я использую много лет».
Для исчерпывающих ответов на те 13 вопросов, что приведены выше, нужно прочитать всего три книги (по протоколам инторнета, основным понятиям ООП-подхода, взаимодействие процессов) и пару статей (оптимизация запросов, алгоритмы сортировки).
А computer science нигде, по сути, не учат. Из того, что могут дать даже в самом хорошем учебном заведении на практике 90% не будет использовано, ибо в этой области все очень быстро меняется, и каким именно направлением кто займется — в вузе не знают. Поэтому один из основных скиллов программиста — быстрое самостоятельное обучение тому, что нужно.
Для исчерпывающих ответов на те 13 вопросов, что приведены выше, нужно прочитать всего три книги (по протоколам инторнета, основным понятиям ООП-подхода, взаимодействие процессов) и пару статей (оптимизация запросов, алгоритмы сортировки).
Для исчерпывающих ответов просто прочитать мало. Нужно или выучить это перед собеседованием, как перед экзаменом, или постоянно это использовать, вариться в темах.
Ну, не исчерпывающих, а тех, что обычно достаточны для работодателей, ибо собеседование таки не экзамен. Да, что-то выучить наверное придется, но немного, потому что остальное где-то использовали и просто запомнить название этого всего.
Вот, например
Задавали подобные вопросы. Когда-то читал, и даже ethernet-кадры(или пакеты? или фрэймы? — не помню :( ) анализировал из интереса, чтобы разобраться. Помню, что даже при простейших запрос-ответ по IP-адресу в пределах одной «шины» (то есть без DNS, без внешнего роутинга и т. п.) пакетов больше чем два, как это можно было бы предположить без хотя бы поверхностных знаний об OSI в приложении к Ethernet/IP/TCP/HTTP. Помню, что как минимум есть пакеты, подтверждающие доставку. Но вот однозначно описать, тем более с правильными названиями типа ack (или ask? — не помню), точно не смогу. Я не гожусь на должность веб-разработчика, оперирующего данными на уровне HTTP?
Опишите, какой обмен TCP/IP-пакетами производится при установлении HTTP-соединения.
Задавали подобные вопросы. Когда-то читал, и даже ethernet-кадры(или пакеты? или фрэймы? — не помню :( ) анализировал из интереса, чтобы разобраться. Помню, что даже при простейших запрос-ответ по IP-адресу в пределах одной «шины» (то есть без DNS, без внешнего роутинга и т. п.) пакетов больше чем два, как это можно было бы предположить без хотя бы поверхностных знаний об OSI в приложении к Ethernet/IP/TCP/HTTP. Помню, что как минимум есть пакеты, подтверждающие доставку. Но вот однозначно описать, тем более с правильными названиями типа ack (или ask? — не помню), точно не смогу. Я не гожусь на должность веб-разработчика, оперирующего данными на уровне HTTP?
ACK — acknowledge.
Ну для веб-разработчика этого точно не надо. А вот если нужно сетевой обмен на tcp писать, то желательно иметь представление о 3 way handshake и прочих «кишках» tcp. Хотя бы, что бы потом не выглядеть глупо в глазах сетевых админов с вопросом «почему у вас сеть так медленно работает?».
Ну для веб-разработчика этого точно не надо. А вот если нужно сетевой обмен на tcp писать, то желательно иметь представление о 3 way handshake и прочих «кишках» tcp. Хотя бы, что бы потом не выглядеть глупо в глазах сетевых админов с вопросом «почему у вас сеть так медленно работает?».
От веб-разработчиков, обычно, не требую знаний таких тонкостей в протоколах, достаточно общих слов, типа «запрос отсылается на сервер (apache/fpm/tornado/ngnix), там происходит обработка параметров, после чего отдается php/python интерпретатору» — этих знания для его работы вполне достаточно.
А вот для разработчика сетевых низкоуровневых сервисов, скорее всего, потребуют примерную раскладку — он обязан это знать, это его специализация. так же, как и отличие демонов, и основы взаимодействия процессов. с другой стороны, от него не потребуют знаний интерпретаторов php/python и методов оптимизации запросов к БД.
А вот для разработчика сетевых низкоуровневых сервисов, скорее всего, потребуют примерную раскладку — он обязан это знать, это его специализация. так же, как и отличие демонов, и основы взаимодействия процессов. с другой стороны, от него не потребуют знаний интерпретаторов php/python и методов оптимизации запросов к БД.
Очень часто требуют чуть ли не уровни сигналов в кабелях описывать.
от веб-разработчиков уровни сигналов? ни разу не встречал.
Утрировал, конечно. Но на уровне Etehrnet-пакетов (всякие ARP и т. п.) спрашивают, причем вакансия явно не предполагает хотя бы ручной разбор HTTP-запросов. Иногда ощущение складывается, что цель собеседований показать, что ты плохой разработчик, а потому на заявленную зарплату можешь не рассчитывать.
Наихудшая сложность сортировки это как минимум O(n!) — генерируем все перестановки, проверяем каждую на отсортированность.
Если так рассуждать, можно за O(n ^ n) прозаниматься херней и вообще максимальная сложность неограничена.
По-моему, вы забыли учесть сложность проверки последовательности на отсортированность. Так что либо O(n*n!), либо O(n^2*n!) (если не пользоваться транзитивностью сравнения).
Bogosort — рандомно раскидываем элементы в массиве и проверяем, не отсортировались ли они случайно.
Почему не может быть сортировки быстрее O(N * ln(N)), кстати, действительно полезно почитать и понять. А потом почитать про radix sort, который сортирует быстрее. Не для прохождения интервью, а потому что такой подход может пригодиться на практике.
Если мне не изменяет память, то быстрее O(N * ln(N)) не бывает сортировок, основанных на сравнениях элементов между собой, а не сортировок вообще.
А если массив уже отсортирован, какая будет временная сложность?
Если известно, что массив отсортирован — то 0. Если это нужно проверить, то зависит от алгоритма. Какой-нибудь пузырёк или простые вставки сработают за O(n). Большинство других алгоритмов не обратит внимания на отсортированность, и пойдёт по своему обычному пути. А наивный quicksort (берущий в качестве разделяющего элемента первый, а не средний) затратит n^2, если не свалится раньше по нехватке стека :)
Я про интервью. Если я правильно понял, сложность сортировки теоретически варьируется от O ( 0 ) до О (+∞)?
Лучше сказать от О(1) (надо ведь проверить условие, что он отсортирован), но, в общем, да. Зависит от конкретной постановки задачи и от алгоритма.
Что-то не соображу… реально сложность проверки отсортированности O(1), а не O(N)?
Как правило, конечно, O(N). Но, как я написал, «зависит от конкретной постановки задачи». Например, возможно, что конкретно этой функции сортировки передают не только длину массива, но и длину уже отсортированного начального куска (а почему бы и нет? Если в конкретном алгоритме она известна, то для сортировки очень даже может пригодиться). Тогда в лучшем случае (когда эта длина равна длине всего массива), сортировка проверит, что делать нечего, и вернётся. За O(1).
Это наверно в конце массива флажок ставить, если он отсортирован. И потом проверять только флажок.
Наверно это то, что хотели сказать комментом выше)
Наверно это то, что хотели сказать комментом выше)
Вопрос про какой алгоритм, radix sort? Так ему всё равно, сложность та же — O(N*k).
Массив из нулей и единиц (детерменировано, больше ничего нет) вы как будете сортировать?
Я тут полузабанен за срач в каком-то топике. Поэтому, я вам сразу скажу, что массив байтов сортируется за О(н). Массив нулей и единиц это самое простое просто, посчитать единицы.
Зачем его сортировать, если всю информацию можно поместить в два счётчика — количество нулей и количество единиц? Сделать это можно за время O(N).
вы правильно выставили тег «hr» — пока вы работаете не на себя, вы все еще человеческий ресурс. Как и любой ресурс вы изнашиваетесь и морально устареваете. Именно с такой позиции вас оценивают люди с деньгами.
Перестраивайтесь. Не закапывайтесь как страус в интересный код. Не надо подтягивать свои слабые стороны, компенсируйте их членами команды. Лучше используйте свои сильные. Делайте сервисы которые генерируют прибыль. Извините за прямоту но возраст штука упрямая, дальше будет хуже.
Перестраивайтесь. Не закапывайтесь как страус в интересный код. Не надо подтягивать свои слабые стороны, компенсируйте их членами команды. Лучше используйте свои сильные. Делайте сервисы которые генерируют прибыль. Извините за прямоту но возраст штука упрямая, дальше будет хуже.
Проблема тут в идиотизме собеседующих.
Опытных программистов, которые не хотят быть руководителями — очень трудно найти и они на вес золота.
Computer science и знание продвинутых алгоритмов крайне редко нужно, и для меня никогда не было определяющим.
У меня бы вы собеседование прошли. ;-)
Опытных программистов, которые не хотят быть руководителями — очень трудно найти и они на вес золота.
Computer science и знание продвинутых алгоритмов крайне редко нужно, и для меня никогда не было определяющим.
У меня бы вы собеседование прошли. ;-)
Я не то, чтобы не хочу быть руководителем — для меня это неважный фактор. Ну есть кем руководить — хорошо. Нету — и фиг бы с ним.
Опытных программистов, которые не хотят быть руководителями — очень трудно найти и они на вес золота.
Примерно как антиквариат. Когда он есть — все говорят, что «на вес золота», но если вдруг захочется продать — то покупателя не найти (а если найдёшь — предложит в 10 раз дешевле). Когда нет, но хочется купить — не найдёшь продавца, а когда найдётся — цена будет такая, что лучше бы и не искал. Как, вероятно, и с любым другим рынком с мизерными спросом и предложением.
Без обид…
Это называется кризис среднего возраста. Вы прошли большой жизненный путь, оглянулись назад, подвели итоги сделанной работы и задумались, что делать дальше (в этой статье всё отражено).
Основная проблема кризиса среднего возраста в том, что человек сталкивается с тем, что он не добился того, чего ожидал в 20-летнем возрасте. Эти умозаключения могут происходить на уровне подсознания, вызывая у человека волнение и депрессию в реальной жизни. Из кризиса всего два выхода — либо признать, что жизнь проё*на и дальше плыть по течению, либо кардинально всё поменять и начать с начала на основе полученного опыта.
Это называется кризис среднего возраста. Вы прошли большой жизненный путь, оглянулись назад, подвели итоги сделанной работы и задумались, что делать дальше (в этой статье всё отражено).
Основная проблема кризиса среднего возраста в том, что человек сталкивается с тем, что он не добился того, чего ожидал в 20-летнем возрасте. Эти умозаключения могут происходить на уровне подсознания, вызывая у человека волнение и депрессию в реальной жизни. Из кризиса всего два выхода — либо признать, что жизнь проё*на и дальше плыть по течению, либо кардинально всё поменять и начать с начала на основе полученного опыта.
А я не уловил депрессию в данном посте.
На мой взгляд автор счастливый человек.
На мой взгляд автор счастливый человек.
В принципе, да, но опасаюсь:
1. Остаться без дохода в связи с отсутствием позиционирования на рынке;
2. Остаться с нулевой (дефолтной) пенсией на старости лет.
1. Остаться без дохода в связи с отсутствием позиционирования на рынке;
2. Остаться с нулевой (дефолтной) пенсией на старости лет.
2. Отбросьте этот пункт, как думаете, заставит он вас активнее двигаться вперед и реализовывать свои идеи (надеюсь, которые потенциально окупятся и будут приносить доход)?
1. Решаемо
2. Так и будет, поглядите на поколение которое будет отдавать денег в пенсионный фонд. Их мало и они все тупее (значит дешевая низкоквафицированная рабочая сила). Пенсионному — просто неоткуда взять столько денег. Надежда только на себя.
2. Так и будет, поглядите на поколение которое будет отдавать денег в пенсионный фонд. Их мало и они все тупее (значит дешевая низкоквафицированная рабочая сила). Пенсионному — просто неоткуда взять столько денег. Надежда только на себя.
Да, я так назвал целое поколение. Если не согласны, прогуляйтесь до ближайшего знакомого преподавателя и спросите прав ли я или нет. Именно они лучше всего это ощутили. Умницы есть в любом поколении но в поколении которое сейчас выпускается из универов или выпустилось не так давно — их на порядки меньше. Не потому что они какие то лентяи или недоумки — просто когда нужно было заниматься их воспитанием их родители пытались удержаться на плаву. К слову это первый год, за последние лет 5-7 когда предыдущий поток студентов был слабее этих новеньких. Радует.
Уровень меняется из года в год так, что оценить средние способности совсем непросто. В этом году группа первокурсников слабая. В прошлом была заметно сильнее. В позапрошлом — средняя. И так далее. Пожалуй, можно сказать, что сильные стали сильнее, чем были раньше.
да почему не просто то)) оценки никто не отменял. У многих преподавателей со стажем в голове есть метрики, которые более менее уже устоялись, по которым они оценивают уровень знаний. Сейчас даже отличные преподаватели часто идут на сделку с самим собой, ибо поставить двойки всей группе — будут проблемы, а по факту то…
оценки никто не отменял
Уж что-что, но это явно не показатель…
Ну… уровень 5-6 сильных студентов группы слегка повышается. Уровень остальных — остаётся прежним: как тратили по часу на реализацию очереди на двух стеках, так и продолжают.
Можно ещё ориентироваться по сложности задач какой-нибудь олимпиады, например, ACM. По-моему, лет за 10 почти не меняется. И распределение результатов остаётся прежним.
Можно ещё ориентироваться по сложности задач какой-нибудь олимпиады, например, ACM. По-моему, лет за 10 почти не меняется. И распределение результатов остаётся прежним.
Не с того начали. Начните с конкурса при поступлении) Раньше был отбор, сейчас — формальность. Не с чего особо выбирать)
Кстати об этом: я дико извиняюсь, но мне для ответа на вопрос «как сделать очередь из двух стеков» понадобилось что-то около двадцати секунд (я не смотрел в интернетах и никогда раньше не сталкивался с такой задачей). Это же просто, разве нет?
И какая получается средняя сложность (в операциях push/pop) прохода одного элемента через эту очередь, если считать, что элементов обработано N, среднее число элементов в очереди K<N/2, а в начале и в конце очередь пуста?
Зависит от последовательности операций же. От ≈1 в лучшем случае до ≈К в худшем.
хмм… а разве не 2 (push+pop) на элемент если они приходят+уходят по одному-два, и до 4(2push+2pop) на элемент, во всех остальных?
(т.е. 4K операций)
(т.е. 4K операций)
Простите, но:
Потому и не кусают.
файлы редактировал упорно в FAR-е, и моя производительность не страдала от этого
Вчерашние выпускники отлично знают computer science и знают все эти загадочные слова, магические пассы и умеют внятно говорить.
Какая именно степень детализации имеется в виду? Мой рассказ может растянуться на целый день, а время у нас ограничено.
Кажется, нет, не общие. Или общие. Забыл уже, в общем.
mike1
Потому и не кусают.
Здравствуйте, уважаемый Дмитрий! Не ожидал, что мой скромный пост всколыхнёт такой трафик, что даже затронет такого гуру. :)
На самом деле, я для C++ использую MS Visual Studio, для Python — PyCharm. Но реально, по привычке иногда возвращаюсь к FAR-y- уж очень там удобно всё…
Что касается fork-ов — ну, конечно, я уж не до такой степени ignorant — знаю, что у них общее, что нет. Это так, для примера написано…
На самом деле, я для C++ использую MS Visual Studio, для Python — PyCharm. Но реально, по привычке иногда возвращаюсь к FAR-y- уж очень там удобно всё…
Что касается fork-ов — ну, конечно, я уж не до такой степени ignorant — знаю, что у них общее, что нет. Это так, для примера написано…
Так что же вы голову морочите? :) «Иногда возвращаться» и «использовать вместо IDE» — разные вещи. Вообще, у меня после этого вашего комментария сложилось впечатление, что вы занимаетесь самобичеванием.
Не, я не использую его вместо IDE, скорее вместе с IDE.
Самобичеванием — к сожалению, да, занимаюсь. Может быть, я представляю себя здесь хуже, чем я есть на самом деле, но это же полезно! Почему нет?
Самобичеванием — к сожалению, да, занимаюсь. Может быть, я представляю себя здесь хуже, чем я есть на самом деле, но это же полезно! Почему нет?
Потому что не выгодно для устройства на работу. Зачем кому-то более плохой или депрессивно настроенный сотрудник, тем более в отношении себя? Если есть те, кто свеж и уверен в себе, имея при этом значительно меньший опыт? В Штатах, насколько я читал, важно, чтобы сотрудник умел себя хвалить и преподнести, иначе кому это делать и как узнать, чем он хорош? Ну да, HR вместе со спецом могут потратить время на то, чтобы разобраться, а могут и не потратить.
В Штатах, насколько я читал, важно, чтобы сотрудник умел себя хвалить и преподнести, иначе кому это делать и как узнать, чем он хорош?
На протяжении большой части жизни нам вдалбливали в голову, что хвастаться плохо. Что хорошего специалиста работа сама найдет. И т. д., и т. п.
Да, так и есть.
А избавиться от этого очень сложно, если вообще возможно.
Возможно. Проверено на себе. Постепенно. Просто хвалите себя и других за всё, что можно. Делайте комплименты. В том числе себе. Вы делаете хорошо? Значит можно гордится своей работой и просто сказать — я доволен тем, что сделал и готов рассказать об этом.
В результате в Штатах все меньше специалистов и все больше гуру самопиара. Естественный отбор.
В здоровом теле здоровый дух, а навыки нужно не только иметь, но и уметь их показать, помоему вполне нормальная ситуация. В Штатах все в порядке с индустрией командной разработки, в отличии от той же России, в которой при наличии талантливых одиночек програмных продуктов не производят (если сравнить со Штатами).
Да, кстати, может, и единичку в нике как-то объясните рационально? При кажущейся неважности такие вещи ведь свидетельствуют об аккуратности и дотошности — наиважнейших качествах кандидата.
Я понимаю, что интерьвюеру за короткое время надо максимально понять человека. Но зачастую перегибают с такими психологическими нюансами (ну признайтесь, вы же не профессиональный психолог). В результате, на основе ответа «mike был занят», вы можете сделать не верные заключения типа «не амбициозен», «без фантазии». Это будет несколько надуманно, если человек просто не отнесся серьезно в момент регистрации к выбору ника и уж никак не мог подумать, что это может как-то повлиять на решение о его принятии или не принятии на работу.
mike был занят, к habrahabr-у присоединился поздно, но очень хотелось быть «майком». Не хочу быть непонятно кем и брать алиасы. Я не скрываюсь ни от кого. Индекс 1 вполне меня устраивал, никаких отрицательных эмоций не вызвал. «Не амбициозен», «без фантазии» — абсолютно верно! Но не думаю, что такой ник влияет на решение о принятии на работу.
Сентенцию об аккуратности и дотошности не очень понял, уважаемый Дмитрий. How does one depend on the other?
Сентенцию об аккуратности и дотошности не очень понял, уважаемый Дмитрий. How does one depend on the other?
типа как петр1 или екатерина2 (на престол взошли поздно, все ники заняты). мне показалось, в ответе dk есть доля иронии ;)
Кто-то моет руки перед едой, а кто-то при посещении столовой, когда берет поднос, плюхает хлеб прямо на него, не подстелив даже салфетки. Или добавляет единичку к логину, когда видит, что такой уже занят. Элементарная гигиена, никакой иронии. Гигиена для программиста — это все, это образ мышления, она во всем прослеживается. Тот, кто не моет руки, пишет с ошибками и т.д., скорее всего налепит в коде костылей (особенно если прослеживается еще симптом «нет времени») и наговнокодит так, что последователям проще потом будет все с нуля переписать (хотя этот же человек в другой области, не связанной с кодингом, может очень неплохо креативить или помогать брейнштормить). Я в данном случае не имею никого конкретного в виду, просто излагаю свои убеждения.
Спасибо за разъяснение, Дмитрий, понял Ваш образ мысли.:) Даже не пришло такое в голову, если честно, когда регистрировался здесь :)
вот жеж. любопытно, какие умозаключения можно сделать об образе мышления программистов, которые пользуются логинами, которые, вообще говоря, они даже не сами придумали? ;)
Немного не понял мысли. Прошу прощения, а на чем основаны эти Ваши убеждения?
Я например не вижу никакой корреляции между гигиеной, частотой опечаток и ошибок в текстах, и качеством кода программиста. И вообще не понимаю, при чем ко всему этому ник с единицей. Может быть поясните?
Я например не вижу никакой корреляции между гигиеной, частотой опечаток и ошибок в текстах, и качеством кода программиста. И вообще не понимаю, при чем ко всему этому ник с единицей. Может быть поясните?
Основаны на опыте и личных наблюдениях. Если у кого-то есть обратные наблюдения — пожалуйста, расскажите эти истории в красках.
А каков размер выборки в Ваших личных наблюдениях? Сколько примерно человек Вы подвергли анализу по этим критериям? Я к тому, что если выборка не велика, то это могло привести к поспешным выводам.
У меня таких наблюдений нет, не проводил. Но если бы была явная взаимосвязь, то наверняка заметил бы. Да и не только я… Уверен, что если это было бы правдой, то программистов на собеседованиях просили бы писать диктант. ))
У меня таких наблюдений нет, не проводил. Но если бы была явная взаимосвязь, то наверняка заметил бы. Да и не только я… Уверен, что если это было бы правдой, то программистов на собеседованиях просили бы писать диктант. ))
Попробую рассуждать логически. С одной стороны действительно, существует поговорка: «неграмотно пишешь — неграмотно думаешь». Это может быть и верно, но только если ставится задача излагать мысли на бумаге. Тут такое дело, можно выбирать специализацию: то ли литературные тексты писать, то ли код, то ли еще что. Можно равномерно развивать несколько скилов одновременно, но если больше вкладывать только в один из них, то и достичь можно большего.
Для профи нормально быть мастером только своего дела, и отставать в других областях, в том числе и во владении таким сложным языком как русский. Например, Александр Сергеевич Пушкин писал на русском языке с ошибками… Исследователи объясняют это так, мол, гений, спешил, старался зафиксировать ускользающий образ. Вот и с программистами тоже может быть где-то так. ))
Для профи нормально быть мастером только своего дела, и отставать в других областях, в том числе и во владении таким сложным языком как русский. Например, Александр Сергеевич Пушкин писал на русском языке с ошибками… Исследователи объясняют это так, мол, гений, спешил, старался зафиксировать ускользающий образ. Вот и с программистами тоже может быть где-то так. ))
Чтобы тебя назвали гением и прощали огрехи, это надобно сперва заслужить. Быть может и не Пушкиным, но хотя бы Маяковским с его вездесущим интонационным «тире», которое грамматикой не предусматривается.
И конечно если человек торопится что-то сформулировать, он может ошибаться и его надобно простить, если это не его основная профессия — грамотно писать.
Но вот когда человек пишет безграмотно постоянно, причем ошибки делает глупые и детские, а исправляться не видит надобности, это означает как минимум (по моему субъективному мнению) две вещи:
1. Он не следит за своим интеллектуальным имиджем (как-то принято считать, что грамота — удел интеллектуалов)
2. Он привык не проверять то, что он делает. То есть делать «тяп-ляп». (Написал — перечитай, прежде чем читать будут другие)
Разумеется, из всех жизненных правил случаются исключения. Но обычно всё именно так.
И конечно если человек торопится что-то сформулировать, он может ошибаться и его надобно простить, если это не его основная профессия — грамотно писать.
Но вот когда человек пишет безграмотно постоянно, причем ошибки делает глупые и детские, а исправляться не видит надобности, это означает как минимум (по моему субъективному мнению) две вещи:
1. Он не следит за своим интеллектуальным имиджем (как-то принято считать, что грамота — удел интеллектуалов)
2. Он привык не проверять то, что он делает. То есть делать «тяп-ляп». (Написал — перечитай, прежде чем читать будут другие)
Разумеется, из всех жизненных правил случаются исключения. Но обычно всё именно так.
Если бы существовала малейшая связь между грамотностью и кодом, это бы давно заметили, и в состав собеседования во всех конторах входил бы диктант по русскому или другому местному языку.
Ответы по пунктам.
1. Специалисту не нужно следить за своим «интеллектуальным имиджем», чтобы оставаться профи. Это личное дело какой имидж иметь, и не факт что это хоть как-то связанно с выполнением рабочих обязанностей.
2. Он не привык уделять внимание неважным вещам, таким как проверка нюансов правописания никому ненужных текстов. Если при этом он полностью отдается своей основной работе, то есть все свои личные ресурсы бросает туда, то это как раз-таки нормально для профи.
Ответы по пунктам.
1. Специалисту не нужно следить за своим «интеллектуальным имиджем», чтобы оставаться профи. Это личное дело какой имидж иметь, и не факт что это хоть как-то связанно с выполнением рабочих обязанностей.
2. Он не привык уделять внимание неважным вещам, таким как проверка нюансов правописания никому ненужных текстов. Если при этом он полностью отдается своей основной работе, то есть все свои личные ресурсы бросает туда, то это как раз-таки нормально для профи.
Непосредственной связи между грамотностью и кодом, разумеется, нет. Но разве вам кажется абсурдной мысль о том, что человек, аккуратно пишущий код, будет стремиться к аккуратности во всём? Мне она кажется вполне естественной.
«Следить за интеллектуальным имиджем» — действительно не вполне корректная формулировка. Вернее было бы сказать «иметь интеллектуальный имидж». Смысл разницы сводится к отличию между «казаться» и «быть». Как сказал профессор Преображенский, «я — московский студент, а не Шариков». И я еще не видел профи, который был бы неспособен внятно излагать свои мысли. Обычно этот навык так или иначе приходит с опытом. А грамотное письмо — просто часть этого навыка. Согласитесь, если некоторый момент в вашем поведении может сыграть вам на руку или наоборот — зарекомендовать вас негативно, вы же постараетесь этот момент обратить в свою пользу, так ведь? Вы сами, к примеру, пишете грамотно. Так зачем же лицемерить?
А вот по третьему пункту, я совсем не соглашусь. «Неважных вещей» в нашем деле не бывает. В этом я убедился многократно. Порой знания, которых мне удалось «нахвататься» и в дизайне интерфейсов, и в юзабилити, и еще черт знает в чём вплоть до типографики (уважаю и порой использую LaTeX) очень упрощали мне работу. На днях, к примеру, коллега получил дизайн-документ для UI, в котором были прописаны расстояния между baseline-ами строк, а он думал, что это — расстояния между нижними границами текстовых блоков. Причем нигде не было специально указано, что это — baseline-ы. Так бы он неверно и сверстал, если бы я ему не объяснил… И легко могу представить себе, что придется набивать текстовые сообщения в программе самому, без помощи аналитиков. И какой же «бледный вид» при этом я буду иметь, если напишу в неположенном месте «ться» или, скажем, бизударную гласную зевну? ;)
В любом случае, человек, сознательно отказывающийся от аккуратности при письме, просто не любит родной язык, что, мне кажется, не умно. И это от профессии никак не зависит. И, кстати, «никому ненужные тексты» лучше вообще не писать, раз они не нужны. А если они всё же нужны, то надо и писать их грамотно.
«Следить за интеллектуальным имиджем» — действительно не вполне корректная формулировка. Вернее было бы сказать «иметь интеллектуальный имидж». Смысл разницы сводится к отличию между «казаться» и «быть». Как сказал профессор Преображенский, «я — московский студент, а не Шариков». И я еще не видел профи, который был бы неспособен внятно излагать свои мысли. Обычно этот навык так или иначе приходит с опытом. А грамотное письмо — просто часть этого навыка. Согласитесь, если некоторый момент в вашем поведении может сыграть вам на руку или наоборот — зарекомендовать вас негативно, вы же постараетесь этот момент обратить в свою пользу, так ведь? Вы сами, к примеру, пишете грамотно. Так зачем же лицемерить?
А вот по третьему пункту, я совсем не соглашусь. «Неважных вещей» в нашем деле не бывает. В этом я убедился многократно. Порой знания, которых мне удалось «нахвататься» и в дизайне интерфейсов, и в юзабилити, и еще черт знает в чём вплоть до типографики (уважаю и порой использую LaTeX) очень упрощали мне работу. На днях, к примеру, коллега получил дизайн-документ для UI, в котором были прописаны расстояния между baseline-ами строк, а он думал, что это — расстояния между нижними границами текстовых блоков. Причем нигде не было специально указано, что это — baseline-ы. Так бы он неверно и сверстал, если бы я ему не объяснил… И легко могу представить себе, что придется набивать текстовые сообщения в программе самому, без помощи аналитиков. И какой же «бледный вид» при этом я буду иметь, если напишу в неположенном месте «ться» или, скажем, бизударную гласную зевну? ;)
В любом случае, человек, сознательно отказывающийся от аккуратности при письме, просто не любит родной язык, что, мне кажется, не умно. И это от профессии никак не зависит. И, кстати, «никому ненужные тексты» лучше вообще не писать, раз они не нужны. А если они всё же нужны, то надо и писать их грамотно.
Но разве вам кажется абсурдной мысль о том, что человек, аккуратно пишущий код, будет стремиться к аккуратности во всём? Мне она кажется вполне естественной.
Нет, мне эта мысль не кажется абсурдной. Такое иногда бывает. Но эта мысль и не кажется естественной. Более того, тот, кто стремится в аккуратности во всём, неизбежно растрачивает много сил и времени на ненужные для его основной работы дела.
И я еще не видел профи, который был бы неспособен внятно излагать свои мысли. Обычно этот навык так или иначе приходит с опытом. А грамотное письмо — просто часть этого навыка.
С этим согласен. Но поспешу добавить, что важно, в каких случаях профи пишет или не пишет грамотно. Если это коммент в коде или техническая документация, то да, там это важно. А если он пишет с ошибками на каком-нибудь форуме или в чате, то это без разницы. Это нормально, что он не вкладывает ни малейших усилий в незначащие тексты, не проверяет их по три раза и т.д.
«Неважных вещей» в нашем деле не бывает. В этом я убедился многократно.
Неважные вещи еще и как бывают. Новые знания в области дизайна интерфейсов, в типографике и т.д. — это как раз полезные знания, тем более для IT профи. Но вот например писать комменты в социальных сетях на всякие ерундовые темы — это относительно неважное занятие, и там нет потребности проверять написанное по нескольку раз, сверяясь со справочником русского языка в сложных случаях.
В любом случае, человек, сознательно отказывающийся от аккуратности при письме, просто не любит родной язык, что, мне кажется, не умно.
Сознательно не отказывается. Это несознательно. Когда человек спешит донести другому свою как ему кажется важную мысль где-нибудь в чате, он в это время может меньше всего думать о родном языке или «интеллектуальном имидже», и это нормально. Да и вообще опечатки — нормальны. У очень грамотного и внимательного человека они тоже неизбежно будут, хотя и существенно меньше.
Или добавляет единичку к логину, когда видит, что такой уже занят.
А если пятерку добавляет? :)
Ой, а что же мне тогда делать с моими четырьмя единичками. Вот уж никогда не думала, что такое может быть важно. :)
Да, кстати, может, и единичку в нике как-то объясните рационально?
С точки зрения психологии цифры в нике говорят об утилитарности мышления. Для программиста это нормально.
Да какая утилитарность? От таких единичек и возникают в коде при рефакторинге переменные вида «count1» и т.д. Единичка в нике (при занятом безъединичном) ИМХО свидетельствует о том, что человек рано сдается и идет по самому простому пути, а не пытается найти что-то универсальное, т.е. = говнокод
x1-x2 vs x_begin-x_end
Не обязательно. Может быть данному человеку нравятся цифры, возможно, нравится именно цифра 1. Мало ли какие ассоциации возникли, когда он ник выбирал… например, царь Петр Первый, и т.д. Такие вещи хорошо прослеживаются при анализе тысяч ников и сопоставлении с психологическими портретами их обладателей. Психология с этим работает.
Диагнозы по никам и аватаркам — весьма странное занятие.
Если нужно ставить диагнозы, то еще и не по такому ставят… Мой знакомый психолог, кстати, кандидат наук, специализировался на рисунках, которые люди от нечего делать бессвязно рисуют когда им скучно, ну там на лекциях, собраниях и т.д.
Впрочем, в данном случае это не диагнозы, а что-то типа классификации.
Впрочем, в данном случае это не диагнозы, а что-то типа классификации.
Не кожу я с единичками! Не кожу! Ну как вам это доказать? Я могу вам на мыло прислать образцы. У меня английский — advanced, и я знаю, как верно называть переменные и классы. Я их называю правильнее, чем многие индусы…
Всё так, и дальше будет хуже. Знаю по себе, так как начинал еще с перфокарт. Подозреваю, что наниматели смотрят на 40-50-60 летнего соискателя и думают: «уж я-то в его возрасте буду ого-го каким специалистом/ученым/предпринимателем, а это какой-то неудачник». Выход один — глубоко копать какую-либо тему и сделать в ней себе имя. Например, создать продукт, которым все будут пользоваться и который будет на слуху. Жаль, что я поздно спохватился.
Это опасно — можно угрохать полжизни и так и не «поймать волну».
целиком и полностью поддерживаю. Осознание того что вещи которые вчера давались за пол дня, с возрастом могут занимать неделю — мало кто осознает. И что он неконкурентоспособен будет даже если удвоит свою производительность и скил. Все хотят заниматься своим любимым делом а не менять парадигму способа получения дохода. На реальность им начхать.
Осознание того что вещи которые вчера давались за пол дня, с возрастом могут занимать неделю — мало кто осознает.
Это какие например?
Дай ка я перепишу этот модуль…
Это образно. Ну если уж сильно чтото интересно то например деятельность связанная с изучением чего то нового… Да, как пример «перепишу модуль» или дали исходнинки — сказали разобраться и дописать. Люди после 30-40 начинаю приобретать косность мышления. Это биология.
Это не биология. Это лень.
Я тоже так думал пока тридцатник не стукнул.
Мне почти сорок. И я всё больше убеждаюсь, что мозг — это мышца. Её нужно тренировать. Иначе — да, коснеет.
У всего в этом мире есть свой ресурс.
Мозг — гибкая структура. Он вытесняет неиспользуемые связи.
вернемся к этому разговору лет через 5-10)) Когда биология расставит все по своим местам))
Давайте вернёмся сейчас, чтобы не ждать. Мне будет 40 в следующем месяце. Пока что не замечаю на себе никаких упомянутых признаков. По отдельным знакомым замечаю даже в 30. Причём, это очень бросается в глаза — биология тут непричём, человек натурально сам решает что ему сколько-то стукнуло и ставит на себе крест в том или ином виде. Чисто психологический аспект. Есть знакомый, которому за 50 — он бодрее и активнее многих 30-летних, по крайней мере со стороны.
(да, естественно речь сейчас не идёт о реальных тяжелых заболеваниях — они могут возникнуть в любом возрасте)
(да, естественно речь сейчас не идёт о реальных тяжелых заболеваниях — они могут возникнуть в любом возрасте)
Вы счас мне что показать то хотите?)) Что чем дальше тем моложе? Или ваши органы не подвергается износу? )) Я не врач, но меня терзают смутные сомнения))
Я хочу сказать что психологическое состояние как правило оказывает несопоставимо большее влияние, чем износ органов. Поэтому серьезно беспокоиться стоит о нём, а вовсе не о возрасте.
Любопытно. Ссылки на результаты медицинских исследований в студию пожалуйста.
Зачем? (тем более, что не представляю как подобные исследования могли бы быть проведены — объективные формальные критерии для психологического состояния людей будет весьма трудно сформулировать).
Я вижу вокруг себя прямые и обратные примеры в достаточном количестве, чтобы иметь уверенность в том, что сказал. А остальные пусть сами решают как им жить.
Я вижу вокруг себя прямые и обратные примеры в достаточном количестве, чтобы иметь уверенность в том, что сказал. А остальные пусть сами решают как им жить.
Ну у нас тут технический ресурс. Научные доказательства -приветствуются. А человек существо интересное — часто выдает желаемое за действительное. Потому и спрашиваю)
К сожалению, о психологическом состоянии в технических терминах говорить не получится — в первую очередь потому, что одни и те же слова и фразы разные люди пропускают через свой собственный опыт и своё текущее состояние. Придавая им подчас противоположные значения. Если бы это было не так, все бы становились счастливыми после пары визитов к психотерапевту :)
Подвергаются. Но обычно до 50 лет, если человек ведёт здоровый образ жизни, все органы, включая мозг, у него в порядке.
Как и с мышцами, тут нужен комплексный подход. Скажем, правильное питание.
К стати, в молодости и мышцы тоже растут быстрее.
К стати, в молодости и мышцы тоже растут быстрее.
Ну не знаю. После 30 замечаю за собой в таких ситуациях наоборот повышение эффективности. Перестаю рыть вглубь и вширь больше чем необходимо для поставленной задачи. Сказано «переписать модуль (незнакомой системы)» — разбираюсь в его входах и выходах, интерфейсах, контрактах и т. п., не обращая внимания на всю систему. Иногда сильно заставлять себя приходится так работать, не поддаваясь искушению «тут не модуль переписывать надо, а всю систему», но когда получается, то эффективность заметно повышается.
Я бы не сказала, что с возрастом стало сложнее воспринимать новый материал. Если человек занимается прокачкой скиллов постоянно, то и мозг у него натренирован.
Это путь вникуда. Рано или поздно вы начнете тупить. Вы будете это понимать но ничего сделать не сможете
Тогда уже можно выходить на пенсию и выращивать цветочки на приусадебном участке. :)
Не понимаю откуда оптимизм и радужные надежды по поводу пенсии)) Вы реально думаете что вас ждет пенсия на которую сможете прожить?:)
Ну живёт же как-то остальной народ. Хорошо, будем не цветочки выращивать, а картошку и прочие овощи. :)
Вот человек)) Пенсионный фонд лет через 10-15 предложит всем потуже затянуть пояски ибо денег у них нет. То что вы сейчас отдаете со «зряплаты» управляется крайне неэффективно. Чтото около 8% годовых в плюсе. Вычтите инфляцию и увидите что они работают вам в минус. Добавьте к этому шикарные здания пенсионных фондов в вашем городе (у нас в Уфе он просто шикарен, не говоря уже про обстановочку). Ну и на десерт демографическая яма с 90-х годов. Я по моим оптимистичным прикидкам 1 работяга в нашей стране будет кормить 5-6 пенсионеров. Можете продолжать игнорировать это а потом удивляться и злиться а можете пытаться адаптироваться ища источники доходов которые будут вас кормить с вашим минимальным участием.
У меня есть пара знакомых программистов, которым уже по 60. Пока продолжают работать. Один дотнетчик, а второй (точнее вторая) не знаю чем занимается.
Тут есть обратная сторона медали: возможность закопаться в своем продукте и выродиться в маразматика. Это легко и просто, когда человек пилит что-то свое, оно приносит деньги, успех. Зачем шевелиться? А как раз самое время чтобы не просто шевелиться, а бежать.
Соглашусь с комментарием о проблеме самоучки и «отсутствия фокуса». Конечно, измыслить писать длинные соображения на тему дурных способов собеседования, неспособных отобрать очевидно толковых людей, но, но…
Сейчас программирование настолько разнообразно, что можно попытаться найти хорошую работу при наличии любого набора навыков. Опытный работнк, прошедший ещё Фидонеты, может, например, попробовать влезть в какие-нибудь унаследованные системы.
Но для работы в «меинстримном» секторе нужны «меинстримные» знания. Скажем, хороший древнегреческий математик обладал совсем другими знаниями, нежели выпускник средней школы. Например, они умели работать с коническими сечениями и умели определять площади криволинейных фигур методом исчерпывания. Ну и с арифметикой у них было неплохо (вспомним Диофанта). Уверен, многие подобные задачи поставят нынешнего школьника в тупик, зато он владеет сегодняшним аппаратом, недоступным древнему греку.
Аппарат, кстати, включает в себя и язык: может, мы с коллегой не круты в программировании, но хотя бы говорим на общем языке, уже на чём спасибо. То есть мне с сегодняшним выпускником проще решить общую задачу, чем с Архимедом. Такие дела.
Сейчас программирование настолько разнообразно, что можно попытаться найти хорошую работу при наличии любого набора навыков. Опытный работнк, прошедший ещё Фидонеты, может, например, попробовать влезть в какие-нибудь унаследованные системы.
Но для работы в «меинстримном» секторе нужны «меинстримные» знания. Скажем, хороший древнегреческий математик обладал совсем другими знаниями, нежели выпускник средней школы. Например, они умели работать с коническими сечениями и умели определять площади криволинейных фигур методом исчерпывания. Ну и с арифметикой у них было неплохо (вспомним Диофанта). Уверен, многие подобные задачи поставят нынешнего школьника в тупик, зато он владеет сегодняшним аппаратом, недоступным древнему греку.
Аппарат, кстати, включает в себя и язык: может, мы с коллегой не круты в программировании, но хотя бы говорим на общем языке, уже на чём спасибо. То есть мне с сегодняшним выпускником проще решить общую задачу, чем с Архимедом. Такие дела.
Выпадение из волны рынка — это такая плата за приятную свободнотворческую работу, где не приходится задумываться о будущем. Можно принять позицию «это весь мир сошёл с ума» и далее получать отказы, однако потребность заучивать «скучные» сегодняшние реалии для получения достойной зарплаты от этого не исчезнет.
Народ, объясните мне бестолковому, что такое «computer science»?
Википедия говорит, что это просто «Информатика».
Если употреблять «computer science», вместо «информатика», то становишься крутыми прогером и зарплата вырастает?
Объясните, пожалуйста.
Википедия говорит, что это просто «Информатика».
Если употреблять «computer science», вместо «информатика», то становишься крутыми прогером и зарплата вырастает?
Объясните, пожалуйста.
Computer science включает в себя намного более широкий спектр отраслей знания, чем информатика в классическом советском понимании, как нас всех научили еще в школе (и современные представления об информатике из школы). У людей в сознании слово «информатика» чаще всего ассоциируется с одним курсом в школе или университете. Однако сами понимаете, в том же университете к информатике относят еще огромную кучу курсов и предметов.
Спасибо.
Но взять туже Википедию и русскоязычная версия "Компьютерные науки". Это ведь так просто, не правда ли?
Я конечно понимаю, что программирование и всё смежное с компами и английский язык не разделимы.
Но в последнее время уже как-то надоедает повсеместная англонизация (так вроде это называется), тем более есть прекрасный русскоязычный перевод «Компьютерные науки», которое прекрасно говорит само за себя. Или просто «Информатика».
У ТП — всякие салинги, принты и ещё куча слов… (ни в коем случае не приравниваю, а просто намекаю :D )
Завтра начнут переводить «Высшую математику» и «Русский язык»?
Но взять туже Википедию и русскоязычная версия "Компьютерные науки". Это ведь так просто, не правда ли?
Я конечно понимаю, что программирование и всё смежное с компами и английский язык не разделимы.
Но в последнее время уже как-то надоедает повсеместная англонизация (так вроде это называется), тем более есть прекрасный русскоязычный перевод «Компьютерные науки», которое прекрасно говорит само за себя. Или просто «Информатика».
У ТП — всякие салинги, принты и ещё куча слов… (ни в коем случае не приравниваю, а просто намекаю :D )
Завтра начнут переводить «Высшую математику» и «Русский язык»?
Уходить в сторону великодержавного шовинизма тоже не стоит, я думаю. В разговорной речи среди программистов и людей из it области говорить «компьютерные науки» просто не принято, звучит достаточно коряво, так как нет и не было никогда в русскоязычной среде такого понятия. Лучше уж информационными технологиями или информатикой обзывать (хотя опять же — нет адекватного понятийного соответствия). Вот и еще один пример — it никто же не называет информатикой или не говорят «итэ» (сокращение от «информационные технологии»).
Дело ведь не западничестве или поклонении перед английским языком (не все, кто пользуется англицизмами, пытаются выглядеть умнее, как ТП). Все упирается в удобство и понятность. Если я хочу коротко дать понять кому-то, что имею ввиду матанализ — я так и скажу «матанализ», зачем мне обзывать это дело calculus. В то же время если я захочу обозначит целый курс предметов от матана до дифуров, я скажу вышмат — и меня поймут. А в английском языке нет адекватного перевода для этого, соответственно переживать что станут переводить, не стоит. А для CS есть — и почему бы им не пользоваться, если говоришь с просвещенным человеком, чтобы более точно выражать свои мысли?
Дело ведь не западничестве или поклонении перед английским языком (не все, кто пользуется англицизмами, пытаются выглядеть умнее, как ТП). Все упирается в удобство и понятность. Если я хочу коротко дать понять кому-то, что имею ввиду матанализ — я так и скажу «матанализ», зачем мне обзывать это дело calculus. В то же время если я захочу обозначит целый курс предметов от матана до дифуров, я скажу вышмат — и меня поймут. А в английском языке нет адекватного перевода для этого, соответственно переживать что станут переводить, не стоит. А для CS есть — и почему бы им не пользоваться, если говоришь с просвещенным человеком, чтобы более точно выражать свои мысли?
А для CS есть — и почему бы им не пользоваться, если говоришь с просвещенным человеком, чтобы более точно выражать свои мысли?
Ну наверное потому что читая некоторые комментарии (не буду тыкать пальцем) — улыбка появляется на лице от использования этого термина «лишь бы воткнуть».
Однако, позволю процитировать автора сей темы
в советском ВУЗе в начале-середине 90-х, когда обучение было иным и даже такое понятие как computer science в наших ВУЗах еще отсутствовало.
И википедию, по ссылке, которую оставлял выше
Начиная с 1980-х годов смысл кардинально меняется, как указывает Д. А. Поспелов: «ближе всего содержание этого понятия подходит к тому, что в США и большинстве других стран называется computer science, то есть компьютерные науки».
Но до 1970-х годов в СССР все исследования велись в рамках науки кибернетики. Как излагает Д. А. Поспелов, дело в том, что науки информатика и кибернетика были в это время смешаны, по причине ряда академических споров. В конце 1970-х рождается информатика, как ни странно подчинив себе свою прародительницу «Кибернетику».
Это примерно как говорить, что в СССР не было секса, но при этом в семьях было детей больше, чем в настоящее время.
Ну спорить дальше не имеет смысла. Ответ я получил в полной мере. Спасибо за диалог.
«Компьютерные науки» гораздо менее удачный термин чем «computer science». Говоря о CS мы понимаем что в английском языке слово «computer» образовано от слова «computing», и связано с вычислениями, а не с компьютером как устройством.
Информатика тоже не подходит — «изучать информатику» обычно означает «учиться работать с компьютером».
Информатика тоже не подходит — «изучать информатику» обычно означает «учиться работать с компьютером».
Это в головах тех так означает, кто хотя бы на вики поленился зайти. Или учителя не слушал в школе на первом уроке информатики :)
Сейчас предмет «информатика» опошлен, особенно в школах и нетехнических вузах. Там что только не изучают — от десятипальцевого набора текста (когда учителю лень, он включает всему классу клавиатурный тренажёр — и погнали), до работы в Microsoft Word.
Поэтому «отличные знания информатики» может обозначать что угодно, чего не скажешь о Computer Science.
Поэтому «отличные знания информатики» может обозначать что угодно, чего не скажешь о Computer Science.
Попробуйте погуглить на тему «Theoretical Computer Science» и поймете разницу.
Проблема скорее всего в том что вы до сих пор не определились со своей специализаций. Веб-программист, прикладной, базы данных или системное программирование. Технологий слишком много и невозможно их все обьять, приходится выбирать какую-то специализацию и концентрироватся на ней. Из вашего описания видно что у вас по сути нету специализации — у вас все и сразу и демоны с ассемблером и джанго на питоне, а это невозможно. Т.е. возможно, но понятно что тут чуть-чуть и там чуть-чуть, а нужно именно глубокое понимание технологий.
Невозможно эффективно работать редактируя в файлы в FAR. Сказать такое на интервью — верный способ получить отказ, если собеседует технический специалист.
файлы редактировал упорно в FAR-е, и моя производительность не страдала от этого
Невозможно эффективно работать редактируя в файлы в FAR. Сказать такое на интервью — верный способ получить отказ, если собеседует технический специалист.
А что требуется для «эффективной работы» в среде разработки? (не сарказм) Отладчик, возможность рефакторинга, сборки из среды, интеграция с VCS? Интересно, что я могу потерять. Правда, иногда простой редактор удобнее среды — например, надо быстро переименовать сто файлов по сложному правилу, и создавать проект ради одноразового десятистрочного скрипта не хочется.
Правильно понимаю, что сказать «хожу по папкам в mc, редактирую всё в vim, отлаживаю в gdb» на интервью — тоже верный способ получить отказ?
Правильно понимаю, что сказать «хожу по папкам в mc, редактирую всё в vim, отлаживаю в gdb» на интервью — тоже верный способ получить отказ?
Изредка применить какую-то возможность инструмента или пользоваться им постоянно это разное. Например, среда программирования обычно позволяет перейти к исходному коду функции по клику на её имени, парсит и показывает синтаксические ошибки и вагон ещё того, что вам не покажет редактор в FAR. Поэтому, сказав, что вы так же эффективно работает в FAR, как и в средах разработки, может показаться, что этот уровень эффективности как раз «такой же низкий», а не «такой же высокий». Т.е. если от использования для редактирования FAR эффективность не падает, то её нету вообще. А если вы пользуетесь FAR изредка для мелкой правки здесь и сейчас, то об этом можно даже не упоминать ибо основная работа идёт в специализированных средах.
От ваших постов веет максимализмом, простите.
У меня в жизни например был факт разработки одного продукта в easy editor`е (ee — редактор такой простенький под FreeBSD). Не то что бы я горжусь качеством кода внутри, давно это было, но продукт до сих пор работает и выполняет свои функции.
Я не думаю что автор хотел сказать что он принципиально пишет в FAR`е, как вы это поняли. Лично мне это говорит что человек способен разрабатывать даже в «пустом окружении». Не знаю как вам, а для меня это признак крутости. Старая школа.
У меня в жизни например был факт разработки одного продукта в easy editor`е (ee — редактор такой простенький под FreeBSD). Не то что бы я горжусь качеством кода внутри, давно это было, но продукт до сих пор работает и выполняет свои функции.
Я не думаю что автор хотел сказать что он принципиально пишет в FAR`е, как вы это поняли. Лично мне это говорит что человек способен разрабатывать даже в «пустом окружении». Не знаю как вам, а для меня это признак крутости. Старая школа.
Быть способным и постоянно так делать — разные вещи. Не только я так понял.
Не принципиально пишу в FAR-е, а вопрос юзабилити или, так сказать, микрооптимизаций от использования различных сред разработки меня не очень волнует. Это не значит, что я не экономлю деньги работодателя. У меня реально высокая скорость печати. Когда нужен дебаггер — я пользуюсь средами для удобства. Когда не нужен — могу писать и в FAR-е.
Т.е. если от использования для редактирования FAR эффективность не падает, то её нету вообще.
Вот… золото
Вот… золото
В условиях стартапов приходилось заниматься всем и понемногу. Так как «спартапное» мышление в меня уже въелось за много лет, то сложно его поменять.
Да, глупо говорить про FAR, когда появилось так много разнообразных IDE для программирования на все вкусы… когда я начинал на Python в 2001 году, было только одно IDE под него, и оно было невероятно глючным… так что использовал FAR.
Да, глупо говорить про FAR, когда появилось так много разнообразных IDE для программирования на все вкусы… когда я начинал на Python в 2001 году, было только одно IDE под него, и оно было невероятно глючным… так что использовал FAR.
> Невозможно эффективно работать редактируя в файлы в FAR.
Не надо переносить свой ограниченный опыт на всех.
Не надо переносить свой ограниченный опыт на всех.
Невозможно эффективно работать редактируя в файлы в FAR. Сказать такое на интервью — верный способ получить отказ, если собеседует технический специалист.
Я не был бы столь однозначным. При всей своей любви к IDE, глядя на коллегу работающего в FAR, я просто не успеваю глазами отслеживать что он вообще делает.
Я так понимаю, вы говорите о скорости набора программного кода в FAR? Даже такая простая операция, как переименование метода в рамках проекта, гораздо сложне выполняется без движка для рефакторинга (т.е. анализа кода проекта). Я поверю, что можно быстро набирать текст в любом редакторе, будь то vim, FAR или Notepad, но для всего остального (профилирование, отладка, рефакторинг, прогон тестов, использование VCS) придется идти за дополнительными утилитами, что не всегда удобно. К примеру, я не понаслышке знаком с взаимодействием фронтенда и бэкенда отладчика (в моем случае Visual Studio и GDB) и могу сказать, что ту тонну информации, которую студия с поразительной частотой запрашивает в процессе отладки и показывает в разных окошках, просто нереально так же быстро получить напрямую у GDB, запустив его через консоль.
Нет, не о скорости набора кода, а именно о его поддержке. Да и при использовании VCS для простых задач (обновить копию, сделать коммит и т. п.) я сам предпочитаю консоль, а не IDE — как-то проще и нагляднее. Вот диффы анализировать уже в IDE иду.
Насчет VCS соглашусь, сам через консоль обычно большинство задач делаю.
Допустим, переименовали функцию, которая используется в 50 разных местах проекта (причем обо многих даже не подозреваем). IDE дает возможность по-тихому заменить ее название, что делать в таком случае в FAR-e?
Поскольку я использую IDE для этого, то могу только предположить, что нужно использовать sed.
regexp-ами заменить. Так же, как и в IDE. Но телодвижений, вероятно, придется сделать больше. А может быть и так же, не знаю.
Регулярные выражения вам не помогут в случае, если функций (или методов) с таким именем несколько.
если речь конкретно про python, то в общем случае вам ни что не поможет. getattr(self, 'mehod')() и приехали. а про частные спорить не интересно — sed или rope какая разница)
Между прочим (ИМХО) тот, кто хотя бы парочку раз пробовал инструмент поиска и замены в phpStorm или pyCharm, никогда, НИКОГДА больше не вернется к sed-у (по крайней мере, при работе с кодом).
Это, кстати, косвенно указывает, что такие языковые конструкции применять в крупных проектах — ни в коем случае нельзя. А если в данном языке без них не удается решить задачУ, значит надо выбирать другой язык.
perl -i -npe 's/old-name/new-name/g' *от пальцев должно отскакивать.
Я так понимаю, вы говорите о скорости набора программного кода в FAR? Даже такая простая операция, как переименование метода в рамках проекта, гораздо сложне выполняется без движка для рефакторинга
Для C# в IDE от MS всё прекрасно, особенно с решарпером.
Но для C++ вплоть до 2010-й версии было настолько всё отвратительно, что FAR, обвешанный плагинами, легко по функционалу обходил IDE в плане навигации, выполнению операций с блоками и т.п.
Ну, почему же, очень даже возможно. У меня на прошлой работе практически все забугорные сеньйор-аксакалы (дяденьки 40-50 лет и немножко выше) писали кто в FAR, кто в vim, кто в TextPad. И в репозиторий коммитились из комманд лайна. Даже в киевском офисе был (и есть) человек, который пишет в FAR — а он, между тем, один из самых крутых программистов на проекте.
И если собеседующий «технический специалист» за подобный факт отказывает на интервью — есть повод усомниться в адекватности такого специалиста.
И если собеседующий «технический специалист» за подобный факт отказывает на интервью — есть повод усомниться в адекватности такого специалиста.
Если идеально знаешь код системы, то да — вполне неплохо можно и а FAR'е писать и ручками рефакторинг делать (т.к. все взаимосвязи в голове).
Но если взять пример, когда приходит новичок и начинает разбираться с кодом, дебажить, профилировать — то это нельзя эффективно делать фаром. Взять хотя бы проваливание в метод, класс, анализ зависимостей, переименование и пр.
Поэтому слова «у нас самый крутой спец все делает в фаре и не жужжит» говорят лишь о том, что этот спец отлично знает код. Посади его в новый проект и эффективность тут же упадет по сравнении с использованием IDE.
Но если взять пример, когда приходит новичок и начинает разбираться с кодом, дебажить, профилировать — то это нельзя эффективно делать фаром. Взять хотя бы проваливание в метод, класс, анализ зависимостей, переименование и пр.
Поэтому слова «у нас самый крутой спец все делает в фаре и не жужжит» говорят лишь о том, что этот спец отлично знает код. Посади его в новый проект и эффективность тут же упадет по сравнении с использованием IDE.
а в vim, например? или emacs?
Возможно тут проблема такая: не хочу быть программистом «как все», боюсь потерять самобытность, не хочу «на конвейер».
Начну учиться «как все» — стану «как все», одним из миллионов таких же. Потеряю индивидуальность.
Спасение — «узкое» знание, высокая продуктивность, смекалка, практический склад ума, направленный на решение конкретных проблем. Также спасает работа в непрофильных компаниях, где ИТ технологии неразвиты и любое их развитие дает сильный толчок вперед. Нет печати отчетов — есть печать отчетов — круто!
Нужно «открыть ум». Не нужно гордится своими слабостями, нужно их подтягивать, не затмевая сильные стороны. И нужно уметь оставлять прошлое в прошлом. Опыт должен трансформировать человека, а не висеть мертвым грузом. Умеете решать проблемы — отлично. Параллельно изучайте теорию.
Боязнь развития.
Начну учиться «как все» — стану «как все», одним из миллионов таких же. Потеряю индивидуальность.
Спасение — «узкое» знание, высокая продуктивность, смекалка, практический склад ума, направленный на решение конкретных проблем. Также спасает работа в непрофильных компаниях, где ИТ технологии неразвиты и любое их развитие дает сильный толчок вперед. Нет печати отчетов — есть печать отчетов — круто!
Нужно «открыть ум». Не нужно гордится своими слабостями, нужно их подтягивать, не затмевая сильные стороны. И нужно уметь оставлять прошлое в прошлом. Опыт должен трансформировать человека, а не висеть мертвым грузом. Умеете решать проблемы — отлично. Параллельно изучайте теорию.
Боязнь развития.
Человек, который знает много всего, но поверхностно, не нужен бизнесу.
Ваша история похожа на резюме какого-то эникейщика, только в контексте программирования.
Мне кажется, что если что-то требует от вас слишком больших усилий на протяжении длительного времени, а результата все равно нет, значит это не ваше и вы стремитесь к неправильной цели.
Если вы не прошли собеседования в топ-компаниях, то это значит, что вы не дотягиваете до их уровня, и не надо себя обманывать «я уверен, что в большинстве компаний, куда я ходил на собеседование, я смог бы работать без особых проблем».
Ваша история похожа на резюме какого-то эникейщика, только в контексте программирования.
Мне кажется, что если что-то требует от вас слишком больших усилий на протяжении длительного времени, а результата все равно нет, значит это не ваше и вы стремитесь к неправильной цели.
Если вы не прошли собеседования в топ-компаниях, то это значит, что вы не дотягиваете до их уровня, и не надо себя обманывать «я уверен, что в большинстве компаний, куда я ходил на собеседование, я смог бы работать без особых проблем».
Интересно, чтобы вы сказали, прочитав биографию Леонардо да Винчи?
«Ваша история похоже на резюме эникейщика, только в контексте инженерного дела. Да еще и Мон Лиз каких-то рисуете, отвлекаетесь от работы.»?
«Ваша история похоже на резюме эникейщика, только в контексте инженерного дела. Да еще и Мон Лиз каких-то рисуете, отвлекаетесь от работы.»?
Интересно, чтобы вы сказали, прочитав биографию Леонардо да Винчи?
Что он был гением.
Если бы такие люди окружали нас постоянно, то ладно, но сравнивать да Винчи с автором топика не совсем логично, как мне кажется.
Интересно, как много современников да Винчи действительно считали его гением?
Да, но на работу бы вы бы его не взяли, верно? Зачем вам перфекционист, который срывает сроки сдачи на десятилетия(!)? :)
Тут вопрос не в этом. Я отвечал на этот пост.
Эникейщик умеет много чего, но ни в чём не достигает совершенства.
Да Винчи же во всём (ну или почти) преуспел, поэтому я и указал на нелогичность сравнения.
«Ваша история похоже на резюме эникейщика, только в контексте инженерного дела. Да еще и Мон Лиз каких-то рисуете, отвлекаетесь от работы.»
Эникейщик умеет много чего, но ни в чём не достигает совершенства.
Да Винчи же во всём (ну или почти) преуспел, поэтому я и указал на нелогичность сравнения.
Вы не бизнесмен чтоб решать нужен человек или нет. Мелкому бизнесу какраз таки не нужен спец который умеет суперски «закручивать гайки на 12 а на 10 — у него уже не хватает навыка» там нужны универсалы, которые могут либо решить проблему, либо иметь достаточно знаний чтоб озадачить кого-то и проконтролировать.
Большое спасибо автору за интересную статью!
Ну зачем вы так прибедняетесь (" не могу отнести себя к касте программистов"). Много людей бы позавидовали вашему опыту, уверен.
Мне меньше лет, чем Вам, я изучал много Computer Science в университете, и хорошо знаю, что на ИТ рынке компании отбирают программистов совершенно по-разному. Я сам бывал на собеседованиях, где кандидатов отсеивали по принципу «знает мало функций стандартной библиотеки Oracle», при этом они даже не проверяют, умеет ли они вообще писать и анализировать код, знает ли он механизмы работы со основными структурами данных и таблицами, итд Можно бы было зазубрить 40-50 функций и выглядеть супер-программистом. Поэтому, ваши истории — ничего удивительного в них нет. У тех, кто отбирает программистов та же самая проблема, которую вы обозначали — смещенный фокус. Они думают, что отбирают программистов, на самом деле рискуя тем, что код писаться будет тяжело. Они сами не понимают, что они делают.
PS. Про Computer Science в 90-ые: Я хорошо знаю, что существует некоторое количество университетов, где и в 90ых это было. Нельзя сказать, что нигде не было.
Ну зачем вы так прибедняетесь (" не могу отнести себя к касте программистов"). Много людей бы позавидовали вашему опыту, уверен.
Мне меньше лет, чем Вам, я изучал много Computer Science в университете, и хорошо знаю, что на ИТ рынке компании отбирают программистов совершенно по-разному. Я сам бывал на собеседованиях, где кандидатов отсеивали по принципу «знает мало функций стандартной библиотеки Oracle», при этом они даже не проверяют, умеет ли они вообще писать и анализировать код, знает ли он механизмы работы со основными структурами данных и таблицами, итд Можно бы было зазубрить 40-50 функций и выглядеть супер-программистом. Поэтому, ваши истории — ничего удивительного в них нет. У тех, кто отбирает программистов та же самая проблема, которую вы обозначали — смещенный фокус. Они думают, что отбирают программистов, на самом деле рискуя тем, что код писаться будет тяжело. Они сами не понимают, что они делают.
PS. Про Computer Science в 90-ые: Я хорошо знаю, что существует некоторое количество университетов, где и в 90ых это было. Нельзя сказать, что нигде не было.
Не понял. В 90-е был один Университет в msk — МГУ. И там это было?
Разве один? Вроде начиная с 92-го пошла мода на переименования институтов в университеты да академии.
Два университета. Один московский государственный (МГУ), другой дружбы народов.
Computer Science — такого термина не было на нашем славном факультеле Вычислительной Матетатики и Кибернетики.
Впрочем, название факультета иногда так переводили, чтоб иностранцам понятнее было.
Программу обучения я могу попробовать восстановить в памяти.
1) Pascal (есть класс «Роботронов»)
2) Ассемблер (или трифтокод для второго потока) ЕС ЭВМ (есть терминальный класс ЕСxxxx — забыл номер). Подсчитать количество разных слов в введенном тексте.
3) Для мальчиков Ада на терминалках военной кафедры. Практики немного. В основном — теория
4) Фортран в терминальном классе HP. Что-то там с методами Рунге-Кутта 4-го порядка.
5) Что-то там на ямахах MSX было. То ли бейсик, то ли элементы машграфа. Был преподами освобожден за явным знанием.
6) Си на бумажке и мелом на доске. Кто имеет доступ к IBM-совместимым компам с гордостью рассказывает о подсветке синтаксиса в BC3.1. Круто! Ребята, использующий соурсер вылетают в коридор с широко открытыми глазами — крутой компилятор! он использует DI и SI для циклов!
7) Пролог и целый семестр как его там… забыл… формальной логики? нет. вылетело из памяти
8) На некоторых кафедрах лисп, рефал и еще несколько забавных языков
9) Лектор на лекции рассказывает про многообразие языков и даже приводит программу сложения матриц на APL
10) Базы данных. За семестр лектор успевает слово-в-слово прочитать 100-120 страниц из книжки. Рассказывает он интересно, но мы знаем, что это за книжка. На компах властвуют dBase и foxBase, самые крутые хвастаются тем, что видели Клиппер и какой-то Кларион.
10) На экзамене (1993г) в аудитории нет ни компьютера, ни даже проектора. Впрочем, и не надо — мы математики по профессии, а не программисты. Компьютерная программа — это не самоцель, а только инструмент для быстрого подсчета или решения математической задачи.
Мы все учились понемногу
Чему-нибудь и как-нибудь (с) Пушкин.
Computer Science — такого термина не было на нашем славном факультеле Вычислительной Матетатики и Кибернетики.
Впрочем, название факультета иногда так переводили, чтоб иностранцам понятнее было.
Программу обучения я могу попробовать восстановить в памяти.
1) Pascal (есть класс «Роботронов»)
2) Ассемблер (или трифтокод для второго потока) ЕС ЭВМ (есть терминальный класс ЕСxxxx — забыл номер). Подсчитать количество разных слов в введенном тексте.
3) Для мальчиков Ада на терминалках военной кафедры. Практики немного. В основном — теория
4) Фортран в терминальном классе HP. Что-то там с методами Рунге-Кутта 4-го порядка.
5) Что-то там на ямахах MSX было. То ли бейсик, то ли элементы машграфа. Был преподами освобожден за явным знанием.
6) Си на бумажке и мелом на доске. Кто имеет доступ к IBM-совместимым компам с гордостью рассказывает о подсветке синтаксиса в BC3.1. Круто! Ребята, использующий соурсер вылетают в коридор с широко открытыми глазами — крутой компилятор! он использует DI и SI для циклов!
7) Пролог и целый семестр как его там… забыл… формальной логики? нет. вылетело из памяти
8) На некоторых кафедрах лисп, рефал и еще несколько забавных языков
9) Лектор на лекции рассказывает про многообразие языков и даже приводит программу сложения матриц на APL
10) Базы данных. За семестр лектор успевает слово-в-слово прочитать 100-120 страниц из книжки. Рассказывает он интересно, но мы знаем, что это за книжка. На компах властвуют dBase и foxBase, самые крутые хвастаются тем, что видели Клиппер и какой-то Кларион.
10) На экзамене (1993г) в аудитории нет ни компьютера, ни даже проектора. Впрочем, и не надо — мы математики по профессии, а не программисты. Компьютерная программа — это не самоцель, а только инструмент для быстрого подсчета или решения математической задачи.
Мы все учились понемногу
Чему-нибудь и как-нибудь (с) Пушкин.
Немного уже подзабыл.
ЕС конечно же 1045, на военке был практикум по PL/1 (а Ада — только как теория, потому что язык вероятного противника)
ЕС конечно же 1045, на военке был практикум по PL/1 (а Ада — только как теория, потому что язык вероятного противника)
Удивлен. СПбГЭТУ (в 1992-м переименован из ЛЭТИ, ехал поступать в институт, поступил уже в университет)), факультет автоматики и вычислительной техники, кафедра «Информационно-измерительная техника» (учились в потоке с другим факультетом, электрофизическим, кажется), инженеры-системотехники (программисты учились в параллельной группе на кафедре вместе со всем факультетом). На первых трех курсах застал:
— FORTRAN на СМ1420 (клон PDP-11)
— C и ASM 8086 на ЕС-1840 (клон IBM PC)
— TurboPascal и TurboVision на каких-то брэндовых PC AT, ООП
— Ассемблер какого-то микроконтроллера, который гоняли на эмуляторах под MS-DOS
— MathCAD на ВМ
— плюс на различных курсах типа микроэлектроники давали доступ к компам для расчетов схем, разводки плат и т. п.
— FORTRAN на СМ1420 (клон PDP-11)
— C и ASM 8086 на ЕС-1840 (клон IBM PC)
— TurboPascal и TurboVision на каких-то брэндовых PC AT, ООП
— Ассемблер какого-то микроконтроллера, который гоняли на эмуляторах под MS-DOS
— MathCAD на ВМ
— плюс на различных курсах типа микроэлектроники давали доступ к компам для расчетов схем, разводки плат и т. п.
Какова алгоритмическая сложность наилучшего и наихудшего возможного алгоритма сортировки массива из N элементов? (Наихудшая сложность – O(N^2), потому что нужно сравнить каждый с каждым, наилучшая – O(N * ln(N)). Почему такая наилучшая? Не помню. Читал в книжке. В какой — не помню).
Вы упоминали Мейл и Яндекс. Так вот незнание таких базовых вещей разработчиком вполне может обернуться дополнительным железом, которое придется поставить под ваш код и которое стоит существенных денег. А разница может быть всего лишь в том, чтобы заюзать стандартный sort или написать в нужном месте нормальный sort, который работает за O(N) вместо O(NlogN).
если сортировка становится прямо проблемой прямо вот такого масштаба, это должно быть понятно из контекста задачи (тетрабайты данных, миллиарды сортировок), и вы будете иметь дело с множеством других умопомрачительных базовых вещей. во всех прочих случаях узкое место вероятнее всего будет в другом месте, а на реализацию нормального sort вы только время потеряете напрасно. а что дороже в Мейл или Яндекс — время или железо — еще вопрос)
Нет, сортировка там может быть совсем не проблемой в контексте задачи. Просто немного неаккуратно написать тут, чуть не оптимально в другом месте, чуть хуже ассимптотику для сортировки выбрать и всё: под нагрузкой (такой как у Яндекса или Мейлру) имеем в кластере для этого сервиса больше железа, чем могло быть, если бы писал человек, который в таких вопросах себя чувствует свободно. А железо — это деньги. А зачем платить больше, когда расходы можно предотвратить ещё на этапе собеседования? :-)
угу) пока ищется кандидат-всезнайка только что и остается — расходы считать. деньги это ведь не только железо. собеседования тоже денег стоят. специалистов нужно отвлекать. высокооплачиваемых, кстати, так ведь?.. а железо оно и в Африке железо. на то время, пока спец на испытательном сроке постигает премудрости оптимизации сортировок и прочие культурные особенности местного тех.процесса, можно вполне приличный vds найти за 10$ чтобы скинуть лишнюю нагрузку. ведь софт уже будет работать, да прибыль приносить :)
Если вы выучите алгоритмы сортировки, и концепции ООП, то выйдете на новый уровень, на котором вас снова будут браковать новые гуру.
Ask any C++ guru and they will tell you: avoid mutation, avoid side effects, don’t use loops, avoid class hierarchies and inheritance.Подозреваю, что у этого процесса нет конца. Всегда есть проект крупнее. Всегда есть человек опытнее…
С наступающим юбилеем! То что вам хочется что-то поменять, это типично и правильно. То что вы сами не знаете какую работу ищите, то это просто здорово, по мне скучны люди которые однозначно знают, кем будут через 10 лет. Когда хочется сделать что-то новое, это нельзя выразить словами, как доказывал Жак Деррида: «Единственное возможное изобретение, это изобретение невозможного, когда мы называем цель, мы уже ее производим». Искренне желаю вам успехов, хотя по приведенным ответам на вопросы, я бы вас вряд ли принял на работу, просто может задавал другие вопросы.
Спасибо, автор. Во многом узнал себя.
Меня вот что удивляет. Постоянно слышно, что «программисты востребованы» и что «работы хватит на всех». В тоже время человеку с таким опытом так сложно найти работу. Судя по всему, собеседования проходят те, кто прочитал какую-то книжку «Как пройти собеседование». А потом они появляются на форумах и задают такие вопросы, что непонятно как их взяли.
Меня вот что удивляет. Постоянно слышно, что «программисты востребованы» и что «работы хватит на всех». В тоже время человеку с таким опытом так сложно найти работу. Судя по всему, собеседования проходят те, кто прочитал какую-то книжку «Как пройти собеседование». А потом они появляются на форумах и задают такие вопросы, что непонятно как их взяли.
Большие корпорации типа Яндекса это всегда большая бюрократия, прежде чем попасть к специалисту, который сможет оценить реальные навыки придется пройти собсеседования, где HRы «сверяют ответы по бумажке». Для этого мало понимать и уметь, для этого надо тупо заучить что-то, как на экзамен, сидишь готовишься пару дней, потом сдаешь и все тут же вылетает из головы.
Мне вот такое не подходит, жалко времени своего, поэтому я в такие компании и не хожу, если уж очень приспичит, всегда можно написать какой-то конечный продукт, который нужен подобной корпорации и продать целиком вместе со своими услугами за много денег.
Мне вот такое не подходит, жалко времени своего, поэтому я в такие компании и не хожу, если уж очень приспичит, всегда можно написать какой-то конечный продукт, который нужен подобной корпорации и продать целиком вместе со своими услугами за много денег.
У Яндекса другая проблема: на собеседованиях они спрашивают вещи, которые никак не связанны с вакансией, на которую вы собеседуетесь.
Не так давно проходил у них собеседование на вакансию Android-разработчика. Про сам Android (или даже Java) ни слова не спросили, зато были вопросы логические и алгоритмические. Не совсем понимаю в таком случае, кого же они на самом деле ищут.
Не так давно проходил у них собеседование на вакансию Android-разработчика. Про сам Android (или даже Java) ни слова не спросили, зато были вопросы логические и алгоритмические. Не совсем понимаю в таком случае, кого же они на самом деле ищут.
Программиста? Как программист может что-то писать, не владея логикой и без способности к построению алгоритмов?
Гугль спрашивает в таком же ключе. Яндекс и Гугль оперируют терабайтами данных, сотнями тысяч запросов в секунду. В таких условиях знания эффективных алгоритмов гораздо важнее знаний конкретного языка и платформы.
мм, тетрабайты данных, сотни тысяч запросов в секунду, на андроид — это из какой области?
1. Вычислительные мощности ограничены (не у всех же 4-х ядерные монстры за штуку баксов). Сначала программисты говорят, зачем знать логику и алгоритмы, а потом пользователи удивляются, чего это у них приложение тормозит и страницы листаются по одной в секунду.
2. Очень многие современные приложения — всего лишь фронт-энд к серверу. Сервер будет явно не рад, получить десять запросов, там где можно обойтись одним. Для приложения у которого 1000 скачиваний может и ничего, но приложения яндекса скачиваются миллионами…
2. Очень многие современные приложения — всего лишь фронт-энд к серверу. Сервер будет явно не рад, получить десять запросов, там где можно обойтись одним. Для приложения у которого 1000 скачиваний может и ничего, но приложения яндекса скачиваются миллионами…
Помните про преждевременную оптимизацию? Тут зависит от того, сколько есть времени на проект. В реальной жизни обычно очень мало. И выгоднее сделать вторую версию приложения или выполнить рефакторинг уже работающего, найдя бутылочное горлышко уже на реально работающем проекте и исправить его.
Смотря о каком уровне оптимизации мы говорим. Об оптимизации уровня кода, или об оптимизации уровня дизайна. Второе может быть многократно дороже, если вообще возможно. Многие знают про «don't optimize prematurely», и с гордостью говрят об этом на собеседованиях, но обычно забывают про менее известное «don't pessimize prematurely».
Если человеку доверяют строить архитектуру, то он уже как-то себя показал? Я надеюсь. А вот оптимизировать код это любимое действо всех новичков.
Ок, пример из реальной жизни. Без всякой архитектуры. Разработчик (индийский) для поиска наибольшего элемента в массиве поступил следующим образом — склонировал массив (оригинальный нельзя было изменять), потом отсортировал копию Arrays.sort и взял последний.
Код красивый, три строчки кода, никаких ветвлений… Красота. Оптимизировать можно потом, правда ведь? И по скорости, и по расходу памяти.
Только вот сроки разработки не резиновые, чтобы тратить их на отлов подобных «перлов»
Не только индусы таким грешат, наши тоже. Вот и приходится проверять на собеседованиях, и сортировки, и обход дерева, и вские виды поиска.
Код красивый, три строчки кода, никаких ветвлений… Красота. Оптимизировать можно потом, правда ведь? И по скорости, и по расходу памяти.
Только вот сроки разработки не резиновые, чтобы тратить их на отлов подобных «перлов»
Не только индусы таким грешат, наши тоже. Вот и приходится проверять на собеседованиях, и сортировки, и обход дерева, и вские виды поиска.
А кто безгрешен? Может, разве что Джефф Дин :)
А может дело в том, что не были описаны максимальные размеры массива? Требования к памяти и прочее? Конечно, разработчик мог всё предположить. А мог и сделал быстро и просто. Мало того, именно этого обычно и хотят менеджеры проектов — чтобы было быстро готово, ведь «вот сроки разработки не резиновые» ваши же слова.
Да и почему не сделать так, как сделал разработчик, если массивы по 1-2 МБ / 100-200 элементов, а в распоряжении валом мощностей?
Я с вами согласен, разработчику следует понимать, как работают распространённые алгоритмы, я своим стажёрам сейчас сортировку даю одной из первых задач.
А может дело в том, что не были описаны максимальные размеры массива? Требования к памяти и прочее? Конечно, разработчик мог всё предположить. А мог и сделал быстро и просто. Мало того, именно этого обычно и хотят менеджеры проектов — чтобы было быстро готово, ведь «вот сроки разработки не резиновые» ваши же слова.
Да и почему не сделать так, как сделал разработчик, если массивы по 1-2 МБ / 100-200 элементов, а в распоряжении валом мощностей?
Я с вами согласен, разработчику следует понимать, как работают распространённые алгоритмы, я своим стажёрам сейчас сортировку даю одной из первых задач.
Да и почему не сделать так, как сделал разработчик, если массивы по 1-2 МБ / 100-200 элементов, а в распоряжении валом мощностей?Никто сразу не догадается, что он хотел этим сказать. Обфускация кода налицо
Ну в моем примере разница между кодом котрый я привел, и нормальным кодом котрый для этих целей пишут с школе на уроке информатики минут 10.
А затраты на профилирование?
Я хотел привсти пример, premature pessimization, когда есть очевидный алгоритм с линейной сложностью и не занимающий дополнитнльной памяти, не требующий супер-усилий.
Даже если типичный массив всего 100 элементов он может просматриваться тысячи раз. В таком очевидном случае лучше сразу написать оптимально.
А вот излишней premature оптимизацией было бы городить какое-нибудь кэширование, мол если в этом массиве уже искали максимум, а массив не изменялся, то давайте возьмем из кэша. Даже если бы это потенциально могло дать постоянное время поиска.
А затраты на профилирование?
Я хотел привсти пример, premature pessimization, когда есть очевидный алгоритм с линейной сложностью и не занимающий дополнитнльной памяти, не требующий супер-усилий.
Даже если типичный массив всего 100 элементов он может просматриваться тысячи раз. В таком очевидном случае лучше сразу написать оптимально.
А вот излишней premature оптимизацией было бы городить какое-нибудь кэширование, мол если в этом массиве уже искали максимум, а массив не изменялся, то давайте возьмем из кэша. Даже если бы это потенциально могло дать постоянное время поиска.
1. из ваших слов я делаю вывод, что гипотеза про тетрабайты данных и тысячи запрсов так-и отметена, и теперь мы ищем причины тормозов андроидного приложения в более привычных областях. проц, ui — т.е. все как везде — ни какой такой особой яндексно-мейлрушной магии)
2. сервер может и не рад, может у него апи такое, универсальное — сначала ткни сюда, затем посмотри туда. а в ответах все данные мира — выковыривай за чем пришел. разработчику приложения может тоже грустно с таким вот сервером работать, а что делать?.. разработчиков же тысячи, приложений — миллионы, а Яндекс один такой — каждому персонально-оптимальное апи писать не будет. а раз не будет — зачем тогда все эти сложности?)
2. сервер может и не рад, может у него апи такое, универсальное — сначала ткни сюда, затем посмотри туда. а в ответах все данные мира — выковыривай за чем пришел. разработчику приложения может тоже грустно с таким вот сервером работать, а что делать?.. разработчиков же тысячи, приложений — миллионы, а Яндекс один такой — каждому персонально-оптимальное апи писать не будет. а раз не будет — зачем тогда все эти сложности?)
Посмотрите мой пример чуть выше про поиск максимального элемента в массиве. Уверен, что такое можно устроить и на Андроиде.
А насчет терабайтов и тысяч запросов…
Возможно Яндекс следует стратегии Гугля — в первую очередь ищется сильный инженер, а уже во вторую разработчик для Андроида. Корпоративный стандарт.
Есть пара знакомых в Гугле, которых пересадили с Java на С++ и Python… Ибо по мнению Гугля нормальному инженеру все равно на чем писать.
А насчет терабайтов и тысяч запросов…
Возможно Яндекс следует стратегии Гугля — в первую очередь ищется сильный инженер, а уже во вторую разработчик для Андроида. Корпоративный стандарт.
Есть пара знакомых в Гугле, которых пересадили с Java на С++ и Python… Ибо по мнению Гугля нормальному инженеру все равно на чем писать.
Для крупных контор это как раз оправдано. Они могут себе позволить, чтобы человек вливался в проект чуть ли не годами, изучая платформу, язык и т. п., главное чтобы задачи умел решать нужные. Программировал не на языке, а с помощью языка.
Всё правильно в целом, хотя и несколько сумбурно написано.
В начале нужны были люди, которые решают все проблемы сразу — если берём программиста, то он и сеть должен тянуть и программы под неё писать, на чём угодно.
Когда рынок стал несколько цивилизованнее, произошло разделение труда, возникла узкая специализация — быть специалистом во всём нереально, объём знаний и опыта слишком большой.
В начале нужны были люди, которые решают все проблемы сразу — если берём программиста, то он и сеть должен тянуть и программы под неё писать, на чём угодно.
Когда рынок стал несколько цивилизованнее, произошло разделение труда, возникла узкая специализация — быть специалистом во всём нереально, объём знаний и опыта слишком большой.
Если роботодятел задает еще какие-то вопросы человеку, программирующему с 1980-х и показавшему примеры своего кода, то он не просто дятел, но еще и дебил.
Почему же? Вдруг есть хоть какие-то шансы, что этот человек ещё на что-то способен? Да и неприлично выгонять вообще без вопросов.
:)
может имелось в виду, что стоит брать таких людей вообще без вопросов =)
Наверняка. Если «примеры кода» оказались на языке, устраивающем работодателя, да ещё и в команде нужен человек с навыками старой школы — то можно брать и без вопросов. А в остальных случаях имеет смысл спросить, хотя бы, изучил ли он хоть один язык после Кобола и Фортрана, и насколько готов сделать это. И, на всякий случай, обсудить, что он знает и думает о современном состоянии ООП и прочей информатики. Опыт-то у него есть, но гибкости может не хватить.
Мне такие вопросы задавали на позицию менеджера. Никогда не понимал зачем задавать вопросы, на которые легче найти ответ чем запомнить.
Мне кажется, что проблема ТС не в нехватке знаний, а в возрасте. В 40 лет никому не нужен рядовой программист, на это место найдутся молодых людей, которым ещё есть время расти в том или ином направлении. Если тебе 40 лет, то стоит задуматься либо о своем бизнесе, либо о позиции тимлида, и тут нужны не одни знания, тут нужен лидерский состав характера. К сожалению такова жизнь и программист сам по себе в 40 лет мало стоит для работодателей.
Кстати, мало кто знает, но существует также другая проблема с возрастом. Мне 16 и у меня есть довольно уверенные навыки junior asp.net либо front-end разработчика. Но к сожалению, очень многие компании отказывали по причине возраста.
Жизнь программиста полна несправедливостей, но всегда существует та компания и то направление, в котором ты будешь нужен.
Кстати, мало кто знает, но существует также другая проблема с возрастом. Мне 16 и у меня есть довольно уверенные навыки junior asp.net либо front-end разработчика. Но к сожалению, очень многие компании отказывали по причине возраста.
Жизнь программиста полна несправедливостей, но всегда существует та компания и то направление, в котором ты будешь нужен.
Возможно дело в трудовом кодексе в части несовершеннолетних? Сейчас лень лезть смотреть, но там было что-то с более коротким рабочим днем с сохранением ЗП «как у всех» и какие-то еще поблажки. + работодатель понимает, что молодым людям грозит армия, институт и т.п. :-)
Конечно же, если вы в России.
Конечно же, если вы в России.
Я из Украины. В нашем трудовом кодексе нет ограничений по рабочему времени для лиц старше 14. Нужно только разрешение родителей, которое у меня есть. Призыв у нас отменили, последний призыв будет в этом году. В институт пойду учиться на заочку, если вообще пойду. Поэтому причина одна — базовое нежелание заморачиваться, когда есть множество совершеннолетних программистов на эту зарплату, даже если немного похуже.
Молодые люди из России вам завидуют, наверное, неимоверно, что призыв отменили у вас :-)
А откуда вы знаете, что «те парни» похуже?
А откуда вы знаете, что «те парни» похуже?
А откуда вы знаете, что «те парни» похуже?
Не знаю как вам на это ответить. «Те парни» понятие абстрактное, поэтому не с кем сравнивать, но я лично знаю несколько случаев, когда брали на работу выпускников, которые никогда не писали на asp.net больше чем тривиальные примеры из книги. Конечно я могу начать перечислять те технологии и тот опыт, который я получил за 4 года самообразования в сторону веб-программирования, но это будет выглядеть хвастовстом. Я свое мнение высказал, а вы можете поверить или нет моему мнению, так как доказывать что-то будет бессмысленно.
Не знаю как вам на это ответить. «Те парни» понятие абстрактное, поэтому не с кем сравнивать, но я лично знаю несколько случаев, когда брали на работу выпускников, которые никогда не писали на asp.net больше чем тривиальные примеры из книги. Конечно я могу начать перечислять те технологии и тот опыт, который я получил за 4 года самообразования в сторону веб-программирования, но это будет выглядеть хвастовстом. Я свое мнение высказал, а вы можете поверить или нет моему мнению, так как доказывать что-то будет бессмысленно.
В нашем трудовом кодексе нет ограничений по рабочему времени для лиц старше 14В нашем трудовом кодексе запрещено принимать на работу, не связанную с профобучением, раньше 15 лет, даже по согласию родителей (статья 188 КЗоТ Украины)
Кроме того, сотрудников до 18 лет нельзя привлекать к ночной и сверхурочной работе (статья 192), а рабочая неделя может составлять в возрасте 14-16 лет — не более 24 часов в неделю, 16-18 — 36 часов в неделю, при этом платить должны, как за 40 (статья 51).
Как-то так.
В 40 лет никому не нужен рядовой программист, на это место найдутся молодых людей, которым ещё есть время расти в том или ином направлении.
В каком том или ином? В техническом плане (новые технологии и т. п.) или в карьерном (руководящие должности и т. д.)?
В техническом плане.
Технологии у нас меняются часто. Я бы даже сказал, что чаще чем средний срок работы специалиста на одном месте. Какая разница работодателю есть у потенциального сотрудника 20 лет на «развитие» или 40, если мала вероятность, что он хотя бы 10 лет проработает у него?
В 40 лет уже нет того энтузиазма и гибкости ума. Да даже здоровье может не позволять просиживать за компом до пяти утра изучая какую-нибудь технологию или исправляя баги к дедлайну.
Тут еще вот какой момент. Молодых проще и дешевле заставить работать больше.
Во-первых, просто потому, что можно платить меньше ссылаясь на отсутствие опыта.
Во-вторых, в 40 лет как правило уже есть свое жилье, жена, дети и финансовая подушка. За опыт надо платить, при этом 40летний встанет в 18:00 и пойдет домой. А в случае чего и заявление на стол может. Потому что ценности уже другие. А молодому нужны деньги — на ипотеку, на кредит за машину, на развлечения, на девушек, на путешествия -он не может все это бросить вот так просто. И будет работать больше. Сидеть ночами, в выходные, гробить здоровье. Ведь здоровья еще дофига…
Во-первых, просто потому, что можно платить меньше ссылаясь на отсутствие опыта.
Во-вторых, в 40 лет как правило уже есть свое жилье, жена, дети и финансовая подушка. За опыт надо платить, при этом 40летний встанет в 18:00 и пойдет домой. А в случае чего и заявление на стол может. Потому что ценности уже другие. А молодому нужны деньги — на ипотеку, на кредит за машину, на развлечения, на девушек, на путешествия -он не может все это бросить вот так просто. И будет работать больше. Сидеть ночами, в выходные, гробить здоровье. Ведь здоровья еще дофига…
О, мы ровесники и вы практически описали мою жизнь :)
Ну разве что «микроша» и, потом, IBM PC у меня появились раньше и позже меня занесло больше в сторону сетей и UNIX.
Да, действительно, сейчас уже не произведешь впечатление на работодателя, если ты «и это умеешь и то». Специалисты широкого профиля уже не в почете. Теперь гораздо важней узкая специализация.
И присоединюсь к комментарию про кризис среднего возраста. Если сейчас работа устраивает, то заморачиваться не стоит.
А меня вот уже не устраивает и я не могу определиться к какому направлению начать стремиться.
Ну разве что «микроша» и, потом, IBM PC у меня появились раньше и позже меня занесло больше в сторону сетей и UNIX.
Да, действительно, сейчас уже не произведешь впечатление на работодателя, если ты «и это умеешь и то». Специалисты широкого профиля уже не в почете. Теперь гораздо важней узкая специализация.
И присоединюсь к комментарию про кризис среднего возраста. Если сейчас работа устраивает, то заморачиваться не стоит.
А меня вот уже не устраивает и я не могу определиться к какому направлению начать стремиться.
автор, это исключительно проблемы HR и 25 летних архитекторов, которые знают МТ, но не знают, что будет когда их архитектора из Visio упадёт под нагрузкой жалких 200 пользователей. Просто на хабре мало людей вашего возраста, потому и советы такие — копать в глубь, быть супер крутым и т.д. Это, к сожалению, тоже не поможет. У меня родственница мега-специалист с колоссальным опытом в пищевой промышленности(инженер-технолог). Её продукцию знает и продолжает покупать уже 15 лет целый регион. А запуск линии Pepsi в России в 90-ые думаете о чём-нибудь говорит работодателю после строчки «возраст: 49»? Да фиг там. Часто даже до собеседования дойти не может с правильно составленным резюме. Это вам не ИТ, где программистов как горячие пирожки разбирают. А если доходит, то все технические руководители в приятном шоке и готовы двумя руками за (бывали и случаи, что просто зависть, что он знает больше), зато какая-нибудь бизнес-леди-директор говорит «хм, слишком старая, коллективу будет не удобно с ней работать» или «ну мы вам можем предложить 50к(в мск) и 6 дней в неделю». Просто в вашем случае это выражается в эфемерных и точных знаниях реализации сортировок, которые в 99% не нужны, кроме случаев когда текущий уровень сортировки и есть bottlenet. И по сути являются вопросами, которые задают людям без опыта — выпускникам. Не спросить же их о проблемах архитектуры и способах решения. Выход один — продолжать искать адекватного работодателя. И выучить уже это ООП, тьюринга и многопточность. Задачи везде повторяются на собеседованиях.
Я думаю если вы попытаетесь запланировать хотябы лет на 5-10 вперед то поймете, что «адекватных» работодателей к полтийнику будет оч трудно найти. Так что это плохая мысль. Я бы всетаки смотрел (да что смотрел — уже так и делаю) в сторону разработки сервисов генерирующих доход и на него жить, ну или книжки писать :)
Книжки писать в отрыве от реалий производства — обман читателей. Если вы о технической литературе.
А книжки будут качать с пиратских сайтов.
Это прекрасная идея. Но придумать и реализовать такой сервис, который можно монетизировать, это нужно очень постараться. Практически на любую потребность есть по несколько сервисов, которые уже давно на рынке и с которыми трудно конкурировать.
Уважаемый, mike1. Разрешите спросить очень тревожащий меня момент а-ля «о чем я буду думать в 40 лет»:
Вы не жалеете, что, где-то в конце 90х-начале 2000 не пришли на работу в крупную компанию, которая занимается тем, что вам интересно и не остались в ней надолго? Вы, как человек не без способностей, могли бы за 15 лет вырасти в ней в материальном плане и в плане профессиональном. Приобрели бы не только широкий кругозор в IT, который у вас есть, но и стали бы глубоким специалистом в какой-нибудь узкой интересной области.
Вы не жалеете, что, где-то в конце 90х-начале 2000 не пришли на работу в крупную компанию, которая занимается тем, что вам интересно и не остались в ней надолго? Вы, как человек не без способностей, могли бы за 15 лет вырасти в ней в материальном плане и в плане профессиональном. Приобрели бы не только широкий кругозор в IT, который у вас есть, но и стали бы глубоким специалистом в какой-нибудь узкой интересной области.
К сожалению, «узкая интересная область» вполне может совсем закрыться под давлением прогресса. И после этого придётся либо метаться в нише остатков применения устаревшей технологии, либо вернуться к вопросу «куда двигаться дальше». А склоны вокруг «глубокой специализации» всё выше…
Меня никто не брал в крупную компанию в конце 90х. Я же писал — не брали. Каспер тогда только начинал — он меня не брал. Еще кто-то был — кажется, Лозинский или drweb — тоже не брали. Я много куда ходил и в то время — взяли только в торговую компанию в отдел автоматизации. Занимался автоматизацией торговой деятельности. Более того, в то время я вообще не решил, кем мне нравится быть — сисадмином или программистом.
Я понимаю, что вас не брали + вы еще не определившийся был. Но вот сейчас, вы бы хотели, чтобы тогда в девяностые вас взяли в крупную компанию, или сейчас вы думаете «слава богу, что тогда не взяли»?
Я не знаю, что было бы в крупной софтверной компании — я никогда в таких не работал. Мне сложно представить.
Ну, допустим, как обычно: нормальная ЗП, должность ведущего инженера-программиста или повыше. Вас ценят и чтут и т.п. и т.д.
Если бы взяли в крупную компанию наподобие Яндекса, которой в начале моей карьеры еще не существовало? Кажется, в 1995-1996 году в России не было ни одной крупной софтверной компании. Я пошел работать куда-то, туда, куда брали.
Крупная компания в некотором смысле лучше, чем мелкая, потому что там много возможностей для роста и более масштабные задачи.
Нет, я думаю, что не выдержал бы всю трудовую карьеру до пенсии работать только в одной, даже крупной, компании.
Что никто не взял не жалею ли? А бесполезно тут жалеть. Не взял и не взял. Это нормально.
Крупная компания в некотором смысле лучше, чем мелкая, потому что там много возможностей для роста и более масштабные задачи.
Нет, я думаю, что не выдержал бы всю трудовую карьеру до пенсии работать только в одной, даже крупной, компании.
Что никто не взял не жалею ли? А бесполезно тут жалеть. Не взял и не взял. Это нормально.
Я бы поработал лет 5 в крупной.
В начале 2000 (конкретно в 2001) начался серьёзный кризис в IT и многие компании закрылись. Тогда вообще было сложно с работой.
Отвечу с точки зрения руководителя, набирающего людей себе в команду.
Представим двух кандидатов, один через год работы с Java уже Regular Developer, а второй через 5 лет в Java все еще Regular Developer (по ответам, а не по должности). Естественно, я предпочту первого.
Или от человека с кучей сертификатов от Oracle/Sun итд я будут ожидать соответсвующего уровня ответов. Если взять двух человек, одного с сертификатами, а второго без, одинково не блестяще отвечающих на одинаковые вопросы — то я возьму того, у кого нет сертификатов — его незнание хотя бы можно объяснить.
Ваш многолетний опыт, сдвигает ожидание работодателей, вынуждая предъявлять к Вам более высокие требования. Чем выше ожидания, тем сильнее разочарование. Junior не могущий ответить на вопрос про сортировку производит менее негативное впечатление, чем Senior не способный дать ответ на такой же вопрос.
Представим двух кандидатов, один через год работы с Java уже Regular Developer, а второй через 5 лет в Java все еще Regular Developer (по ответам, а не по должности). Естественно, я предпочту первого.
Или от человека с кучей сертификатов от Oracle/Sun итд я будут ожидать соответсвующего уровня ответов. Если взять двух человек, одного с сертификатами, а второго без, одинково не блестяще отвечающих на одинаковые вопросы — то я возьму того, у кого нет сертификатов — его незнание хотя бы можно объяснить.
Ваш многолетний опыт, сдвигает ожидание работодателей, вынуждая предъявлять к Вам более высокие требования. Чем выше ожидания, тем сильнее разочарование. Junior не могущий ответить на вопрос про сортировку производит менее негативное впечатление, чем Senior не способный дать ответ на такой же вопрос.
Ваш многолетний опыт, сдвигает ожидание работодателей, вынуждая предъявлять к Вам более высокие требования.
Интересно почему, если я не претендую на должность Senior, хотя она есть рядом.
Возможно, у них есть заинтересованность в том, чтобы принятый Junior успел, работая над их проектом, развиться до Middle или до Senior (чтобы сэкономить на времени вхождения новых сотрудников в проект). И они считают, что из двоих, претендующих на одинаковую должность и показывающих одинаковый уровень, у более молодого больше шансов вырасти. А если у старшего есть опыт, который помог бы в конкретной работе или в развитии, он должен как-то проявиться в ответах (и, тем самым, стартовый уровень был бы выше).
Возможно, но тогда делают ошибку, не указав это в требованиях. Я вот просто не хочу расти до Senior Developer (если я правильно понимаю, что это аналог «ведущий инженер-программист»). Я хочу развиваться профессионально, а не карьерно. Решать новые технические задачи, а не делегировать и контролировать их решение. Приглашая меня на собеседование они просто тратят зря свое и мое время.
Интересно, бывает ли Junior full-stack developer :)
А Senior Developer вы не считаете профессиональным развитием? Senior это не обязательно руководящие обязанности. В моем понимании Senior это человек за которым не надо следить. Которому можно дать задачу, и расслабиться, потому что будешь уверен, что он все сделает как надо, без квадратичных алгоритмов, с элегантной архитектурой классов и все это без Code Review. К сожалению, набрать команду целиком из Senior'ов удовольствие дорогое, как по зарплате, так и по времени на поиск. Поэтому если речь идет о Regular/Junior уровне, то преимущество будет у тех, кого есть надежда дорастить до уровня Senior. И еще большее преимущество у тех, кто способен учиться сам.
Правда, я говорю с позиции Research and Development. Возможно, в сфере SL3 будет другой подход.
Правда, я говорю с позиции Research and Development. Возможно, в сфере SL3 будет другой подход.
В моем понимании Senior это человек за которым не надо следить.
В моем понимании это Middle/Regular. Senior уже сам следит за Junior.
Ну а Code Review должно быть для всех — это не слежка, а типа мозгового штурма.
Когда как. Мне доводилось работать в команде целиком состоящей из Сеньоров. Мой лучший опыт.
Не знаю, не представляю просто. В моем понимании в обязанности Senior входят уже не только технические вещи, но и административные: управление кем-то, делегирование задач, контроль за их выполнением и т. п. Пытались на меня подобные вещи повесить в приказном порядке — месяц-два отработал честно за двоих, а потом заявление на стол положил.
ненене
Junior/Middle/Senior — это исключительно професиональные уровни.
А административные — это уже тимлид/ПМ и тд.
Code review, knowledge exchange, обучение новичков — да, но не управление.
Надо называть это всё своими именами — тогда и проще говорить о зарплате (ибо тимлид — это уже другая сетка) и о претензиях (если от административной работы воротит) :)
Junior/Middle/Senior — это исключительно професиональные уровни.
А административные — это уже тимлид/ПМ и тд.
Code review, knowledge exchange, обучение новичков — да, но не управление.
Надо называть это всё своими именами — тогда и проще говорить о зарплате (ибо тимлид — это уже другая сетка) и о претензиях (если от административной работы воротит) :)
Там, где я подробно узнавал условия Senior входило именно административная работа. В частности не просто обучать новичков, но и давать им задания и контролировать их выполнение. Этакий мини тим-лид. Проще говоря, тимлид даёт задание сеньору на него и джуниора(ов), а не дает отдельные задания каждому и просит сеньора помочь джуниору(ам).
Нормальная ситуация это когда Senior-у дают большую сложную задачу, он основное пишет сам, а небольшую рутинную часть скидывает на джуниора, поясняя при необходимости как ее сделать. Это стандартный сениор, без всяких минилид, работа далеко не административная и даже не обучение.
Если за эти рамки выходит, тогда уже тимлид.
Если за эти рамки выходит, тогда уже тимлид.
Для меня это уже административная. Решать, что скидывать, следить есть ли необходимость в помощи, причем не веря на слово, а за конечный результат отвечать самому целиком и полностью.
Это значит, вы очень большие задача не брали. Такие, у которых просвета не видно и через месяц и примитивные части кодить самому просто неинтересно. Например, сделал сервер, а гуй на кучу клиентов можно отдать, сделал схему данных в базе или сервисы доступа к данным, а тупые типичные формочки list/query/edit/view для десятка сущностей ну вообще не интересно, как они написаны. Пусть хоть сто раз говнокод, ты знаешь, что ядро стабильно, в внешние к нему задачи настолько просты, что ты разберёшься в любой реализации, если понадобится (т.е. не теряешь контроль над проектом).
и примитивные части кодить самому просто неинтересно.
Давать их кому-то и, главное, контролировать, ещё больше не интересно. Я предпочитаю просто не брать их. Есть джуниор — дайте ему, пускай обращается ко мне, если что-то непонятно — помогу, могу даже сам иногда спрашивать как у него дела, не нужна ли помощь. Но зачем доводить до ситуации когда я за него отвечаю?
Но ты ж не рассказываешь менеджеру технические подробности.
Ты рассказываешь их напрямую исполнителю. И в какой-то степени только от тебя зависит, правильно ли он всё понял. Ну, а то, что тестить неинтересно… Есть тестировщики. От тебя, как правило, просто глянуть, что оно в принципе работает и дать ц.у. и пожелания, как это можно улучшить (код можно не смотреть). Это намного менее напряжно, чем самому писать нудный код.
А по ответственности — она не манагерская. Манагеру могут вставить люлей за то, что программист в сроки не укладывается, а тим-лид может спокойно с лицом Будды говорить «этот модуль пишется этим человеком, будет готов, когда будет готов, моя оценка сроков — не напрягаясь, можно написать за 3 дня, хотите ещё что-то спросить — идите к этому человеку и спрашивайте». В принципе, прокатывает.
Ты рассказываешь их напрямую исполнителю. И в какой-то степени только от тебя зависит, правильно ли он всё понял. Ну, а то, что тестить неинтересно… Есть тестировщики. От тебя, как правило, просто глянуть, что оно в принципе работает и дать ц.у. и пожелания, как это можно улучшить (код можно не смотреть). Это намного менее напряжно, чем самому писать нудный код.
А по ответственности — она не манагерская. Манагеру могут вставить люлей за то, что программист в сроки не укладывается, а тим-лид может спокойно с лицом Будды говорить «этот модуль пишется этим человеком, будет готов, когда будет готов, моя оценка сроков — не напрягаясь, можно написать за 3 дня, хотите ещё что-то спросить — идите к этому человеку и спрашивайте». В принципе, прокатывает.
Те, кто начинал в 80-х, могли иногда чувствовать себя в команде, состоящей целиком из архитекторов :)
На сколько я понимаю, на работу принимают не только по тому, что вы умеете, а еще и по тому, каковы ваши способности.
Не намекаю на автора топика:
крайний вариант: за 100 лет человек выучил только PHP. И за 1 год человек выучил только PHP. Вы возьмете того, кому 100 или того, кому 1?
Не намекаю на автора топика:
крайний вариант: за 100 лет человек выучил только PHP. И за 1 год человек выучил только PHP. Вы возьмете того, кому 100 или того, кому 1?
Я скорее не возьму никого, кто скажет, что выучил PHP, но при этом не может показать свой код в трансляторе. Я вот за 10+ лет не выучил — так, на троечку знаю, считая, что разработчики языка знают его на пятерку. Помню где основные камни и чуть что лезу в документацию, а то и в исходники, если по документации не понять ничего.
А так скорее возьму того, кто за 100 — вероятность того, что он знает (или подсознательно обходит) подводные камни сильно выше.
А так скорее возьму того, кто за 100 — вероятность того, что он знает (или подсознательно обходит) подводные камни сильно выше.
Вы все не о том :-)
При прочих равных условиях. Оба одинаково отвечают на базовые вопросы, оба одинаково валятся на глубоких вопросах. Оба показывают код в трансляторе. Просто один этого достиг за год, другой за 100.
PS: кстати, в что такое «показать код в трансляторе?», чем отличается от просто «показать код?» :-)
При прочих равных условиях. Оба одинаково отвечают на базовые вопросы, оба одинаково валятся на глубоких вопросах. Оба показывают код в трансляторе. Просто один этого достиг за год, другой за 100.
PS: кстати, в что такое «показать код в трансляторе?», чем отличается от просто «показать код?» :-)
Оба показывают код в трансляторе
Только у первого это HelloWorld, а у второго — эмулятор Вселенной в реальном времени (надо же было ему чем-то 100 лет заниматься?). А в остальном, да, всё одинаково.
Зачем вы мой пример изменяете. Создайте свой пример и изменяйте его :-)
В моем примере — оба одинаковые за исключением 100 лет и 1 года. И в таком случае ясно, что брать надо тому, кому 1 год т.к. у него больше способностей.
И это объясняет тот факт, что чем старше человек, тем больше с него могут требовать на собеседовании на одну и ту же позицию.
В моем примере — оба одинаковые за исключением 100 лет и 1 года. И в таком случае ясно, что брать надо тому, кому 1 год т.к. у него больше способностей.
И это объясняет тот факт, что чем старше человек, тем больше с него могут требовать на собеседовании на одну и ту же позицию.
Если так смотреть, то речь об исправлении ошибки (не соблюдение английской орфографии например) в сообщении об ошибки или об переводе ядра php на Unicode в версии 76.0 :)
Тут уже от бизнеса зависит. Нужен ли мне человек, который за год может перейти на другую платформу или такой человек несёт дополнительные риски — за год PHP выучил, глядишь за полгода Java освоит и уйдет.
P.S. Свой код на github.com/php/php-src
P.S. Свой код на github.com/php/php-src
За последние 10 лет мне не понадобилось выучить ни одного нового языка — C# полностью покрывает потребности и на работе и в хобби-проектах. Наверное, это плохо. Но для того, чтобы учить какой-нибудь другой язык, не понимая, чем он может пригодиться (кроме строчки в резюме), явно не хватает мотивации.
Сортировка, сортировка, сортировка.
Каждый пятый комментарий про сортировку.
Послушаешь, так создаётся впечатление, что типичная работа программиста — писать сортировки. Каждый день. Разные. Чем больше, тем лучше. И уметь оценивать её производительность — на глаз, и ни в коем случае не на реальных данных.
Каждый пятый комментарий про сортировку.
Послушаешь, так создаётся впечатление, что типичная работа программиста — писать сортировки. Каждый день. Разные. Чем больше, тем лучше. И уметь оценивать её производительность — на глаз, и ни в коем случае не на реальных данных.
Во всём этом я не нашёл ссылки на ваш профиль в гитхабе и contribute в opensource проекты. Что может характеризовать программиста лучше, чем это?
афторитетом давишь?))
Нет, указываю на большой пробел в списке того, что стоит распушать на собеседованиях программистам.
В принципе, охрененное резюме от программиста выглядит так (допустим, для фронтэндщика):
Участие в разработке сайтов а, б, ц.
Опенсорс:
* Участие в разработке jquery (~80 принятых коммитов из 120 засланных)
* Багрепорты в bootstap, несколько коммитов
* Моя библиотека по js-рендерингу *.cxs-файлов на канвас (htts://github...)
* Некоторое количество багрепортов в FF и Хром
В принципе, такого человека оторвут с руками, а те, кто не оторвут, идиоты с ними не надо сотрудничать.
Вот и всё. Опенсорс, оставляя в стороне идеологию и социально-политические аспекты, это единственный достоверный метод программисту показать, насколько он хорошо умеет программировать и не рисковать при этом нарушением NDA с предыдущего места работы.
В принципе, охрененное резюме от программиста выглядит так (допустим, для фронтэндщика):
Участие в разработке сайтов а, б, ц.
Опенсорс:
* Участие в разработке jquery (~80 принятых коммитов из 120 засланных)
* Багрепорты в bootstap, несколько коммитов
* Моя библиотека по js-рендерингу *.cxs-файлов на канвас (htts://github...)
* Некоторое количество багрепортов в FF и Хром
В принципе, такого человека оторвут с руками, а те, кто не оторвут, идиоты с ними не надо сотрудничать.
Вот и всё. Опенсорс, оставляя в стороне идеологию и социально-политические аспекты, это единственный достоверный метод программисту показать, насколько он хорошо умеет программировать и не рисковать при этом нарушением NDA с предыдущего места работы.
Опенсорс, оставляя в стороне идеологию и социально-политические аспекты, это единственный достоверный метод программисту показать, насколько он хорошо умеет программировать
Как я с Вами согласен.
В который раз не жалею, что не поленился вести активную деятельность на ГитХабе.
Ну багрепортил я в разные места, и что? Это моё личное дело. За 20 лет куда только я не багрепортил.
мне мой профиль на гитхабе ни разу не помог. Ни на одном собеседовании не поинтересовались.
А ссылку можно?
Почему сами не говорили о том, что там-то и там можно взглянуть на мои проекты и код?
Почему сами не говорили о том, что там-то и там можно взглянуть на мои проекты и код?
github.com/rfqu
Говорил, если к слову приходилось. И в резюме указано. Но заинтересовать никого не удалось.
Говорил, если к слову приходилось. И в резюме указано. Но заинтересовать никого не удалось.
Вы это серьезно?
Извините конечно, но в чем разница между вашим и совершенно пустым профилем?
Извините конечно, но в чем разница между вашим и совершенно пустым профилем?
Не понял вашего сарказма. Большой перерыв в коммитах? Это баг в гитхабе, коммиты были постоянно. Низкая оценка 22 звезды? Тема не самая популярная, ценителей мало. Все же взять и вот так грубо помножить на ноль — нужны же какие-то основания?
Не сарказм, если прозвучало грубо, то мои извинения.
Большой? Пол года без коммитов, для разработчика, мне кажется плохо. Вот глядя на текущий профиль я бы задался вопросом, а что вы эти 5 месяцев делали? Вы нашли работу и перестали коммитить? Вам надоело коммитить? Вам нечем поделиться? Может вы на пять месяцев стали художником, а потом опять решили программировать?
Лично моё мнение, что подобный перерыв частично говорит о «застое» профессиональном. Давайте только рассматривать тот случай, когда программист любит вкладывать в opensource и ему есть чем поделиться.
Постоянно? Странно, возможно и баг, но думаю его пофиксили уже давно.
Не буду спорить, возможно. За 3 года и более профессиональной деятельности не накопилось чего-то такого, что можно было бы выложить в общественный доступ, а затем, в будущем показывать работодателям и любоваться качеством кода и не боязнью его показать?
Большой перерыв в коммитах?
Большой? Пол года без коммитов, для разработчика, мне кажется плохо. Вот глядя на текущий профиль я бы задался вопросом, а что вы эти 5 месяцев делали? Вы нашли работу и перестали коммитить? Вам надоело коммитить? Вам нечем поделиться? Может вы на пять месяцев стали художником, а потом опять решили программировать?
Лично моё мнение, что подобный перерыв частично говорит о «застое» профессиональном. Давайте только рассматривать тот случай, когда программист любит вкладывать в opensource и ему есть чем поделиться.
Это баг в гитхабе, коммиты были постоянно.
Постоянно? Странно, возможно и баг, но думаю его пофиксили уже давно.
Низкая оценка 22 звезды?
Тема не самая популярная, ценителей мало.
Не буду спорить, возможно. За 3 года и более профессиональной деятельности не накопилось чего-то такого, что можно было бы выложить в общественный доступ, а затем, в будущем показывать работодателям и любоваться качеством кода и не боязнью его показать?
А вы не рассматриваете, что человек эти полгода может заниматься работой (!!!), иметь рабочий git сервер и просто не хватает времени на open source? Какой уж тут застой.
мне мой профиль на гитхабе ни разу не помог. Ни на одном собеседовании не поинтересовались.
человек эти полгода может заниматься работой
Показывать-то просто нечего.
А вы не рассматриваете
Хм, не рассматриваю… удивитесь, но у меня получалось и в рабочее время работать на opensource, причем никакого вреда основной работе.
Или работодатель был, как минимум, с этим согласен, или вы нарушали закон. Когда работал во фрилансе, то специально у всех заказчиков спрашивал: «вы не против, если я код в паблик выложу?» — все были против. Даже против того, чтобы багфиксы CMS в апстрим отправлял. Аргумент простой: «я работу оплачиваю и все результаты принадлежат мне».
Или работодатель был, как минимум, с этим согласен, или вы нарушали закон.
Либо ему было просто по барабану, что какой-то модуль для работы с соц. сетями будет в opensource, лишь бы не код самого приложения.
Когда работал во фрилансе, то специально у всех заказчиков спрашивал: «вы не против, если я код в паблик выложу?» — все были против.
Я бы сказал, что с большой вероятностью они вопрос не так понимали. А может вы не так спрашивали? Если корректно построить вопрос, то можно и согласие получить ;)
Даже против того, чтобы багфиксы CMS в апстрим отправлял.
А что там сама лицензия на CMS говорит?
Что мешало трактовать бакфикс не как фикс в рабочее время, а как в свободное, что собственно позволило бы его закоммитить?
По-правде очень удивляет такая позиция работодателя.
Либо ему было просто по барабану
От этого закон нарушаться не перестал.
Если корректно построить вопрос, то можно и согласие получить ;)
Тут коротко написал, объяснял подробно, со ссылками на определения, лицензии и т. п.
А что там сама лицензия на CMS говорит?
А ничего GPL не говорит. Вправе править баги и изменения в апстрим не отправлять.
Что мешало трактовать бакфикс не как фикс в рабочее время, а как в свободное, что собственно позволило бы его закоммитить?
Совесть. Получил формальный запрет.
Профиль-то должен быть не пустой (это я ниже комменты прочитал), а с приличной активностью. Вообще, человек на собеседовании должен себя хвалить. Если он себя не хвалит, то на работодателя ложится работа «найди в этом человеке хорошее». Что, конечно, допустимо, но во-первых создаёт ему проблемы (надо напрягаться), а во-вторых если даже на собеседовании человек сваливает на другого часть работы, то какой он работник будет? Я утрирую, но вообще говоря, проводить собеседования интересно только в первые N раз, дальше это работа, причём довольно занудная. И если кандидат не горит желанием помочь в ней, то почему надо напрягаться?
У меня есть профиль на гитхабе, но нет contribute-a в opensource проекты. Свои же проекты у меня есть какие-то, но их исходники я не готов выкладывать, потому что они просто не готовы к выкладке и когда будут готовы — я не знаю. Да и смысла не вижу выкладывать исходники того, что узкоспециализировано и никому не нужно. Условно говоря, зачем вам исходники моих сайтов?
Ну, там, сделал я ветку cometd на Python, и что? Она заточена под мои конкретные нужды и не общеупотребительна (да еще и, подозреваю, содержит шероховатости и небольшие косяки).
Ну, там, сделал я ветку cometd на Python, и что? Она заточена под мои конкретные нужды и не общеупотребительна (да еще и, подозреваю, содержит шероховатости и небольшие косяки).
)) Мне 50 недавно исполнилось. IT начинал изучать с Б3-21 (первый российский программируемый калькулятор). 350 рублей стоил — чуть дешевле мотоцикла «Восход». Был просто счастлив, когда отец дал денег. Б3-34, МК-61, МК-72… Самодельный Спектрум (постоянно что-нибудь отваливалось), ассемблер, разные бейсики, паскаль, первое знакомство с базами данных. И книги, книги, книги… А как их тогда мало было!
Семья, ребенок, армия.
«Пёрся» от математики, хотел поступить на прикладную — не вышло (заочных не было, а на очном семья, уже моя, не позволила).
В общем, где хотел учиться — не вышло. Просто денег не было. Решил, что от семьи отрывать не имею права.
Попробовал поступить просто «для корочки» — стало противно. Наверное юношеский максимализм. Бросил.
Где только не работал. В трудовой не один вкладыш. И вот как-то получилось так, что опять вернулся к «детской мечте» — к компутерам.
Даже делал свою собственную «Зарплату» и несколько раз ее продал. ))
В итоге, сейчас, «ведущий програмёр/системщик» у небольшого, но бурно развивающегося провайдера. Решаю вполне успешно поставленные задачи. Часто сам себе эти задачи и ставлю. Периодически изобретаю велосипеды. Иногда мои решения нестандартны и сильно эффективны. Иногда не эффективны, но тогда жизнь быстро поправляет.
Нехватка знаний… Ощущается сильно. Скорее даже не «нехватка», а отсутствие системы знаний. Программист должен знать «из коробки», а мне приходится обращаться к гуглу. Не то чтобы напрягает, но ощущается.
Да и «мозги» уже не те. Если раньше мог запомнить страницу текста почти наизусть с одного прочтения, то сейчас иногда перечитать надо чтобы понять. Впрочем, опыт часто выручает. И даже не в смысле накопленных знаний, а опыт решения различных задач. Ну и учиться постоянно приходится, без этого никак.
В общем, работаю. При желании мог бы и работу легко поменять, но сейчас меня все устраивает.
А успех, счастье в жизни… Вот внуки у меня растут — это куда важнее, чем какая-то карьера.
PS. IMHO. mcedit — самое крутое средство для написания программ. По моим наблюдениям, чем проще средство разработки, тем эффективнее программа получается. Писать правда труднее. Впрочем, для больших и срочных проектов, IDE наверное незаменима. Думаю, для каждого «зверя» эффективной будет своя «пушка».
Семья, ребенок, армия.
«Пёрся» от математики, хотел поступить на прикладную — не вышло (заочных не было, а на очном семья, уже моя, не позволила).
В общем, где хотел учиться — не вышло. Просто денег не было. Решил, что от семьи отрывать не имею права.
Попробовал поступить просто «для корочки» — стало противно. Наверное юношеский максимализм. Бросил.
Где только не работал. В трудовой не один вкладыш. И вот как-то получилось так, что опять вернулся к «детской мечте» — к компутерам.
Даже делал свою собственную «Зарплату» и несколько раз ее продал. ))
В итоге, сейчас, «ведущий програмёр/системщик» у небольшого, но бурно развивающегося провайдера. Решаю вполне успешно поставленные задачи. Часто сам себе эти задачи и ставлю. Периодически изобретаю велосипеды. Иногда мои решения нестандартны и сильно эффективны. Иногда не эффективны, но тогда жизнь быстро поправляет.
Нехватка знаний… Ощущается сильно. Скорее даже не «нехватка», а отсутствие системы знаний. Программист должен знать «из коробки», а мне приходится обращаться к гуглу. Не то чтобы напрягает, но ощущается.
Да и «мозги» уже не те. Если раньше мог запомнить страницу текста почти наизусть с одного прочтения, то сейчас иногда перечитать надо чтобы понять. Впрочем, опыт часто выручает. И даже не в смысле накопленных знаний, а опыт решения различных задач. Ну и учиться постоянно приходится, без этого никак.
В общем, работаю. При желании мог бы и работу легко поменять, но сейчас меня все устраивает.
А успех, счастье в жизни… Вот внуки у меня растут — это куда важнее, чем какая-то карьера.
PS. IMHO. mcedit — самое крутое средство для написания программ. По моим наблюдениям, чем проще средство разработки, тем эффективнее программа получается. Писать правда труднее. Впрочем, для больших и срочных проектов, IDE наверное незаменима. Думаю, для каждого «зверя» эффективной будет своя «пушка».
>> Мы слишком разные. Я например, люблю поэзию, литературу, музыку и английский язык. А вот любит ли это Яндекс? Не уверен.
>> В начале 90-х же была демографическая яма, в которую должны были угодить мои потенциальные конкуренты
Сильно! Уважаю)))
>> В начале 90-х же была демографическая яма, в которую должны были угодить мои потенциальные конкуренты
Сильно! Уважаю)))
Я руководитель, есть опыт успешного найма программистов в команду.
Сам когда-то был программистом.
Автор, вас бы к себе на работу я не взял, и вот почему.
Вы — ленивый и звездите. Это будет помехой в работе команды.
Например, задача про очередь из двух стеков. Немного подумав, я сразу нашёл решение.
Правило очереди — первый вошёл, первый вышел.
Правило стэка — первый вошёл, последний вышел.
Если все нужные записи поместить в один стэк, а потом из него во второй — элементы перевернутся дважды. И снова первый вошедший выйдет первым из нашей цепочки.
Итого: два последовательных стека превращают общую структуру в очередь.
Никакого гугла не потребовалось — достаточно немного поработать бесплатно на собеседовании и включить мозг.
С вашим подходом вы годитесь там, где нужен талантливый одиночка. В бизнесе большинство задач — командные. Там слаженность и синергия важнее эффективности отдельного человека.
Сам когда-то был программистом.
Автор, вас бы к себе на работу я не взял, и вот почему.
Вы — ленивый и звездите. Это будет помехой в работе команды.
Например, задача про очередь из двух стеков. Немного подумав, я сразу нашёл решение.
Правило очереди — первый вошёл, первый вышел.
Правило стэка — первый вошёл, последний вышел.
Если все нужные записи поместить в один стэк, а потом из него во второй — элементы перевернутся дважды. И снова первый вошедший выйдет первым из нашей цепочки.
Итого: два последовательных стека превращают общую структуру в очередь.
Никакого гугла не потребовалось — достаточно немного поработать бесплатно на собеседовании и включить мозг.
С вашим подходом вы годитесь там, где нужен талантливый одиночка. В бизнесе большинство задач — командные. Там слаженность и синергия важнее эффективности отдельного человека.
Вы извините… Можете меня заминусить, сказать что я выскочка, да вообще сказать что я может даже ничему не соответствую…
Но в бизнесе как правило командная работа в IT наступает только когда этот IT приносит прибыль! В остальных случаях IT большинством ТОПов считается «расходная статья бюджета».
Я могу конечно же посетовать на то что я вообще начал с сис. администратора(эникейщика) а закончил ведущим инженером(Ога, который держит в своих руках, сеть, контролеры домена, oracle pm primavera, sharepoint( для этого самого бизнеса), exchange, postfix( работающий в промышленных масштабах на 15тыс пользователей), и так далее). И я могу сказать что весь бизнес вообще начинался с старого хлама от dlink(dslam), cisco роутеров, и не самых нормальных полу убитых catalyst 5000 серии. Этим всем занимался я, к сожалению много руководителей отдела организации связи поменялось, но до сих пор нормальных инженеров которые бы знали что такое SQL, или чем отличается postfix от exchange я не видел. У нас работает более 100 инженеров, программистов, руководителей различных информационных подразделей(sic!). Но когда падает сеть звонят мне, когда падает ферма из KVM гипервизоров звонят опять таки мне, когда падает call manager (из за того что, манагерам религия не позволяет раскошелиться на нормальные APC UPS системы а держится все на powercom который не предназначен на нагрузки ЦОДа) опять таки звонят мне.
Это команда справляется с поддержкой пользователей, и дописываем определенные вещи в sharepoint, но эта команда не может справится с сетями, а так же с многими тривиальными задачами.
В бизнесе к сожалению ставят задачу, и если ты с ней справился то, молодец!!! И получишь свой кусочек хлеба, если нет то пополняешь армию безработных
Но в бизнесе как правило командная работа в IT наступает только когда этот IT приносит прибыль! В остальных случаях IT большинством ТОПов считается «расходная статья бюджета».
Я могу конечно же посетовать на то что я вообще начал с сис. администратора(эникейщика) а закончил ведущим инженером(Ога, который держит в своих руках, сеть, контролеры домена, oracle pm primavera, sharepoint( для этого самого бизнеса), exchange, postfix( работающий в промышленных масштабах на 15тыс пользователей), и так далее). И я могу сказать что весь бизнес вообще начинался с старого хлама от dlink(dslam), cisco роутеров, и не самых нормальных полу убитых catalyst 5000 серии. Этим всем занимался я, к сожалению много руководителей отдела организации связи поменялось, но до сих пор нормальных инженеров которые бы знали что такое SQL, или чем отличается postfix от exchange я не видел. У нас работает более 100 инженеров, программистов, руководителей различных информационных подразделей(sic!). Но когда падает сеть звонят мне, когда падает ферма из KVM гипервизоров звонят опять таки мне, когда падает call manager (из за того что, манагерам религия не позволяет раскошелиться на нормальные APC UPS системы а держится все на powercom который не предназначен на нагрузки ЦОДа) опять таки звонят мне.
Это команда справляется с поддержкой пользователей, и дописываем определенные вещи в sharepoint, но эта команда не может справится с сетями, а так же с многими тривиальными задачами.
В бизнесе к сожалению ставят задачу, и если ты с ней справился то, молодец!!! И получишь свой кусочек хлеба, если нет то пополняешь армию безработных
Вы за деревьями не видите леса. Решение этой задачи лежит на поверхности. А вот ее адекватность вызывает сомнения. На кой черт использовать вместо сущности очередь два стека? Первая не реализована в библиотеках к языку, а стек реализован? Сильно сомневаюсь. А если и так — наверняка очередь уже кто-то написал. Взять и пользоваться. Нету — тогда написать, и не на стеках, а нормально.
То же с сортировкой — зачемзнать помнить внутреннее устройство QuickSort, если в любом приличном языке он уже реализован в библиотеке? Прошли в институте один раз, поняли как использовать и выкинули из головы как устроено.
Об этом автор и пишет, что задаваемые вопросы имеют мало общего с реальными потребностями.
То же с сортировкой — зачем
Об этом автор и пишет, что задаваемые вопросы имеют мало общего с реальными потребностями.
avz, дело не в вопросах, и даже не в ответах на них. Дело в отношении к работе и работодателю. Для ответа на вопрос требуется усилие. Если программисту лень его проявить — он или тупой, или ленивый, или не хочет «думать забесплатно». Все три варианта часто плохи для работодателя.
Есть другой способ — скажите, как нужно правильно собеседовать программистов? Как бы вы это делали?
Есть другой способ — скажите, как нужно правильно собеседовать программистов? Как бы вы это делали?
Ок, а если программист не тупой, а понимает что в дальнейшем данный go to только навредит?
Если компании не хочется революций в своей работе, а программист не согласен работать по её правилам, то они расстанутся к обоюдному согласию. Если программист не тупой, и тем не менее, хочет работать именно в этом месте, он решит задачу требуемым способом, хотя бы чтобы показать, что он может работать и в этих условиях. У компании вполне могут быть свои причины не использовать сторонних библиотек и языков, в которых очередь уже реализована. А уже потом, разобравшись в ситуации, можно попробовать сдивинуть её в правильном направлении. Хотя бы на своём участке.
понимает что в дальнейшем данный go to только навредит
Значит, надо обосновать, почему навредит, а не говорить, что решение элементарно гуглится.
Для ответа на вопрос требуется усилие. Если программисту лень его проявить — он или тупой, или ленивый, или не хочет «думать забесплатно». Все три варианта часто плохи для работодателя.
А если просто память плоха на то, что 10-20 лет назад изучал, а на практике не использовал ни разу? На собеседованиях ведь погуглить не дают.
Я не отвечаю на вопрос сразу: «Не знаю». Это равносильно «пошёл нафиг со своими дурацкими вопросами». Я сначала думаю до тех пор, пока у работодателя не случится таймаут или начинаю выдвигать гипотезы.
Что касается собеседования программистов — я своих собеседовал очень просто — условно говоря прогонял тупо по всей документации на требуемую технологию, или по стандарту языка, начиная с простейших вопросов о том, какие в языке есть типы, а затем давал несколько простейших задач, чтобы выяснить практические навыки. Этого было достаточно.
Что касается собеседования программистов — я своих собеседовал очень просто — условно говоря прогонял тупо по всей документации на требуемую технологию, или по стандарту языка, начиная с простейших вопросов о том, какие в языке есть типы, а затем давал несколько простейших задач, чтобы выяснить практические навыки. Этого было достаточно.
На кой черт использовать вместо сущности очередь два стека?Например, чтобы решить для очереди задачу, уже решённую для стека.
http://e-maxx.ru/algo/stacks_for_minima
То же с сортировкой — зачем знать помнить внутреннее устройство QuickSort, если в любом приличном языке он уже реализован в библиотеке?
Например затем, чтобы суметь написать многопоточную сортировку, которой нету в известных мне фреймворках. Или суметь написать неполный QuickSort если из массива в миллион нужно найти Top 100, или написать QuickSort в виде StateMachine, потому что компаратор — это пользователь веб-страницы.
Прошу обратить внимание, что это не абстрактные примеры, все это мне реально приходилось делать.
Ну, так можно посмотреть описание quicksort где-нибудь в сети и быстренько переделать его на то, что надо. Тем более, если алгоритм когда-то проходили в институте.
Другое дело, что для этого нужен немалый опыт алгоритмиста, но если он имеется — зачем помнить детали? Главное, знать, что они есть ;)
Другое дело, что для этого нужен немалый опыт алгоритмиста, но если он имеется — зачем помнить детали? Главное, знать, что они есть ;)
Ааа! Про top 100 меня тоже кто-то спрашивал, и я начал невнятицу нести типо что надо отсортировать всё, а потом взять последние 100… это не Вы меня собеседовали?
А оно требовалось за гарантированно линейное время? Или было достаточно «с большой вероятностью линейного»?
Задача полностью звучала так: «Даны 5 компьютеров. Дан внешний генератор случайной последовательности из 10 ^ 7 целых неотрицательных чисел, которые проходят через функцию f(x) такую, что f(xi) != f(xj) для любого x последовательности (дабы избежать возможности кеширования). Задача. Спроектируйте наиболее эффективную систему с описанием архитектуры и используемых алгоритмов, масштабирующуюся на эти компьютеры так, чтобы она выдавала актуальный top 100 от результата f(x). Можно при этом использовать термины наподобие „шина данных“.
1. Берем 1 комп
2. Скармливаем ему последовательность, top100 храним в куче
3. отключаем остальные 4 компа, чтоб не жрали электричество
4.…
5. PROFIT!
2. Скармливаем ему последовательность, top100 храним в куче
3. отключаем остальные 4 компа, чтоб не жрали электричество
4.…
5. PROFIT!
Не-не-не. Надо чтобы во время вычисления top100 на одном компьютере другие бы вызывали f(x), общались бы с генератором или еще что-то делали — так будет эффективнее. Генератор не помню где у них был — то ли внешний, то ли на одном из этих пяти… да и последовательность была длиннее. Не помню, сколько точно.
Похоже на гугловскую задачу. :-) Вы точно не у меня собеседовались.
Я попроще спрашиваю. Выбрать k наибольших из N. При этом N >> k
Задача кажется простой до безобразия. Но при N измеряющихся миллионами… можно очень сильно сэкономить по времени, особенно если k и N отличаются на порядки
Я попроще спрашиваю. Выбрать k наибольших из N. При этом N >> k
Задача кажется простой до безобразия. Но при N измеряющихся миллионами… можно очень сильно сэкономить по времени, особенно если k и N отличаются на порядки
А числа в случайной последовательности повторяться могут? А если повторяются то в top100 они входят столько же раз сколько повторились?
Большинство фундаментальных вопросов на сообразительность не представляют ни научного, ни инженерного интереса. А если представляют, то вряд ли их зададут на собеседовании (последняя научная проблема, решенная в процессе чисто учебного процесса, известная мне — распределение Максвелла, которое он получил на экзамене, решив с его помощью задачу)
А задаются эти вопросы с двумя целями:
1. Понять, насколько человек сообразителен и способен ли он думать не stl и google-ом, а собственной головой
2. Понять, как человек решает вставшую перед ним проблему. Будет он подходить серьёзно и аккуратно, или просто попытается свалить эту проблему на других. Станет искать простое решение, или будет придумывать танк для стрельбы по воробьям. И, наконец, — готов ли он решать задачу в условиях нехватки информации, или заноет в духе «дайте мне гугл, я без него не могу». Гугл тоже не всеведущ. Если вам в жизни ни разу не приходилось создавать то, чего он не знает, значит вы не занимались ничем интересным.
Я в последний раз засыпался на собеседовании у очень умных и адекватных людей (по-моему) после того, как на просьбу написать довольно простую программу я ее написал, но не выполнил в ней обработку исключений. А задание было — написать промышленную программу, решающую простую задачу.
Сперва было обидно, но затем я понял, что с тем же успехом мог позабыть проверку исключений в серьёзном проекте, а это — непростительный просчёт. Это стало для меня своего рода уроком.
А задаются эти вопросы с двумя целями:
1. Понять, насколько человек сообразителен и способен ли он думать не stl и google-ом, а собственной головой
2. Понять, как человек решает вставшую перед ним проблему. Будет он подходить серьёзно и аккуратно, или просто попытается свалить эту проблему на других. Станет искать простое решение, или будет придумывать танк для стрельбы по воробьям. И, наконец, — готов ли он решать задачу в условиях нехватки информации, или заноет в духе «дайте мне гугл, я без него не могу». Гугл тоже не всеведущ. Если вам в жизни ни разу не приходилось создавать то, чего он не знает, значит вы не занимались ничем интересным.
Я в последний раз засыпался на собеседовании у очень умных и адекватных людей (по-моему) после того, как на просьбу написать довольно простую программу я ее написал, но не выполнил в ней обработку исключений. А задание было — написать промышленную программу, решающую простую задачу.
Сперва было обидно, но затем я понял, что с тем же успехом мог позабыть проверку исключений в серьёзном проекте, а это — непростительный просчёт. Это стало для меня своего рода уроком.
Интересно, какая была задача?
Я вообще за принцип «let it fail»: если происходит непоправимое исключение, задача инфраструктуры его обработать.
Я вообще за принцип «let it fail»: если происходит непоправимое исключение, задача инфраструктуры его обработать.
Я не помню точно — что-то простое, пишущееся на бумажке за 10 минут. Суть не в том — просто я не смог правильно понять и решить основную задачу — «написать готовый пользовательский продукт». Суть задачи была не «сделать, чтобы работало» и даже не «сделать красиво», а в первую очередь «сделать надёжно».
Могу опровергнуть. Я не ленивый. Не «звезжу». Командный я игрок, почти всю жизнь работал я в Agile, и не на ведущих ролях.
Я стараюсь взять на себя всю черную работу, если это необходимо команде, болею за дело и за команду. Я так работал 15 лет.
Два стэка и очередь — да, но нужно написать имплементацию. То, что Вы пишете, понимал и я. Я же не смог за отведённое время написать имплементацию. Нужно чётко, очень чётко структурировать. Когда делать это перекладывание? Мешают догмы, стереотипы, устоявшиеся в голове модели.
Я стараюсь взять на себя всю черную работу, если это необходимо команде, болею за дело и за команду. Я так работал 15 лет.
Два стэка и очередь — да, но нужно написать имплементацию. То, что Вы пишете, понимал и я. Я же не смог за отведённое время написать имплементацию. Нужно чётко, очень чётко структурировать. Когда делать это перекладывание? Мешают догмы, стереотипы, устоявшиеся в голове модели.
Похоже, у Вас путь «нестандартного» программиста. А «стандарту» найти место под Солнцем всегда проще, поверьте. Немного непонятно, на что именно Вы жалуетесь и что именно Вас не устраивает (а такое чувство почему-то присутствует). Посмотрите ru.xored.com — там весьма понятно и просто описано и про «нестандарт», и про мотивацию, и про синергию, и про многое другое. Просто примите себя таким, какой Вы есть, найдите свое и идите дальше. Или уходите из профессии вообще — это не совет, и даже не критика — просто ощущение от статьи. Я сам недавно таким образом чуть не перегорел — но «переварил» и пошел дальше. Определитесь с тем, что дальше — и будет проще.
Насчет ухода из профессии небольшой комментарий.
Чтобы опубликовать эту статью, у меня не хватало кармы, что стало для меня неприятной неожиданностью. Habrahabr-ом я раньше не пользовался. Я понял, что нужно срочно, очень срочно заработать карму. Как? Только один способ: надо срочно написать статью в профильный хаб. Какую статью? С какого, собственно, перепугу? И, вот идея! Есть опция «перевод»! Я за 1.5 часа написал перевод этой документации: code.google.com/p/shedskin/wiki/docs
Вот он: habrahabr.ru/post/194650/
Хороший перевод получился? По-моему, не очень. Но я его набрал вслепую за 1.5 часа и заработал 5 баллов кармы, что мне как раз хватило на публикацию данной статьи о работодателях и выборе профессии.
Написать перевод мне не составило никакого труда и даже было немного приятно.
Что это значит? Значит, что мне надо бросать свой 20-летний опыт и кидаться к переводчикам, где меня сочтут гораздо большим профаном, чем программисты? Смешно.
Чтобы опубликовать эту статью, у меня не хватало кармы, что стало для меня неприятной неожиданностью. Habrahabr-ом я раньше не пользовался. Я понял, что нужно срочно, очень срочно заработать карму. Как? Только один способ: надо срочно написать статью в профильный хаб. Какую статью? С какого, собственно, перепугу? И, вот идея! Есть опция «перевод»! Я за 1.5 часа написал перевод этой документации: code.google.com/p/shedskin/wiki/docs
Вот он: habrahabr.ru/post/194650/
Хороший перевод получился? По-моему, не очень. Но я его набрал вслепую за 1.5 часа и заработал 5 баллов кармы, что мне как раз хватило на публикацию данной статьи о работодателях и выборе профессии.
Написать перевод мне не составило никакого труда и даже было немного приятно.
Что это значит? Значит, что мне надо бросать свой 20-летний опыт и кидаться к переводчикам, где меня сочтут гораздо большим профаном, чем программисты? Смешно.
Вы почти угадали: можно пробовать что-то, кажущееся совсем «непрофильным», «не Вашим», Как кажется на первый взгляд: переводами, HR, статьями, уехать на тропический остров или стать модератором где-нибудь на Stack Overflow (нужное подчеркнуть)… вообще любыми вещами, от которых в данный момент Вас «прет». Не ради того, чтобы заработать карму, а просто так. Не ради собеседований, бонусных очков и работодателей, не ради престижной работы, а для себя. И тогда рано или поздно найдете вещи, на которые раньше Вы не обращали внимания и которые покажутся Вам в совершенно другом свете. А если не прет уже ничего — значит, действительно перегорели. Хотя я лично не верю, что так бывает — когда «не прет» вообще. Нужно просто уметь найти свое, а не искать причину «почему меня не берут на работу в Гугл». Нужна самореализация или тупо не хватает денег?.. Если денег — то их можно пойти и заработать, но без внутреннего «драйва», если просто плыть по течению, они удовлетворения не принесут. И иногда нужно плыть против течения — иначе этого драйва не почувствуешь никогда. А искать причины всего, что и почему — не увлекайтесь… это вообще очень соответствует нашему менталитету — и иногда это хорошо, но иногда очень вредно. Потому, что просто есть как есть — кто-то в девяностые работал таксистом и перегонял машины из Владивостока, а теперь рулит компанией с миллиардными оборотами; а кто-то коллекционировал самолетики… И то, и другое — не хорошо, и не плохо. Просто так есть, это жизнь. Извините, если где-то жестко сказал — не в обиду.
С большим интересом прочитал вашу заметку, спасибо.
Есть мнение, что у работодателей есть определенные градации. Вы готовы пойти на их жуниорскую позицию и там за идею работать 12 часов 6 дней в неделю? Сомневаюсь. Скорее всего, вы будете таким подходом возмущаться и развалите весь тимбилдинг :)))
По возрасту вы попадаете не менее чем на senior/ведущего. Вы очень честно написали с какими технологиями у вас были проблемы при ответах. Я удивился, что это прошло мимо вас, т.к. все эти вопросы действительно нужные, из пальца тут ничего не высосано. И спрашивали это у вас сугубо потому, что оно всплывет, и только ведущий программист или архитектор, кто там у них, сможет и должен докопаться. Если вы нес можете залезть в сеть с анализатором пакетов, что не сможет сделать молодой программист, то кто же тогда сможет??
ООП. ООП — это наше все. Молодой напишет ерунду. Не зная теоретических основ вы не сможете сказать, что он написал неправильно, не сможете его исправить. Вот это все работодателей и не устроило, причем на дальних подступах :(
Я программирую с 1990 года, сразу на х86, то есть тоже дофига лет. Последние 10 лет взял за себя правило: изучать в год не менее одной новой технологии: язык, платформу. Это единственный способ в нашей работе остатья на плаву, не перестать уважать самого себя, уметь сравнивать технологии осмысленно, осмысленно делать выбор.
Желаю вам подтянуть-почитать и всех их победить :) Времени еще хватает.
Есть мнение, что у работодателей есть определенные градации. Вы готовы пойти на их жуниорскую позицию и там за идею работать 12 часов 6 дней в неделю? Сомневаюсь. Скорее всего, вы будете таким подходом возмущаться и развалите весь тимбилдинг :)))
По возрасту вы попадаете не менее чем на senior/ведущего. Вы очень честно написали с какими технологиями у вас были проблемы при ответах. Я удивился, что это прошло мимо вас, т.к. все эти вопросы действительно нужные, из пальца тут ничего не высосано. И спрашивали это у вас сугубо потому, что оно всплывет, и только ведущий программист или архитектор, кто там у них, сможет и должен докопаться. Если вы нес можете залезть в сеть с анализатором пакетов, что не сможет сделать молодой программист, то кто же тогда сможет??
ООП. ООП — это наше все. Молодой напишет ерунду. Не зная теоретических основ вы не сможете сказать, что он написал неправильно, не сможете его исправить. Вот это все работодателей и не устроило, причем на дальних подступах :(
Я программирую с 1990 года, сразу на х86, то есть тоже дофига лет. Последние 10 лет взял за себя правило: изучать в год не менее одной новой технологии: язык, платформу. Это единственный способ в нашей работе остатья на плаву, не перестать уважать самого себя, уметь сравнивать технологии осмысленно, осмысленно делать выбор.
Желаю вам подтянуть-почитать и всех их победить :) Времени еще хватает.
По возрасту вы попадаете не менее чем на senior/ведущего.
Вот как так по возрасту судить на кого человек попадает?
Видимо, критерий такой: если к такому возрасту человек не дорос до подобных высот, значит он либо бездельник, либо дурак, либо обладает какими-то скрытыми личными недостатками, противоречащими карьерному росту. Не мне судить, насколько это верно — сам еще слишком молод и неопытен.
Помимо этого, очевидно, человек, давно и прочно стоящий на ногах в жизни, имеющий, скорее всего, семью, просто банально нуждается в деньгах. А если у него ни семьи, ни стабильности в жизни, значит см. первый абзац. Что-то с ним нечисто. Слышал как-то точку зрения, что женщин после 30 и мужчин после 35 без семьи на работу принимать не комильфо. Это, по-моему, чушь, но мнение такое имеется.
Помимо этого, очевидно, человек, давно и прочно стоящий на ногах в жизни, имеющий, скорее всего, семью, просто банально нуждается в деньгах. А если у него ни семьи, ни стабильности в жизни, значит см. первый абзац. Что-то с ним нечисто. Слышал как-то точку зрения, что женщин после 30 и мужчин после 35 без семьи на работу принимать не комильфо. Это, по-моему, чушь, но мнение такое имеется.
Прокомментирую тоже с позиции работодателя. Скажу сразу, что излагаю мнение, сложившееся на основе прочтения поста (и особенно списка вопросов-ответов с собеседования). Сказать, взял ли я бы вас на работу можно было бы только после собеседования и выполнения тестовых задач.
Так вот, из поста видны два недостатка:
1. Есть ощущение, что человек находится в состоянии неосознанной некомпетентности по многим технологиям. ТС пишет, что «блестяще изучил с++», но не может назвать принципов ООП. Упоминает семиуровневую модель OSI, но не отвечает на вопрос про TCP протокол. Для меня это тревожный звонок (даже если по другим технологиям этот человек действительно компетентен). Осознанная некомпетентность гораздо лучше, чем неосознанная — особенно у зрелого человека. В случае ТС у меня есть риск, что мне придется не только дообучать его, но и доказывать, что он не так компетентен, как ему кажется.
2. Есть ощущение, что ТС больше ориентирован на процесс, а не на результат. Мне как работодателю не интересны «мегабайты кода» — мне интересен уровень решенных задач, а в посте про задачи как-то практически ничего нет — только про технологии. Опыт показывает, что разработка ПО — это такая область, где можно месяцами работать днями и ночами, а на выходе получить ноль. Так что интенсивность работы и объем кода не являются мерилом уровня разработчика. Причем если ориентированность на процесс у студента — это, в целом нормально, то от зрелого разработчика ожидаешь четкую направленность на решение задач.
Мой совет ТС был бы таким:
1. Если моя оценка не верна, исправить подачу своего опыта и компетенций. Потому что из поста (а я так понимаю, резюме ему примерно аналогично) складывается именно такое впечатление, как я описал.
2. Если все-таки доля правды есть, то более трезво оценить свои компетенции, выбрать наиболее сильные и интересные, и делать упор именно на них. Или совершенствовать те, которые развиты недостаточно.
P.S. И насчет студентов без опыта не соглашусь (по крайней мере для МСК). Умные ребята обычно трудоустроены уже на 4-5 курсах. Мы всегда рассматриваем кандидатуры и выпускников, и студентов. Причем если человек действительно перспективный, то как правило он выбирает среди предложений, а не наоборот. То есть наша стратегия подбора — это найти правильного человека, а потом уже «продать» ему компанию.
Ну и еще скажу, что вопрос совместимости разработчиков по возрасту — это вполне серьезный момент. Ситуация, когда тимлид, например, младше своего разработчика, потенциально может быть источником конфликта и разрушительно подействовать на команду. Так что при прочих равных возрастной уровень лучше держать уравновешенным. Но это только в общем случае и ни в коем случае не является правилом.
Так вот, из поста видны два недостатка:
1. Есть ощущение, что человек находится в состоянии неосознанной некомпетентности по многим технологиям. ТС пишет, что «блестяще изучил с++», но не может назвать принципов ООП. Упоминает семиуровневую модель OSI, но не отвечает на вопрос про TCP протокол. Для меня это тревожный звонок (даже если по другим технологиям этот человек действительно компетентен). Осознанная некомпетентность гораздо лучше, чем неосознанная — особенно у зрелого человека. В случае ТС у меня есть риск, что мне придется не только дообучать его, но и доказывать, что он не так компетентен, как ему кажется.
2. Есть ощущение, что ТС больше ориентирован на процесс, а не на результат. Мне как работодателю не интересны «мегабайты кода» — мне интересен уровень решенных задач, а в посте про задачи как-то практически ничего нет — только про технологии. Опыт показывает, что разработка ПО — это такая область, где можно месяцами работать днями и ночами, а на выходе получить ноль. Так что интенсивность работы и объем кода не являются мерилом уровня разработчика. Причем если ориентированность на процесс у студента — это, в целом нормально, то от зрелого разработчика ожидаешь четкую направленность на решение задач.
Мой совет ТС был бы таким:
1. Если моя оценка не верна, исправить подачу своего опыта и компетенций. Потому что из поста (а я так понимаю, резюме ему примерно аналогично) складывается именно такое впечатление, как я описал.
2. Если все-таки доля правды есть, то более трезво оценить свои компетенции, выбрать наиболее сильные и интересные, и делать упор именно на них. Или совершенствовать те, которые развиты недостаточно.
P.S. И насчет студентов без опыта не соглашусь (по крайней мере для МСК). Умные ребята обычно трудоустроены уже на 4-5 курсах. Мы всегда рассматриваем кандидатуры и выпускников, и студентов. Причем если человек действительно перспективный, то как правило он выбирает среди предложений, а не наоборот. То есть наша стратегия подбора — это найти правильного человека, а потом уже «продать» ему компанию.
Ну и еще скажу, что вопрос совместимости разработчиков по возрасту — это вполне серьезный момент. Ситуация, когда тимлид, например, младше своего разработчика, потенциально может быть источником конфликта и разрушительно подействовать на команду. Так что при прочих равных возрастной уровень лучше держать уравновешенным. Но это только в общем случае и ни в коем случае не является правилом.
Основные принципы ООП — инкапсуляция, наследование и полиморфизм. Это я замечательно знаю и заучил еще с ВУЗа. Я могу описать их подробнее. Но эти парни имеют в виду какой-то принцип SOLID из 5 букв, о котором я впервые слышу.
Что такое «чёткая направленность на решение задач»? В моём резюме эта сфера, то есть, достижения, замечательно описана: mikhail-gorshkov.moikrug.ru/
Я не понимаю, куда ещё можно быть направленным, как не на решение задач? На просмотр соцсетей, что ли? Я считаю деньги работодателя и делаю задачи.
Возраст не главное, мои тимлиды всю жизнь были моложе меня, что не мешало нам эффективно работать вместе.
Что такое «чёткая направленность на решение задач»? В моём резюме эта сфера, то есть, достижения, замечательно описана: mikhail-gorshkov.moikrug.ru/
Я не понимаю, куда ещё можно быть направленным, как не на решение задач? На просмотр соцсетей, что ли? Я считаю деньги работодателя и делаю задачи.
Возраст не главное, мои тимлиды всю жизнь были моложе меня, что не мешало нам эффективно работать вместе.
Ах, это SOLID они имею в виду — ни в жизнь бы не догадался :) Так это принципы проектирования класса. Требовать знать их наизусть как-то странно. Да и буквальное их выполнение часто приводит к перегруженной архитектуре. Особенно принцип, по которому классы не должны изменяться.
Это значит, что класс нельзя менять, а надо от него наследоваться при необходимости. Это, по моему, и так очевидно, без всякого SOLID-a.
Для меня это далеко не очевидно. Есть, скажем, класс Article для движка сайта, есть атрибуты Title, Content, Authors, и т. п. Сделал, сдал, сайт работает, количество статей растет, ориентироваться пользователям становится сложно и захотел заказчик прикрутить к каждой статье ещё категорию. Делать класс CategorizedArticle, унаследованный от Article, который лишь добавляет один атрибут и во всем коде заменять Article на CategorizedArticle? Ради чего? Чем архитектура и/или код, в котором есть два этих класса лучше той, в которой один класс, если класс Article используется ровно в одно месте — для объявления класса CategorizedArticle?
Вы описываете, вероятно, вырожденный частный случай, к которому, наверное, действительно впрямую неприменим этот подход, но я думаю, что если есть готовая имплементация класса, и у нее есть пользователи, то по живому её менять — значит, подвергать риску этих пользователей. Есть же юнит-тесты к классу, наконец, которые надо исправлять. Чтобы всего этого не делать, надо просто отнаследоваться (к тому же, если это не просто формальное изменение, а новый функционал, и есть юзера старого функционала).
Так в том-то и дело, что существующее поведение не меняется, юнит-тесты менять не нужно. Если кто-то продолжает пользоваться новым классом Article как старым, то он ничего не заметит. Свойство Category даже может использоваться в старых методах типа getFullTitle(), но если его не инициализировать (null или типа того), то результат getFullTitle() тоже не изменится, хотя реализация getFullTitle изменится.
В общем на «принцип ООП» OCP, имо, не тянет. Так, рекомендация, о которой полезно знать, но не использовать её бездумно.
В общем на «принцип ООП» OCP, имо, не тянет. Так, рекомендация, о которой полезно знать, но не использовать её бездумно.
Ой, что это? Почему сохраненные в БД сезиализованные данные (статьи, и т.д.) перестали читаться? А-а-а!!!
Иными словами, существующее поведение (если это можно так назвать) таки меняется. Хотя это от способа сериализации зависит, конечно.
Иными словами, существующее поведение (если это можно так назвать) таки меняется. Хотя это от способа сериализации зависит, конечно.
А причем тут БД? По принципу единственной ответственности в классе Article никакого кода взаимодействия с БД нет. :)
У класса Atricle нет, а у какого-нибудь другого класса ArticleManager могут и быть. Как насчет имплементации метода saveArticle(Article a)? Сделали. Допустим, сохраняем сериализованные объекты класса Article со сжатием, всё работает… точнее работало, до того, как кто-то залез руками в наш любимый Article и что-то туда добавил. :)
EntityManager всё равно будет рефлексией пользоваться, если Article себя почему-то сериализовывать не умеет.
Зачем же рефлексией, это уже чит, с таким подходом можно просто все поля пабликами делать. Наш Article хороший, умеет себя сериализовывать, бинарный формат, последовательно пишет в поток содержимое своих полей. Это так архитектор того проекта задумал изначально, в лучших традициях конца 90х годов. Он молодец, че. Был. Проект уже 15 лет в продакшене, и сейчас мы просто дописываем код, добавляем новые фичи. Вот, возникла потребность категории в статьи добавить.
А, забыл добавить, движок проекта успешно жужжит примерно на тридцати тысячах хостов партнеров, которые время от времени получают от нас обновления, в том числе обновления либы, включающей в себя класс Article. И что они там у себя дописали для работы с классом Article, какие плагины и т.д. мы не знаем, и это не наше дело. У них может быть и рефлекшен, и унаследование нашего теплого лампового Article в свой монстрокласс с переопределением всех методов, и что угодно.
А, забыл добавить, движок проекта успешно жужжит примерно на тридцати тысячах хостов партнеров, которые время от времени получают от нас обновления, в том числе обновления либы, включающей в себя класс Article. И что они там у себя дописали для работы с классом Article, какие плагины и т.д. мы не знаем, и это не наше дело. У них может быть и рефлекшен, и унаследование нашего теплого лампового Article в свой монстрокласс с переопределением всех методов, и что угодно.
А, забыл добавить, движок проекта успешно жужжит примерно на тридцати тысячах хостов партнеров
С этого надо было начинать. Я же описывал другую ситуацию — индивидуальная разработка.
Очень приятно читать обсуждение в этом треде. Прямо ощущение дежавю. Всякий раз, когда появляется необходимость придумать архитектуру для некоторой задачи (или изменить/расширить), возникает куча паттернов проектирования, правил и т. п…
Правила и шаблоны — это, конечно, хорошо. Если вы — новичок и ничего не смыслите в проектировании архитектуры. Если же вы — опытный человек, вероятно, правило лишь одно — «думай головой над каждым конкретным случаем». А шаблоны проектирования при всём уважении к их апологетам, должны рождаться в голове проектирующего, чтобы быть его собственными.
Но в реальности они остаются чужими. Человек просто прочёл в книге, называемой «Принцип ЁКЛМН», что классы нельзя расширять — только наследоваться — и он начинает по каждому чиху плодить наследников, так что его код сворачивается в лист Мёбиуса.
А другой в книжке «10 основных правил ООП» прочитал, что наследование — вообще злобное зло, надо всегда делать обёртки. Или фабрики. Или еще как-нибудь делать, только не писать этот ужасный «extends» или там двоеточие…
И вот встретят они друг друга в недобрый час в одном проекте и начинается игра в шашки (это я, разумеется, не про обсуждавших господ — здесь чисто гипотетический пример). Один говорит «долой наследование», а другой это наследование требует по каждому поводу.
А потом пришел третий и ни фига не понял, что в коде написано — сплошные костыли и баги.
Думать надо своей головой. И на собеседовании проверять, умеет ли человек думать. Я бы тех, кто на вопрос о решении поставленной задачи говорил «применяем паттерн такой-то» просил объяснить, что это за паттерн такой, а главное — какие альтернативные способы решения он знает. Если говорит, что альтернатив нет, значит долой его. Я не прав?
(Сам я, к слову, еще задолго до того, как услышал, к стыду своему, весьма поздно, понятие «паттерн проектирования», придумал себе систему этих самых паттернов, среди которых был и observer, и factory, и pool. Только не знал, как они называются. Названия мне рассказали на собеседовании умные люди ;) )
Правила и шаблоны — это, конечно, хорошо. Если вы — новичок и ничего не смыслите в проектировании архитектуры. Если же вы — опытный человек, вероятно, правило лишь одно — «думай головой над каждым конкретным случаем». А шаблоны проектирования при всём уважении к их апологетам, должны рождаться в голове проектирующего, чтобы быть его собственными.
Но в реальности они остаются чужими. Человек просто прочёл в книге, называемой «Принцип ЁКЛМН», что классы нельзя расширять — только наследоваться — и он начинает по каждому чиху плодить наследников, так что его код сворачивается в лист Мёбиуса.
А другой в книжке «10 основных правил ООП» прочитал, что наследование — вообще злобное зло, надо всегда делать обёртки. Или фабрики. Или еще как-нибудь делать, только не писать этот ужасный «extends» или там двоеточие…
И вот встретят они друг друга в недобрый час в одном проекте и начинается игра в шашки (это я, разумеется, не про обсуждавших господ — здесь чисто гипотетический пример). Один говорит «долой наследование», а другой это наследование требует по каждому поводу.
А потом пришел третий и ни фига не понял, что в коде написано — сплошные костыли и баги.
Думать надо своей головой. И на собеседовании проверять, умеет ли человек думать. Я бы тех, кто на вопрос о решении поставленной задачи говорил «применяем паттерн такой-то» просил объяснить, что это за паттерн такой, а главное — какие альтернативные способы решения он знает. Если говорит, что альтернатив нет, значит долой его. Я не прав?
(Сам я, к слову, еще задолго до того, как услышал, к стыду своему, весьма поздно, понятие «паттерн проектирования», придумал себе систему этих самых паттернов, среди которых был и observer, и factory, и pool. Только не знал, как они называются. Названия мне рассказали на собеседовании умные люди ;) )
а главное — какие альтернативные способы решения он знает. Если говорит, что альтернатив нет, значит долой его. Я не прав?
Частично. Я тоже «наизобретал» кучу паттернов методов проб и ошибок, а потом узнал что это паттерны. Но уже как-то ошибки в голову не приходят.
Так вот в том и соль. Я — сторонник сакратического метода образования. Считаю, что чтобы человек что-то действительно хорошо понял, он должен до этого додуматься, решая задачу сам. Если просто взять и объяснить ему готовое решение, пользы будет в разы меньше.
Именно по этой причине, я думаю, многие истинные мастера своего дела во многих областях поднимались из полуграмотных молодых людей. Не имея амбиций, навязанных регулярным образованием, они привыкли до всего доходить своим собственным умом и не останавливались в этом процессе, пока не достигали заоблачных высот.
Увы, такое образование на поток не поставишь — оно слишком дорого стоит и требует слишком индивидуального подхода
Именно по этой причине, я думаю, многие истинные мастера своего дела во многих областях поднимались из полуграмотных молодых людей. Не имея амбиций, навязанных регулярным образованием, они привыкли до всего доходить своим собственным умом и не останавливались в этом процессе, пока не достигали заоблачных высот.
Увы, такое образование на поток не поставишь — оно слишком дорого стоит и требует слишком индивидуального подхода
Всё правильно, согласен. Про паттерны разве что могу добавить, что конторы правильно делают, что на собеседованиях про них спрашивают. Мало уметь думать головой, нужно еще и говорить с командой на одном языке. Например, если кто-то упоминает cинглтон, фабрику, или декоратор, то остальные должны это как минимум это понимать и уметь реализовать.
Вот — да. Учил их прежде всего как язык, чтобы меня понимали. Правда замечаю, что те, чье понимание обычно ценнее всего, поймут даже если просто обговорить, что и как работает. А те, кому нужны эти «магические слова» обычно «думают паттернами» и с ними что либо обсуждать бессмысленно, так как в реальных задачах почти никогда паттерны в чистом виде не встречаются. Всегда так или иначе гибридизируются…
Вот и на собеседованиях надо спрашивать не «какие паттерны вы знаете?» (интересно, кто-нибудь вообще способен их перечислить, чтобы от зубов отскакивало, не забыв ни одного указанного хотя бы в GoF и у Фаулера?), а «Что означает паттерн X? Как вы будете его реализовывать на языке Y? С какими трудностями встретитесь и как будете их обходить?».
== сохраненные в БД *сериализованные* данные ==
Сохранённые в БД *структурированные* данные :)) Может ещё сохранённые в БД *упакованные* данные? Что там у нас с объектными СУБД на рынке творится?
Такой подход часто встречается, когда сериализованные данные где-либо хранятся — в сессии ли, в БД ли, в файловой системе ли, и т.д. Или другой пример, если кто делает ремотные вызовы, передавая экземпляры класса как параметры или возвращая их. В этом случае аналогично используется сериализация. При изменении класса формат сериализованых данных уже будет другим, если, конечно, не реализовывать сериализацию самому. Вполне возможно, что и пользователям класса придется вносить соответствующие изменения в свой код, но вообще они могут это и не сразу заметить, что чревато.
В общем, это лишь пример, подчеркивающий, что принцип OCP оправдывает себя в большинстве случаев. Просто еще один шаг в сторону безопасного программирования.
В общем, это лишь пример, подчеркивающий, что принцип OCP оправдывает себя в большинстве случаев. Просто еще один шаг в сторону безопасного программирования.
Михаил, не думаю, что есть смысл обсуждать конкретные кейсы. Я лишь изложил то впечатление, которое сложилось у меня на основе вашего поста. Предполагаю, что аналогичное мнение может сложиться и у других работодателей. Что с этим делать — вам решать.
Не сомневаюсь, что многие собеседования по подбору разработчиков проводятся непрофессионально. Но при этом вряд ли этим поголовно грешат крупные IT компании, такие как Yandex, Rambler и т.п., которых вы упомянули. Они же себе не враги, подбор правильных кадров разработчиков — это основа конкурентоспособности для них. Значит, по каким-то параметрам вы им реально не подходите. Может быть, не по профессиональным параметрам, а по личностным. По каким — не знаю, делать какие-то заключения в этом плане на основе поста было бы непрофессионально — недостаточно информации.
Как пример (не принимайте на свой счет), иногда на собеседование приходят люди, которые соответствуют типу «суперзвезда» (этот термин ДеМарко с Листером ввели, если я правильно помню). Это крутой программист, он реально классно разбирается в технологиях, но он презрительно относится к другим, считает, что он всегда прав, и не умеет слушать. Да, он действительно умен и крут, но на работу его я не возьму, потому что он не сможет эффективно работать в команде. Это, конечно, упрощенный пример, но, думаю, идея ясна.
Не сомневаюсь, что многие собеседования по подбору разработчиков проводятся непрофессионально. Но при этом вряд ли этим поголовно грешат крупные IT компании, такие как Yandex, Rambler и т.п., которых вы упомянули. Они же себе не враги, подбор правильных кадров разработчиков — это основа конкурентоспособности для них. Значит, по каким-то параметрам вы им реально не подходите. Может быть, не по профессиональным параметрам, а по личностным. По каким — не знаю, делать какие-то заключения в этом плане на основе поста было бы непрофессионально — недостаточно информации.
Как пример (не принимайте на свой счет), иногда на собеседование приходят люди, которые соответствуют типу «суперзвезда» (этот термин ДеМарко с Листером ввели, если я правильно помню). Это крутой программист, он реально классно разбирается в технологиях, но он презрительно относится к другим, считает, что он всегда прав, и не умеет слушать. Да, он действительно умен и крут, но на работу его я не возьму, потому что он не сможет эффективно работать в команде. Это, конечно, упрощенный пример, но, думаю, идея ясна.
Вы правы, с небольшой оговоркой.
Основные принципы ООП — инкапсуляция, наследование, полиморфизм и абстракция. 20 лет назад основными принципами ООП считались только первые три, именно это мы и застали в свое время в ВУЗах. Абстракцию в этот перечень добавили позднее. Все остальное — уже от лукавого, то есть нельзя назвать основными принципами ООП.
SOLID — это лишь хорошие правила (можно сказать, принципы) дизайна, которым можно следовать или не следовать. Так же как и DRY, KISS и т.д., их много.
Возможно, это был вопрос-детектор на собеседовании, чтобы проверить, может ли специалист аргументированно отстаивать свою точку зрения.
Основные принципы ООП — инкапсуляция, наследование, полиморфизм и абстракция. 20 лет назад основными принципами ООП считались только первые три, именно это мы и застали в свое время в ВУЗах. Абстракцию в этот перечень добавили позднее. Все остальное — уже от лукавого, то есть нельзя назвать основными принципами ООП.
SOLID — это лишь хорошие правила (можно сказать, принципы) дизайна, которым можно следовать или не следовать. Так же как и DRY, KISS и т.д., их много.
Возможно, это был вопрос-детектор на собеседовании, чтобы проверить, может ли специалист аргументированно отстаивать свою точку зрения.
Абстракция — основной принцип любого программирования. Программирование — это всегда построение иерархии абстракций, начиная с изобретения подпрограмм. Причем тут вообще ООП?
Я бы сказал, начиная с появлением переменных (или подобных сущностей), которые моделируют некие свойства сущностей реальных. Ну или воображаемых :)
Абстракция не является «основным принципом любого программирования». Писать программы можно без малейших абстракций. Если Вы когда-нибудь писали программы под микроконтроллеры, то, надеюсь, понимаете, что я имею в виду.
Программирование суть построение моделей. А абстракция —
отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков.Что является необходимым свойством любой модели.
Программирование бывает не только построением модели, это бывает и просто кодированием, написанием инструкций для выполнения.
Допустим, я написал программу для микроконтроллера, которая при поступлении прерывания внешнего датчика включает световой индикатор. Где тут модели и абстракции? А, ну да, можно было бы сделать иерархию классов, реализовать гибкую расширяемую архитектуру, все дела… но у меня для моей задачи было всего лишь 128 байт, и мне этого хватило. Или это не программирование? ))
Допустим, я написал программу для микроконтроллера, которая при поступлении прерывания внешнего датчика включает световой индикатор. Где тут модели и абстракции? А, ну да, можно было бы сделать иерархию классов, реализовать гибкую расширяемую архитектуру, все дела… но у меня для моей задачи было всего лишь 128 байт, и мне этого хватило. Или это не программирование? ))
У программы есть назначение. Например, прога для микроконтроллера, которая перекрывает поступление воды в унитаз, когда бачок полон. Она абстрагируется от материала, из которого сделан унитаз, от формы бачка и т.п.
В более узком значении абстракция данных, как принцип ООП, присутствует в программировании микроконтроллеров как передача хендлов или указателей в процедуру. Например, процедуре печати строки неважно, куда указывает переданный указатель — на поле Name в структуре Person или на константную строку в сегменте RODATA, она от этого абстрагируется.
поступлении прерывания внешнего датчика включает световой индикатор. Где тут модели и абстракции?Бит в каком-то порту кодирует включение светового индикатора :) Абстракция налицо ;)
В более узком значении абстракция данных, как принцип ООП, присутствует в программировании микроконтроллеров как передача хендлов или указателей в процедуру. Например, процедуре печати строки неважно, куда указывает переданный указатель — на поле Name в структуре Person или на константную строку в сегменте RODATA, она от этого абстрагируется.
А при чем тут программирование? Тогда уж к вообще под что угодно можно подвести те или иные абстрактные категории, вообще всё, что существует или не существует. Это уже скорее из области философии. Ну ладно.
Данная прога для микропроцессора ни от чего не абстрагируется. Ей не нужно ни от чего абстрагироваться. При чем тут форма бачка унитаза? Эта прога самодостаточна — это просто последовательность команд микропроцессора, которая запускается при срабатывании прерывания, не более. Неважно что вызвало прерывание, если оно вызвано, то прога запустится. ))
Данная прога для микропроцессора ни от чего не абстрагируется. Ей не нужно ни от чего абстрагироваться. При чем тут форма бачка унитаза? Эта прога самодостаточна — это просто последовательность команд микропроцессора, которая запускается при срабатывании прерывания, не более. Неважно что вызвало прерывание, если оно вызвано, то прога запустится. ))
Можно подумать, прерывание — это не абстракция взаимодействия с внешним миром, а запись бита в контроллер — это не абстракция управления лампочкой. В данном случае у вас есть тонкий слой абстрагирования от физической реальности — электронов и перепадов напряжения.
Можно подумать, прерывание — это не абстракция взаимодействия с внешним миром, а запись бита в контроллер — это не абстракция управления лампочкой.
Прерывания — не обязательно абстракция взаимодействия с врешним миром, прерывания могут возникать в том числе и в результате тех или иных событий, которые могут быть порождены самой же программой. Например, при делении на ноль.
Запись бита в контроллер — это не обязательно абстракция управления лампочкой, это может быть просто спонтанное поведение глючной программы, написанной школьником в учебных целях.
Незачем строить иерархию абстракций там, где это не нужно. Например, вам поручили вскопать огород. Вы копаете, абстрагируюясь от того, что в это время где-то далеко в Африке родился слоненок? Нет же, причем тут слоненок к вашему огороду? Вы абстрагируетесь от начальника, коротый поручил эту работу? Нет, так тоже нельзя сказать, при чем тут это? Вы абстрагируетесь от того, что потом за эту работу получите оплату? Так тоже нельзя сказать, это вообще другая плоскость. Или кто-то скажет, что, мол, копает огород, абстрагируясь от погодных условий, от ветра, дождя… но это бред же. А вот у бухгалтера есть листочек, где написано, что он должен заплатить каждому работнику по N денег за каждую обработанную сотку огорода. Для него и работники, и сотки абстрактны, и как раз тут упоминание абстракции уместно. Чувствуете разницу?
Практически всегда можно подобрать [как бы] логичную абстракцию для чего угодно. Но зачем это делать в тех случаях, когда это избыточно? Бритва Оккама — «сущности не следует умножать без необходимости», это относится в том числе и к абстрактным сушностям. Прога для микроконтроллера на обязательно от чего-то абстрагируется… точно также можно сказать, что она просто имеет некое поведение сама по себе, как некий самодостаточный объект, а подкюченные к девайсу внешние устройства просто используют это поведение.
Повторюсь, в данном случае это спор о философских понятиях, не имеющих отношения не только к ООП, но и вообше к программированию. В ООП же абстракции другого рода, они касаются именно абстракции программной реализации, и это уже не философское понятие.
Вам часто дают задания «напишите такую-то последовательность команд для микропроцессора»? Думаю, крайне редко. А если дают задание «при прерывании I должен быть установлен бит B в порту P», то тот, кто даёт задание, уже произвел абстрагирование от схемотехники к терминам программирования. Вам не важно как генерируется прерывание, ему не важно какие конкретно команды вы напишите. Вы абстрагированы от задач друг друга, даже если вы в одном лице заказчик, схемотехник и программист. Как заказчик вы мыслите на уровне абстракции терминов предметной области («каждую секунду должна лампочка мигать»), как схемотехник на уровне железа («каждую секунду должно прерывание генерироваться генератором, а высокий уровень на таком-то выходе ЦАП должен лампочку зажигать»), а как программит на уровне абстракций, предоставляемых процессором («на прерывание я должен установить бит на порту»). Может коряво объяснение выглядит, но, думаю, понятна идея.
И даже не «каждую секунду», а «каждые 200 млн. тактов».
Вам не важно как генерируется прерывание, ему не важно какие конкретно команды вы напишите.
Да, это именно так.
Вы абстрагированы от задач друг друга, даже если вы в одном лице заказчик, схемотехник и программист.
Действительно, можно притянуть за уши, и назвать это абстракцией. Но на самом деле это просто разные задачи. Железо и прога… тут просто один объект сделал нечто, и передал сообщение другому объекту через некий заданный интерфейс, не более. Так ли уж необходимо вводить дополнительное избыточное понятие абстракции в этом случае?
Вот этот интерфейс и есть абстракция. Вы его сами ввели :)
Правильно ли я Вас понял, что всё, что по ту сторону интерфейса — абстракция?
Наконец-то! Кажется, я начинаю понимать! Всё предметы, которые я вижу своими глазами (то есть через визуальный интерфейс) — абстрактны. И все люди, которых я видел, и про которых читал — абстрактны. Нужно будет не забыть казать своей жене, что она тоже абстрактна.
Наконец-то! Кажется, я начинаю понимать! Всё предметы, которые я вижу своими глазами (то есть через визуальный интерфейс) — абстрактны. И все люди, которых я видел, и про которых читал — абстрактны. Нужно будет не забыть казать своей жене, что она тоже абстрактна.
То что ваша жена абстрактна не исключает того, что она и в определенном смысле реальна. Но я бы на вашем месте не углублялся слишком в ее реальную составляюшую, а то выясниться что она либо набор атомов, либо набор органов в перемешку с мясом, уверен вам будет гораздо приятнее ее воспринимать как абстракцию более высокого уровня :)
Без абстракций ни куда, просто для программистов это чуть более очевидно.
Без абстракций ни куда, просто для программистов это чуть более очевидно.
Мне кажется, что это просто некий переходный период. Неосознанное желание реализоввывать собственные проекты. Такое наступает, причём не с возрастом, а с опытом.
Хм… Позвольте не согласится. Переходный период это может быть и опыт, а может все таки не желание работать именно так как хотят от него работадатели.
Поясню, я где то до 2007 года работал простите обычным менеджером по продажам в компании Элтел, но уже тогда я знал про сети многое… Помогал к примеру с настройками сетевого оборудования у клиентов, делал разнообразные проекты им(вне компании в которой я работаю), об этом узнал руководители и меня оттуда попросили уйти. Вот тогда я понял что я не желаю продавать услуги, и начал с рядового сис. админа в НИИ, видя какое там отношение и так же помогал людям… Потом я уже никогда не работал менеджером.
P.S. Сейчас мне 30 лет я прохожу обучение в ВУЗе на заочном на инженера, поверьте это не легко, особенно писать рефераты про ms office! Но сдавать ту же дискретку(а там требуется минимум одна лабораторная на cи) мне в разы проще, чем тем же заочниками которые моложе меня.
Поясню, я где то до 2007 года работал простите обычным менеджером по продажам в компании Элтел, но уже тогда я знал про сети многое… Помогал к примеру с настройками сетевого оборудования у клиентов, делал разнообразные проекты им(вне компании в которой я работаю), об этом узнал руководители и меня оттуда попросили уйти. Вот тогда я понял что я не желаю продавать услуги, и начал с рядового сис. админа в НИИ, видя какое там отношение и так же помогал людям… Потом я уже никогда не работал менеджером.
P.S. Сейчас мне 30 лет я прохожу обучение в ВУЗе на заочном на инженера, поверьте это не легко, особенно писать рефераты про ms office! Но сдавать ту же дискретку(а там требуется минимум одна лабораторная на cи) мне в разы проще, чем тем же заочниками которые моложе меня.
Возникает ощущение, что вы жалуетесь. Меж тем, как основы computer science изучаются за месяц по книжке Кормена и грех за столько лет не попробовать восполнить пробел.
И, конечно, если вы устраиваетесь в яндекс, контекстно-свободные грамматики вам наверняка понадобятся. Вроде и не обязательно знать термин, чтобы писать программы, и всё-таки другим людям будет тяжело с вами работать, если вы говорите на другом языке и не понимаете общепринятых терминов сходу. Кроме того, я предпочел бы, чтобы мой коллега понимал, как делаются алгоритмы-примитивы, поскольку иначе у вас нет ни малейшего шанса придумать сложный и эффективный алгоритм. И ваш пример с очередью из стэков это подтверждает. Тривиальный вопрос, ответ на который можно придумать без всякого интернета секунд за 30, даже если ответа на вопрос не знать заранее.
И, конечно, если вы устраиваетесь в яндекс, контекстно-свободные грамматики вам наверняка понадобятся. Вроде и не обязательно знать термин, чтобы писать программы, и всё-таки другим людям будет тяжело с вами работать, если вы говорите на другом языке и не понимаете общепринятых терминов сходу. Кроме того, я предпочел бы, чтобы мой коллега понимал, как делаются алгоритмы-примитивы, поскольку иначе у вас нет ни малейшего шанса придумать сложный и эффективный алгоритм. И ваш пример с очередью из стэков это подтверждает. Тривиальный вопрос, ответ на который можно придумать без всякого интернета секунд за 30, даже если ответа на вопрос не знать заранее.
Сам бегаю по такому же кругу. Возраст почти тот же.
Единственное что понял — это то, что чтобы заниматься _своим_ делом (т.е. делом, для которого ты создан), нужно иметь финансовую поддержку. Без нее -никак. В параллель с работой, которую делаешь чтобы жить, ничего серьезного не наработаешь. Я до сих пор пытаюсь совместить обычную работу днем и работу ночью для души, но чувствую, что результатов мало, а здоровье не прибавляется. Поэтому впереди видна только обычная работа для существования. Это угнетает. Тем более, если есть ответсвенность перед семьей которую надо кормить.
Единственный выход — иметь сторонний стабильный источник дохода.
Но правда состоит в том, что чтобы иметь такой источник, нужно поступиться своими принципами. Можно, например, сделать сеть бессмысленных сайтов, крутить их на SAPE, и диверсифицировать деятельность сайтами с тизерной рекламой. Люди реально имеют на таких вещах более тыщи долларов в месяц, для финансовой подстраховки более чем достаточно. Если вы умеете программировать, вам легко создать «скриптовую империю», которая будет работать сама с минимальным вмешательством и приносить доход.Но позволите ли вы себе заниматься такими вещами?
Можно заниматься «сайтами для взрослых». Мне поступали такие предложения, я немного в теме, потому что в моем окружении была пара человек, которые как раз занимались адулт-сайтами и проститутками, а на работу ходили «чтоб было с кем общаться», не боясь работать как захочется. Но вы захотели бы заниматься такими вещами?
Кому-то везет, и у него есть вторая квартира. Ее тупо сдают и занимаются своими делами. Самое смешное, что человек, имеющий вторую квартиру, легко покупает себе и третью и четвертую. Да, за счет аренды. Но если вы смогли решить квартирный вопрос, то скорее всего у вас только одна квартира, а не две. Купить вторую квартиру — это тот же подвиг, что купить первую. Вы согласны его повторить в вашем возрасте?
Поэтому, задача для таких как мы — найти сторонний постоянный источник дохода, который бы не занимал много времени. Как только эта задача будет решена, вы обретете покой и станете заниматься своим делом. У меня такой источник есть, но слабый — он в 20 раз меньше, чем нужно, хотя я там вероломно использую труд других людей (они не возражают). И за три года он особенно не увеличился, так что вопрос об источнике остается открытым. Проклятые моральные принципы.
Единственное что понял — это то, что чтобы заниматься _своим_ делом (т.е. делом, для которого ты создан), нужно иметь финансовую поддержку. Без нее -никак. В параллель с работой, которую делаешь чтобы жить, ничего серьезного не наработаешь. Я до сих пор пытаюсь совместить обычную работу днем и работу ночью для души, но чувствую, что результатов мало, а здоровье не прибавляется. Поэтому впереди видна только обычная работа для существования. Это угнетает. Тем более, если есть ответсвенность перед семьей которую надо кормить.
Единственный выход — иметь сторонний стабильный источник дохода.
Но правда состоит в том, что чтобы иметь такой источник, нужно поступиться своими принципами. Можно, например, сделать сеть бессмысленных сайтов, крутить их на SAPE, и диверсифицировать деятельность сайтами с тизерной рекламой. Люди реально имеют на таких вещах более тыщи долларов в месяц, для финансовой подстраховки более чем достаточно. Если вы умеете программировать, вам легко создать «скриптовую империю», которая будет работать сама с минимальным вмешательством и приносить доход.Но позволите ли вы себе заниматься такими вещами?
Можно заниматься «сайтами для взрослых». Мне поступали такие предложения, я немного в теме, потому что в моем окружении была пара человек, которые как раз занимались адулт-сайтами и проститутками, а на работу ходили «чтоб было с кем общаться», не боясь работать как захочется. Но вы захотели бы заниматься такими вещами?
Кому-то везет, и у него есть вторая квартира. Ее тупо сдают и занимаются своими делами. Самое смешное, что человек, имеющий вторую квартиру, легко покупает себе и третью и четвертую. Да, за счет аренды. Но если вы смогли решить квартирный вопрос, то скорее всего у вас только одна квартира, а не две. Купить вторую квартиру — это тот же подвиг, что купить первую. Вы согласны его повторить в вашем возрасте?
Поэтому, задача для таких как мы — найти сторонний постоянный источник дохода, который бы не занимал много времени. Как только эта задача будет решена, вы обретете покой и станете заниматься своим делом. У меня такой источник есть, но слабый — он в 20 раз меньше, чем нужно, хотя я там вероломно использую труд других людей (они не возражают). И за три года он особенно не увеличился, так что вопрос об источнике остается открытым. Проклятые моральные принципы.
Не, до порносайтов, славбогу, еще не дошёл :))) тизерки — тоже гадость. зачем мне это? «Скриптовая империя» — фууу!!!
зря вы так. человек потратил время, чтобы вам ответить и что-то предложить, а вы презрительно фыркаете. как минимум hamster что-то делает, а вы застряли в нарциссизме и судя по вашим репликам — так и будете дедом-аникейщиком на старости, которого будут держать в мелкой конторе в память о былых заслугах.
Не думаю, что Вы жалуетесь, но впечатление может создаться.
Просто Вы по собеседованиям давно не ходили вот и все.
А вообще собеседования это забавно — можно узнать много нового :) с людьми пообщаться и найти что подучить. Многие теоретические вещи забываются, но перед собеседованием ведь никто не мешает почитать. Ну и познание это всегда удовольствие.
Если на собеседовании засыпали чем-то — так это ж здорово — можно почитать, да и запомниться лучше. Я вот свои фейлы помню :) и это не грустные воспоминания.
Мне вот возраст в одном напрягает — слишком много бытовых забот и мало времени на учебу :) А хочется и то и это и знания в систему привести…
Как-то оглянуться не успел, уже вот тоже скоро 39.
Просто Вы по собеседованиям давно не ходили вот и все.
А вообще собеседования это забавно — можно узнать много нового :) с людьми пообщаться и найти что подучить. Многие теоретические вещи забываются, но перед собеседованием ведь никто не мешает почитать. Ну и познание это всегда удовольствие.
Если на собеседовании засыпали чем-то — так это ж здорово — можно почитать, да и запомниться лучше. Я вот свои фейлы помню :) и это не грустные воспоминания.
Мне вот возраст в одном напрягает — слишком много бытовых забот и мало времени на учебу :) А хочется и то и это и знания в систему привести…
Как-то оглянуться не успел, уже вот тоже скоро 39.
а вот вам бы я не доверил бы даже за компьютер садиться. слишком много самопиара, слишком мало желания
Что-то знакомое, хотя, можно сказать, что я в самом начале пути. Однако, уже вижу чем он закончится… Вот теперь я понимаю, почему все усатые дядечки руководители такие тупые и так держатся за свои места. А все просто, если их выкинуть на рынок, никому они будут не нужны. А все что они умеют — лизать жопу вышестоящему руководству и нагибать нижестоящих «руководить», выставляя себя в чужих глазах нужными и полезными. Причем получают за это хорошую зарплату. Им не надо постоянно учиться, не надо быть в курсе современных технологий, не надо проектировать и планировать. Все это можно спихнуть на подчиненных. Ведь руководитель должен только руководить, но даже это он не в состоянии грамотно сделать. Что-то меня понесло.
И печальна судьба тех самоучек, кто к сорока годам не стал таким вот дядечкой. А таким людям как автор, видимо противна сама мысль стать таким вот дядечкой. И наверное, с нашими реалиями, это печально.
И печальна судьба тех самоучек, кто к сорока годам не стал таким вот дядечкой. А таким людям как автор, видимо противна сама мысль стать таким вот дядечкой. И наверное, с нашими реалиями, это печально.
Тоже возраст приближается к 40. И тоже некоторое время назад было нечто похожее. Решение нашел, помогло вот что:
1. Ранее я терялся, когда задавали простые вопросы по базовым либам, API и т.д. Подготовился и сдал сертификационные экзамены по нескольким технологиям. Сертификаты не факт что помогут в поиске работы, но сама подготовка и экзамен сильно помогут в систематизации знаний. Впрочем, от сертификатов польза всё равно есть — очень добавляют уверенности в себе.
2. Я терялся, когда задавали вопросы с упоминанием незнакомых названий алгоритмов и структур данных, по оценке сложности алгоритмов, по различным деревьям и т.д. Прошел несколько курсов, в том числе и на Курсере. По алгоритмам, технологиям и различной теории. Помимо всего прочего это еще и неслабая тренировка английского, плюс, узнал кучу новых терминов, касающихся давно привычных вещей.
3. Терялся, когда прямо на собеседовании просили сходу написать какую-либо мелкую программку, например генератор простых чисел, комбинаторные задачки и т.д. Волновался, опечатывался, ошибался, спешил, выбирал неоптимальные решения и т.д. Мне это не нравилось. Занялся спортивным программированием, решил весьма большое количество задачек, и теперь всякую мелкоту получается сходу решать моментально.
4. Вообще терялся на собеседованиях, особенно когда задавали провокационные вопросы, типа про слона в холодильнике. Специально потратил массу времени, чтобы разобраться, какие вообще бывают вопросы на собеседованиях, какие вопросы задаются в крупных компаниях, какие ответы оптимальны. Особенно пригодились индийские сайты, где ихние программеры делились друг с другом реальными вопросами с собеседований и детально разбирали ответы. Сейчас их что-то не видно… раньше были.
5. Терялся, когда на собеседовании спрашивали про владение английским языком. На одном из собеседований попросили перевести какой-то текст, я не смог, было очень неудобно. Пошел на хорошие курсы, потом параллельно занятия с репетитором, потом второй репетитор. Получилось.
6. Терялся, когда спрашивали, сколько хочу денег. Вообще не мог себе цены сложить. Решил вопрос кардинально. Так как все вышесказанное (обучение, курсы, проектики для себя и т.д.) занимало кучу времени, вообще уволился с работы. Стал свободным человеком, занялся самообразованием, научился жить очень скромно с минимумом денег, хотя было непросто перестроиться после программерских зарплат. Потом настал момент, когда уже по скилам был готов работать чуть ли не в любой конторе в своем городе, но решил, что ну его, нужно идти дальше. Ранее как-то попробовал работать менеджером, не понравилось, показалось, что туповатая работа функционера, да и не очень-то получалось. Свой бизнес решил не заводить, хотя чуть было не попробовал… тоже оказалось что не интересно, а деньги, как я к этому времени понял, это вообще ничто.
7. Но возраст, мысли всякие, что делать, кто я, что я… Рекрутеры постоянно заваливали предложениями, и однажды согласился поработать за границей. И там я увидел такое… в общем, 50- или 60-летний программист — это в Европе нормально. И только тогда я успокоился. Теперь спокойно пишу код в своё удовольствие, постоянно переключаюсь на те или иные новые технологии, слушаю те или иные курсы, также, вот, учу еще один иностранный язык. То есть кризис прошел. ))
Совет автору: если данная тема тяготит, то, если есть возможность, попробуйте на несколько лет сменить обстановку. Скажем, поработав пару лет в Европе, можете быть уверенными, что потом, если вернетесь, отечественные конторы просто завалят прекрасными предложениями. Ну а если сейчас всё в порядке, тогда то, что я написал, можете игнорировать. ))
1. Ранее я терялся, когда задавали простые вопросы по базовым либам, API и т.д. Подготовился и сдал сертификационные экзамены по нескольким технологиям. Сертификаты не факт что помогут в поиске работы, но сама подготовка и экзамен сильно помогут в систематизации знаний. Впрочем, от сертификатов польза всё равно есть — очень добавляют уверенности в себе.
2. Я терялся, когда задавали вопросы с упоминанием незнакомых названий алгоритмов и структур данных, по оценке сложности алгоритмов, по различным деревьям и т.д. Прошел несколько курсов, в том числе и на Курсере. По алгоритмам, технологиям и различной теории. Помимо всего прочего это еще и неслабая тренировка английского, плюс, узнал кучу новых терминов, касающихся давно привычных вещей.
3. Терялся, когда прямо на собеседовании просили сходу написать какую-либо мелкую программку, например генератор простых чисел, комбинаторные задачки и т.д. Волновался, опечатывался, ошибался, спешил, выбирал неоптимальные решения и т.д. Мне это не нравилось. Занялся спортивным программированием, решил весьма большое количество задачек, и теперь всякую мелкоту получается сходу решать моментально.
4. Вообще терялся на собеседованиях, особенно когда задавали провокационные вопросы, типа про слона в холодильнике. Специально потратил массу времени, чтобы разобраться, какие вообще бывают вопросы на собеседованиях, какие вопросы задаются в крупных компаниях, какие ответы оптимальны. Особенно пригодились индийские сайты, где ихние программеры делились друг с другом реальными вопросами с собеседований и детально разбирали ответы. Сейчас их что-то не видно… раньше были.
5. Терялся, когда на собеседовании спрашивали про владение английским языком. На одном из собеседований попросили перевести какой-то текст, я не смог, было очень неудобно. Пошел на хорошие курсы, потом параллельно занятия с репетитором, потом второй репетитор. Получилось.
6. Терялся, когда спрашивали, сколько хочу денег. Вообще не мог себе цены сложить. Решил вопрос кардинально. Так как все вышесказанное (обучение, курсы, проектики для себя и т.д.) занимало кучу времени, вообще уволился с работы. Стал свободным человеком, занялся самообразованием, научился жить очень скромно с минимумом денег, хотя было непросто перестроиться после программерских зарплат. Потом настал момент, когда уже по скилам был готов работать чуть ли не в любой конторе в своем городе, но решил, что ну его, нужно идти дальше. Ранее как-то попробовал работать менеджером, не понравилось, показалось, что туповатая работа функционера, да и не очень-то получалось. Свой бизнес решил не заводить, хотя чуть было не попробовал… тоже оказалось что не интересно, а деньги, как я к этому времени понял, это вообще ничто.
7. Но возраст, мысли всякие, что делать, кто я, что я… Рекрутеры постоянно заваливали предложениями, и однажды согласился поработать за границей. И там я увидел такое… в общем, 50- или 60-летний программист — это в Европе нормально. И только тогда я успокоился. Теперь спокойно пишу код в своё удовольствие, постоянно переключаюсь на те или иные новые технологии, слушаю те или иные курсы, также, вот, учу еще один иностранный язык. То есть кризис прошел. ))
Совет автору: если данная тема тяготит, то, если есть возможность, попробуйте на несколько лет сменить обстановку. Скажем, поработав пару лет в Европе, можете быть уверенными, что потом, если вернетесь, отечественные конторы просто завалят прекрасными предложениями. Ну а если сейчас всё в порядке, тогда то, что я написал, можете игнорировать. ))
Классный подход!
Где вы были лет 10 назад!? Я бы за такой текст пол-царства отдал, потому что шел ко всему, что вы перечислили, сам, путем проб и ошибок.
Решительно прошу оформить как пост-наставление «сомневающимся».
Решительно прошу оформить как пост-наставление «сомневающимся».
Спасибо! Да, это очень ценный и верный совет! Хватит ли сил на всё это?..
А вот пост про ситуацию в Канаде. Интересная информация. Специально там задал вопрос автору, чтобы потом Вам ссылку дать. )) К слову, в Европе аналогичная ситуация.
Подерживаю господина выше, чуть добавить подробностей и будет очень нужный пост. Мотивационный и с правильным, позитивным подходом.
Немного не по теме, но у вас случайно не сохранилось «Композитора» или его исходников? Мне очень интересна тематика генерации музыки.
У нас на проекте есть одно, единственное требование — исправить баг или написать кусок кода в нашем проекте, и как показывает практика, нужны именно те, кто может писать код. Необходимое и достаточное требование, чтобы найти подходящего человека.
Некоторые из наших коллег, которые ищут другую работу, более оплачиваемую, не могут найти ее из-за глупых вопросов.
Некоторые из наших коллег, которые ищут другую работу, более оплачиваемую, не могут найти ее из-за глупых вопросов.
> Я не знаю, какую именно работу я ищу
Вот отсюда и нужно было начинать. Я хочу чего-то но сам не знаю чего-авось кривая выведет. Вот она и выводит но я так понял не туда куда хочется…
Вот отсюда и нужно было начинать. Я хочу чего-то но сам не знаю чего-авось кривая выведет. Вот она и выводит но я так понял не туда куда хочется…
А может пора построить свой маленький свечной заводик в интернет? А лучше пару десятков заводиков, стать интернет-рантье и положить болт на любые поиски работы?
повидимому — не царское это дело)
Прибыльные стартапы не умею запускать. Делаю их исключительно для себя и под себя. Не хочу ориентироваться на широкую публику. Прибыльно == сервис для всех, поголовный сервис. Неее.
Это популизм уважаемый)) «Горизонтальные» продукты «для всех» вроде ms office — у вас здоровья не хватит осилить. А осилите — помрете их раскручивать. Слопают. Сейчас делать надо " вертикальные" продукты. Узко-специализированные сервисы. Там и 1-2 человека могут сделать хороший инструмент и большому бизнесу там не интересно.
Как человеку по той стороны баррикады (тому, кто проводит много интервью), позвольте мне побыть адвокатом дьявола и объяснить некоторые нюансы. Сразу скажу, что по-русски я технические термины уже не употребляю достаточно давно, так что буду писать кое-где по английски, чтобы не делать коверканных переводов. Ответ достаточно большой, возможно кто-то захочет увидеть полноценную статью, дайте знать. Также надо отметить, что интервью junior-ов и senior-ов разные, далее я имею в виду именно последнее (автор явно не junior).
Сначала в поддержку автора. Многие интервьюеверы ленивы и недалеки. Не в последнюю очередь это из-за того, что они бывшие программисты, которых подняли до менеджера, но при этом они не имеют никаких социальных навыков для этого. Для них интервью — это просто трата времени, поэтому они быстро гуглят одни и те же вопросы, и повысив свое ЧСВ за счет унижения кандидата, они довольные собой, дают отказ. Причем отказ этот зачастую имеет эмоциональную природу («он — тупой, не знает алгоритма вычисления пи, а я такой умный и все знаю», либо «он — слишком умный и подсидит меня на моем теплом местечке»). Но не все такие.
Про резюме. Я никогда не доверяю резюме. Большой опыт ни о чем не говорит — это может быть большой опыт написания миллиона строк там, где использование библиотек или даже хорошего знания инструментария позволило бы сократить этот код до нескольких сотен строк. Или например, «LLVM contributor», что в реальности может быть — «LLVM вываливался на мой говнокод, пришлось связываться с разработчиками, и через месяц я еле как разобрался с gdb и смог-таки найти ошибочную строку. Потом еще целый месяц делал патч, т.к. не знаю основ (D)VCS.»
Далее, элементарные вопросы, на которые отвечают «дайте мне гугл, я найду за минуту». Иногда некоторые базовые вещи надо просто знать. Например, иметь хотя бы представление о типах данных и их размерностях. «Я тут умножаю миллион на миллион и сохраняю в int, что может пойти не так?» Для некоторых отраслей элементарные вопросы могут быть достаточно сложными, но обязательными для работы. Например, если идет речь о разработке сетевых приложений, надо обязательно знать sniffer-ы и OSI.
Далее, термины. Многие упускают такой момент, что в команде желательно говорить на одном языке. Опять-таки это можно нагуглить, но по своему опыту я знаю, что зачастую гугл не особо помогает. Например, один из моих тестеров даже после гугления термина CSRF и долгого муторного объяснения от меня, так и не понял, как сама атака работает. Такая же ситуация повторилась и с некоторыми нашими разработчиками. Зачастую программисты не могут понять позицию пользователя (или хакера, как в моем случае), потому что они не имеют достаточной гибкости мышления («не хочу я думать как хакер, я тут вызвал escape(), все должно теперь работать путем»).
Небольшое отступление. Иногда можно не знать сам термин, но использовать его на практике. Например, программист знает, что надо скрывать внутреннее состояние объекта от внешнего мира, и всегда делает это правильно, но не знает что это называется инкапсуляция. Хорошие интервьюверы обычно это выясняют. Особенно это важно в многонациональных компаниях, когда языковой барьер не позволяет кандидату сказать как термин называет по-английски.
И последнее. Многие жалуются что на интервью их спрашивают слишком сложные вопросы, ответы на которые знают только единицы. Обычно мы это делаем специально, чтобы выяснить пределы знаний и навыков кандидата. Никто не ожидает, что вы ответите на эти вопросы, но если ответите, то это будет большой плюс. Так что не надо воспринимать это как издевательство — это стандартная практика, как минимум, на западе.
Сначала в поддержку автора. Многие интервьюеверы ленивы и недалеки. Не в последнюю очередь это из-за того, что они бывшие программисты, которых подняли до менеджера, но при этом они не имеют никаких социальных навыков для этого. Для них интервью — это просто трата времени, поэтому они быстро гуглят одни и те же вопросы, и повысив свое ЧСВ за счет унижения кандидата, они довольные собой, дают отказ. Причем отказ этот зачастую имеет эмоциональную природу («он — тупой, не знает алгоритма вычисления пи, а я такой умный и все знаю», либо «он — слишком умный и подсидит меня на моем теплом местечке»). Но не все такие.
Про резюме. Я никогда не доверяю резюме. Большой опыт ни о чем не говорит — это может быть большой опыт написания миллиона строк там, где использование библиотек или даже хорошего знания инструментария позволило бы сократить этот код до нескольких сотен строк. Или например, «LLVM contributor», что в реальности может быть — «LLVM вываливался на мой говнокод, пришлось связываться с разработчиками, и через месяц я еле как разобрался с gdb и смог-таки найти ошибочную строку. Потом еще целый месяц делал патч, т.к. не знаю основ (D)VCS.»
Далее, элементарные вопросы, на которые отвечают «дайте мне гугл, я найду за минуту». Иногда некоторые базовые вещи надо просто знать. Например, иметь хотя бы представление о типах данных и их размерностях. «Я тут умножаю миллион на миллион и сохраняю в int, что может пойти не так?» Для некоторых отраслей элементарные вопросы могут быть достаточно сложными, но обязательными для работы. Например, если идет речь о разработке сетевых приложений, надо обязательно знать sniffer-ы и OSI.
Далее, термины. Многие упускают такой момент, что в команде желательно говорить на одном языке. Опять-таки это можно нагуглить, но по своему опыту я знаю, что зачастую гугл не особо помогает. Например, один из моих тестеров даже после гугления термина CSRF и долгого муторного объяснения от меня, так и не понял, как сама атака работает. Такая же ситуация повторилась и с некоторыми нашими разработчиками. Зачастую программисты не могут понять позицию пользователя (или хакера, как в моем случае), потому что они не имеют достаточной гибкости мышления («не хочу я думать как хакер, я тут вызвал escape(), все должно теперь работать путем»).
Небольшое отступление. Иногда можно не знать сам термин, но использовать его на практике. Например, программист знает, что надо скрывать внутреннее состояние объекта от внешнего мира, и всегда делает это правильно, но не знает что это называется инкапсуляция. Хорошие интервьюверы обычно это выясняют. Особенно это важно в многонациональных компаниях, когда языковой барьер не позволяет кандидату сказать как термин называет по-английски.
И последнее. Многие жалуются что на интервью их спрашивают слишком сложные вопросы, ответы на которые знают только единицы. Обычно мы это делаем специально, чтобы выяснить пределы знаний и навыков кандидата. Никто не ожидает, что вы ответите на эти вопросы, но если ответите, то это будет большой плюс. Так что не надо воспринимать это как издевательство — это стандартная практика, как минимум, на западе.
возможно кто-то захочет увидеть полноценную статью, дайте знать.
Даю знать :)
«Я тут умножаю миллион на миллион и сохраняю в int, что может пойти не так?»
А какая разрядность у int? Она вообще есть или используется арифметика неограниченной точности? Слишком много нюансов, чтобы ответить однозначно.
Сегодня видел странную книжку. Какой-то курс по С. Датирована 2012 или 2013 годом, но int там 16-битный.
Хорошо, напишу статью чуть попозжу. Вообще, работа с большой транснациональной компании открыла глаза, как все может быть запущено — и со стороны кандидатов, и со стороны интервьюверов.
Насчет int-а. Ваш ответ весьма замечателен, многие даже не задумываются про нюансы. Но в целом, я имел в виду баг на переполнение, которые некоторые «специалисты» делают, т.к. не особо осведомлены про разрядность. Например, у них все работает на x86-64 платформе, а потом оказывается, что ARM-платформа «почему-то» не работает (и конечно же виноваты разработчики процессора, слишком много там багов, вон даже Торвальдс ругается).
Насчет int-а. Ваш ответ весьма замечателен, многие даже не задумываются про нюансы. Но в целом, я имел в виду баг на переполнение, которые некоторые «специалисты» делают, т.к. не особо осведомлены про разрядность. Например, у них все работает на x86-64 платформе, а потом оказывается, что ARM-платформа «почему-то» не работает (и конечно же виноваты разработчики процессора, слишком много там багов, вон даже Торвальдс ругается).
В принципе очевидно, что вы имеете в виду, но сама простота ответа в «боевых условиях» на реальном собеседовании натолкнула бы меня на то, что есть какой-то подвох. Начал бы готовить ответ типа «ну, если допустить, что разрядность int меньше (и тут большая пауза, когда я пытаюсь в уме подсчитать сколько разрядом минимально необходимо для записи 10^12 — 40? 39? ...)», а ситуация собеседования уточняющие вопросы задавать не позволяет, чтобы не выглядеть идиотом.
«ситуация собеседования уточняющие вопросы задавать не позволяет, чтобы не выглядеть идиотом» — это одна из ошибок, зачастую совершаемая кандидатами. На интервью анализируются не только технические, но и социальные навыки. Можно быть хорошим программистом, но если на все ответы думать по полчаса ища подвох, не смотреть в глаза и держаться скованно, то есть большой шанс получить отказ, потому что менеджеры решат, что такой человек не сможет работать в команде.
Я понимаю, что есть исключения, но мой опыт показывает, что индивидуалисты склонны решать проблемы только своей головой, не консультируясь ни с менеджерами, ни с коллегами. Зачастую это приводит к тому, что их решение хоть и brilliant, но по сути своей ошибочно, потому что они не учли каких-то факторов или требований, которые не были озвучены в спецификации или багрепорте. Когда им указывают на ошибку, они начинают старую песню про то, что «этого не было в спецификации, так что это ваши проблемы». К сожалению, мир не идеален, и особенно в условиях жесткой конкуренции необходимо учитывать, что всего не учтешь. Естественно, есть инструменты, чтобы минимизировать риски — тот же процесс codereview, однако и он зачастую заканчивается перепалками и обвинениями в некомпентности, только уже в онлайне.
Я понимаю, что есть исключения, но мой опыт показывает, что индивидуалисты склонны решать проблемы только своей головой, не консультируясь ни с менеджерами, ни с коллегами. Зачастую это приводит к тому, что их решение хоть и brilliant, но по сути своей ошибочно, потому что они не учли каких-то факторов или требований, которые не были озвучены в спецификации или багрепорте. Когда им указывают на ошибку, они начинают старую песню про то, что «этого не было в спецификации, так что это ваши проблемы». К сожалению, мир не идеален, и особенно в условиях жесткой конкуренции необходимо учитывать, что всего не учтешь. Естественно, есть инструменты, чтобы минимизировать риски — тот же процесс codereview, однако и он зачастую заканчивается перепалками и обвинениями в некомпентности, только уже в онлайне.
По-моему, никак не связано как я веду себя на собеседовании и как на работе. Собеседование это же типа экзамен, «вопросы здесь задаю не я».
Ха, ничего подобного. Это стереотип, который я бы не хотел видеть у кандидатов (но конечно вижу очень часто). Любой начальник любит, когда под него прогибаются, однако надо знать рамки. На западе интервью — это больше торг, чем экзамен. У кандидата есть товар — его навыки и знания, у интервьюверов есть потребность в покупке этого «товара» (не было бы потребности, они бы и не искали). Никто на реальном рынке не согласится продать товар за бесценок, при этом кланяясь в ноги (кроме отчаянных ситуаций). Конечно, последнее слово всегда за покупателем, но это не значит, что надо соглашаться на все. В интернете очень много статей на тему, как правильно продать себя, как правильно проходить интервью, и одно из первых правил — это установка личного контакта, включая и постановку вопросов. Просто надо понимать, что для интервьювера (как в принципе, и для экзаменатора) интервью — это очень скучный процесс, и они всегда рады сделать его менее скучным. Такой же трюк можно использовать и на экзаменах — я помню, когда я получил 5, не ответив и на половину вопросов, но при этом я установил контакт с экзаменатором, и мы вместе пришли к решению вопросов, которые я не осилил.
Да, я понимаю, что это немного дико для программистов, которые считаются несколько замкнутыми в себе людьми, но это очень неплохо работает, и такие навыки сильно увеличивают шансы на успехи в жизни :)
P.S. В России ситуация все-таки с этим похуже, потому что открытость считается чем-то плохим и подозрительным, но с адекватными людьми тоже работает.
Да, я понимаю, что это немного дико для программистов, которые считаются несколько замкнутыми в себе людьми, но это очень неплохо работает, и такие навыки сильно увеличивают шансы на успехи в жизни :)
P.S. В России ситуация все-таки с этим похуже, потому что открытость считается чем-то плохим и подозрительным, но с адекватными людьми тоже работает.
Это смотря с какой целью народ набирают. Когда в аутрорсинговой конторе стоит задача быстро подобрать под жирный проект допустим 10 спецов-явистов, причем единственное, но жесткое требование заказчика — идеальное знание Java core и какого-либо фреймворка, то можете поверить, на собеседовании будут гонять именно по Java core и по этому фреймворку. И как раз нужно будет отвечать в режиме «вопросы здесь задаю не я». Причина проста, через неделю аналогичные же вопросы будут задаваться этому же уже сотруднику в таком же режиме, но уже менеджером заказчика из-за океана, по телефону, и у менеджера запросто может оказаться сложный для наших ребят, допустим, индийский акцент. Там должно быть очень четко, вопрос — ответ, иначе проект контора может просто не получить.
Готово: habrahabr.ru/post/194930/ Хотел разбавить примерами, но и так получилось слишком много.
А еще, задавая сложные вопросы, можно понять, как человек будет вести себя, когда встретит в работе действительно сложную задачу. Скажет «это нам не задавали, это мы не проходили» или будет подступаться к ней с разных сторон пока не решит или не докажет, что она нерешаема. Мы на собеседованиях иногда даем сложную задачу и оставляем кандидата на какое-то время с компьютером и интернетом. Потом просим рассказать, что он делал, как решал. Даже если он задачу не решил, вполне возможно, что мы ему сделаем предложение, если он шел правильным путем.
И часто у вас в процессе работы возникают действительно сложные задачи? ))
У меня мнение такое. Вообще, в идеале, при разработке коммерческого софта желательно избегать сложных задач, так как это и повышенный риск, да и вообще банально невыгодно. Если сложные задачи таки появляются, то их опять-таки нужно преобразовывать в простые. Если упрощать не получается — уклоняться от этих задач, пусть их делают другие команды. Наиболее выгодна — простая и предсказуемая, но высокотехнологичная рутина. Соответственно, нет никакого смысла требовать у каждого новобранца наличия скилов решения сложных задач, это и само по себе избыточно, и отсеивает хороших кандидатов.
У меня мнение такое. Вообще, в идеале, при разработке коммерческого софта желательно избегать сложных задач, так как это и повышенный риск, да и вообще банально невыгодно. Если сложные задачи таки появляются, то их опять-таки нужно преобразовывать в простые. Если упрощать не получается — уклоняться от этих задач, пусть их делают другие команды. Наиболее выгодна — простая и предсказуемая, но высокотехнологичная рутина. Соответственно, нет никакого смысла требовать у каждого новобранца наличия скилов решения сложных задач, это и само по себе избыточно, и отсеивает хороших кандидатов.
Если упрощать не получается — уклоняться от этих задач, пусть их делают другие команды.
Это как, простите? Кто же при таком подходе будет их делать в конечном итоге?
Отложить на какое-то время, если возможно — это понятно. Либо шейх помрёт, либо ишак сдохнет… либо задача перейдёт в разряд «не столь сложной» из-за изменения требований, или понимания задачи, или появления подходящих для решения инструментов где-нибудь сбоку.
У нас в процессе работы сложные задачи возникают всегда. Точнее, не то, чтобы возникали, но с десяток обычно держится в списке отложенных задач.
И то, что «невыгодно» — спорный вопрос. У маленькой фирмы это может быть единственным шансом — решать задачи, которые не умеет решать больше никто. Собственно, на этом и живём…
При таком подходе эти задачи будет делать тот, для кого они простые. Например, для меня перевести работающий высоконагруженый проект с Oracle 9 на 11 было бы сложной задачей, хотя я давно работаю с Oracle, а вот для не Oracle DBA это бы не составило ни малейшего труда, и наверняка он сделает это качественнее.
Иными словами, для бизнеса лучше строить процесс так, чтобы ту или иную задачу делал профессионал, для которого эта задача не является сложной. Нет нужного спеца в данный момент времени? Не проблема, его можно пригласить для выполнения работ по краткосрочному контракту. В этом случае меньше рисков, можно прогнозировать результат, и браться за действительно серьезные проекты, беря на себя ответственность по их разработке.
Иными словами, для бизнеса лучше строить процесс так, чтобы ту или иную задачу делал профессионал, для которого эта задача не является сложной. Нет нужного спеца в данный момент времени? Не проблема, его можно пригласить для выполнения работ по краткосрочному контракту. В этом случае меньше рисков, можно прогнозировать результат, и браться за действительно серьезные проекты, беря на себя ответственность по их разработке.
== а вот для* Oracle DBA это бы не составило ни малейшего труда ==
У нас сложные задачи появляются часто. Если от них отказываться и заниматься только технологической рутиной, то появляются следующие проблемы:
1. Потеря конкурентоспособности на рынке (кстати несколько команд в одной компании иногда тоже можно рассматривать как рынок). Ведь на рынке вы делаете что-то либо лучше других, либо дешевле. Если отказываться от сложных и новых задач, то придется урезать издержки.
2. Без сложных задач самые одаренные члены команды заскучают, и вы их потеряете. Они либо потеряют интерес к работе, либо уйдут.
1. Потеря конкурентоспособности на рынке (кстати несколько команд в одной компании иногда тоже можно рассматривать как рынок). Ведь на рынке вы делаете что-то либо лучше других, либо дешевле. Если отказываться от сложных и новых задач, то придется урезать издержки.
2. Без сложных задач самые одаренные члены команды заскучают, и вы их потеряете. Они либо потеряют интерес к работе, либо уйдут.
По пунктам.
1. Не вижу связи между потерей конкурентоспособности и выполнением невыгодных для бизнеса (сложных) задач. Наоборот, меньше рисков, значит больше заказчиков и больше прибыль. Можно нанимать более опытных спецов, а при необходимости нанимать на краткосрочные контракты дополнительных узких профи для решения того, чему своими людьми делать невыгодно.
При решении сложной задачи свой человек потратит много времени с неизвестным результатом, в то время как кто-то другой, для кого эта задача не является сложной, сделает её быстро и надежно.
2. Это да, согласен. Для программиста интереснее работать со сложными задачами. Но вот для бизнеса наоборот, выгоднее, чтобы был простой предсказуемый конвейер проектов. Соответственно, нужно заботиться о балансе.
1. Не вижу связи между потерей конкурентоспособности и выполнением невыгодных для бизнеса (сложных) задач. Наоборот, меньше рисков, значит больше заказчиков и больше прибыль. Можно нанимать более опытных спецов, а при необходимости нанимать на краткосрочные контракты дополнительных узких профи для решения того, чему своими людьми делать невыгодно.
При решении сложной задачи свой человек потратит много времени с неизвестным результатом, в то время как кто-то другой, для кого эта задача не является сложной, сделает её быстро и надежно.
2. Это да, согласен. Для программиста интереснее работать со сложными задачами. Но вот для бизнеса наоборот, выгоднее, чтобы был простой предсказуемый конвейер проектов. Соответственно, нужно заботиться о балансе.
Эта схема работает, если команда специализируется на «простых задачах», решает их на уровне конкурентов или лучше, Кроме того, имеет отлаженный «конвейер проектов» и достаточно высокую репутацию среди заказчиков (например, проводит грамотную рекламную кампанию). При нарушении этих условий заказчики уйдут к более привлекательным конкурентам, и прибыли не будет. А от сложных задач другие откажутся, и сработает принцип «если задача выглядит невозможной, обращайся к ним». Картина рисков другая, и не всегда очевидно, что лучше.
Да. конечно, программистом быть нелегко. Хорошим программистом еще тяжелее, а гениальным — это вообще фанатизм и дар божий. Но… есть и хорошая новость, технологии и знания накапливаются и уже можно делать сложнейшие вещи, не задумываясь о их сложности, спасибо ООП. Что имеем в итоге, даже плохой программист может неплохо зарабатывать, выше, чем профессионалы в других профессиях, а если держаться трэндов постоянно, то… вообще можно зарабатывать больше, чем стоишь…
Спасибо автору за статью и отклики — все это помогает осознать в чем проблема и как из этого вылезать ;).
Ситуация, как мне кажется, типична для нашего поколения (тем, кому сейчас около 40) — коллеги подтверждают по своему опыту (не только программисты).
Позволю себе предположить, что причина не в персоналиях, а в смене парадигмы. Раньше готовили специалиста широкого профиля, способного взяться за любую проблему и ее решить (написать программу, код для контроллера, спроектировать последний и т.п.). Тогда спецы были счетные, а задач масса. Эникейщик был лучшим вариантом.
За прошедшие почти 20 лет ИТ из области искусства одиночек превратилась в огромную индустрию, где спрос на продукты диктует требования к рабочей силе. Стала важна прикладная специализация и знания конкретной предметной области.
На языке маркетологов это звучит вот так:«Лучше делать что-то одно исключительно, чем многое хорошо».
Ситуация, как мне кажется, типична для нашего поколения (тем, кому сейчас около 40) — коллеги подтверждают по своему опыту (не только программисты).
Позволю себе предположить, что причина не в персоналиях, а в смене парадигмы. Раньше готовили специалиста широкого профиля, способного взяться за любую проблему и ее решить (написать программу, код для контроллера, спроектировать последний и т.п.). Тогда спецы были счетные, а задач масса. Эникейщик был лучшим вариантом.
За прошедшие почти 20 лет ИТ из области искусства одиночек превратилась в огромную индустрию, где спрос на продукты диктует требования к рабочей силе. Стала важна прикладная специализация и знания конкретной предметной области.
На языке маркетологов это звучит вот так:«Лучше делать что-то одно исключительно, чем многое хорошо».
Ниже не советы, не критика, а просто собственные ощущения от прочтения статьи и комментов (кстати, на удивление много конкретных, грамотных и обоснованных комментариев по теме).
1. Не следует так гордиться своими слабостями. Исходя из того, что «везде» вы получили отказы, можно сделать вывод, что на собеседовании вы общаетесь в той же манере, в какой написана эта статья.
2. Есть две крайности по типам проектов: А) где все строится на элегантности архитектуры, Б) где все строится на усердии и количестве программистов. Разные продукты делаются по-разному, и требования к разработчикам там разные. В крупных интернет-компаниях делают большие продукты, где все держится не на количестве кода, а не его архитектуре. В то же время, например, в банковском секторе даже в самых крупных компаниях все держится на количестве и надежности кода, а не на архитектуре.
Вы думаете, что в состоянии эффективно работать в любой компании (об этом написано в статье). Это глубокое заблежние, и странно, что оно присуще человеку с вашим не только жизненным, но и профессиональныем опытом. Складывается стойкое впечатление, что вы все это время шли вперед и смотрели только под ноги, не оглядываясь ни назад, ни по сторонам. Моя мысль в том, что ваш опыт пригодится для решения лишьт части задач, которые попадают под пункт Б. А в мейнстриме в интернет-компаниях (мы же про python тут говорим, а не про c++ на сколько я понял) как раз сейчас популярен и нужен программист-А (Б и так хватает). И программистов, так же как и инструменты, зачастую выбирают под задачи.
3. Ваш начальный опыт вообще имеет малое значение для работодателя. Все, что было более 15 лет назад, уже не актуально. Это даже про C++ можно сказать, а про Python я вообще молчу. Так что козырять этим багажом особого смысла нет. Важно, на сколько вы умеете работать в современных условиях, а не сколько кода написали ранее.
4. Ну и важный момент про работу в команде. Вы — индивидуалист. Вы готовы все делать своими руками (из-за этого и не стали до сих пор руководителем). При работе в команде нужно попадать под шаблон команды. Нужно уметь излагаит и понимать других. Это очень хорошо проверячется на собеседовании. Исходя из отказов, опять же предположу, что ваше мышление и общение не стыкуется со стандартными шаблонами. А в больших компаниях большие команды, там нужны люди-компоненты, а не индивидуалисты. Зато там, где нужны именно индивидуалисты, вас брали сразу, видя готовность решать любые задачи (именно решать, при этом не важно как).
5. После 40 лет на мой взгляд хороший программист — это тот, кто руководит. Как то вырисовывается такая картина из жизненного опыта. Если взялись ранно (как вы), то к такому возрасту можно уже высоко вырасти. Если взялись поздно (это не про вас, но мне такие попадались), то извините, но хорошим программистом вам уже не стать.
И ценность руководства не в том, чтобы много денег платили, или в хваставстве, или в ничего неделании. Ценность в масштабе. Карьерный рост — это увеличение масштаба воздействия своей работой. Вы как на вертолете должны взлетать все выше и охватывать все больше, при этом с меньшей детализацией. Это рост. А изучение новых инструментов — это не рост. Это просто опыт, который рано или поздно обесценится в такой динамичной отрасли.
1. Не следует так гордиться своими слабостями. Исходя из того, что «везде» вы получили отказы, можно сделать вывод, что на собеседовании вы общаетесь в той же манере, в какой написана эта статья.
2. Есть две крайности по типам проектов: А) где все строится на элегантности архитектуры, Б) где все строится на усердии и количестве программистов. Разные продукты делаются по-разному, и требования к разработчикам там разные. В крупных интернет-компаниях делают большие продукты, где все держится не на количестве кода, а не его архитектуре. В то же время, например, в банковском секторе даже в самых крупных компаниях все держится на количестве и надежности кода, а не на архитектуре.
Вы думаете, что в состоянии эффективно работать в любой компании (об этом написано в статье). Это глубокое заблежние, и странно, что оно присуще человеку с вашим не только жизненным, но и профессиональныем опытом. Складывается стойкое впечатление, что вы все это время шли вперед и смотрели только под ноги, не оглядываясь ни назад, ни по сторонам. Моя мысль в том, что ваш опыт пригодится для решения лишьт части задач, которые попадают под пункт Б. А в мейнстриме в интернет-компаниях (мы же про python тут говорим, а не про c++ на сколько я понял) как раз сейчас популярен и нужен программист-А (Б и так хватает). И программистов, так же как и инструменты, зачастую выбирают под задачи.
3. Ваш начальный опыт вообще имеет малое значение для работодателя. Все, что было более 15 лет назад, уже не актуально. Это даже про C++ можно сказать, а про Python я вообще молчу. Так что козырять этим багажом особого смысла нет. Важно, на сколько вы умеете работать в современных условиях, а не сколько кода написали ранее.
4. Ну и важный момент про работу в команде. Вы — индивидуалист. Вы готовы все делать своими руками (из-за этого и не стали до сих пор руководителем). При работе в команде нужно попадать под шаблон команды. Нужно уметь излагаит и понимать других. Это очень хорошо проверячется на собеседовании. Исходя из отказов, опять же предположу, что ваше мышление и общение не стыкуется со стандартными шаблонами. А в больших компаниях большие команды, там нужны люди-компоненты, а не индивидуалисты. Зато там, где нужны именно индивидуалисты, вас брали сразу, видя готовность решать любые задачи (именно решать, при этом не важно как).
5. После 40 лет на мой взгляд хороший программист — это тот, кто руководит. Как то вырисовывается такая картина из жизненного опыта. Если взялись ранно (как вы), то к такому возрасту можно уже высоко вырасти. Если взялись поздно (это не про вас, но мне такие попадались), то извините, но хорошим программистом вам уже не стать.
И ценность руководства не в том, чтобы много денег платили, или в хваставстве, или в ничего неделании. Ценность в масштабе. Карьерный рост — это увеличение масштаба воздействия своей работой. Вы как на вертолете должны взлетать все выше и охватывать все больше, при этом с меньшей детализацией. Это рост. А изучение новых инструментов — это не рост. Это просто опыт, который рано или поздно обесценится в такой динамичной отрасли.
После 40 лет на мой взгляд хороший программист — это тот, кто руководит.
Если руководить нет не желания, ни способностей — значит плохой программист?
Карьерный рост — это увеличение масштаба воздействия своей работой.
А увеличение масштабов проектов, в которых участвуешь?
Если руководить нет не желания, ни способностей — значит плохой программист?
Подчеркиваю — это мои личные наблюдения и личное мнение. Отвечаю: скорее всего да. Наверное есть исключения. И очень важное замечание: руководить — не значит перестать писать код. Обычно как раз наоборот — хороший программист-руководитель продолжает писать код, но это уже код более высокого уровня (например, библиотеки, или опенсорс для души). Очень хочу, чтобы меня правильно поняли. Постарайтесь, пожалуйста: хороший программист естественным образом растет не столько вширь, сколько ввысь. С ростом опыта и знаний он начинает шефствовать над другими, более молодыми программистами. Он использует свой опыт эффективно — на всю команду, а не на себя лично. Т.е. он растет по карьерной лестнице. Либо как вариант, начинает преподавать.
И еще раз: да, исключения, есть. И в большинстве случаев это либо гении, либо что-то близкое к гению.
P.S. Хоть я и использую глупое относительное понятие «хороший программист», но думаю, что большинство читающих правильно поймут, о чем идет речь.
А увеличение масштабов проектов, в которых участвуешь?
Увеличение масштаба проектов не имеет никакого значения, если собственная роль в проекте не меняется. Это не имеет отношения к персональному росту. Опыт, рост вширь — да, рост ввысь — нет.
Шефствовать в плане помогать и передавать знания — куда не шло (хотя предпочитаю обмен знаниями и опытом), но от руководителя даже уровня «ведущий программист» как правило требуется управление другими людьми. Прежде всего делегирование задач и контроль за их выполнением с личной ответственностью перед тимлидом, начальником отдела и т. п. То есть задачу ставят тебе, сроки спрашивают с тебя, а выполнять её должен не только ты. Причем прямо запрещают тупо работать за двоих-троих. Или впадать в другую крайность — выдавать ТЗ на «рутину» под подпись и «стучать» начальству, что задание в срок не выполнено, потому что подчиненный сорвал свою часть, ну и другие подобные способы, минимизирующие необходимость говорить другому человеку, что он должен делать, проверять делает ли он это, да ещё, не дай бог, мотивировать его или хотя бы давать рекомендации необходима ли мотивация. Да, к гениями себя не отношу :) Скорее к полным идиотам в рамках межличностных отношений — нет у меня к ним никаких способностей, какие-то гены не те достались.
Поддержу, собственно, вопрос и позицию. В моем окружении, например, достаточно много действительно высококлассных инженеров, но руководить они согласны исключительно с технической точки зрения. Т.е. они способны построить архитектуру приложения, способны реализовать любой аспект этой архитектуры в коде, способны проводить ревью кода и выполненных задач, но им совершенно неинтересны задачи управления людьми, сроками, ресурсами и т.д.
Вот, да, хорошее выражение «руководить исключительно с технической точки зрения». Создать тикет или написать ТЗ, объяснить что-то на словах, если нужно, пускай даже выбрать ответственного и раскритиковать потом его решение — ради бога. Но вот разбираться почему в срок не укладывается решение, что нужно сделать чтобы успеть или хотя бы минимизировать срыв — увольте.
Почему бы нет? Это же известно, если вы хорошо знакомы с вашими кодерами и знаете их индивидуальные особенности. Одному надо помочь, второго подбодрить и сказать ему, что он очень крут, третьего поругать…
Подбодрить, поругать — не ко мне. Реакция на это непредсказуема, системы-то недетерминированные, а меня с такими не учили работать :)
А-ха-ха-ха-ха-ха! Они спокойно управляются методом «белого ящика». Все, что вам надо знать про них, вы знаете, а то, что не надо — и буй с ним.
В том-то и дело, что это типичные черные ящики. Я сам для себя черный ящик, куда уж реакцию других предсказывать.
Что вам их реакция? Ну не съедят же они. Реакцию можно спокойно в /dev/null отправлять, если она вам не нужна. Если вы разбираетесь лучше них в технологиях, тогда вообще никакой проблемы не вижу в управлении людьми.
Пример реальный. Я говорю вечером «если завтра с утра тикет не будет закрыт, я пишу гендиру докладную». Утром прихожу, а там уже жалоба на меня, что я нарушаю ТК, заставляя работать сверхурочно.
Оххх, уважаемый VolCh… нужен индивидуальный подход к этим ящикам, а не агрессия… как вы этого не понимаете? Вам же не докладная нужна, а getting things done… а от докладной они не будут done, а только их разозлите, эти ящики, и настроите против себя…
Я понимаю, что нужен. И понимаю, что это вне моих возможностей пока не создано практически применимых матмоделей мозга.
Вам не нужен весь их мозг, а только та часть, которая отвечает за работу + чуть-чуть психологии. Вот у вас дети есть? Если да, то вы меня понимаете. Программеры управляются в точности, как маленькие дети.
Психологию я считаю шарлатанством. Нет повторяемости результатов и т. п.
Нет детей :( Не справился с управлением женой :(
Нет детей :( Не справился с управлением женой :(
Шутите? Конечно, в психологии есть повторяемость результатов. Это же наука.
Женой тоже методом черного ящика управляли?
Женой тоже методом черного ящика управляли?
Все что я слышал от психологов — никаких гарантий. Может сработать какой-то прием, а может нет. И даже вероятность срабатывания назвать затрудняются.
Типа того, пытался модель построить, но на одни и те же воздействия совершенно разная реакция была. То ли какие-то условия не учитывал, то ли внутри ГСЧ :)
Типа того, пытался модель построить, но на одни и те же воздействия совершенно разная реакция была. То ли какие-то условия не учитывал, то ли внутри ГСЧ :)
Повторяемость результатов есть в инженерной психологии. В той, где томографом мозг изучают. А в психотерапии — только опыт и шаманство, но никакой повторяемости.
Вдогонку:
Как-то мне кажется, что имеет. Разработка ядра или архитектуры системы с 10 пользователями далеко не то же самое, что с 10 миллионами пользователей. Или с системой учитывающей МЦ и НМА на тысячи рублей и на миллиарды. Я считаю это вполне нормальным персональным ростом. Цена ошибки, ответственность и т. п. постоянно растут. Возможности причинять добро — тоже :)
Увеличение масштаба проектов не имеет никакого значения, если собственная роль в проекте не меняется.
Как-то мне кажется, что имеет. Разработка ядра или архитектуры системы с 10 пользователями далеко не то же самое, что с 10 миллионами пользователей. Или с системой учитывающей МЦ и НМА на тысячи рублей и на миллиарды. Я считаю это вполне нормальным персональным ростом. Цена ошибки, ответственность и т. п. постоянно растут. Возможности причинять добро — тоже :)
Не вырывайте из контекста. Я сформулировал очень четко:
Ваш комментарий выше, на который я отвечал, касался карьерного роста (т.е. становления себя в качестве руководителя). Именно в этом контексте сказано: «Увеличение масштаба проектов не имеет никакого значения [в отношении к карьерному росту]»
Увеличение масштаба проектов не имеет никакого значения, если собственная роль в проекте не меняется. Это не имеет отношения к персональному росту. Опыт, рост вширь — да, рост ввысь — нет.
Ваш комментарий выше, на который я отвечал, касался карьерного роста (т.е. становления себя в качестве руководителя). Именно в этом контексте сказано: «Увеличение масштаба проектов не имеет никакого значения [в отношении к карьерному росту]»
Если переформулировать тот вопрос в ваших терминах, то звучать он будет, наверное, так: «Разве отсутствие карьерного роста (т.е. становления себя в качестве руководителя) говорит об отсутствии персонального профессионального роста? Он же может выражаться и в, скажем, росте масштаба проектов без понижения выполняемой роли»
Я бы хотел возразить:
Это в зависимости от того, кого берут на работу. Если красноглазого молодого кодера — да, все именно так. Если человека, от которого важно думать проекты, архитектуру и доводить дело до конца, особенно в перспективе какого-нибудь 10-летнего жизненного цикла проекта — ох как сомнительно на счет предыдущего опыта. Если у человека за спиной 20 лет, сплошной успех, миллионы довольных клиентов и столько же заработанных его конторами денег — ну как нормальный работодатель на это не посмотрит? Да это же ключевой фактор. Кроме совсем убитого на голову оутсорса, где завтра забудут что делали сегодня.
Вы мыслите шаблонной категорией компании «более 1000 человек», где действительно существует карьерная лестница и формальный понятный карьерный рост. На небольших продуктовых конторах все это сжато в комок, и от того, какая должность написана у разработчика в визитке — не важно, если он продакт овнер и т.п. Тут эти шаблоны индустрии никак не действуют.
Ваш начальный опыт вообще имеет малое значение для работодателя. Все, что было более 15 лет назад, уже не актуально. Так что козырять этим багажом особого смысла нет. Важно, на сколько вы умеете работать в современных условиях, а не сколько кода написали ранее.
Это в зависимости от того, кого берут на работу. Если красноглазого молодого кодера — да, все именно так. Если человека, от которого важно думать проекты, архитектуру и доводить дело до конца, особенно в перспективе какого-нибудь 10-летнего жизненного цикла проекта — ох как сомнительно на счет предыдущего опыта. Если у человека за спиной 20 лет, сплошной успех, миллионы довольных клиентов и столько же заработанных его конторами денег — ну как нормальный работодатель на это не посмотрит? Да это же ключевой фактор. Кроме совсем убитого на голову оутсорса, где завтра забудут что делали сегодня.
После 40 лет на мой взгляд хороший программист — это тот, кто руководит. Как то вырисовывается такая картина из жизненного опыта. Если взялись ранно (как вы), то к такому возрасту можно уже высоко вырасти. Если взялись поздно (это не про вас, но мне такие попадались), то извините, но хорошим программистом вам уже не стать
Вы мыслите шаблонной категорией компании «более 1000 человек», где действительно существует карьерная лестница и формальный понятный карьерный рост. На небольших продуктовых конторах все это сжато в комок, и от того, какая должность написана у разработчика в визитке — не важно, если он продакт овнер и т.п. Тут эти шаблоны индустрии никак не действуют.
Если человека, от которого важно думать проекты, архитектуру и доводить дело до конца, особенно в перспективе какого-нибудь 10-летнего жизненного цикла проекта — ох как сомнительно на счет предыдущего опыта.
Тут вопрос. Насколько изменились архитектура и масштабы проектов за эти годы. Будет ли 20-летний опыт поддержки успешного проекта, начинавшегося ещё на IBM PC 386 с 4 мегабайтами RAM, полезен для новых проектов сейчас? Или сотруднику придётся забыть всё, к чему он привык, чтобы «думать проекты» в новых условиях? И не будет ли здесь преимущества у какого-нибудь молодого кандидата наук, которому забывать пока нечего?
Думаю, будет. Самая главная цель любого проекта — удовлетворение потребностей заказчика. Если умеешь их удовлетворять, а ещё лучше выявить те, о которых он ещё не догадывается (или объяснять почему их невозможно удовлетворить :) ), то хороший работник. :) Необходимости держать руку на пульсе, чтобы знать о новых возможностях удовлетворения (грубо — знать, что из того, что вчера была невозможно для мегакорпораций и правительств, сейчас доступно на любом телефоне), это не отменяет.
Это иллюзия. На самом деле ничего не меняется. Меняются технологии, ну и что? Они 20 лет меняются каждый день.
Есть еще умение «увидеть» задачу, спроектировать, войти в предметную область, сделать, сделать сразу и качественно,…
Хотя, когда народ мыслит только категориями того, что нужно в оутсорсе, тогда это все не нужно…
Есть еще умение «увидеть» задачу, спроектировать, войти в предметную область, сделать, сделать сразу и качественно,…
Хотя, когда народ мыслит только категориями того, что нужно в оутсорсе, тогда это все не нужно…
На самом деле, на собеседовании бывает смешно, когда выдают самые несущественные детали за важнейшие, краеугольные камни, без которых вообще нельзя себе представить разработчика. Например, когда server-side разработчика сайтов под веб спрашивают про редкоиспользуемый функционал СУБД, такой как Common Table Expressions, потом спрашивают SYN/ACK-схему коннекта HTTP и выдают это всё за самые, просто наиважнейшие вещи, без которых программист — не программист, мотивируя с серьезной миной это тем, что-де у них один раз у какого-то пользователя трафик был заблокирован файерволлом, и им это тайное знание очень, очень пригодилось, когда они разбирались с этим случаем, то просто смех разбирает, честное слово. Зачем, я не понимаю, знать эту схему? Ну приспичит посмотреть трафик — да пожалуйста, залезем в трафик Ethereal-ом, да и посмотрим. Какое отношение вообще эта тема имеет к блокировке файерволлом?
Да и уважаемый feedbee, ну какой я индивидуалист, скажите на милость, если я 15 лет работал в команде? Я этого не понимаю. Отнюдь. Я абсолютно командный игрок.
Индивидуалист — это подход к работе, стиль работы. Это не значит, что вы работали один. Индивидуалист развивает себя, собственные программерские скилы. А командный игрок развивает команду, собственные скилы взаимодействия и использования других людей в работе, имея за счет этого рост вверх (а не вширь).
Кто скажет, что я развиваю только собственные программерские скилы, пусть первый кинет в меня камень :) Но кто скажет, что я должен напрямую использовать других людей в приказном порядке, то есть говорить что им нужно делать и проверять ход выполнения — получит заявление об увольнении. Поучаствовать в мозговом штурме, высказать свое мнение, покритиковать решение, дать рекомендации, передать свои знания и т. п. — не вопрос. Контролировать как другие люди справляются со своими обязанностями — увольте. По собственному желанию. Или даже за несоответствие занимаемой должности, если занял её в приказном порядке не смотря на свои возражения, что для мало-мальской руководящей должности я не гожусь.
Да ладно, уважаемый VolCh, чё бы и не проконтролировать? Что тут такого страшного? Я — не вопрос — могу проконтролировать, и контролировал в своем последнем стартапе. Просто это не самоцель — контролировать — и совсем меня не прикалывает.
Сама цель в моем понимании — это увеличение масштаба воздействия. И достигается она только через переход к руководству. Это как в армии: офицеры только руководят, они сами окопы не капают. При этом именно от их решений зависит буквально все в бою. Чем выше уровень, тем больше степень влияния вплоть до максимального. А чем выше степень влияния, тем интереснее и эффективнее работа конкретного человека.
Если вам не интересно работать на высоком уровне, будьте готовы к такой ситуации, как написано в топике и некоторых комментах. И ничего страшного в этом нет — каждому свое. Просто понимание такой ситуации — это уже неплохо. А поддержание мысли, что вы самый нужный и самый ценный, даже если этот опыт приносит не больше профита, чем (1,5*senoir), влечет к таким обидам и непониманию требований на собеседованиях.
Если вам не интересно работать на высоком уровне, будьте готовы к такой ситуации, как написано в топике и некоторых комментах. И ничего страшного в этом нет — каждому свое. Просто понимание такой ситуации — это уже неплохо. А поддержание мысли, что вы самый нужный и самый ценный, даже если этот опыт приносит не больше профита, чем (1,5*senoir), влечет к таким обидам и непониманию требований на собеседованиях.
Вот, кстати про армию. Хотел всё вставить, что «плох тот солдат, который не хочет стать генералом» — не абсолют. В технически сложных видах войск или, например, в штабной работе, у офицера (вплоть до полковника, про генералов не знаю, хотя вроде ) вполне может не быть подчиненных. Честь ему солдаты отдавать должны, а вот выполнять приказания «по службе» нет — единоначалие. Он может попросить коллегу по «горизонтали», чтобы тот отдал приказ своим подчиненным. Может попросить общего командира, чтобы тот отдал приказ коллеге, чтобы тот отдал приказ подчиненному и т. п. Но кто-то разве скажет, что аналитик в штабе в звании полковника — плохой офицер, раз у него нет подчиненных?
Подчиненных может не быть, но зона влияния соответствует званию. Это, наверное, про всяких замполитов. Думаю, вы понимаете, какое у них влияние, и какой уровень масштаб деятельности. Кроме того, это определенно руководители. Отсутствие прямых подчиненных не значит, что человек не относится к руководящему составу.
Это вырожденный случай руководителя. И точно такой же пример есть и в software engineering — архитекторы и евангилисты. Масштаб их деятельности очень широк в крупных и просто широк в средних компаниях. А в мелких компаниях по профиту они равносильны сеньерам. И в любой нормальной компании кандидаты на такие позиции должны отлично знать все, что тут обсуждалось. И это подтверждали многие руководители в комментах выше. Не можешь нормально и доступно объяснить, как работает HTTP и HTTPS, как работает TCP/IP? Какой из тебя тогда архитектор или евангелист? Как ты будешь коллегам передавать объяснять свои наработки? Подчеркиваю, не обязательно все знать на зубок, но уметь объяснить сходу (== понимать) нужно. Это моя позиция.
P.S. Если на собеседовании человек действительно в теме, то на вопрос «Как работает HTTP» он спросит на каком уровне объяснять (1-е обязательное условие) и сможет объяснить на запрошенном уровне (это не ниже уровня TCP/IP, но чаще всего речь вообще только об уровне HTTP, т.е. на уровне интерфейса стека TCP/IP) — 2-е условие. А вот если начинается выпендреж про WM_*, то это как раз человек толком и не знает ничего (либо он пришел на собеседование повыпендриваться, что всегда влечет отказ).
Это вырожденный случай руководителя. И точно такой же пример есть и в software engineering — архитекторы и евангилисты. Масштаб их деятельности очень широк в крупных и просто широк в средних компаниях. А в мелких компаниях по профиту они равносильны сеньерам. И в любой нормальной компании кандидаты на такие позиции должны отлично знать все, что тут обсуждалось. И это подтверждали многие руководители в комментах выше. Не можешь нормально и доступно объяснить, как работает HTTP и HTTPS, как работает TCP/IP? Какой из тебя тогда архитектор или евангелист? Как ты будешь коллегам передавать объяснять свои наработки? Подчеркиваю, не обязательно все знать на зубок, но уметь объяснить сходу (== понимать) нужно. Это моя позиция.
P.S. Если на собеседовании человек действительно в теме, то на вопрос «Как работает HTTP» он спросит на каком уровне объяснять (1-е обязательное условие) и сможет объяснить на запрошенном уровне (это не ниже уровня TCP/IP, но чаще всего речь вообще только об уровне HTTP, т.е. на уровне интерфейса стека TCP/IP) — 2-е условие. А вот если начинается выпендреж про WM_*, то это как раз человек толком и не знает ничего (либо он пришел на собеседование повыпендриваться, что всегда влечет отказ).
Не можешь нормально и доступно объяснить, как работает HTTP и HTTPS
Помнится как-то на собеседовании удивил собеседующего при ответе на вопрос «что происходит когда пользователь набирает адрес в строке браузера» рассказав, что при приходе заголовков типа if-modified-since сервер может дать ответ 304 и больше ничего не делать. Он кэширование знал только экспайр, не проверяемое браузером при каждом запросе. А вот HTTPS я «завалил», потому что ответил что-то вроде «клиент и сервер устанавливают защищенный канал договариваясь с помощью ассимитричного шифрования о ключе симметричного, а потом внутри этого канала обычный HTTP». Ну вот не приходилось мне с https близко работать — не было требований шифрования канала нижt http или оно реализовывалось ещё ниже (vpn и т. п.) — один раз прочитал, принцип отложился и хватит, а с кэшированием приходилось плотно.
Подчиненных может не быть, но зона влияния соответствует званию.Никак нет. Классический пример — авиаполк: летный состав сконцентрирован в трех эскадрильях, там может вообще не быть рядового и сержантского состава, он будет весь сконцентрирован, например, в части аэродромно-технического обеспечения. При этом ни прямого, ни оперативного влияния у, положим, капитана-летчика, на сержанта из АТО не будет — только через командира части.
Речь о зоне влияния не на других людей, а на результат работы организации. Если вы пишете код, то зона влияния ограничена возможностями одного человека — малая. Если вы разрабатываете архитектуру (касается только крупных и средних компаний) или управляете другими людьми, то зона влияния у вас большая. Кстати, разрабатывать архитектуру тоже можно на разных уровнях детализации. Вообще, про детализацию Лебедев хорошо написал в параграфе про прогрессивный JPEG.
Вон возьмите Торвальдса. Он код не пишет. Он управляет сообществом и применяет патчи. А Аксенов, например, код пишет. И сравните масштаб результатов их деятельности. (Это я в очередной раз к тому, что каждому свое.)
Так вот если бы уважаемый mike1 хотя бы близко приближался по уровню к таким людям, как Аксенов или Сысоев, не было бы этой статьи. И было бы одно из двух: либо работа в крупной технологической компании (то, чего он хотел), либо свой бизнес. А тут кроме огромного самомнения, долгого и широкого опыта (мастерсва) и насмешливого отношения к работодателю я ничего не вижу.
Вон возьмите Торвальдса. Он код не пишет. Он управляет сообществом и применяет патчи. А Аксенов, например, код пишет. И сравните масштаб результатов их деятельности. (Это я в очередной раз к тому, что каждому свое.)
Так вот если бы уважаемый mike1 хотя бы близко приближался по уровню к таким людям, как Аксенов или Сысоев, не было бы этой статьи. И было бы одно из двух: либо работа в крупной технологической компании (то, чего он хотел), либо свой бизнес. А тут кроме огромного самомнения, долгого и широкого опыта (мастерсва) и насмешливого отношения к работодателю я ничего не вижу.
И в любой нормальной компании кандидаты на такие позиции должны отлично знать все, что тут обсуждалось. И это подтверждали многие руководители в комментах выше. Не можешь нормально и доступно объяснить, как работает HTTP и HTTPS, как работает TCP/IP? Какой из тебя тогда архитектор или евангелист?
Ой… а если в проектах, которыми занимается компания, сетевые интерфейсы вообще не используются? Всё равно их надо отлично знать?
Еще раз:
1. Я устраивался не на архитектора и евангелиста, а на обычного разработчика.
2. Я прекрасно знаю, как работает HTTP, формат HTTP-пакетов также знаю, знаю все HTTP-заголовки, но не знаю алгоритм TCP-хендшейка при установления HTTP-соединения.
1. Я устраивался не на архитектора и евангелиста, а на обычного разработчика.
2. Я прекрасно знаю, как работает HTTP, формат HTTP-пакетов также знаю, знаю все HTTP-заголовки, но не знаю алгоритм TCP-хендшейка при установления HTTP-соединения.
С вами мне уже все ясно. Ваше отношение к интервьюеру и манеры общения отодвигают все остальное на второй план. Неуважение хорошо читается в процессе разговора с умными и уверенными в себе людьми. Возможно есть и другие моменты (типа больших теоретических пробелов), но это уже не более чем догадки. И цель написания этой статьи для меня тоже очевидна — потешить самолюбие. Это мое личное мнение, которые сформировано вашим текстом статьи и ответами в комментах. С таким подходом вам действительно будет сложно пройти 90 % самых адекватных собеседований.
Сейчас практически все системы клиент-серверные. При разработке Paint, наверное, действительно не обязательно знать сети. Но любой хороший питонист, пхп-шник, рубильник и сишник должен сети знать.
Ну… может быть. Когда будем подключать сканер к компьютеру по Ethernet, тогда и сетевые протоколы, наверное, изучать придётся. А пока по скорости хватает USB, переходить на другие интерфейсы не хотят ни хардверщики, ни программисты. Для обработки сеть тоже не очень нужна (пока). Но, в общем, да — это где-то уровень Paint. В лучшем случае, Photoshop.
Насколько он (то есть я, пхпшник) должен их знать, если 99% это работа в «песочнице», где есть входные параметры и вывод на stdin, делающим ненужным даже знание http?
На столько, на сколько и другие программисты, которые разрабатывают клиент-сервер. Эти знания нужны, чтобы делать осознанный выбор технологий, находить трудноуловимые ошибки взаимодействия, в том числе на продакшане, разрабатывать защищенные системы.
Ну а что бы сразу не сдавать экзамен по цифровой схемотехнике: вся эта транзисторно-транзисторная логика, мультиплексоры, дешифраторы — это же база любых вычислений.
Надеюсь вы понимаете, что неиспользуемые знания «удаляются». Я читал протоколы, разрисовывал, многое снифил и дампил, «эмулировал» браузер через telnet, пытался «ломать» некорректными пакетами и т. п. Но это было лет 10 назад. За эти 10 лет уровень ниже HTTP понадобился раза три (если не считать ping, traceroute и т. п.). Все три раза я просто читал заново как происходят те или иные процессы. Естественно без подготовки на собеседовании я не смогу описать даже http запрос на уровне ip. Сейчас смогу, но только потому что в этом месяце последний раз был, когда я пакеты ловил tcpdump'ом, чтобы определить принимает ли удаленный сервер запрос с моего или пакет где-то по дороге умирает. Месяц назад не смог бы. Через месяц тоже не смогу. Мне нужно каждый месяц читать описания протоколов?
Я понимаю то, что сам использую эти знания постоянно. telnet-ом слал POST-ы ровно вчера, tcpdump-ом смотрел трафик месяц назад. При проектировании все это нужно, все это используется. И спорить, извините, не буду. Свою позицию я озвучил и обосновал.
Только отмечу, что в мои обязанности входит не только разработка (по большей части руководство и архитектура), но и построение инфраструктуры и обслуживание работающих проектов (опять же на уровне архитектуры и руководства). Может быть по-этому я особенно ценю свои знания в сетях.
Вообще, как писали выше, чтобы получить фундаментальные знания по базовым дисциплинам достаточно действительно прочитать подряка 5 книг. Причем, сети полностью и операционные системы (межпроцессное взаимодействие в частности) полностью покроют 2 книги Танненбаума, написание нормального кода — Боб Мартин, паттерны — тут уже по вкусу из нескольких вариантов. Т.е. все не так сложно, но очень полезно.
И да, так как знания удаляются, предлагаю не изучать математику после 5 класса, т.к. в жизни ей почти никто не пользуется. Извечный вопрос — учить или не учить. И ответ по-моему очевиден.
Вообще, как писали выше, чтобы получить фундаментальные знания по базовым дисциплинам достаточно действительно прочитать подряка 5 книг. Причем, сети полностью и операционные системы (межпроцессное взаимодействие в частности) полностью покроют 2 книги Танненбаума, написание нормального кода — Боб Мартин, паттерны — тут уже по вкусу из нескольких вариантов. Т.е. все не так сложно, но очень полезно.
И да, так как знания удаляются, предлагаю не изучать математику после 5 класса, т.к. в жизни ей почти никто не пользуется. Извечный вопрос — учить или не учить. И ответ по-моему очевиден.
Если контроль заключается только в том, чтобы оценить какая примерно часть задачи выполнена и доложить «наверх», чтобы там сделали оргвыводы (не по отношению ко мне :) ), то ещё терпимо. Делать оргвыводы самому — увольте. По собственному.
Ну почему «увольте»-то? Вы боитесь поругать программера? А если за дело поругать?
Поругать — это полбеды. К сожалению, в большинстве случаев, когда речь идет не о «своем бизнесе», возникает вопрос вот какого свойства: у человека есть «зона влияния» и «зона ответственности». В идеальном случае человек не отвечает за то, на что не может повлиять. Проблема в том, что в задачах управления людьми никто не может на сто процентов гарантировать поведение человека; приходится страховать риски — но это увеличивает стоимость, а она тоже не резиновая. В итоге любой руководитель находится в положении, когда его зона ответственности шире зоны влияния. А это ситуация стрессовая и не для всех приемлимая.
Типа того. Раскритиковать решение с технической точки зрения — не вопрос. Критиковать человека, особенно ему в глаза — увольте.
В этом ответе сжато изложено ваше отношение к работодателю, которое 100 % отслеживается во время собеседования любым адекватным собеседующим. Тоже самое написано в статье, только здесь оно сжато. Вы проходили интервью в серьезных компаниях и так и не поняли, что у них огромный опыт в том, что надо спрашивать, чтобы найти нужный им персонал. И они отлично справляются с этой задачей. Они находят нужных. А вы им не нужны. А вы задачу устроиться на работу в хорошей технологической компании проваливаете из раза в раз. И не желаете понять, почему так происходит. Наоборот, вы убеждаете себя, что сам такой хороший и нужные, а они глупы.
И я не говорю, что вам надо меняться. Если вообще говорить о советах, то выше есть много классных комментов — именно советов. Обоснованных. И проплюсованных. А я от советов воздержусь, в том числе и по причине разницы в возрасте и опыте. Но чего мне действительно хотелось бы, так это постараться донести понимание ситуации до вас. Хотя бы просто взгляд с другой стороны. Вы упорно смотрите с одного угла и не желаете понять тех, кто смотрит по-другому. Вы пытаете объяснить коллегам, что эти работодатели какие-то странные, ничего не понимают. И, как известно, когда все вокруг странные, то обычно проблема не во всех.
И я не говорю, что вам надо меняться. Если вообще говорить о советах, то выше есть много классных комментов — именно советов. Обоснованных. И проплюсованных. А я от советов воздержусь, в том числе и по причине разницы в возрасте и опыте. Но чего мне действительно хотелось бы, так это постараться донести понимание ситуации до вас. Хотя бы просто взгляд с другой стороны. Вы упорно смотрите с одного угла и не желаете понять тех, кто смотрит по-другому. Вы пытаете объяснить коллегам, что эти работодатели какие-то странные, ничего не понимают. И, как известно, когда все вокруг странные, то обычно проблема не во всех.
Но чего мне действительно хотелось бы, так это постараться донести понимание ситуации до вас.
Не потому что я тут такой умный разумный. Не умнее вас, наверное. А потому что смотрю на все со стороны. И имею собственный программерский опыт, в том числе и управленческий, чтобы делать какие-то подобные умозаключения.
После 40 лет на мой взгляд хороший программист — это тот, кто руководит.Значит ли это, что с возрастом падает продуктивность и раз человек начинает хуже кодить, то пусть хотя бы поруководит? Если 40-летний работает как 25-летний сеньор, то он плохой программист, или это просто невозможный случай (по вашему опыту)?
Без ответов на вопросы Ваш рассказ был бы IT-драмой, но вопросы и ответы положительно меняют восприятие поста. Спасибо! =)
Спасибо, уважаемый ev42! На самом деле в этом есть какой-то драматизм. Потому что проблема с работой у меня до сих пор не решена. Я езжу по софтверным компаниям ...to no avail… Скоро буду как этот испанец: www.rb.ru/article/post-bezrabotnogo-ispantsa-o-rynke-truda-vzorval-facebook/7226987.html
Предлагаю решение для всех. Буду рад комментариям.
Прекрасный шаблон биографии!
Можно фигачить, например, «Основные вехи моих взаимоотношений с женщинами»:
— 1973-1985. Периодически находил в журналах и книгах картинки и фотографии женщин и внимательно их рассматривал.
— 1985. Мечтал о беспорядочных взаимоотношениях. Выписывал журнал «Здоровье», где публиковались предупреждения о беспорядочных взаимоотношениях.
— 1990. Мне купили надувную куклу, с большими ППЗУ и расширенным набором команд. Я вводил в неё свои программы. Ни о каких других женщинах я не имел понятия.
Или «Основные вехи моих взаимоотношений с автомобилями».
Или «Основные вехи моих взаимоотношений с алкоголем».
Или «Основные вехи моих взаимоотношений с религиозно настроенными гражданами».
Можно фигачить, например, «Основные вехи моих взаимоотношений с женщинами»:
— 1973-1985. Периодически находил в журналах и книгах картинки и фотографии женщин и внимательно их рассматривал.
— 1985. Мечтал о беспорядочных взаимоотношениях. Выписывал журнал «Здоровье», где публиковались предупреждения о беспорядочных взаимоотношениях.
— 1990. Мне купили надувную куклу, с большими ППЗУ и расширенным набором команд. Я вводил в неё свои программы. Ни о каких других женщинах я не имел понятия.
Или «Основные вехи моих взаимоотношений с автомобилями».
Или «Основные вехи моих взаимоотношений с алкоголем».
Или «Основные вехи моих взаимоотношений с религиозно настроенными гражданами».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нелёгкая карьера программиста или чего хотят работодатели