Балаболы бывают разные, как и дяди Леши, собственно. У разных проектов разные требования к работе. На каком-нибудь гейм-деве, когда не понятно, будет ли репа поддерживаться через год, но очень надо успеть к дате релиза (поскольку за рекламу уже заплачены деньги) – такой дядя Леша был бы рок-звездой. А если контора большая и долгоживущих проектов много, то возможно еще и санитаром леса.
А может быть и какая-нибудь эмбедед разработка “на века” когда важна не скорость выполнения работы, а получившийся по итогу дизайн, масштабируемость и удобство исходников для понимания других программистов. В таком окружении дядя Леша заставлял бы свою команду страдать, ведь есть масса работы, которую никто не хочет делать, включая упомянутые созвоны, менторство трейни, или трату кучи времени на ревью чужого кода. Это приводит к тому, что за дядей Лешей должен быть закреплен специальный человек, который будет доделывать, все, что им обоим не хотелось бы делать. Таким вот “подтерателем попы для всех” одно время и я работал. И знаете, одно дело когда молодой человек что-то не делает потому что не умеет (его можно со временем научить). Но когда образованный человек, искренне верит, что он лучше других и у конторы должны быть к нему особые требования – с таким персонажем работа плохо ладится. Сначала он сам выдавливает из коллектива равных по силам инженеров, чтобы давить авторитетом оставшихся, а потом жалуется что все держится на нем. Команде от его пренебрежительного отношения очень не комфортно и в итоге он сам со временем начинает скучать и уходит, а его творчество потом годами рефакторится. Мораль – определенный типаж людей я бы не брал в свою команду ни за какие деньги, но это гиперболизированный случай конечно. Сложность в том, чтобы этот типаж выявить на собесе, и желательно не ложно-позитивно.
БТВ, субъективно, в истории из поста Роман далек от того, чтобы делать работу интервьюера профессионально. Обычно умный парень знает что он умный, но наивно думать, что ты умнее всех. Как правило, такой Роман, это среднего ума разработчик, который старается честно выполнять любую работу, которую ему поручат (даже если он к такому не был подготовлен). В итоге он основываясь на своем опыте (и неприятных случаях) создает в голове картинку идеального работника, и судит о людях исходя из соответствия этой субъективной картинке. Вот только картинка составлена в терминах интервьюера. Соискатель может его просто не понять и интервьюер обязан это держать в голове. Твердолобость – плохая черта для любого руководителя. Если не заладилось с будущими коллегами еще на собесе, то хорошо что это стало понятно сразу.
Мне далеко до маститого специалиста, но свой гит в резюме указываю. Хоть своим кодом не доволен, да и вряд ли его кто-то будет смотреть с пристрастием.
Другое дело, что если в процессе собеседования выясняется, что будущий начальник ожидает каких-то сверхурочных активностей (а иначе не тру-программист), то руководство там будет барин-стайл. Это когда просчеты менеджмента ложаться на плечи разработчиков, а поощряют вместо денег всяким барахлом.
Надо из такого места валить поскорее, можно рыбкой в окно)
В общем, я за програмистский кураж, но только если он добровольный.
Ну мы обычно первые комиты новичков очень придирчиво смотрим, а со временем становится понятно какие у каждого сильные и слабые стороны. Конечно идеально было бы найти идеального кандидата, но мне пока так ни разу не везло)
Согласен. Такого рода ошибки можно отловить на код-ревью. Таким тонкостям как раз можно научить, я думаю. А вот если человек плохо обучаем, или склонен безосновательно стоять на своем, то такого человека лучше сразу не брать в команду.
Мне это пригодилось для ленивого способа подсчета числа сочетаний для своего домашнего мини-бикини-пет-проекта. Рабочие задачи, к сожалению, более унылые. А те что не унылые требуют знания предметной области, которого от соискателя не ожидается.
произведение dimX * dimY вычисляется без переполнения
Мб я что-то не понял, но по моему самый простой вариант, если код будет работать на 64-разрядной машине, то произведение двух uint32_t не сможет превысить размер адресного пространства, Так можно наложить ограничения без накладных расходов на проверку. Правда проверка того, что сами аргументы не были вычислены с переполнением уже становится заботой клиентского кода). Кроме того у системы закончится память гораздо раньше и аллокатор выбросит bad_alloc исключение. Если же это код для 32-разрядной машины (или для контроллера), то всевозможные учеты аппаратных ограничений становятся самостоятельным видом искусства). В целом согласен - хорошая задача на внимание к деталям.
С моей точки зрения - любой корректно работающий вариант - правильный. Я, к примеру пошел на https://umath.ru/calc/graph , построил y=x!/2^128 и посмотрел в какой точке кривая пересекает 1. Потом, чтобы убедиться, что логика сайта не забагована для таких случаев, пошел в убунтовский калькулятор, убедился, что 2^128−34! - положительное, а 2^128−35! отрицательное. Конечно решение изяществом не блещет, но с точки зрения продакшена - корректный результат за разумное время - то что надо. Соискатели (среди которых бывают и вчерашние студенты) демонстрируют, к примеру свой матан: "Надо вывести уравнение, так сейчас, сейчас... Минуточку, но у факториала же нет обратной функции!" иногда еще и с вопросительной интонацией в конце) Дальше мы переходим к численным методам. В лоб перемножать числа с 2 почему-то всем очень не нравится, пытаются приплести метод половинного деления. Много разговоров об О-нотации, но это все - чтобы оценить на сколько инженер самостоятельный, будет ли он искать способ самому проверить свое творчество (не рассчитывая что другой инженер на код ревью все исправит), на сколько склонен к оверинжениренгу, достаточно ли у него фантазии, чтобы решать абстрактные задачи.
Это все я к тому, что над такой вот задачкой не надо 5 минут вчитываться, задавать уточняющие вопросы, потом 5 минут думать в неловкой тишине. А информации о том, как потом с человеком работать это даст не меньше. Но это субъективное мнение, конечно.
Мне сложно представить на собесе реального человека, который думал бы так быстро и так совершенно. По моему, пора уже на литкоде, где-нибудь под катом прятать секретное стоп-слово, чтобы каждый знакомый с задачей разработчик мог предъявить его другому такому-же разработчику. А за одно можно было бы и остановить интервьюера, пока он не достиг экстаза от самолюбования. Как то желчно вышло, но я бы и правда предпочел скорее тимейта с на 30% меньшим интеллектом и душностью, но на 20% большей честностью, сообразительностью и коммуникабельностью. Такой человек, как правило, всегда при работе и не станет специально готовится к собеседованию. Мой типовой вопрос попроще: Есть 128-битный без знаковый инт на входе. При валидации этого числа надо проверить, влезет ли его факториал в такой-же 128-битный инт (т.е. сравнить с захардкоженым числом). Как будешь считать это число?
я вдруг понял, что можно развести холивар на тему того, что считать soft скилами)
На мой взгляд, рецепт хорош - формализовать цель, идти к ней, трекать прогресс. Это применимо и для софтскилов, если возможно формализовать цель.
Но для того, чтобы почувствовать себя молодцом есть способ попроще. Например можно брать задачи, которые дугие не хотят или не могут делать, тогда на саморазвитие и учет потраченного на него времени просто не останется сил)
Зато, когда придет время “продавать” себя начальству, будет гораздо проще убедить его в своей незаменимости. А деньги, в каком-то смысле и есть мера общественной пользы и личной не субьективной крутости.
"... выполним заказ ДЕШЕВО, КАЧЕСТВЕННО и БЫСТРО*" А внизу мелким шпифтом: " * выберите два любых требования." Все пытался представить челвека, который умеючи делать качественно будет выполнять работу долго и дешево, а это оказывается Вася)
Хм, прикольное узнал, я только не пойму…
Если 0 и 1 должны быть равновероятны в целях минимизации износа памяти, то зачем AES, если можно по очереди давать для xor-а, сначала 010101… а потом 101010…?
Это, к примеру, позволило бы восстановить данные с диска со сгоревшим контроллером
Соискатель заявил: «Подписанный акт выполненных работ»
Я бы не смог найти на Ваш вопрос более логичного ответа. Может дело в том, что я просто кодер и всегда избегал менеджерских задач.
А для Вас что является успешным завершеннием проекта и какой ответ Вы надеялись услышать от соискателя?
Так надо не на разрабов сетовать, а на требования рынка (т.е самих потребителей). А программисту скоько заплатили, столько он и споет.
Звучит, как будто зодчий из 16 века, посмотрел на современные многоэтажки и говорит:"что за ерунда! Это фуфло бетонное и 100 лет не простоит. Вот я замки строил из чистого камня 500 лет назад, так они до сих пор не покосились". И будет прав, только никто все равно не будет покупать жилье на которое надо собирать деньги три поколения.
Прекрасные истории, правда некоторые сейчас сложно представить.
А еще страшно подумать, что будет через 40 лет.
Одеваешь такой, свои винтажные VR-очки, махаешь пальцами в воздухе,
пишешь на Хабре «От, я помню на работу в офис ходил…».
А тебе в ответ: «Правда, что ли? Зачем? Неужели было время, когда надо было вставать с дивана…»
Овер 900 комментариев – вот так полемика! Честно-говоря, все не осилил…
На самом деле мне 30, я программист уже полтора года и прочитав статью, я вдруг подумал, что прошёл по самому краю. Может кому-то будет полезна/интересна моя история и советы (заранее извиняюсь за немного панибратский стиль).
В детстве не испытывал острой потребности научиться программировать, правда мне нравилось делать/придумывать всякие интересные штуки. Ходил в авиамодельный кружок, потом в радиотехнический, после поступил в радиотехнический-же техникум.
После технаря в университет на радиофизику.
Примерно после выпуска из техникума начал пробовать разные убогие подработки (торговля, сервис и пр.). Всё ради денег? – конечно ради них, родимых!
С третьего курса подрабатывал на кафедре по науке, позже пошел в аспирантуру.
Наука она такая, пока есть спрос (контракт) по конкретной (твоей) теме – платят неплохо, остальное же всё время – самый скромный минимуму, чтоб с голодухи человек дубца не врезал.
Потому, наверное, не такая и редкость, когда младший научный сотрудник в свой выходной день бежит шпаклевать соседу стену (это был не я, если что). Я-же тратил своё свободное (а подчас и рабочее) время на изучение программирования. Я был мотивирован не только и не столько нехваткой денег, а ещё и тем, что это как раз та сфера, где надо что-то придумывать, изобретать предусматривать множество вариантов использования. Только в сравнении с хардверной разработкой (куда ещё радиофизику применить..) софт он такой, что тебе для старта не нужно ни редкое оборудование, ни дорогие микросхемы – всё что не хочешь покупать, можешь написать сам. Для чего угодно нужно только твоё время и умения.
Правда понимание того, что деньги (в широком смысле) есть мера общественной пользы пришло довольно поздно. Лет в 27 некоторые из моих сверстников (кто пошёл в ай-ти-контору, а не в аспирантуру) уже стали неплохо зарабатывать. Я, недолго думая, подготовил резюме и бросил на сайт для безработных. Примерно раз в один-два месяца, еще смотрел вакансии, находил что-то хоть немного подходящее корректировал резюме под требования и отправлял.
К 28 годам кроме хело-вёрдов и калькуляторов я мог похвастаться массивным алгоритмом в матлабе для обработки изображений(тогда в резюме было Matlab, C++).
От друзей я узнал о хорошей вакансии, сходил – выпросил тестовое задание. Оно было рассчитано на неделю, мне-же добавили еще одну, чтобы я изучил джаву (с нуля! Wtf?). В итоге я потом попросил дополнительную неделю, а меня все-равно не взяли.
Правда через пару дней после отказа перезвонили из конторы поменьше (они нашли резюме на том сайте для безработных), пригласили, и в общем, тут я работаю до сих пор.
Неочевидные, на мой взгляд, советы:
Уделить больше внимания составлению резюме. У меня был друг, который посмотрел, и сказал, что исправить. Вы-же можете найти десяток хороших примеров или статью в интернете. Обязательно надо адаптировать резюме под конкретный оффер, если он есть. Надо убирать все лишнее – если гуманитарный красный диплом – пишешь образование: высшее, с отличием. Специальность лучше не писать, если она мимо кассы, это всегда можно устно добавить. Можно ещё немного приукрасить свои возможности. На пример, требуют знание SVN, а ты только гит пробовал – тратишь день на поверхностное изучение, пишешь Git (beginner). Чего бы достиг Мухамед Али, если бы из принципа всегда дрался только левой рукой?
На собеседовании держаться более естественно. Если всем своим видом демонстрировать своё желание всеми правдами и неправдами влезть в коммерческое программирование, менеджеру это может не понравится на эмоциональном уровне (как то чувство, когда тебе пытаются что-то впарить на базаре). Не стоить сильно настаивать, что ты готов программировать все что скажут, лишь бы только программировать. Менеджер знает, что первые 2-3 месяца стажер фактически не приносит денег, а только расходует их, в том числе и за счет того, что отвлекает коллег. А когда они тебя выучат, ты быстро найдешь себе новую «работу мечты» с зп повыше, или проектом поинтереснее – оно им надо? Лучше пытаться убедить менеджера в том, что ты хочешь работать именно в их компании. Посмотри сайт конторы, странички руководства, составь мнение – они это оценят. Кроме того, возможно, если идти на собеседование не мечтателем полным надежд и фантазий, а прагматиком, со здоровой долей скептицизма, который даром, что джуном быть хочет, а всё равно цену себе знает, то это произведет правильный эффект. В конце концов, трудовой договор – это сделка и в ней каждый в праве вежливо настаивать на своих интересах.
Всегда выжимать из себя максимум. Звучит пафосно, но иначе никак. До работы я думал: «джаву за неделю это вам не мешки ворочать». В первый день моего испытательного срока меня посадили исправить простенький баг в скрипте на Lua – тогда я и знать не знал, что это вообще такое… Думаете мне дали пару дней, чтобы я в рабочее врем читал книги по Луа? Как бы не так… Моя задача была в том, чтобы, используя интернет, свой кругозор и советы от будущих коллег разобраться в проблеме и предоставить решение. Мораль в том, что, если бы от меня этого не ожидали, я бы не пробовал и, наверное, так бы и не узнал, что на это способен. Сейчас в этом смысле, я чувствую себя увереннее: модуль с Qt, парсер на питоне? – нет ничего, в чём невозможно разобраться, эти-ж языки не для академиков придумывают). Оглядываясь назад могу сказать, что знания понемногу забываются, особенно если ими длительное время не пользуешься, а понимание остаётся. В большинстве языков есть ООП, везде используются одинаковые структуры данных (новых еще не изобрели), регулярки вот, почти в любой язык протянуты. Чтобы развивать именно понимание, удобнее (во всяком случае для меня) не книги модные читать и тут же забывать, а искать ответы на интересующие тебя конкретные вопросы.
Слушать руководство. В этом смысле возраст только в плюс. Не редко слышу и вижу, как молодежь получая задание на слух либо сразу спрашивает: «а как это сделать», а тимлид такой: «откуда мне знать? Разберись, подумай, предложи варианты», а про себя ещё добавляет: «если б я точно знал, что будет лучше, сам бы всё сделал быстрее чем тебе тут объясняю». Или же наоборот – задание требует сразу уточнений (хотя бы по ожидаемым результатам), а джун думает: «я пока нифига не понял, посмотрю код, станет понятнее какие варианты проще сделать, а потом отвлеку ментора ещё раз». Простая человеческая адекватность, судя по всему, не присутствует у людей с рождения, а приобретается с опытом.
Не жалеть своего труда. Довольно часто от решения проблемы ожидается не только, что оно будет работать надежно и без сбоев. Есть еще архитектура, масштабируемость, гибкость.
Сказать честно, мой первый серьёзный код, который я делал, работая в науке я бы сейчас никому не показывал. Я тогда сильно пренебрегал читаемостью кода, поскольку плохо понимал, что это такое. Но тем не менее, без него я бы не получил нужного развития. Моё первое тестовое задание есть на гитхабе, но я и его не спешу всем показывать, потому что, скорее всего через пару лет и оно мне покажется слишком убогим. В конечном счете самое ценное это опыт, тем боле что количество денег зависит от него в первую очередь. Даже сейчас, бывает такое, что я предложу тимлиду готовое решение, отвечающее всем требованиям, надежное и без багов, а он его забракует, поскольку его дальнейшее развитие будет багоопасным или потребует изуродовать архитектуру. Я отношусь к такому с пониманием (хоть и Х часов пошли на смарку) – он тимлид, ему виднее, а меня такой продолб сделает умнее чем любая другая успешно решенная задача.
И еще один совет специально для автора (если, конечно ему интересно). Мне хорошо знакомо чувство, когда ты стучишься лбом во все двери, причем довольно продолжительное время, а тебя игнорируют. И в душе начинают шевелиться сомнения: «может я слишком глупый для этого?». Сейчас я могу сказать, что нет возможности повлиять непосредственно на исход собеседования, есть только возможность повлиять на вероятность желаемого исхода. Всё-таки Вас собеседуют живые люди и слишком многое остаётся на откуп удаче. Единственный верный рецепт – увеличить количество испытаний. Вероятность, она упрямая, но честная. Я не в том смысле, что надо ходить на все собеседования и ждать от вселенной кармической справедливости. Я стараюсь следовать совету одного старшего товарища: «Если тратишь время на что-то без удовольствия, то это не отдых. Значит оно должно приносить тебе пользу если не в денежном эквиваленте, то хотя бы в виде опыта.» Очень важно проводить работу над ошибками после каждого собеседования. Я думаю, для Вас вполне реально в обозримом будущем на одном из собеседований выпросить тестовое задание. Вполне возможно, оно не сможет быть удачно решено в срок, но можно будет его доделать, просто ради опыта, найти ревьюверов, довести его до совершенства. И уже это сильно повысит шансы получить работу на втором собеседовании.
Мне видится аналогия с более старой и ёмкой проблемой.
кодер(хирург/функция) в большей степени следует алгоритмам (догмам/рекомендациям), а разработчик(инженер/руководитель/функционал) сам эти алгоритмы составляет. По моему мнению упомянутая книга как-бы и намекает, что если твоя функция в том, чтобы совершать выбор (и большой и маленький), то ты человек творческий, а разработка чего-либо — это без сомнения очень творческий вид деятельности.
Вопрос в том, нужно ли стремится к тому чтобы стать творческим, или лучше уступить место другим?
Балаболы бывают разные, как и дяди Леши, собственно. У разных проектов разные требования к работе. На каком-нибудь гейм-деве, когда не понятно, будет ли репа поддерживаться через год, но очень надо успеть к дате релиза (поскольку за рекламу уже заплачены деньги) – такой дядя Леша был бы рок-звездой. А если контора большая и долгоживущих проектов много, то возможно еще и санитаром леса.
А может быть и какая-нибудь эмбедед разработка “на века” когда важна не скорость выполнения работы, а получившийся по итогу дизайн, масштабируемость и удобство исходников для понимания других программистов. В таком окружении дядя Леша заставлял бы свою команду страдать, ведь есть масса работы, которую никто не хочет делать, включая упомянутые созвоны, менторство трейни, или трату кучи времени на ревью чужого кода. Это приводит к тому, что за дядей Лешей должен быть закреплен специальный человек, который будет доделывать, все, что им обоим не хотелось бы делать. Таким вот “подтерателем попы для всех” одно время и я работал. И знаете, одно дело когда молодой человек что-то не делает потому что не умеет (его можно со временем научить). Но когда образованный человек, искренне верит, что он лучше других и у конторы должны быть к нему особые требования – с таким персонажем работа плохо ладится. Сначала он сам выдавливает из коллектива равных по силам инженеров, чтобы давить авторитетом оставшихся, а потом жалуется что все держится на нем. Команде от его пренебрежительного отношения очень не комфортно и в итоге он сам со временем начинает скучать и уходит, а его творчество потом годами рефакторится.
Мораль – определенный типаж людей я бы не брал в свою команду ни за какие деньги, но это гиперболизированный случай конечно. Сложность в том, чтобы этот типаж выявить на собесе, и желательно не ложно-позитивно.
БТВ, субъективно, в истории из поста Роман далек от того, чтобы делать работу интервьюера профессионально. Обычно умный парень знает что он умный, но наивно думать, что ты умнее всех. Как правило, такой Роман, это среднего ума разработчик, который старается честно выполнять любую работу, которую ему поручат (даже если он к такому не был подготовлен). В итоге он основываясь на своем опыте (и неприятных случаях) создает в голове картинку идеального работника, и судит о людях исходя из соответствия этой субъективной картинке. Вот только картинка составлена в терминах интервьюера. Соискатель может его просто не понять и интервьюер обязан это держать в голове. Твердолобость – плохая черта для любого руководителя. Если не заладилось с будущими коллегами еще на собесе, то хорошо что это стало понятно сразу.
Мне далеко до маститого специалиста, но свой гит в резюме указываю. Хоть своим кодом не доволен, да и вряд ли его кто-то будет смотреть с пристрастием.
Другое дело, что если в процессе собеседования выясняется, что будущий начальник ожидает каких-то сверхурочных активностей (а иначе не тру-программист), то руководство там будет барин-стайл. Это когда просчеты менеджмента ложаться на плечи разработчиков, а поощряют вместо денег всяким барахлом.
Надо из такого места валить поскорее, можно рыбкой в окно)
В общем, я за програмистский кураж, но только если он добровольный.
Ну мы обычно первые комиты новичков очень придирчиво смотрим, а со временем становится понятно какие у каждого сильные и слабые стороны.
Конечно идеально было бы найти идеального кандидата, но мне пока так ни разу не везло)
Согласен.
Такого рода ошибки можно отловить на код-ревью.
Таким тонкостям как раз можно научить, я думаю. А вот если человек плохо обучаем, или склонен безосновательно стоять на своем, то такого человека лучше сразу не брать в команду.
А... зачем может пригодиться такой факториал? :)Мне это пригодилось для ленивого способа подсчета числа сочетаний для своего домашнего мини-бикини-пет-проекта. Рабочие задачи, к сожалению, более унылые. А те что не унылые требуют знания предметной области, которого от соискателя не ожидается.
произведение dimX * dimY вычисляется без переполненияМб я что-то не понял, но по моему самый простой вариант, если код будет работать на 64-разрядной машине, то произведение двух uint32_t не сможет превысить размер адресного пространства, Так можно наложить ограничения без накладных расходов на проверку. Правда проверка того, что сами аргументы не были вычислены с переполнением уже становится заботой клиентского кода). Кроме того у системы закончится память гораздо раньше и аллокатор выбросит bad_alloc исключение. Если же это код для 32-разрядной машины (или для контроллера), то всевозможные учеты аппаратных ограничений становятся самостоятельным видом искусства). В целом согласен - хорошая задача на внимание к деталям.
С моей точки зрения - любой корректно работающий вариант - правильный.
Я, к примеру пошел на https://umath.ru/calc/graph , построил y=x!/2^128 и посмотрел в какой точке кривая пересекает 1. Потом, чтобы убедиться, что логика сайта не забагована для таких случаев, пошел в убунтовский калькулятор, убедился, что 2^128−34! - положительное, а 2^128−35! отрицательное.
Конечно решение изяществом не блещет, но с точки зрения продакшена - корректный результат за разумное время - то что надо.
Соискатели (среди которых бывают и вчерашние студенты) демонстрируют, к примеру свой матан: "Надо вывести уравнение, так сейчас, сейчас... Минуточку, но у факториала же нет обратной функции!" иногда еще и с вопросительной интонацией в конце)
Дальше мы переходим к численным методам. В лоб перемножать числа с 2 почему-то всем очень не нравится, пытаются приплести метод половинного деления. Много разговоров об О-нотации, но это все - чтобы оценить на сколько инженер самостоятельный, будет ли он искать способ самому проверить свое творчество (не рассчитывая что другой инженер на код ревью все исправит), на сколько склонен к оверинжениренгу, достаточно ли у него фантазии, чтобы решать абстрактные задачи.
Это все я к тому, что над такой вот задачкой не надо 5 минут вчитываться, задавать уточняющие вопросы, потом 5 минут думать в неловкой тишине. А информации о том, как потом с человеком работать это даст не меньше. Но это субъективное мнение, конечно.
Вполне.
спросить на WolframAlphaПро такой сервис не знал, спасибо.
Мне сложно представить на собесе реального человека, который думал бы так быстро и так совершенно.
По моему, пора уже на литкоде, где-нибудь под катом прятать секретное стоп-слово, чтобы каждый знакомый с задачей разработчик мог предъявить его другому такому-же разработчику. А за одно можно было бы и остановить интервьюера, пока он не достиг экстаза от самолюбования.
Как то желчно вышло, но я бы и правда предпочел скорее тимейта с на 30% меньшим интеллектом и душностью, но на 20% большей честностью, сообразительностью и коммуникабельностью. Такой человек, как правило, всегда при работе и не станет специально готовится к собеседованию. Мой типовой вопрос попроще:
Есть 128-битный без знаковый инт на входе. При валидации этого числа надо проверить, влезет ли его факториал в такой-же 128-битный инт (т.е. сравнить с захардкоженым числом).
Как будешь считать это число?
я вдруг понял, что можно развести холивар на тему того, что считать soft скилами)
На мой взгляд, рецепт хорош - формализовать цель, идти к ней, трекать прогресс. Это применимо и для софтскилов, если возможно формализовать цель.
Но для того, чтобы почувствовать себя молодцом есть способ попроще. Например можно брать задачи, которые дугие не хотят или не могут делать, тогда на саморазвитие и учет потраченного на него времени просто не останется сил)
Зато, когда придет время “продавать” себя начальству, будет гораздо проще убедить его в своей незаменимости. А деньги, в каком-то смысле и есть мера общественной пользы и личной не субьективной крутости.
Видел рекламу:
"... выполним заказ ДЕШЕВО, КАЧЕСТВЕННО и БЫСТРО*"
А внизу мелким шпифтом: " * выберите два любых требования."
Все пытался представить челвека, который умеючи делать качественно будет выполнять работу долго и дешево, а это оказывается Вася)
Если 0 и 1 должны быть равновероятны в целях минимизации износа памяти, то зачем AES, если можно по очереди давать для xor-а, сначала 010101… а потом 101010…?
Это, к примеру, позволило бы восстановить данные с диска со сгоревшим контроллером
Я бы не смог найти на Ваш вопрос более логичного ответа. Может дело в том, что я просто кодер и всегда избегал менеджерских задач.
А для Вас что является успешным завершеннием проекта и какой ответ Вы надеялись услышать от соискателя?
Так надо не на разрабов сетовать, а на требования рынка (т.е самих потребителей). А программисту скоько заплатили, столько он и споет.
Звучит, как будто зодчий из 16 века, посмотрел на современные многоэтажки и говорит:"что за ерунда! Это фуфло бетонное и 100 лет не простоит. Вот я замки строил из чистого камня 500 лет назад, так они до сих пор не покосились". И будет прав, только никто все равно не будет покупать жилье на которое надо собирать деньги три поколения.
А еще страшно подумать, что будет через 40 лет.
Одеваешь такой, свои винтажные VR-очки, махаешь пальцами в воздухе,
пишешь на Хабре «От, я помню на работу в офис ходил…».
А тебе в ответ: «Правда, что ли? Зачем? Неужели было время, когда надо было вставать с дивана…»
Овер 900 комментариев – вот так полемика! Честно-говоря, все не осилил…
На самом деле мне 30, я программист уже полтора года и прочитав статью, я вдруг подумал, что прошёл по самому краю. Может кому-то будет полезна/интересна моя история и советы (заранее извиняюсь за немного панибратский стиль).
В детстве не испытывал острой потребности научиться программировать, правда мне нравилось делать/придумывать всякие интересные штуки. Ходил в авиамодельный кружок, потом в радиотехнический, после поступил в радиотехнический-же техникум.
После технаря в университет на радиофизику.
Примерно после выпуска из техникума начал пробовать разные убогие подработки (торговля, сервис и пр.). Всё ради денег? – конечно ради них, родимых!
С третьего курса подрабатывал на кафедре по науке, позже пошел в аспирантуру.
Наука она такая, пока есть спрос (контракт) по конкретной (твоей) теме – платят неплохо, остальное же всё время – самый скромный минимуму, чтоб с голодухи человек дубца не врезал.
Потому, наверное, не такая и редкость, когда младший научный сотрудник в свой выходной день бежит шпаклевать соседу стену (это был не я, если что). Я-же тратил своё свободное (а подчас и рабочее) время на изучение программирования. Я был мотивирован не только и не столько нехваткой денег, а ещё и тем, что это как раз та сфера, где надо что-то придумывать, изобретать предусматривать множество вариантов использования. Только в сравнении с хардверной разработкой (куда ещё радиофизику применить..) софт он такой, что тебе для старта не нужно ни редкое оборудование, ни дорогие микросхемы – всё что не хочешь покупать, можешь написать сам. Для чего угодно нужно только твоё время и умения.
Правда понимание того, что деньги (в широком смысле) есть мера общественной пользы пришло довольно поздно. Лет в 27 некоторые из моих сверстников (кто пошёл в ай-ти-контору, а не в аспирантуру) уже стали неплохо зарабатывать. Я, недолго думая, подготовил резюме и бросил на сайт для безработных. Примерно раз в один-два месяца, еще смотрел вакансии, находил что-то хоть немного подходящее корректировал резюме под требования и отправлял.
К 28 годам кроме хело-вёрдов и калькуляторов я мог похвастаться массивным алгоритмом в матлабе для обработки изображений(тогда в резюме было Matlab, C++).
От друзей я узнал о хорошей вакансии, сходил – выпросил тестовое задание. Оно было рассчитано на неделю, мне-же добавили еще одну, чтобы я изучил джаву (с нуля! Wtf?). В итоге я потом попросил дополнительную неделю, а меня все-равно не взяли.
Правда через пару дней после отказа перезвонили из конторы поменьше (они нашли резюме на том сайте для безработных), пригласили, и в общем, тут я работаю до сих пор.
Неочевидные, на мой взгляд, советы:
Сказать честно, мой первый серьёзный код, который я делал, работая в науке я бы сейчас никому не показывал. Я тогда сильно пренебрегал читаемостью кода, поскольку плохо понимал, что это такое. Но тем не менее, без него я бы не получил нужного развития. Моё первое тестовое задание есть на гитхабе, но я и его не спешу всем показывать, потому что, скорее всего через пару лет и оно мне покажется слишком убогим. В конечном счете самое ценное это опыт, тем боле что количество денег зависит от него в первую очередь. Даже сейчас, бывает такое, что я предложу тимлиду готовое решение, отвечающее всем требованиям, надежное и без багов, а он его забракует, поскольку его дальнейшее развитие будет багоопасным или потребует изуродовать архитектуру. Я отношусь к такому с пониманием (хоть и Х часов пошли на смарку) – он тимлид, ему виднее, а меня такой продолб сделает умнее чем любая другая успешно решенная задача.
Мне видится аналогия с более старой и ёмкой проблемой.
кодер(хирург/функция) в большей степени следует алгоритмам (догмам/рекомендациям), а разработчик(инженер/руководитель/функционал) сам эти алгоритмы составляет. По моему мнению упомянутая книга как-бы и намекает, что если твоя функция в том, чтобы совершать выбор (и большой и маленький), то ты человек творческий, а разработка чего-либо — это без сомнения очень творческий вид деятельности.
Вопрос в том, нужно ли стремится к тому чтобы стать творческим, или лучше уступить место другим?