Если программист не знает английского языка, то и функции он не сможет запомнить, а только зазубрить, т.к. большинство функций несут в себе смысловое описание на английском (да и не только функций, взять те же string, array).
Не поймите меня неправильно, я ничего против этих систем против не имею (Вообще говорю только про 1С Бухгалтерия, ABAP не видел).
Но я ни разу не видел красивого кода на 1С, обычно это просто быдлокод причем логика там минимальная. Не говоря уже о том, что сам ЯП выглядит отвратительно.
А русские названия в коде, впринципе, как и транслит — это чертовски плохо. Выучить английский не настолько сложно, а код будет выглядеть намного приятней и аккуратней.
За названия типа jachekaGetZnachenie или [Статусы Гос Служащих] просто убить готов.
Может быть, но по-крайней мере, англоговорящие люди не делают вставок на русском :)
Мне это не нравится по двум причинам:
1) Постоянное переключение раскладки.
2) Постоянное щелканье в мозгу «русский, английский». Однородная информация лучше воспринимается.
Как буд-то бы других причин учить английский нету. Ну это же смешно. Как вы представляете себе работу с менеджерами? Выкрутиться можно, но намного полезнее выучить язык. В жизни пригодиться.
Потому что так и я изредка косячу :) Привычка: слышишь «то» — поставь дефис. Но вроде как стараюсь проверять и пресекать такие попытки моих пальцев. А вот мягкие знаки дико слух режут.
Когда мне пишут через переводчик, то не всегда с первого раза можно понять что именно хотел спросить человек или даже двояко. Особенно когда изначально предложение было слишком сложно или не совсем грамотно составлено.
С ужасом представляю техническое задание на важном проекте, которое было написано через такой переводчик и переведено несколько раз через разные языки.
Напомнило старый анекдот.
Обычный американский фильм с обычным американским диалогом:
— How do you do?
— All right!
Вот знаете, есть у меня друг, который на одеске пытается писать через гугл транслэйт т.е. английский не знает. Так вот его не то что англоговорящие не понимают, его никто не понимает, даже он сам не может вспомнить что хотел сказать этой чудо фразой из гугл транслеэйта…
Если представить закон Мура в грубой форме, то каждых 2 года количество информации для IT-шника удваивается, при этом вы стабильно отстаёте на год лишь из-за незнания языка. Такой специалист неконкурентоспособен.
И ещё интересно как вы хотите работать в США не зная английского, в магазин тоже с гугл транслейтом ходить будете? ИМХО это превращение рабочего процесса в горы лулзов.
Мне одному кажется, что незнание английского в IT это признак профнепригодности?
Потому что вся документация — на нем, родимом. А ошибок в переводной документации полно, ибо переводят ее зачастую далекие от IT люди.
Проходил собеседование в амазон, было аж 3 телефонных интервью. Вопросы очень похожи на указанные автором. И рекомендации правильные. В амазон конечно не спрашивали про продукцию гугл, но про идеи развития амазон, конечно да.
Здорово, классно, правильно, но не подписывали ли вы какого-нибудь NDA, которое может помешать вам с чистой совестью выкладывать все об интервьюировании на Гугл?
Список теории и кижки, это безусловно правильно, но вот транскрипт и задачи — это как-то чуть слишком. Не находите?
А это разве не вещи такого же уровня, как опубликовать, скажем, список билетов для экзамена и список точных ответов на эти билеты? Автор вроде как просто огласил билеты.
Во-первых большинство вещей, описанных в топике — общеизвестные и причем даже Google сами дают ссылки на некоторые материалы, которые надо знать для второго собеседования по телефону.
Во-вторых, NDA они подписывают после второго собеседования по телефону, когда приглашают к себе в офис.
Они на первых интервью ничего не подписывают, но просят обещать не распространять точную информацию о вопросах — например, все вопросы, которые были заданы.
А вот примерную информацию как тут можно и так найти на сайтах Google, но тут вместе собрано.
Им ведь нужны люди, которые могут мыслить на ходу, а не зубрить чужие ответы.
Вопрос был обговорён. Задачи я беру из обще-доступных источников. Про интервью — меня не просили не разглашать задачи. Но как человек порядочный, я подожду чуть больше месяца перед обсуждением оных. И на самом деле, задачи действительно очень-очень общие. Что хочется обсуждать при решении задач, это не просто конкретный способ, хотя его конечно хорошо бы знать, а скорее то, на что стоит обращать внимание при кодинге. Так что даже не просто подготовка к интервью, а наработка навыков хорошего программирования.
Удачи на интервью.
А насчет «меня не просили не разглашать задачи», на самом деле просили. Прочитайте документы которые вам высылал рекрутер. Перед телефонным интервью не просят ничего подписать, но как раз таки просят не рассказывать вопросы.
почему? устроитесь в гугл, поймете :)
Дорогие товарищи. Спасибо.
Специально для вас всех, я покажу те строки в посте, к которым хотел привлечь внимание:
Технические задачки и их решения на C/C++ и Python
Транскрипт моего реального интервью
…
В следующей части мы поговорим о конкретных задачах и их реализациях на Си, Си++ и Питоне.
Еще раз, для тех, кто читает быстро — скидывать реальные вопросы и реальный транскрипт по меньшей мере неэтично (для меня по крайней мере), ну и скорее всего, есть какое-то NDA на эту тему.
Автор, я просто прошу тебя подумать, не нарушаешь ли ты ненароком чего.
От себя могу порекомендовать сайты:
1) www.careercup.com/page — Можно фильтровать вопросы по позиции и компаниями. Выглядит страшновато, но много полезного.
3) Книга от авторов первого сайта — «Cracking the Coding Interview: 150 Programming Questions and Solutions». Ставлю ее рядом с Programming Interviews Exposed.
4) www.glassdoor.com/ — кандидаты выкладывают свои впечатления и вопросы на собеседованиях. Менее техническое чем 1 и 2.
Достаточно базовые знания. Конечно, что-то я уже подзабыл, но практически всё, что вы перечислили, мне давали в университете. Разве что с мегабольшими объёмами данных не работали. В общем, удачи!
Там тоже не учат, например, математику. А учатся отвечать на вопросы егэ по математике.
(для школофобов напомню что егэ начали экспериментально вводить с начала нулевых)
Хотя конечно полезно когда все в команде гарантировано знают какой-то общий стандартизированный набор понятий из области программирования.
Наверное отбирать огромное кол-во эффективных специалистов это очень трудная работа. Интересно, каков процент непрохождения испытательного срока.
Не думаю, что после телефонного интервью вас попросят руководить созданием нового сервиса. Это скорее проверка на вшивость, чем, собственно, является егэ.
А вообще, что привлекает в гугле: задачи, аналогов которым нет в других компаниях, люди, которые обладают, как техническими навыками, так и сами-по-себе разносторонне развиты, перспектива роста, как по вертикали, так и перевода между разными отделениями. Ну и из мелочей: английский, путешествия, перки, бесплатная еда :D
От себя могу рассказать:
1) Собеседование на стажёра в Microsoft
2) Собственно, сама летняя стажировка в офисе в Редмонде
3) Опыт собеседования в Фейсбук (пока не окончено — впереди on-site интервью в Калифорнии =))
Интересно кому? =)
Не наброса для, но меня действительно интересует: а разве нормальный программист, получивший профильное образование и любящий программирование на входе не знает всех этих вещей?
Ну, то есть, очень базовые штуки как темы названы, странно, что их могут не знать те, кто уже идёт на собеседование.
Одно дело знать, что такие вещи есть — а другое, как их применять и где. Тем более все зависит от того же профильного образования. Если человек в жизни не видел задачу о ранце, то он точно не сможет понять как и где её применить. И понятие «нормальный пограммист» — довольно размытое понятие.
На мой взгляд из O(n log n) сортировок лучше вместо mergesort'а разобраться в heapsort'е, ибо:
1. В отличие от quicksort'а гарантированное Θ(n log n) время.
2. В отличие от mergesort'а, in-place, т.е. требует O(1) дополнительной памяти.
3. Используется структура heap, знать которую, конечно же, нужно.
Ну и вообще, для саморазвития не лишним будет разобраться в сортировках, работающих за линейное время, почему такое возможно, и, возможно, методами обеспечения Θ(n log n) времени для quicksort'а (см. introsort).
Лучше уметь программировать merge (и не уметь heap), чем наоборот. Хотя и то, и другое, конечно, еще лучше.
Слияние трех упорядоченных массивов студенты на экзамене написать (на C/C++) не могут — проверено :(
Спасибо. Кажется, они забыли сказать, что для сортировки групп надо использовать алгоритм, работающий за O(k) обменов групп (иначе все слияние в O(n) никак не уложится), но в целом, идея понятна. Как-нибудь попробую.
Еще бы smoothsort понять :)
Я хочу работать в Google! Телефонное интервью (часть 1)