Здравствуйте, sergey_cheban, Вы писали:
_>Здравствуйте, alxn1, Вы писали:
A>>Офигеть. Сколько негатива и неуважения. Даже "Вы" выглядит издевкой. _>"Вы" — это не издёвка, а вежливость. Очень полезная штука: она позволяет более-менее сносно общаться людям в конфликтной ситуации. А негатив и неуважение — всё-таки лучше неискренности в стиле "Вы замечательно ответили на все наши вопросы и очень нам понравились, но работу поищите в другом месте".
A>>Ждем и правда вашего кода. _>Зачем? В данном случае оценка моей квалификации зависит не от моего умения писать код, а от того, правильно ли я оценил кандидата. Если Вы считаете, что я ошибся — пожалуйста, берите его себе.
_>Надеюсь, Вы чувствуете границу между защитой чести и достоинства и самоутверждением. Я эту границу переходить не хочу.
По-моему, Вам не помешает познакомиться с работами Эрика Берна и книжкой русского автора "Игры, в которые играют менеджеры" (автора не помню). Если еще не знакомы, конечно. Ну а негатив и неуважение никогда полезными не бывают.
Оптимальный стиль общения — нейтрально-положительный. Безэмоциональная формулировка решения, опционально — причин решения.
Здравствуйте, sergey_cheban, Вы писали:
_>Здравствуйте, KhConstantine, Вы писали:
KC>> Покажите нам, КАК ВЫ САМИ пишете серьезные приложения — отнюдь не тексты под копирайтом, KC>>о нет! И никто вас не просит выложить нечто, что требует больше нескольких часов работы. _>Вы предлагаете мне быстренько, на коленке, за пару часов написать "серьёзное приложение"? _>Или Вы предлагаете написать что-нибудь простенькое, но использовать при этом избыточно "тяжёлый" подход?
Именно простенькое, "на коленке", но с "тяжелым" подходом. Если под словом "тяжелый" вы понимаете те подходы, что следует применять
при коллективной разработке сложных систем по вашему мнению.
И не бойтесь, что я отнесусь к нему так же, как вы отнеслись к моему написанному на коленке за пару часов коду.
У меня вообще нет привычки "опускать" собеседников, тем более — распуская пальцы веером над приложением, которое нет смысла вылизывать и документировать. А то, что в любом коде, написанном "на автомате" и не отсмотренном повторно коде ляпы будут, и много — очевидно.
Более того, и в повторно отсмотренном самим программистом коде встречаются ляпы, ибо глаз замыливается. Потому во многих конторах еще и
коллективный анализ каждого изменения выполняется. Так что по вашим ляпам от оскорбительных комментариев я воздержусь.
Мне просто интересно — а вдруг я действительно увижу нечто новое для себя?
KC>>Дайте же нам идеал, к которому нам надлежит стремиться! _>Отстаньте, нет у меня этого идеала. И нимба вокруг головы — тоже нет.
KC>> Вы же сами критики не боитесь? _>Вам угодно считать меня плохим программистом? Ради бога. Главное — не ставьте мои копирайты на свой код и воздержитесь от описаний моего мнения. _>Вам угодно заняться фаллометрией на форуме? С этим — не ко мне.
Пока что есть основания считать вас лишь критиком, причем худшего сорта.
И мне совершенно все равно, лучше вы меня как программиста или хуже. Вы не тот эталон, с которым имеет себя сравнивать.
Здравствуйте, KhConstantine, Вы писали:
>>> несколько десятков тысяч рублей чистого убытка KC>Понятен стандартный уровень ваших зарплат.
С точностью до десятичного порядка — да, понятен и отсюда (т.е. это не сотни тысяч рублей в месяц и не тысячи за всё время испытательного срока). Но заглянув в описание наших вакансий, Вы получили бы куда более точную оценку.
Вы считаете, что нам следует терять на своих ошибках больше?
>>> до того, как он сможет претендовать на работу у нас KC>Да, каждый сам устанавливает планку. И компании уровня "несколько десятков тысяч рублей"/брэнд из разряда "а разве они все еще существуют?" — тоже.
Не существует нас. И офис вам померещился, и собеседование. Сон это был. Переворачивайтесь на другой бок и спите дальше.
KC>В адаптированном виде описание применения транзакционного анализа нередко включается в ученики по управлению проектами, team building, etc KC>В соответствии с этой терминологией: Практически все транзакции идут у Вас с позиции "родитель критикующий". Позиция известна, как наиболее конфликтная и наименее продуктивная. Человек, общающийся с этой позиции, в своем восприятии транслирует все ответные транзакции, к какому бы типу они ни принадлежали в действительности, исключительно в два типа: "Ребенок послушный->Родитель критикующий" и "ребенок непослушный-> родитель критикующий". Второй тип вызывает отторжение. Так, данный абзац оформлен в нейтральном стиле,
Я просто вынужден Вам сказать, что в Вас пропадает талантливый психолог. Попытайтесь трудоустроиться в психдиспансер. Там Вас обеспечат лицензией на занятие психиатрией, и после этого Вы сможете практиковать. А без лицензии — не надо.
PS. Шутки шутками, а вовремя пролечиться или оформить инвалидность — это лучше, чем помереть от безденежья.
_>PS. Шутки шутками, а вовремя пролечиться или оформить инвалидность — это лучше, чем помереть от безденежья.
Ну, Сергей, раз в дело пошли прямые оскорбления — разговор пора заканчивать. Мир?
В принципе жаль, что ситуация сложилась с самого начала именно так, а не иначе.
Конечно, я и ваша компания несовместимы — ну и что? С парой моих несостоявшихся работодателей, к примеру,
даже нашлись нашлись другие взаимные интересы, никак не связанные с моим прямым наймом в их компании.
Давайте договоримся: больше никаких сообщений друг о друге НИГДЕ и НИКОГДА.
Разве что взаимные извинения c СОГЛАСОВАННЫМИ друг с другом текстами.
Мое мыло для вас секретом не является, вашего личного я не знаю.
Через "мой круг" я вам отправил пару сообщений.
Также я вам оставил сообщение в вашем личном журнале.
Прочитайте их, потом побеседуем НЕ на форуме.
Можем даже просто по телефону — благо, мой сотик для вас — тоже не секрет.
Договорились? И, пожалуйста, воздержитесь от ЛЮБЫХ несогласованных ответов относительно моей персоны.
Ну и я воздержусь от несогласованных комментариев о вас лично и о вашей компании.
Закончим уже, OK?
_>4. Мы тоже иногда ошибаемся, причём при наличии сомнений предпочитаем отказать кандидату. В конце концов, каждый ошибочно принятый на работу человек обходится нам в несколько десятков тысяч рублей чистого убытка, а каждый ошибочно отвергнутый — найдёт себе применение где-нибудь в другом месте.
Странно, что вы не понимаете, что ошибочно отвергнутый на самом деле обходится в сотни тысяч рублей убытка.
Здравствуйте, sergey_cheban, Вы писали:
_>Надеюсь, Вы чувствуете границу между защитой чести и достоинства и самоутверждением. Я эту границу переходить не хочу.
Что не помешало Вам перейти границу "публично сраться с кандидатом после собеседования".
Зачем, спрашивается? Тем более, что, [имхо], рассказывать всем как вёл себя кандидат на собеседовании, — не принято.
A>Какие проблемы Вы видите в этих фрагментах кода и как предлагаете их решать?
A>1.
A>void g( char *, char *, size_t );
A>void f( size_t n )
A>{
A> char *a = new char[n];
A> char *b = new char[n];
A> g( a, b, n );
A> delete [] b;
A> delete [] a;
A>}
A>2.
A>int main(int argc, char* argv[])
A>{
A> if( argc > 1 )
A> printf( argv[1] );
A> return 0;
A>}
A>
Основная проблема — необходимость переписать этот код полностью. А так он нормальный.
UP!!!
Во, блин. Мне тож drWeb говнокод прислал, даже и не знаю чего им ответить.
Какие проблемы Вы видите в этих фрагментах кода и как предлагаете их решать?
1.
void g( char *, char *, size_t );
void f( size_t n )
{
char *a = new char[n];
char *b = new char[n];
g( a, b, n );
delete [] b;
delete [] a;
}
Здравствуйте, Tesh, Вы писали:
T>Здравствуйте, любой, Вы писали:
Л>>Здравствуйте, amberovsky, Вы писали:
Л>>Тут по существу уже сказали. А меня в таком коде всегда прикалывает, почему два блока нельзя за раз выделить:
Л>>char *a = new char[n*2]; Л>>char *b = a + n; Л>>g( a, b, n ); Л>>delete [] a;
T>Насколько я понимаю в этом случае нужен будет в два раза больший непрерывный блок памяти, который найти меньше шансов, чем два поменьше
В общем случае это не предсказуемо из за фрагментации этих блоков поменьше на еще более поменьше — один выделен, второй нет. А чем больше фрагментация — том дольше искать следующий блок.
Зато операция выделения/освобождения — одна. Что без шансов в ~два раза быстрей & меньше фрагментация памяти. Единственный минус — надо быть внимательней самому и тем кто этот код будет править.
На первый вопрос ответил, что текст не отформатирован, переменные и названия функций не несут смысловой нагрузки. Я не должен делать предположения по поводу тела функции g и поведению операторов new, без большей информации нет смысла искать проблемы. На второй ответил, что следуют заменить printf(argv[1]) на puts(argv[1]). Может они хотели услышать про уязвимость printf или еще чего. На досуге подумаю. Смысл в этом задании ведь должен какой-то быть.
Приветствую героев, дочитавших эту тему до шестнадцатой страницы.
Несколько комментариев от автора вопросов:
1. Поскольку вопросы до сих пор используются для предварительного отбора кандидатов, дать "правильные ответы" или указать на конкретные ошибки я, увы, не могу.
2. Единственно верных ответов на эти вопросы не существует. На шестнадцати страницах обсуждения есть несколько вариантов, которые нас вполне устроили бы. Есть и такие, которые нам не нравятся.
3. Фактически, на каждый из вопросов нас устраивает любой ответ, который в каком-нибудь плане лучше предложенных фрагментов кода, и при этом не создаёт больше проблем, чем решает.
4. К сожалению, нам очень часто приходилось сталкиваться с ситуацией, когда явная глупость, написанная кандидатом, обозначала именно саму себя. Мы оцениваем то, что написано в ответе, не приписывая кандидатам свой взгляд на мир.
5. Большинство хороших программистов трудоустроены. 99% не трудоустроенных нам не подходят (прежде всего речь идёт о людях, у которых за спиной — один семестр "основ программирования на C/C++" и больше ничего). Мы хотим отфильтровывать 90% кандидатов на уровне предварительного отбора, и 90% оставшихся — на уровне очного собеседования. Это очень жёсткие фильтры, и не удивительно, что они иногда отбрасывают хороших разработчиков. Ничего страшного, такие разработчики найдут работу где-нибудь ещё.
6. Мы хотим увидеть хорошие ответы на оба вопроса.
7. Мы, увы, не можем задавать более сложные вопросы: хорошие разработчики на них не отвечают, а плохие нам не нужны.
8. Учитесь и развивайтесь, но не ломайте себя. Не пытайтесь подогнать ответ под то, что мы, якобы, хотим услышать. Руководствуйтесь своим здравым смыслом, своим чувством прекрасного, и вы найдёте команду единомышленников. Может быть, это будет наша команда. Но даже если нет, — может, оно и к лучшему?
Здравствуйте, sergey_cheban, Вы писали: _>5. Если кандидат в процессе чтения этой ветки узнаёт много нового и интересного для себя — это верный признак того, что ему ещё есть чему поучиться до того, как он сможет претендовать на работу у нас.
C учетом предлагаемой зарплаты, других кандидатов вы наврятле увидите усебя на собеседовании
Здравствуйте, sergey_cheban, Вы писали:
_>3. Фактически, на каждый из вопросов нас устраивает любой ответ, который в каком-нибудь плане лучше предложенных фрагментов кода, и при этом не создаёт больше проблем, чем решает.
Очень многие такие тесты на собеседовании и этот в том числе имеют серьезный недостаток: они даны вне контекста и испытуемому на самом деле предлагается усовершенствовать "сферический код в вакууме." Я бы такой код без дополнительных условий вообще переписывать не стал бы Работает — и хорошо.
Как можно говорить, что усовершенствованный код должен решать больше проблем, чем создает, если даже достоверно неясно какого рода проблемы имели место?
А то может первый код вообще хитрый хак чего-то или оптимизирован по быстродействию, а тут уже на форуме напредлагали и boost и смартпоинтеры, которые там возможно уместны как седло у коровы.
По второму коду можно сказать, что вообще-то есть библиотечные функции для разбора опций командной строки getopt для Unix или более универсально boost::program_options, а может этого не нужно совсем и тут важно, что внещний результат работы программы может быть одинаковым в случае отсутствия опций и в случае неотображаемого символа в аргументах.
Здравствуйте, lennyn, Вы писали:
L>UP!!! L>Во, блин. Мне тож drWeb говнокод прислал, даже и не знаю чего им ответить.
L>Какие проблемы Вы видите в этих фрагментах кода и как предлагаете их решать? L>1. L>void g( char *, char *, size_t ); L>void f( size_t n ) L>{ L>char *a = new char[n]; L>char *b = new char[n]; L>g( a, b, n ); L>delete [] b; L>delete [] a; L>}
L>2. L>int main(int argc, char* argv[]) L>{ L>if( argc > 1 ) L>printf( argv[1] ); L>return 0; L>}
Ну раз это доктор Вэб, то
1. Я бы ответил что в функции f n не проверяеться размер n ,можно запросить столько памяти что не сможет выделить система
2. Стопудово что размер argv[1] не проверяеться, программа становиться уязвимой
A>Ну раз это доктор Вэб, то A>1. Я бы ответил что в функции f n не проверяеться размер n ,можно запросить столько памяти что не сможет выделить система
А если задача работать быстро, размер n заведомо не превосходит доступной памяти, а лишние проверки только затормозят?
A>2. Стопудово что размер argv[1] не проверяеться, программа становиться уязвимой
Тогда еще надо проверять и все возможные модификаторы в строке ввода, вообще есть готовые функции для разбора опций, чтобы велосипед не изобретать. А тут может быть программа — это затычка для какого-нибудь скрипта и говорить про уязвимость бессмысленно.
В общем, как я уже написал, на практике без дополнительных не видно смысла что-то с этим делать, тест, строго говоря, некорректный.
Здравствуйте, Michael7, Вы писали:
M>Здравствуйте, artkarma, Вы писали:
A>>Ну раз это доктор Вэб, то A>>1. Я бы ответил что в функции f n не проверяеться размер n ,можно запросить столько памяти что не сможет выделить система
M>А если задача работать быстро, размер n заведомо не превосходит доступной памяти, а лишние проверки только затормозят?
A>>2. Стопудово что размер argv[1] не проверяеться, программа становиться уязвимой
M>Тогда еще надо проверять и все возможные модификаторы в строке ввода, вообще есть готовые функции для разбора опций, чтобы велосипед не изобретать. А тут может быть программа — это затычка для какого-нибудь скрипта и говорить про уязвимость бессмысленно.
M>В общем, как я уже написал, на практике без дополнительных не видно смысла что-то с этим делать, тест, строго говоря, некорректный.
даже не знаю...
Но данные задания, позволяют посмотреть как думает человек, обычно задание дается, и просится озвучивать что видит, что нужно изменить, и т.д.
Не обязательно правильно ответить, правильных ответов обычно нету, имеется ввиду один правильный ответ и других нет, ответов может быть много, и каждый по своему правильный, но по размышлениям примерно видно что за инженер, обычно цель не проверить знания, а проверить способность мыслить, способность видеть потенциальные ошибки, и т.д. Для инженера самое главное не помнить названия всех функций,и что они делают, а умение мыслить, а знания приобретаются по ходу работу, если чего-то инженер не знает, он должен знать где найти ответ, взять книгу или банально гуглонуть, найти ответ и применить его на практике. Зачастую студент без опыта работы но думающий, потенциально принесет больше пользы, чем просто ходячий справочник с опытом работы, а таких хватает, на собеседовании все отвечает, а на деле с простой задачей, где нужно именно думать и искать решение не может справиться.
Это мое мнение ))
