Pull to refresh
34
0
forketyfork @forketyfork

User

Send message
Отличный пример. Вот я предпочту взять тех немногих, кто выкинет молоток и попросит шуруповёрт.
Да, сам по себе ответ «отсортирую и возьму первый элемент» ещё ничего не значит. Самое интересное начинается тогда, когда интервьюер задаёт вопрос «а можно быстрее?»
У человека есть контекст в виде процедурного языка программирования общего назначения, в котором есть циклы, присваивания и операторы сравнения. Этого достаточно, чтобы решить задачу в один проход.
В статье речь идёт не об отсутствии технического собеседования, а о той ситуации, когда кандидата готовы принять без технического собеседования. Как я понимаю, оффер вам не делали, так что это не ваш случай. Рассказать своими словами о рабочем опыте — вполне нормальная просьба интервьюера, даже если всё подробно расписано в резюме, ведь на работу принимают не резюме, а живого человека.

«Выгнал» — сильное слово, это в моём понимании когда вам говорят «пшёл вон, свободен». Не могу себе представить что-то подобное из уст моих коллег. По окончании собеседования никто вам не скажет «вы нам не подходите, потому что...» — обычно интервьюер просто заканчивает собеседование тогда, когда считает нужным, и по его результатам составляет внутренний отзыв, который, естественно, никто и нигде вам не предоставит. При наличии положительного отзыва вам могут сделать оффер. Это абсолютно нормальная процедура проведения собеседования.
Я не смеялся над вашим резюме, как раз наоборот, отметил, что спектр указанных там умений достаточно широкий, его сложно подогнать под какой-то ограниченный набор вакансий, и такие ошибки неизбежны. С таким резюме вам неизбежно придётся самостоятельно отсеивать все поступающие предложения, не надеясь на то, что резюме правильно истолкуют HRы, чтобы не погрязнуть в бесконечных собеседованиях на самые разнообразные вакансии.
Нет, это был не я. Думаю, меня при желании можно опознать по аватарке: о)
Если HR не сообщил вам, на какую вакансию вас приглашают, это, конечно, не очень хорошо с его стороны. Но вообще совет лично от меня как от человека, много походившего по собеседованиям — следует помнить, что HRы далеко не всегда разбираются в тонкостях технологий и ориентируются в основном по ключевым словам в резюме. Нет смысла судить их за это, они не технические специалисты. Поэтому лучше не идти на собеседование вслепую, а всё же самостоятельно уточнять такие вещи, как вакансия и список требований, заранее. Не стоит надеяться на то, что ваше резюме правильно соотнесли с вакансией и догадались, какую именно должность вы ищете, особенно если в резюме написано «всё умею, всё могу»: о)
Мне очень жаль, если у вас остались плохие впечатления о нашем собеседовании. У нас достаточно большая компания, много подразделений, куда набор идёт по совершенно разным критериям. Я отвечаю лишь за набор людей в свои команды, поэтому не в курсе всех происходящих интервью. На какую именно вакансию вас пригласили, и чем обидели?
Да, там ошибка, не проверил перед отправкой. Хотел только показать идею.
Я же расшифровал, какая именно часть ответственности приходится на подчинённого, а какая — на начальника. Начальник отвечает за принятое решение перед своим начальством. Подчинённый же отвечает за реализацию идеи перед самим начальником.

Иначе говоря, нормальный начальник никогда не «сдаст» подчинённого своему собственному начальству в духе «у нас не заработало, потому что имярек такой-сякой придумал хреновую идею» — потому что он сам принял решение и все шишки заранее взял на себя. Но при этом никто не снимает с подчинённого ответственность за эту идею перед его начальником и перед коллегами (в том числе и будущими разработчиками на проекте), которым тоже придётся с этой идеей потом жить.
Если под «фронтэндом» вы понимаете «программирование браузера», то пожалуй, хотя даже там это важно. Например, чтобы не городить велосипедный транспорт поверх HTTP/REST там, где можно перейти на более низкий уровень, или чтобы понимать, как работает TLS и сертификаты. А если рассматривать понятие «фронтэнд» как разработку клиентского ПО вообще, то там такое понимание незаменимо.

По-хорошему, любой разработчик приложений, которые что-то передают/принимают по сети, должен хотя бы примерно представлять себе, как происходит весь процесс передачи данных на всех уровнях, и к кому бежать, если что-то пошло не так. Область ответственности быстро расширяется, когда что-то не работает, и человек не может не то что решить проблему, а даже диагностировать её, чтобы определить эту самую область ответственности.
Кроме технического аспекта «начинаний», есть ещё и аспект ответственности. С моей точки зрения, инициатива всегда приветствуется, но она наказуема. Это означает, что если человек принёс какую-то идею, то он за неё отвечает — т.е. помогает внедрять, подсказывает другим, собирает грабли, вовремя отслеживает, если идея не работает, и её надо пересмотреть и т.д.

Просто иногда случается такое, что человек приносит свою гениальную идею, а потом, когда она не работает, отходит в сторону со словами «мучайтесь сами, это не идея была плохая, это ваша задача отстой». Отвечать за криво реализованную идею приходится как раз начальнику. Поэтому начальник может не принимать идеи подчинённых не по причине того, что он самодур и считает себя умнее всех, а потому что он понимает, что отвечать за эту идею потом ему.
При чём тут нанооптимизации? Я привёл совершенно типовую реализацию задачи на стандартном SQL, в котором LIMIT отсутствует.
Если бы мне такую аргументацию привели, это было бы человеку только в плюс. К сожалению, зачастую соискатель вообще не знает, что такое сложность и как её оценить.
Не очень понимаю, откуда ваша формула. Если вы сначала сортируете массив, а потом берёте первый элемент, то на сортировку у вас уходит (в типовой реализации сортировки в стандартных библиотеках) как раз O(ln(n)*n), а потом константное время чтобы взять первый или последний элемент по индексу.
Естественно, универсальных способов построения команды нет. Для кого-то нормальный начальник («нему*ак» в ваших терминах) — это тот, с которым можно потрындеть про шутки на тему ООП и паттернов, а для кого-то — тот, кто всё под контролем держит и умеет нормально работу команды организовать. Далеко не всегда эти вещи совпадают.
Ну а это уже было бы из области провокаций, я мог бы добавить это шестым пунктом в «как отпугнуть соискателя». Я бы указал на ошибку, но спорить не стал бы. Если из этого следует какой-то вывод о моих личных качествах, то он, скорее всего, будет неверным.
Для этого на собеседованиях, как правило, есть специальные задачи. Например, спроектируйте какую-нибудь архитектуру кода или системы. А почему вы так сделали? А как вы учли это? А почему выбран не этот, а тот вариант? Вот это хороший повод для того, чтобы проявить умение убеждать и аргументировать. А вот «вы не правы» — типичное самоутверждение.
Нет, на практике всегда можно выкрутиться родным диалектом SQL, спору нет, но даже в вашей конструкции есть некоторая неинтуитивность. ORDER это всё-таки глагол, и мне надо очень постараться, чтобы увидеть в этой конструкции декларативное описание того, что я на самом деле хотел получить.
Согласен, это важное умение, но есть целый спектр между умением отстаивать свою точку зрения ради пользы общего дела и самоутверждением в виде попыток на каждом ровном месте доказывать окружающим, какой ты крутой. Едва ли собеседование — это адекватное место для первого. Чаще на собеседованиях проявляется что-то ближе ко второму.
Да, а в других базах есть ещё FIRST, LIMIT и т.д. Я говорил про стандартный SQL.

Information

Rating
Does not participate
Location
Екатеринбург, Свердловская обл., Россия
Registered
Activity