Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 125
Вы забыли дописать, что это руководство — для студентов / джуниоров. Кандидатов на позицию синиора будут спрашивать совсем-совсем другое.
А так, спасибо за статью! Мне бы она очень пригодилась в мою бытность студентом.
А так, спасибо за статью! Мне бы она очень пригодилась в мою бытность студентом.
Что-то мне кажется, студентов с такими знаниями оторвут с руками, причем на позицию вовсе не джуниора, а несколько «постарше». Хотя, наверное, многое зависит уровня от компании — для гугла эти знания вполне могут требоваться и от джуниора.
Коллеги, напоминаю, что для того, чтобы успешно проходить собеседования, нужно учиться программировать, а не проходить собеседования.
Позволю себе не согласиться: к тем собеседованиям, которые проходил я, нужно было готовиться и обязательно повторять то, что скорее всего будут спрашивать и то, что наиболее интересно заказчику (встречают по-одежке). И чем сложнее позиция, тем более явно это было выражено.
Так или иначе, но на каждом проекте список активно используемых технологий ограничен и background skills забываются, поэтому точно так же, как иногда «затачивают» резюме под вакансию, необходимо «затачивать» себя технически перед собеседованием: чаще всего для этого достаточно изучить список требований и обязательно просмотреть хотя бы концепты — заказчик/интервьюер будет впечатлен и отдаст предпочтение тому, кто знает и помните именно те детали, с которыми придется работать.
Так или иначе, но на каждом проекте список активно используемых технологий ограничен и background skills забываются, поэтому точно так же, как иногда «затачивают» резюме под вакансию, необходимо «затачивать» себя технически перед собеседованием: чаще всего для этого достаточно изучить список требований и обязательно просмотреть хотя бы концепты — заказчик/интервьюер будет впечатлен и отдаст предпочтение тому, кто знает и помните именно те детали, с которыми придется работать.
Можно-ли натаскать, под экзамен, человека, который все 11 лет не учился? И не за полгода, а за 2 дня?
P. S. Я не против, кто не уверен в себе, может готовиться к собеседованиям, но все, без исключения, должны учиться делать то, что они в будущем собираются делать, а не учиться доказывать то, что они это умеют делать.
P. S. S. Последнее утверждение справедливо в контексте светлого будущего, если контекст — деньги/деньги/деньги, то забудьте все о чем я говорил.
P. S. Я не против, кто не уверен в себе, может готовиться к собеседованиям, но все, без исключения, должны учиться делать то, что они в будущем собираются делать, а не учиться доказывать то, что они это умеют делать.
P. S. S. Последнее утверждение справедливо в контексте светлого будущего, если контекст — деньги/деньги/деньги, то забудьте все о чем я говорил.
Можно ли натаскать за год под ЕГЭ, человека который толком 10 лет не учился и было это 20 лет назад? Вопрос практический — захотелось тут ВО получить, а, говорят, вступительные экзамены отменили…
Когда ещё были вступительные экзамены, я после пары лет слесарения на нефтепромыслах на севере, пары лет бродяжничества по Питеру и службы в советской армии (пойдёт лет за 10), выучил школьную математику за 2 дня, а физику за 4. Посдавал на хор и отл, что на что не помню уже. Не думаю, что ЕГЭ сложнее прежних экзаменов.
Можно, ну не за два. Три дня. =) собственный опыт =) результат 78 баллов =)
У меня подготовка к собеседованию занимает минут 10-15.
Потому что нужные знания и голова всегда на месте, исформацию по работодателю и позиции, как правило, есть в и-нете.
Гораздо больше времени занимает мини-расследование на тему плюсов и минусов работы именно в данной организации.
Потому что нужные знания и голова всегда на месте, исформацию по работодателю и позиции, как правило, есть в и-нете.
Гораздо больше времени занимает мини-расследование на тему плюсов и минусов работы именно в данной организации.
Не кажется ли вам, что это некоторый дефект системы? В идеале все-таки на подготовку должно уходить никак не полгода.
Спасибо. Возьму на заметку.
PS только мне кажется, что сравнение NULL == что-то непривычно выглядит?
PS только мне кажется, что сравнение NULL == что-то непривычно выглядит?
Это для того, чтобы случайно перепутав "==" с "=", сразу получить ошибку компиляции. В случае «обычного» стиля — логическую ошибку очень трудно выявить.
! Возьму на заметку, спасибо.
Извините, что-то повторяюсь :)
Туда же кейсы типа FALSE == ..., TRUE == ..., да и вообще <константа> == (первые два мало относятся к Си, больше к языкам где 0 и FALSE значения разных типов, но анализировать нужно именно булевый типа, т. к. функция может вернуть 0 (или лбое другое привдимое к FALSE значение, а может именно FALSE и сравнивать надо не спомощью ==, а ===).
искренне был уверен что == на = путается только первые пару дней перехода с паскаля на нечто си-подобное…
Еще одна причина, по которой могут так писать, — это чтобы не возникало непредвиденного поведения из-за перегруженного оператора сравнения.
GCC предупреждает об этой ошибке, кстати.
Спасибо. Буду ждать продолжение.
значит я буду мести двор все-таки…
Если, %username%, вы не заметили утечек памяти в приведённых выше алгоритмах, то на собеседования вам пока рано.
Не хотелось бы ломать вам шаблон, но в собеседованиях на должность программиста на языке без ООП, ООП спрашивать скорее всего не будут.
Ни разу на собеседованиях похожих вещей не спрашивали, кроме «общежитейских» вопросов (родился, учился и т. п.) — просто давали учебно-боевое задание и просили реализовать его (когда на бумажке, когда на компе) — максимум спрашивали после этого почему именно так решил.
Реализуйте функцию определяющую все ли символы неповторяющиеся в заданной строке
Ваше решение, если честно, удивило. Я бы тупо сделал
map<char,int> histogram ну и дальше вы понимаете.Конечно, но в основном во время интервью, так сказать, «требуют написать с нуля», это я к тому, что если вопрос «напишите функцию, сортирующую массив» требуют именно написания функции, а не использования, скажем, std::sort. Это так мне кажется)) Во всяком случае со мной всегда так было)
и это блин странно.
тупо по-моему проверять человека в условиях в которые он никогда не попадет.
если вы обучаетесь битве на мечах то тупо проводить экзамен под водой ибо вы туда никогда не попадете.
проверять умение решать на бумаге — нереальные условия.
проверять умение решать без использования стандартных либ- нереальные условия. бить надо тех кто без стандартных либ будет пробовать что-то делать.
и не надо говорить что это способ проверить то, как человек думает — есть куча способов проверить это и без того чтобы придумывать то, чего никогда не будет.
тупо по-моему проверять человека в условиях в которые он никогда не попадет.
если вы обучаетесь битве на мечах то тупо проводить экзамен под водой ибо вы туда никогда не попадете.
проверять умение решать на бумаге — нереальные условия.
проверять умение решать без использования стандартных либ- нереальные условия. бить надо тех кто без стандартных либ будет пробовать что-то делать.
и не надо говорить что это способ проверить то, как человек думает — есть куча способов проверить это и без того чтобы придумывать то, чего никогда не будет.
Тут фишка в оптимизации за счет знания о том, что char может принимать только 256 значений.
А если wchar_t?
тогда было бы:
std::vector char_set(sizeof(wchar_t), false);
P.S. кстати, а зачем здесь использовать vector? он же, блин, медленнее и вообще его использование считается плохим тоном
std::vector char_set(sizeof(wchar_t), false);
P.S. кстати, а зачем здесь использовать vector? он же, блин, медленнее и вообще его использование считается плохим тоном
> P.S. кстати, а зачем здесь использовать vector? он же, блин, медленнее и вообще его использование считается плохим тоном
Не согласен, я никогда не слышал, что использование вектора считается плохим тоном и даже не «замечал» в проектах.
> std::vector char_set(sizeof(wchar_t), false);
Что вы здесь имели в виду? Это строка создает вектор с 2 (размер wchar_t, если не ошибаюсь) элементами, инициализировав их значением false. И наверное парсер съел <wchar_t>
Не согласен, я никогда не слышал, что использование вектора считается плохим тоном и даже не «замечал» в проектах.
> std::vector char_set(sizeof(wchar_t), false);
Что вы здесь имели в виду? Это строка создает вектор с 2 (размер wchar_t, если не ошибаюсь) элементами, инициализировав их значением false. И наверное парсер съел <wchar_t>
блин, парсер съел в P.S. тег, вы правы
я выразил недоумение зачем использовать vector<bool>
а в основноем теле сообщения конечно же vector<bool> char_set(1 << (8 * sizeof(wchar_t)), false);
правда оно будет не очень приятно в случае если wchar_t будет из себя представлять 4-байтный символ, тогда будет дешевле обойтись set<bool>
я выразил недоумение зачем использовать vector<bool>
а в основноем теле сообщения конечно же vector<bool> char_set(1 << (8 * sizeof(wchar_t)), false);
правда оно будет не очень приятно в случае если wchar_t будет из себя представлять 4-байтный символ, тогда будет дешевле обойтись set<bool>
Всем желающим подготовиться к интервью, настоятельно рекомендую сайт www.careercup.com/, особенно вопросы (реальные) с интервью в Амазоне, Гугле, Эппле, которые там обсуждаются. И еще рекомендую книжку, которую там они предлагают купить. Реально полезно даже не только для интервью, но еще и там есть прикольные задачки на «размять мозги» и «stay tuned».
Частенько дают задачи… эммм… даже не знаю на логику ли или на, что это — типа куда едет автобус. Это из личного опыта ;).
3 раза перечитал задачу про узел из середины односвязного списка — какой то бред.
1. Удаляется не указанный узел а следующий. Указанный удалить нельзя, если нет указателя на начало или предыдущий элемент.
2. Зачем переприсваивать указатель на данные не понятно.
1. Удаляется не указанный узел а следующий. Указанный удалить нельзя, если нет указателя на начало или предыдущий элемент.
2. Зачем переприсваивать указатель на данные не понятно.
Вот вы и не прошли собеседование :) Это классическая задача с «подколкой». Вместо реального удаления текущего узла всем его полям, включая указатель на следующий элемент и указатель на данные, присваиваются значения следующего узла. И именно поэтому нельзя удалить последний элемент списка — после него идёт только NULL, так что значения полей менять бесполезно.
Жыыырный плюс. Не останавливайтесь.
С самого начала, с первого же кода увидел следующее. Нет комментариев. Какой бы человек не был умный — его код будут читать другие люди. Пусть даже и код для собеседования, но наличие комментариев будет только плюсом. Два — это тонкий момент — return из цикла, как и continue, а иногда и break, крайне нежелательны. Три — Zend-way расстановки скобок несколько пугает. Предложу свой вариант:
bool are_unique_characters(const std::string& str)
{
// assume all chars are unique by default
bool result = true;
// flags for found chars, where index is char's ASCII code
std::vector<bool> char_set(256, false);
// iterate through string and set flags for found chars to true
for (int i = 0; i < str.size() && result; ++i)
{
// get ASCII code for i-th char
int val = str.at(i);
// get flag at val-th index
result = !char_set[val];
// set flag at val-th index to true
char_set[val] = true;
}
return result;
}
Эх, Макконнелла с Мартином на вас нет, с комментариями и скобочками :).
Из Макконнелла навскидку:
Use of break eliminates the possibility of treating a loop as a black box. Limiting yourself to only one statement to control a loop’s exit condition is a powerful way to simplify your loops. Using a break forces the person reading your code to look inside the loop for an understanding of the loop control. That makes the loop more difficult to understand. Use break only after you have considered the alternatives. To paraphrase the nineteenth-century Danish philosopher Søren Kierkegaard, you don’t know with certainty whether continue and break are virtuous or evil constructs. Some computer scientists argue that they are a legitimate technique in structured programming; some argue that they are not. Because you don’t know in general whether continue and break are right or wrong, use them, but only with a fear you might be wrong. It really is a simple proposition: If you can’t defend a break or a continue, don’t use it.
1) Конкретно ваш код читать сложнее, чем примеры в статье.
2) Это почему? короткий jmp очень «тяжел» по-вашему?
3) Холивар не слабее «пробелов и табов». К сожалению, большое обсуждение удалено с Хабра :(
2) Это почему? короткий jmp очень «тяжел» по-вашему?
3) Холивар не слабее «пробелов и табов». К сожалению, большое обсуждение удалено с Хабра :(
Все-таки оно живо, только было хорошо спрятано! habrahabr.ru/blogs/complete_code/114975/
«Египтяне» победили в три голоса
«Египтяне» победили в три голоса
Принцип «одна точка входа одна точка выхода». Ты всегда знаешь, где выйдешь из метода. Далее, переменная result служит одновременно и условием цикла и возвращаемым значением. Она контролирует весь метод — это семантически правильно.
Насчет последнего утверждения и прерываний цикла — цитата из Макконнелла выше, если «какому-то мне» не верят, может старичек Стив что напомнит…
Я упомянул не «египетские» скобки, и не говорил про «прямые» скобки. Я сказал про Zend-way — бессмысленная и беспощадная смесь двух предыдущих (тело метода — египетские, все остальное — прямые).
Насчет последнего утверждения и прерываний цикла — цитата из Макконнелла выше, если «какому-то мне» не верят, может старичек Стив что напомнит…
Я упомянул не «египетские» скобки, и не говорил про «прямые» скобки. Я сказал про Zend-way — бессмысленная и беспощадная смесь двух предыдущих (тело метода — египетские, все остальное — прямые).
В статье как раз использован K&R стиль в чистом виде.
Такие элементарные вещи комментировать — издевательство имхо.
Вы, конечно правы, но не во всем). Во-первых, если вы начнете писать комментарии во время интервью — вас тут-же попросят написать код, а комментарий, если нужно, потребуют после приема на работу).
Во-вторых, return, break, continue — не то, чтоб крайне нежелательны, а именно желательны, во многих случаях они помогут не тратить в пустую дополнительные переменные и еще — конкретная «куча» кода может быть просто сэкономлена(не выполнена), поскольку при «желании», достижении того, для чего кусок кода предназначался, просто выходим из цикла)
И в третьих, расстановка скобок и т.д. — это чисто вопрос вкуса, и в основном принятых стандартов в компании, где вы работаете/будете работать. Если в фирме «требуют» писать имена функции со строчными буквами, то, несмотря на ваш любовь на прописные буквы, вы будете «должны» писать со строчными.
Думаю все) Ваш вариант тоже понравился.
Во-вторых, return, break, continue — не то, чтоб крайне нежелательны, а именно желательны, во многих случаях они помогут не тратить в пустую дополнительные переменные и еще — конкретная «куча» кода может быть просто сэкономлена(не выполнена), поскольку при «желании», достижении того, для чего кусок кода предназначался, просто выходим из цикла)
И в третьих, расстановка скобок и т.д. — это чисто вопрос вкуса, и в основном принятых стандартов в компании, где вы работаете/будете работать. Если в фирме «требуют» писать имена функции со строчными буквами, то, несмотря на ваш любовь на прописные буквы, вы будете «должны» писать со строчными.
Думаю все) Ваш вариант тоже понравился.
// set flag at val-th index to true
char_set[val] = true;
если вы комментируете простейшее обращение по индексу, то вы профнепригодны
// get ASCII code for i-th char
int val = str.at(i);
аналогично
// get flag at val-th index
result = !char_set[val];
комментарий врёт! это неправда! get value opposite to flag at val-th index, хотя какой смысл писать комментарии длиннее, чем код?
// iterate through string and set flags for found chars to true
да ты что, издеваешься?
И этих людей пугает Zend-way расстановки скобок
char_set[val] = true;
если вы комментируете простейшее обращение по индексу, то вы профнепригодны
// get ASCII code for i-th char
int val = str.at(i);
аналогично
// get flag at val-th index
result = !char_set[val];
комментарий врёт! это неправда! get value opposite to flag at val-th index, хотя какой смысл писать комментарии длиннее, чем код?
// iterate through string and set flags for found chars to true
да ты что, издеваешься?
И этих людей пугает Zend-way расстановки скобок
в первой серии первого сезона Футурамы есть момент, когда Профессор показывает Фраю свою лабораторию: «это то, это сё, это мой межгалактический космический корабль, а в этом ящике у меня проводки. смотри, они отсортированы по длине».
двух комментариев к этой функции более чем достаточно. один — оптимально. я бы ограничился говорящим названием функции и потратил время на документирование более нетривиального кода, или нарисовал бы диаграмму классов, или завёл бы весёлую ферму и выращивал бы брюкву, потому что выращивать брюкву и свиней в весёлой ферме это более полезное занятие, чем бесполезные комментарии, на которые коллеги потом будут тратить своё время. потому что комментарии длиннее чем код, неточны (или станут такими при первом же изменении кода), на неродном языке и к тому же они в 2 раза увеличивают размер программы.
двух комментариев к этой функции более чем достаточно. один — оптимально. я бы ограничился говорящим названием функции и потратил время на документирование более нетривиального кода, или нарисовал бы диаграмму классов, или завёл бы весёлую ферму и выращивал бы брюкву, потому что выращивать брюкву и свиней в весёлой ферме это более полезное занятие, чем бесполезные комментарии, на которые коллеги потом будут тратить своё время. потому что комментарии длиннее чем код, неточны (или станут такими при первом же изменении кода), на неродном языке и к тому же они в 2 раза увеличивают размер программы.
В одной контрое, куда я по-глупости устраивался, весь код должен был быть прокомментирован :)
Не то, чтобы это было очень плохо, они сумели выпустить и поддерживать продукт и код был вполне читаем, не смотря на обилие мусора.
Не то, чтобы это было очень плохо, они сумели выпустить и поддерживать продукт и код был вполне читаем, не смотря на обилие мусора.
я слышал об одной компании, в которой не только прокомментирована каждая строчка кода, но и ведётся история изменений каждой строчки кода, причём каждое изменение подробно описано — когда, кем, по какой причине, и где спецификация на это изменение.
www.fastcompany.com/node/28121/print
или то же на русском
но они делают шаттлы
www.fastcompany.com/node/28121/print
или то же на русском
но они делают шаттлы
Да, это распространенная практика, недавно в ACM была про это статья.
Я вначале тоже не комментировал простые и очевидные вещи. После Мартина также всецело стоял на позиции говорящего именования и прочего. Но… Судя по Вашему анализу моей никчемности, Вы достаточно опытный программист, раз можете давать такие суждения. И, конечно, в курсе, что над кодом работают несколько человек (иногда их называют командой).
Если абстрагироваться от простоты вещей и взглянуть на комментарий не как разъяснение чего-то, а как элемент метапрограммирования, то вы получаете мощный инструмент построения логики в отрыве от кода. Здесь комментарии стоят в качестве метаописания.
Я не претендую на глубоко продуманный комментариев, нет. И да, они лгут (о чем в частности предупреждал Мартин, которого по мнению andreycha на меня нет). Я пытался показать идею. Не надо читать код, чтобы понять его суть. Код может переписываться так, что внутри будут использованы полиморфные вызовы, табличные методы, запутанная иерархия, но метаописание должно оставаться легким. Поэтому комменты здесь смотрятся нелепо, но когда этот метод перепишется десяток раз, Вы возопите, что ничерта не понятно.
Если абстрагироваться от простоты вещей и взглянуть на комментарий не как разъяснение чего-то, а как элемент метапрограммирования, то вы получаете мощный инструмент построения логики в отрыве от кода. Здесь комментарии стоят в качестве метаописания.
Я не претендую на глубоко продуманный комментариев, нет. И да, они лгут (о чем в частности предупреждал Мартин, которого по мнению andreycha на меня нет). Я пытался показать идею. Не надо читать код, чтобы понять его суть. Код может переписываться так, что внутри будут использованы полиморфные вызовы, табличные методы, запутанная иерархия, но метаописание должно оставаться легким. Поэтому комменты здесь смотрятся нелепо, но когда этот метод перепишется десяток раз, Вы возопите, что ничерта не понятно.
да мне уже ничерта не понятно, мне говорят что делают одно а на самом деле делают другое.
у вас:
// iterate through string and set flags for found chars to true
for (int i = 0; i < str.size() && result; ++i)
это неправда. цикл, который вы описали, вот такой:
for (int i = 0; i < str.size(); ++i)
но это глупо, странно и нелогично. потому что «for (int i = 0; i < str.size(); ++i) » — это совершенно стандартный цикл, классический, эталон цикла в вакууме. его можно не комментировать, его назначение всем понятно. было бы неплохо прокомментировать && result, но вы от этого как раз уклонились.
ну и зачем?
нет, комментарии имеют право на существование, даже такие подробные. например, можно быть учителем. или писать книги «c++ для начинающих» — и там самое место таким комментариям.
комментировать нужно нетривиальные вещи. ну или, по крайней мере, комментировать не то, как работает код, а что он делает.
вот такой вариант, например, уже не оскорбляет меня своим существованием. хотя я бы всё равно решил, что это комментарии написал идиот.
// assume all chars are unique by default
bool result = true;
// flags for found chars, where index is char's ASCII code
std::vector char_set(256, false);
// for each character in string, until non-unique character found
for (int i = 0; i < str.size() && result; ++i)
{
// get a character
int val = str.at(i);
// is the character non-unique
result = !char_set[val];
// set character presence flag
char_set[val] = true;
}
return result;
у вас:
// iterate through string and set flags for found chars to true
for (int i = 0; i < str.size() && result; ++i)
это неправда. цикл, который вы описали, вот такой:
for (int i = 0; i < str.size(); ++i)
но это глупо, странно и нелогично. потому что «for (int i = 0; i < str.size(); ++i) » — это совершенно стандартный цикл, классический, эталон цикла в вакууме. его можно не комментировать, его назначение всем понятно. было бы неплохо прокомментировать && result, но вы от этого как раз уклонились.
ну и зачем?
нет, комментарии имеют право на существование, даже такие подробные. например, можно быть учителем. или писать книги «c++ для начинающих» — и там самое место таким комментариям.
комментировать нужно нетривиальные вещи. ну или, по крайней мере, комментировать не то, как работает код, а что он делает.
вот такой вариант, например, уже не оскорбляет меня своим существованием. хотя я бы всё равно решил, что это комментарии написал идиот.
// assume all chars are unique by default
bool result = true;
// flags for found chars, where index is char's ASCII code
std::vector char_set(256, false);
// for each character in string, until non-unique character found
for (int i = 0; i < str.size() && result; ++i)
{
// get a character
int val = str.at(i);
// is the character non-unique
result = !char_set[val];
// set character presence flag
char_set[val] = true;
}
return result;
Комментарии не должны говорить «что делает это код», они должны говорить «почему он это делает, зачем».
В первом случае означает, что это хреновый код и его надо бы переписать, чтобы было понятно и без комментариев.
В первом случае означает, что это хреновый код и его надо бы переписать, чтобы было понятно и без комментариев.
Извините, Вы с какого ВУЗа сбежали? :-)
Ребята, что спрашивают на собеседованиях для уровня Middle Developer (web, .net)?
спрашивают все что написали в резюме если таковое показывает опыт в нескольких компаниях с разными технологиями, дополнительно дают еще тестовое что бы видеть что справляетесь. На моем опыте на качественность кода и методы реализации ни кто не проверял.
ООП, архитектура приложений, паттерны, технологии, заявленные в резюме (плюсы/минусы, краевые условия), тесты на логические задачи.
Вёб как таковой (основы верстки, CSS).
Вёб как таковой (основы верстки, CSS).
А много вы собеседований проходили вобще (интересует опыт большой или нет :) )? Всегда задачки дают на месте ковырять?
Не бывает так, что на первый раз ограничиваются устной беседой и обсуждением резюме и оценкой вменяемости человека в целом, а потом дают либо по почте, либо сразу — большое задание, чтоб вы сделали и прислали через пару дней, а после если понравится работа, то прийти и ответить на вопросы по написанному коду?
А то вот начал поиск работы (первый раз в жизни, раньше не был никогда на собеседованиях), дык когда в первый раз дали ручку и листок бумаги, я мягко говоря ошалел… написать почти ничего не смог, нервничал так, что даже говорить то связно не мог, не то чтоб решать, что то.
И вот сейчас уже пройдено 4 собеседования, выданная ручка и листок бумаги уже так не пугают, как в первый раз, но вот настроиться на решение каких либо серьёзных задач, так и не получается (хотя дома без особых трудностей решаю, то что дают), вобще стресс какой то испытываю при интервью, валерьянка не помогает… Видимо надо просто побольше ходить и привыкнешь после первой десятки собеседований.
Не бывает так, что на первый раз ограничиваются устной беседой и обсуждением резюме и оценкой вменяемости человека в целом, а потом дают либо по почте, либо сразу — большое задание, чтоб вы сделали и прислали через пару дней, а после если понравится работа, то прийти и ответить на вопросы по написанному коду?
А то вот начал поиск работы (первый раз в жизни, раньше не был никогда на собеседованиях), дык когда в первый раз дали ручку и листок бумаги, я мягко говоря ошалел… написать почти ничего не смог, нервничал так, что даже говорить то связно не мог, не то чтоб решать, что то.
И вот сейчас уже пройдено 4 собеседования, выданная ручка и листок бумаги уже так не пугают, как в первый раз, но вот настроиться на решение каких либо серьёзных задач, так и не получается (хотя дома без особых трудностей решаю, то что дают), вобще стресс какой то испытываю при интервью, валерьянка не помогает… Видимо надо просто побольше ходить и привыкнешь после первой десятки собеседований.
я не знаю, окажется ли мой совет полезным, но я бы попробовал следующее:
когда работодатель будет назначать интервью, сообщить ему, что, мол, так и так, я очень волнуюсь и провалил свои предыдущие интервью из-за этого, и что хотели бы телефонное интервью. ну т.е. интервью в real-time, но по телефону или по скайпу (у вас, соответственно, должна для этого быть гарнитура и желательно вебкамера). код можно писать в collabedit (чтобы интервьювер видел ваш прогресс).
когда работодатель будет назначать интервью, сообщить ему, что, мол, так и так, я очень волнуюсь и провалил свои предыдущие интервью из-за этого, и что хотели бы телефонное интервью. ну т.е. интервью в real-time, но по телефону или по скайпу (у вас, соответственно, должна для этого быть гарнитура и желательно вебкамера). код можно писать в collabedit (чтобы интервьювер видел ваш прогресс).
Ну тут главное ощущать увереность в себе. Или ощущать пофигизм от того, устроишся, или нет :)
У меня тоже были трудности с задачей на бумаге. Но помогло две штуки: во первых не бояться рисовать сбоку схемы, диаграммы, крайние случаи и т.д. Оно с одной стороны увлекает в процесс обдумывания, а с другой — помогает не сделать досадных косяк. Плюс, итервьювер видит ваш процесс мышления, что тоже немаловажно.
А второе — если совсем ничего не выходит — так и сказать интервьюверу. После этого рассказать, какие были идеи решения. Интервьювер ведь тоже человек, видит что вы волнуетесь, понимает, что у вас прото из-за нервов может не получитья (если не видит — подумайте, нужен ли вам такой начальник). Если способ решения его устроит, то можно будет набросать потом код. С уже большей увереностью в своих действиях.
У меня тоже были трудности с задачей на бумаге. Но помогло две штуки: во первых не бояться рисовать сбоку схемы, диаграммы, крайние случаи и т.д. Оно с одной стороны увлекает в процесс обдумывания, а с другой — помогает не сделать досадных косяк. Плюс, итервьювер видит ваш процесс мышления, что тоже немаловажно.
А второе — если совсем ничего не выходит — так и сказать интервьюверу. После этого рассказать, какие были идеи решения. Интервьювер ведь тоже человек, видит что вы волнуетесь, понимает, что у вас прото из-за нервов может не получитья (если не видит — подумайте, нужен ли вам такой начальник). Если способ решения его устроит, то можно будет набросать потом код. С уже большей увереностью в своих действиях.
Пожалуйста, поправьте слова, начинающиеся у Вас в тексте с «объяз» — после «б» твердого знака в них быть не должно. Уж очень глаз режет, честное слово.
Проверка — «обязанность», а не «обЪязанность».
Проверка — «обязанность», а не «обЪязанность».
Опять двадцать пять! Про какие-то никому не нужные деревья и списки (кто еще их использует в наше время) написали чуть ли не 2 страницы, про ассоциативные массивы и хеш-таблицы — ни слова. Неучи.
И да, почему-то в названии не отражено, что речь идет о Си++. Например, на скриптовых языках делать списки довольно глупо.
И да, почему-то в названии не отражено, что речь идет о Си++. Например, на скриптовых языках делать списки довольно глупо.
ассоциативный массив обычно реализован на хеш-таблицах, либо деревьях. и я не понимаю зачем их вообще затрагивать — халва же.
+ как показывает практика реализовать хеш-таблицу гораздо проще, чем то же самое дерево => это гораздо лучше показывает знания программиста. ну и опять же, хеш-таблица есть в самом stl => ее необязательно уметь реализовывать самому, хех) а если таки придется, то она пишется за минут 5-10, там нет абсолютно ничего сложного.
ну а списки показывают навыки работы с указателями :) понимает ли интервьюируемый как они вообще работают или нет)
+ как показывает практика реализовать хеш-таблицу гораздо проще, чем то же самое дерево => это гораздо лучше показывает знания программиста. ну и опять же, хеш-таблица есть в самом stl => ее необязательно уметь реализовывать самому, хех) а если таки придется, то она пишется за минут 5-10, там нет абсолютно ничего сложного.
ну а списки показывают навыки работы с указателями :) понимает ли интервьюируемый как они вообще работают или нет)
Что-то простые какие-то задачки.
Вроде бы, если на работу нужен алгоритмист, то спросить могут и fast fourier transform, и поток в сети за n^3 и много чего еще…
А если нет — то спросят ооп/знание языка, на котором пишешь…
Вроде бы, если на работу нужен алгоритмист, то спросить могут и fast fourier transform, и поток в сети за n^3 и много чего еще…
А если нет — то спросят ооп/знание языка, на котором пишешь…
Цель этих задачек не решить их, а показать процес мышления. Так как даже если дать человеку задачку про детектирование цикла в односвязном списке, то по тому как он объясняет, пишет код, пишет тест кейсы, дебажит, уже можно многое сказать про то как он будет работать, внимателен ли он к деталям и так далее. А Преобразование Фурье это специфические знания. Веб программист их никогда не применит. А даже если и применит, то он пойдет на википедию и прочитает что это такое.
ну да а умение обернуть си-строчку (не дай бог вам ей пользоваться) для веб программистов обязательный минимум…
правильный ответ был — замените си-строки на string ?)
и да. как это показывает процесс мышления? оно может показать либо его присутствие либо его отсутствие…
правильный ответ был — замените си-строки на string ?)
и да. как это показывает процесс мышления? оно может показать либо его присутствие либо его отсутствие…
> Как это показывает процесс мышления.
Так же как я описал выше. Если вам прежде всего нужен не человек думающий, а человек умеющий в момент перевернуть строку на си, то это другое. По моему опыту, и по опыту людей которые вокруг, лучший результат дает беседа и решение на доске задачек по типу того что я сказал. Лично мне важнее увидеть что человек может четко обозначить проблему, собрать требование, продумать решение, обьяснить ход того как он думает, протестировать функцию, предвидеть исключительные ситуации, а потом еще и обсудить это все с теми корректировками которые я внесу. Хороший программист это прежде всего человек думающий, а не только набивающий код. Поэтому мне важно видеть, что он сможет общаться, четко выражать свои мысли.
Я не говорю что техническая подкованость это лишняя часть. Я лишь утверждаю, что даже на простой задаче можно увидеть намного больше, чем на каком-то сложном алгоритме.
И да, последнее. Опять же все зависит от требований. В разных компаниях предьявляют разные требования. Кому-то нужны люди которые я описал. Кому-то просто человек который спеку перенесет в код, причем быстро и эфективно. А кому то просто нужна печатная машинка, которая примет слова, и выдаст код.
Так же как я описал выше. Если вам прежде всего нужен не человек думающий, а человек умеющий в момент перевернуть строку на си, то это другое. По моему опыту, и по опыту людей которые вокруг, лучший результат дает беседа и решение на доске задачек по типу того что я сказал. Лично мне важнее увидеть что человек может четко обозначить проблему, собрать требование, продумать решение, обьяснить ход того как он думает, протестировать функцию, предвидеть исключительные ситуации, а потом еще и обсудить это все с теми корректировками которые я внесу. Хороший программист это прежде всего человек думающий, а не только набивающий код. Поэтому мне важно видеть, что он сможет общаться, четко выражать свои мысли.
Я не говорю что техническая подкованость это лишняя часть. Я лишь утверждаю, что даже на простой задаче можно увидеть намного больше, чем на каком-то сложном алгоритме.
И да, последнее. Опять же все зависит от требований. В разных компаниях предьявляют разные требования. Кому-то нужны люди которые я описал. Кому-то просто человек который спеку перенесет в код, причем быстро и эфективно. А кому то просто нужна печатная машинка, которая примет слова, и выдаст код.
А лучше бы спрашивали про декомпозицию и архитектуру.
Вернее как сказал Alex_MIPT, для алгоритмиста — слабовато, а для простого кодера непонятно что показывает.
— что он понимает простейшие структуры данных?
— дак он врядли будет сам писать сортировку или хеш, а вот делать декомпозицию и рефакторинг придется постоянно. (С) кто-то с хабра.
Вернее как сказал Alex_MIPT, для алгоритмиста — слабовато, а для простого кодера непонятно что показывает.
— что он понимает простейшие структуры данных?
— дак он врядли будет сам писать сортировку или хеш, а вот делать декомпозицию и рефакторинг придется постоянно. (С) кто-то с хабра.
Для размышления — классическая задача: «Переверните C-строку (имеется в виду, что “abcd” – это пять символов, пятый – завершающий нуль-символ ‘\0’)».
Юникод? Не, не слышали.
под си-строкой обычно понимается char*, а sizeof(char) на современных процессорах равен 8 => 256 символов
Может, это автор и имел ввиду :)
Типа, грамотный кандидат должен писать функцию, работающую на любых входных данных, а не только на простых (именно они коварно приведены в примере).
Сравните ваше решение с этим и ответьте на вопрос, почему ваш код лучше?
Типа, грамотный кандидат должен писать функцию, работающую на любых входных данных, а не только на простых (именно они коварно приведены в примере).
В точку! Хорошо сказано.
Для Юникодной строки невозможно разумно определить операцию переворачивания. И в нормальных фреймворках операция переворачивания строки не нужна.
Почему невозможно? Код
Приведённый вами код, конечно, лучше, чем версия автора поста, но тоже работает неправильно, т.к. не обрабатывает модификаторы букв. Например, он выдаст strrev(«über») = «reb̈u» если исходная строка была в денормализованной форме. Но даже если вы всё же научите алгоритм не переворачивать модификаторы, останутся другие проблемы. Например, должна ли концевая буква мем 'ם' преобразовываться в обычную мем 'מ', если мы переворачиваем слово и эта буква становится первой? Или что делать с модификаторами направления письма (слева-направо/справо-налево) при обращении строки? Чтобы ответить на эти вопросы нужно ответить на вопрос «Зачем на переворачивать строку». И когда вы пытаетесь ответить на этот вопрос, вы понимаете, что на самом деле операция переворачивания строки вам не нужна, просто в вашем классе String нет метода lastIndexOf и вы думали сделать что-то вроде string.reverse().indexOf(substring.reverse()). Так вот, не стоит этого делать. Просто добавьте в класс String метод, которые делает действительно то, что вам нужно.
Коллега, по-моему, вы кандидатам медвежью услугу оказываете. Это как литературу изучать по кратким содержаниям. Главная задача ведь не на работу устроиться, а потом хорошие программы писать, чтобы за них стыдно не было.
Даже в одной сфере все задают разные вопросы при собеседовании. Я проходил довольно много собеседований и сам также собеседовл программистов. Однако у меня так и не сложилось понимание, что нужно знать чтобы тебя полюбому взяли. У каждой компании свои требования, а вопросы больше зависят от личности человека, который их придумывает. И по тексту вакансии требования тоже не понять, например, где-то пишут что нужно зание математики, потому что они скопипастили текст вакансии, а где-то оно действительно нужно. Я например старался задавать вопросы максимально приближенные к тому, что действительно требуется в работе. А кто-то спрашивает всякий бред типа реализации списков, алгоритмов сортировки или задачки на тонкости языка, которые никогда не встретятся на практике.
Я думаю, характер вопросов на собеседовании сильно зависит от компании. Я сам отсобеседовал пол команды и ничего подобного мы никогда не спрашивали. Стандартные воросы на нашем собеседовании (для любого разработчика, не только старшего и ведущего):
— Паттерны проектирования.
— Смэлы и методы рефакторинга.
— Типы блокировок в многопоточной среде. Возможные проблемы с параллельным доступом.
— Транзакции — определение, уровни изоляции, выбор уровня изоляции.
— Когда лучше использовать/неиспользовать индексы.
— Основные проблемы информационной безопасности и способы их предотвращения (это ужасно, но в этой области только единицы могут ответить что-то внятно).
— Если человек заявляет, что знает несколько языков программирования, просим сравнить несколько языков (особенности, сильные/слабые стороны) — С# vs Java, C# vs C++ и т. д.
— SQL запросы — оптимизация и т. д. Классический вопрос: дан запрос, запрос использует full table scan. Почему? Что проверить?
— Вопросы на опыт работы с заявленными технологиями: как вызвать утечку памяти в .NET, как положить на лопатки кэш Oracle одним запросом, что такое ORA-01555 Snapshot too old и т. д. в зависимости от заявленных знаний. Иными словами, это вопросы, знать ответы на которые человек может только проработав с технологией какое-то время.
Ну и наконец, что скорее специфично для нашей компании, но часто требуется, — это знание английского. Что касается нас, то мы вообще не можем принять на работу человека, который вообще никак не знает английский. Для синьйора свобоное владение разговорным и письменным английским обязательно, для рядового — хотя бы базовое знание грамматики и основных слов, чтобы читать документацию и техническую переписку.
— Паттерны проектирования.
— Смэлы и методы рефакторинга.
— Типы блокировок в многопоточной среде. Возможные проблемы с параллельным доступом.
— Транзакции — определение, уровни изоляции, выбор уровня изоляции.
— Когда лучше использовать/неиспользовать индексы.
— Основные проблемы информационной безопасности и способы их предотвращения (это ужасно, но в этой области только единицы могут ответить что-то внятно).
— Если человек заявляет, что знает несколько языков программирования, просим сравнить несколько языков (особенности, сильные/слабые стороны) — С# vs Java, C# vs C++ и т. д.
— SQL запросы — оптимизация и т. д. Классический вопрос: дан запрос, запрос использует full table scan. Почему? Что проверить?
— Вопросы на опыт работы с заявленными технологиями: как вызвать утечку памяти в .NET, как положить на лопатки кэш Oracle одним запросом, что такое ORA-01555 Snapshot too old и т. д. в зависимости от заявленных знаний. Иными словами, это вопросы, знать ответы на которые человек может только проработав с технологией какое-то время.
Ну и наконец, что скорее специфично для нашей компании, но часто требуется, — это знание английского. Что касается нас, то мы вообще не можем принять на работу человека, который вообще никак не знает английский. Для синьйора свобоное владение разговорным и письменным английским обязательно, для рядового — хотя бы базовое знание грамматики и основных слов, чтобы читать документацию и техническую переписку.
Вход: (5 -> 9 -> 2), (3 -> 1 -> 5)
Выход: (8 -> 0 -> 8)".
наверное. все же, 9 -> 0 -> 7?
Выход: (8 -> 0 -> 8)".
наверное. все же, 9 -> 0 -> 7?
> Сложность в этом случае равна O(n), где n — длина входной строки. Это очень важно, чтобы вы во время интервью упомянули о сложности и смогли реально/правильно вычислять сложность некоторого алгоритма.
вы не учли что в вашем алгоритме используется вектор, который выделяет память из кучи, и это может менять сложность в зависимости от состояния кучи.
на небольшом размере строки, выделение памяти может быть тяжелее работы самой функции, и ваше O(N) с длинной строкой не всегда будет больше O(N) с короткой, так как сложность выделения неизвестна и зависит от величин, которые вы учесть и контролировать не можете
обычно если заранее известно сколько памяти нужно, то она выделяется на стеке, эта операция имеет сложность О(1) и даже с учетом обнуления будет быстрее чем выделение памяти из кучи
если количество памяти неизвестно, то всегда нужно упоминать ее расход в определении сложности алгоритма
вы не учли что в вашем алгоритме используется вектор, который выделяет память из кучи, и это может менять сложность в зависимости от состояния кучи.
на небольшом размере строки, выделение памяти может быть тяжелее работы самой функции, и ваше O(N) с длинной строкой не всегда будет больше O(N) с короткой, так как сложность выделения неизвестна и зависит от величин, которые вы учесть и контролировать не можете
обычно если заранее известно сколько памяти нужно, то она выделяется на стеке, эта операция имеет сложность О(1) и даже с учетом обнуления будет быстрее чем выделение памяти из кучи
если количество памяти неизвестно, то всегда нужно упоминать ее расход в определении сложности алгоритма
На мой взгляд, решение про удаление узла из списка, если есть доступ только к этому узлу — плохое. Оно создаёт неожиданные побочные эффекты, которые потом может быть очень трудно отловить.
(То есть я бы человека, предложившего такое решение и не прокомментировавшего тут же, почему оно плохое, в команду не взял).
(То есть я бы человека, предложившего такое решение и не прокомментировавшего тут же, почему оно плохое, в команду не взял).
Есть тонкость в are_unique_characters. Автору следует либо выделять вектор на 128 элементов, а не 256 (тем более, что написано про ASCII), либо в строке int val = str.at(i); кастить правую часть к unsigned char.
Есть ли повторяющиеся символы в ASCII-строке длиной в 336 символов? Да! И для этого не надо просматривать всю строку… :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скромное руководство по прохождению интервью: часть 1