Comments 78
То есть вы работаете за деньги?
Шедевр. «Работать в нашем
Полный бред — эти вопросы. Я поэтому и захотела рассказать о них)
По поводу «ты» — они уточнили, можно ли так обращаться.
трафарет А — меньше Х галок — недостаточно честные ответы
трафарет Б — больше Н галок — неуверен в себе
и т.п. Т.е. делаются выводы по косвенным признакам, поэтому опрос часто с таймером — чтобы не слишком задумывался. О точности судить не берусь.
Один раз посчитать с какой точностью? Плюс не указано насколько сильно деградирует скорость от кол-ва знаков… Может 50 знаков посчитать займёт 5 лет xD
а как же округление?
Всем желаю найти свою команду, ведь команда — это слаженный механизм, от работы которого зависит успех проекта.
А почему во всех ИТ-конторах обязательно строят «команды»? На всех собеседованиях и во всех вакансиях всегда рассказывают про «команду». Чем плох «коллектив», который меньше про эмоции, но больше про профессионализм.
На мой взгляд, в коллективе все работают за деньги и карьерный рост, и это правильно. А в составе команды хорошо играть в спортивные игры, где сам факт принадлежности к команде является мотивацией.
Без разницы как называть, хоть «коллективом» хоть «командой». Главное, чтоб все сработались и делали нормальный продукт на выходе.
Да управлять через коллективную ответственность гораздо проще. :-)
Я ещё понимаю, когда бытовые маршрутизаторы называют «роутерами» — вроде звучит попроще, сойдёт.
С другой стороны «команды», «лиды», «сеньёры» или конторы в которых из десяти человек шесть — разные «директора» — это всё бездумная калька из западной деловой культуры, которая в российских компаниях смотрится глупо. А по задумке, наверное, всё это должно сплачивать коллектив.
И да, к примеру, я работаю в коллективе, распределённом по разным территориям, решающим при этом одну общую задачу.
А вот что касается общей задачи — она может стоять и перед коллективом. Если коллектив мобилизуется для совместного ее решения — он становится командой.
Команда — группа лиц, работающая над одним проектом/подпроектом… в общем имеющая общую задчу. Коллектив — это вот прям все сотрудники, включая бухгалетров и уборщиц.
А уж если у компании есть возможность содержать кадровиков и психологов, которые будут сидеть нахлебниками, вы потенциально соглашаетесь навешать на себя обязанность не только работать по специальности, но и уметь правильно проходить тесты, чтобы эти психологи рапортовали о вас исключительно хорошо и к вам не было вопросов.
На мой взгляд, это как-то через чур — идти в компанию и работать там не потому что прикольно и нравится, а работать на каких-то психологов, которые даже понятия не имеют, каким профессионалом может быть тот чувак в углу, который провалил все тесты, потому что эти психологи так и не нашли к нему индивидуального подхода.
Тут уместны только слова министра Лаврова.
На мой взгляд, это как-то через чур
Через что, простите?
Технические вопросы по джаве, которые задают на собеседованиях, пора уже выпускать в виде книги.
Когда вы будете интервьювером, вас сильно удивит, что при огромном количестве тысячу раз повторенных вопросов, люди с опытом будут «лажать» в самых распространенных вопросах. А если некоторые кандидаты и прочитали что-то — насколько это было для них бесполезно.
Например, спросите про сложность какого-нибудь Qsort, человек гордо скажет «логарифмическя!». Ок, спросите вы, «а в терминах О-нотации это как записать?»
Тут кандидат зависнет.
Некоторые всё-таки отвисают, и пишут O(log n). Некоторые, после уточнения, напишут O(n log n). Но после вопроса «а откуда взялась n перед логарифмом? — кандидат все-таки зависнет. И даже если не зависнет, а ответит правильно, вопрос в какую сложность может выродиться этот алгоритм в худшем случае набора данных, лишь 10% от исходной воронки ответят про n^2.
P.S. этим комментом я не пытаюсь развязать холивар между „практиками“ и „теоретиками“, нужно или не нужно знать и уметь писать/оценивать сложность алгоритмов. Просто привел зарисовку из жизни.
Очень много хороших вопросов. И хороши они тем, что когда их слышишь, то сразу понимаешь что с этой фирмой тебе совсем не по пути :)
Судя по "от мечты отказываться нельзя” — это возврат к заданиям, которые нужно тупо запомнить, типа как в тюремной культуры нужно просто знать ответы на все эти типовые загадки про "два стула" и уметь на лету понимать, как ответить на похожие. Раньше было про люки, сейчас уклон в психо. Не могу сказать, что по этим штукам можно что-то хорошо понять про кандидата нужное, просто видимо правду говорят, что кандидатов так много, что без разницы как их отклонять, хоть гаданием по ромашке.
Как вы можете быть лидом, если Ваши друзья не назвали ни одного качества лидера?
Так и запишем, лидеру не нужны
Ответственность, усидчивость, коммуникабельность
Складывается впечатление, что качества лидера это некий сферический конь
а. Лень
б. Необходимость в отчёте перед начальством — «Смотрите, я составил каталог вопросов, который поможет...»
в. что-то ещё, не имеющее реального большого смысла.
Идеологическая цель этих вопросов: выявить качества человека, за как можно короткое время. К сожалению, это недоразвитость интервьюверов, задавать эти вопросы. Ибо нужно вести диалог или задавать не прямые вопросы о человеке, отвечая на которые он раскроется и ты только успевай делать себе записки, типа «не боится резких решений, нужно узнать о стрессоустойчевости» и т.д.
И оооочень важно сопостовлять всё на свою фирму, куда принимаешь на работу. Иначе толку в этих всех вопросах, когда работа проходит в подвале в паре с двумя интравертами си-шниками, которых заставили писать на джаве?!
Там не нужно составлять психотип человека — который так и так никто не делает, но вопросы зачем-то задают. Нужно понять адекватность и на сколько человек реально поможет компании.
Моё личное имхо по опыту. Если задел кого — не хотел — другого опыта не было.
Я лично, на днях спрыгнул с процесса резюмирования в одну большую компанию, на позицию Cloud Architect — после отправки резюме, мне стоило пройти математические и тесты по логике. Даже заглядывать в них не стал.
Скорее всего я бы эти тесты не прошёл на отлично, так-как более 10 лет на рынке, а они заточены на отбор юниоров. Я не хочу нагружать себя информацией, которую любят использовать в тестах и считаю, что могу дать намного больше, рассказывая о своей практике, которая имеет намного более весомые факты о моей проф деятельности.
А в итоге многие хотят и на ёлку и ж…
И тут я понимаю, что первоначально прийдётся встать на одну ступень с юниором, который хорошо учился, и скорее всего, станет в скором времени супер крутым разработчиком и т.д., но нет… и потом доказывай, почему ты лучше того парня, который прошёл тест на 99%, а ты нет…
Это моя позиция, мой выбор, правилен исключительно для меня, исходя из ситуации на рынке, которая происходит по месту моего жительства.
Правильный ответ этой задачи: “Отдать машину другу, он увезет бабушку, а сама останешься с мужчиной своей мечты. Потому что от мечты отказываться нельзя”
Воу, постойте-ка, от мечты отказываться нельзя — это ограничение (constraint), о котором в задаче ничего не говорилось, а раз уж мы решаем задачу как программист, то без формализации требований и ограничений не обойтись, иначе мало ли какие у заказчика хотелки, программист может решить взять друга, а не человека своей мечты, т.к. у него может быть требованием «от друзей отказываться нельзя» и оно приоритетнее «от мечты отказываться нельзя „
Поэтому можно ответить, что общепринятый ответ (среди собеседующих) правильный, но только, если требования и ограничения заранее оговорены. А если они не оговерены заранее, то любой ответ верный.
Думаю, это покажет Вас с лучшей стороны, т.к. не ведетесь на общепринятые ответы, а максимально ответственно подходите к решение поставленной задачи. Типа out-of-the-box thinking, а на самом деле здравый смысл и внимание к деталям.
Большой интерес вызывает что имел в виду интервьюер под "мужчина вашей мечты". Если то, что внешне он выглядит как Аполлон — это ещё не значит, что в общении он нормальный; если по условию задачи общения с ним раньше не было, то он вполне может оказаться чудаком на букву "м" (прям как эта контора).
«Ой, а от мечты нельзя отказываться!»
Так же не формализованы начальные условия: куда Вы едете, срочно ли это, можете ли остановиться.
И вообще, может у них там своя тусовка, а Вы остановились и лезете без приглашения.
Добавим к исходным условиям, что "х мечты" может принимать значения "девушка мечты" и "мужчина мечты" в зависимости от ориентации клиента (кстати, а собеседуюмую перед этим вопросом опрашивали этот момент?). Просто без этого условия совсем бред получается.
А теперь посмотрим на задачу с совем другого угла:
- у друга может не быть прав (нарушение законов, вплоть до уголовной отвестственности)
- при чём тут какая-то незнакомая бабушка (не, ну реально, кто-то останавливался ради незнакомой бабушки, чтобы куда-то там её подбросить? не верю (с))
- х мечты это конечно хорошо, но у меня "ипотека, жена, дети", на кой мне подставляться и подвергать риску отношение и состояния зависимых от меня объектов?!
К: Как вы можете быть лидом, если Ваши друзья не назвали ни одного качества лидера?«потому что с друзьями я дружу, а не ДОМИНИРУЮ-ВЛАСТВУЮ-УНИЖАЮ.» шах и мат, хрюши.
(Дальше додумывайте сами, что бы вы ответили. Но подход был очень интересный)
Люблю в таких случаях вспоминать свое очное собеседование в один московский магазин электрониники. Там тоже был психологический тест на 300 вопросов — сидишь, кликаешь на эти повторяющиеся "я скорее Х чем У", а рядом сидят кликают еще десяток кандидатов в менеджеры, продавцы, техники, аналитики… А когда все прокликано, тебе рассказывают, что у нас учет времени на рабочем месте по карточкам (не в офисе в целом, а в кабинете, карл!), и доступ в интернет запрещается, и никаких мобильников на рабочем месте, у нас все строго. Шел 2017й год, собеседование на разработчика С++...
Вопрос странно/непонятно поставлен — факт.
4 вопрос по Exception: разве иерархия не для полиморфизма? То есть я могу ловить более абстрактное исключение выше, при этом ниже — могу строить логику уже на конкретных эксепшнах, логи — лишь сугубо частное применение этого всего. Кроме того для логов достаточно просто возможности создавать разные классы исключений и иерархия для этого прям не нужна.
- я пхпшник, могу сильно ошибаться о том, как у вас там в джава устроено
опрос по Exception: разве иерархия не для полиморфизма
Не только, во-первых, начнем с того что есть Error (такие как OutOfMemory error) и Exception (оба наследуются от Throwable), первые обычно нет смысла ловить (но в принципе можно поймать, если пишешь что-то сильно системное) потому что это обычно означает такой писец, который обычное приложение уже не способно исправить, вторые стоит ловить, во-вторых, есть checked и unchecked Exception, первый банально не дадут скомпилироваться, если их не обработать.
Вероятно, интервьер хотел услышать разбор разных типов и как с ними работают, можно еще углубиться в вопросы почему не обрабатывают error и достоинства и недостатки checked Exception, как работает try with resources, блок finally и т.п. В общем, там можно задвинуть речь минут на пять.
разве иерархия не для полиморфизма
не только,… начнем с того что есть Error (такие как OutOfMemory error) и Exception (оба наследуются от Throwable)
Ну как не только, когда разная (поли) обработка и есть полиморфизм… логика «это обрабатываем, то нет» как раз-таки очень хорошо описывает полиморфное поведение интерфейса Throwable, при том является частным и малым примером использования иерархии исключений, или я как всегда все не так понял :(
Ну как не только, когда разная (поли) обработка и есть полиморфизм… логика «это обрабатываем, то нет» как раз-таки очень хорошо описывает полиморфное поведение интерфейса
Ну можно придумать разные понимаения полиморфизма, но вообще это не совсем так. Полиморфизм это когда логика обработки отдается на откуп конкретной реализации интерфейса, а не просто разная обработка в зависимости от разного типа (она и без ООП существует). То есть когда в коде у вас
public void func(MyInterface m) {
m.doSometing()
}
И вы не должны задумываеться, что будет делаться в doSometing() в том коде, а чисто передать управления реализации и получить какой-то результат. В случае когда у вас есть:
if(x instanseOf X) doSomething1();
else if(x instanseOf Y) doSomething2();
else if(x instanseOf Z) doSomething3();
Это уже не совсем правильный полиморфизм (да и вообще не совсем правильное ООП), так как можно просто ввести некоторое поле тип и делать тоже самое вообще без всякого ООП.
if(x.type == X) doSomething1();
else if(x.type == Y) doSomething2();
else if(x.type == Z) doSomething3();
P.S. На всякий случай catch(Exception1 e) {}… catch(Exception2 e) {} это как раз синтаксический сахар над конструкцией if(e instanseOf Exception1 ) doSomething1();, что уже не совсем чистые принципы ООП на самом деле.
public void func(MyInterface m) {
if(m instanseOf X) doSomething1();
else if(m instanseOf Y) doSomething2();
else if(m instanseOf Z) doSomething3();
}
:) Так что вполне нормальный и хороший полиморфизм у иерархии исключений, по определению
я не писал про ситуацию
catch() {} catch() {}
а писал про иерархию:
catch(GeneralException $e) {}
когда GeneralException может иметь наследников (например 10 штук) и в слое ниже на них построен полноценный слой, но выше, где мы ловим — нам не важно
«Зачем в джаве придумали эти иерархии, если можно просто сделать один?» (Рассказы про логи и распределение его не устроили, так я и не знаю какого ответа человек ожидал)
Непонятны, вы ответили, что без иерархии нельзя написать catch(DetailedException e), а без этой конструкции придется писать if, что против принципов ООП.
Про вопрос кого увезёте на машине, я считаю что ответ Вы дали верный. Тем более когда говорят «как» программист. Конкретное условие должно иметь конкретный вариант. «Правильный ответ» это лишь разлетевшееся
«Я знаком с этим вопросом, и не вижу смысла выдавать Вам заведомо правильный ответ, а отвечу с учётом постановления вопроса и моих человеческих качеств.» И какой бы ответ я не выбрал, с учётом моих моральных устоев, я бы выплюнул объяснение, почему я сделал этот выбор.
Совет — если Вы научитесь заберать эстафету разговора у Вашего собеседника, это очень хорошо может повлиять на результат. Совет к сожалению не из принципа — прочитал научился. Могу его дать проведя кучу собеседований с компаниями и рекрутами. Однако, если у Вас есть это качество и/или отсутствует страх, это может стать очень выгодным шагом на этом собеседовании.
А если это окажется не выгодно, боюсь, это не то место работы, где Вы хотите работать и развиваться.
Подборка психологических и нетипичных технических вопросов с собеседований Java-разработчика