Интервью с разработчиком программного обеспечения - справедливо или несправедливо [закрыто]

Я только что разговаривал по телефону с компанией на должность дипломированного разработчика программного обеспечения, и мне задали следующие вопросы. Я должен добавить, что компания не является поставщиком баз данных.

1. Как работает оптимизатор запросов?

2. Если база данных работает плохо, как бы вы использовали журналы производительности, чтобы выяснить проблему.

Я спросил, задают ли они такие вопросы всем кандидатам на разработку программного обеспечения (выпускникам или опытным) в первом телефонном интервью. Они ответили, что им нравится проверять свои кандидатские знания по разработке баз данных.

Я хочу написать в компанию, чтобы сказать, что эти вопросы нецелесообразно задавать на собеседовании с разработчиком программного обеспечения, и просить, чтобы мое собеседование было закончено.

Я хотел бы проверить обоснованность следующих предположений

а) Эти вопросы не могут быть справедливо классифицированы как вопросы разработки баз данных.
б) Я думаю, что вопросы подходят для интервью с DBA, но совершенно нецелесообразно для интервью с разработчиком программного обеспечения (опытным или нет).
в) Первый вопрос относится только к поставщику базы данных.
d) Второй вопрос несправедлив, поскольку разработчики программного обеспечения обычно не имеют дело с журналами производительности базы данных, поскольку это работа администратора баз данных.

Возможно, некоторые из вас будут достаточно любезны прокомментировать мои предположения или могут иметь какие-либо другие предложения, прежде чем я напишу в компанию.

Если бы я был интервьюером (которым я иногда являюсь) и получил бы письмо от кандидата с жалобой на то, что вопросы были несправедливыми, и они хотели переиграть, я бы поблагодарил моих счастливых звезд, что мы увернулись от этой пули, и немедленно переместил бы заявку в "отбросить" кучу. Поступая так, вы показываете, что вы являетесь жалобщиком, и у вас нет позиции «можно сделать», которую вы ищете.

а. вопросы были разумными, чтобы задать тему разработки баз данных.
б. ложный. Все, что связано с разработкой программного обеспечения, является честной игрой. Имейте в виду, что получение неправильного ответа автоматически не дисквалифицирует вас на должность (или другие должности в компании); это может помочь классифицировать вас как человека, который не подходит для работы, ориентированной на базу данных.
с. ложный.
д. ложный. Прежде всего, может не быть выделенного администратора баз данных; во-вторых, разработчик программного обеспечения должен знать о широком спектре проблем, которые могут повлиять на производительность (и точность), и, по крайней мере, иметь общее представление об управлении базами данных.

Возьмите это как урок, что есть вещи, которые вы еще не знаете. Теперь вы знаете, чему учиться в следующий раз.

Я думаю, что это справедливый вопрос (и он звучит так, как будто он задает Google). :) Суть вопроса заключается не в том, чтобы по-настоящему проверить ваши подробные знания о запросах к базе данных и тому подобном, а в том, чтобы посмотреть, как вы подходите и решаете проблему. Необходима способность выполнить задачу, которую вы уже выполнили ранее, но способность думать на ногах и подходить к новой проблеме - жизненно важный навык.

Когда мне задают такой вопрос, если мне не хватает конкретных знаний о данной базе данных, я думаю, что справедливый ответ начнется: «Ну, у меня нет особого опыта работы с этой технологией в конкретных, но в В общем, я бы посмотрел журналы производительности, чтобы найти операции, которые выполняются наиболее часто, и попытаться ранжировать их по времени обработки. Таким образом, я мог бы определить, какие операции являются самыми дорогими и могут быть хорошими кандидатами для оптимизации ».

Вам не нужны какие-либо конкретные технические знания для ответа выше, но это показывает вашему интервьюеру, что вы готовы решить новую проблему.

Если честно или несправедливо, вопрос не в этом, их нанимают, поэтому они устанавливают правила, и им разрешается спрашивать все, что они хотят (хорошо, не все, но почти все;))

И если вы все еще хотите эту работу, я не думаю, что вы сделаете себе одолжение, если напишите им.

Очень распространенная стратегия собеседований при приеме на работу - задавать вопрос, который находится за пределами уровня интервьюируемой должности, и проследить, как кандидат с трудом справляется. С заданными вопросами можно ожидать, что вы ответите примерно так:

Ну, мои знания баз данных зачаточны, но я думаю, что-то вроде этого ...

Или даже:

Извините, это далеко не в моей компетенции, мне нужно проверить детали журналов производительности с администратором базы данных.

В целом, я ожидал бы, что кандидаты начального уровня будут иметь хотя бы базовое понимание того, как работают базы данных, а также иметь отношение «я не знаю, но я буду стараться и учиться».

Если вы предприняли честную попытку, и они немедленно прекратили телефонный звонок, то у вас была бы реальная причина чувствовать себя тяжело, но я бы сказал, что вы должны научиться чувствовать себя уверенно, признавая, что ничего не знаете.

Я знаю интервьюеров, которые не считают собеседование завершенным, если не могут найти несколько относительных технических вопросов, на которые кандидат не может ответить. Цель состоит в том, чтобы увидеть, как кандидат имеет дело с этим типом вопроса.

Признавая, что они не знают? Хорошо. Составляете спин / BS для ответа? Дверь.

Во многих компаниях роли IMO, разработчика программного обеспечения и администратора базы данных плохо распределены по категориям. Как правило, вам необходимо знать хотя бы некоторые части баз данных, если вы разработчик программного обеспечения. Таким образом, вопросы кажутся мне справедливыми, если их не спрашивать более свежо.

Я думаю, что это справедливо. Я не работаю с поставщиком базы данных, но очень важно знать, как читать планы запросов (и журналы производительности, в меньшей степени). Знать, как работает оптимизатор запросов, также полезно знать.

В ответ на ваши пули:

а) а ? Конечно, они связаны с разработкой базы данных, и если вы пишете код, а ваша программа должна запрашивать данные, это актуально.

б) Не совсем. Администратор базы данных лучше знал ответы, но хороший разработчик тоже должен знать ответ. Я не ожидал бы столь подробного ответа, как от администратора баз данных, но я бы ожидал чего-то. И если разработчик не знает, я могу просто принять в качестве ответа «Я бы попросил DBA научить меня», если разработчик все еще был относительно новым для работы с базами данных.

в) Нет, это не так. Это относится ко всем, кто обеспокоен производительностью своих запросов к базе данных. Если вам не важно, насколько быстро выполняются ваши запросы, вы можете проигнорировать это. С другой стороны, ваши клиенты, чьи показатели на своих сайтах становятся все хуже и хуже, могут не согласиться.

г) возможно. Не все разработчики видят журналы производительности, но если есть проблема, вы можете ожидать, что администратор базы данных отправит вам соответствующие части по электронной почте и объяснит проблему, если вы не знаете, как ее интерпретировать. По крайней мере, разработчик должен иметь возможность взглянуть на план запроса и увидеть основные проблемы (полное сканирование таблицы => плохое, быстрое сканирование индекса => хорошее).

Поскольку вы только что закончили школу и, возможно, вы не покрывали эту тему на своих уроках, вы могли бы ответить, сказав: «Я бы поговорил с более старшим разработчиком или администратором баз данных и попросил помощи в понимании этого». Интервьюеры могут принять это, поскольку это показывает, по крайней мере, что вы готовы изучать новые вещи, поскольку у вас еще не было опыта, чтобы их узнать. Другой вариант - пойти и изучить их самостоятельно.

Удачи на следующем интервью!

Они имеют полное право спрашивать, чего они хотят. Возможно, вы не затронули эти темы в своей учебной программе для колледжа, но это не означает, что другие собеседники не имеют или не проявляют достаточного интереса к этой теме, чтобы выйти за рамки учебной программы. Они ищут лучшее. Надеюсь, ты хотя бы попытался ответить на вопросы и не стал защищаться. Если бы я был ими и получил от вас плаксивое письмо, вы бы попали в черный список.

Разработка программного обеспечения - это междисциплинарная профессия. Я не думаю, что вы получите какой-либо пробег, прося о перезаключении вашего интервью. «Разумным» в этом контексте является то, исключит ли данная компания вас из рассмотрения только из-за отсутствия у вас навыков DBA. Задавать вопрос вполне разумно.

Чем дальше вы продвигаетесь в своей карьере, тем больше вам нужно будет знать. Если вам интересно, почему разработчик программного обеспечения должен заботиться об оптимизации запросов, подумайте о разработке приложений. Новые проекты часто вовлекают обсуждения моделирования данных. Это приведет к обсуждению нормализации, которая приведет к работе по проектированию базы данных. Хорошие принципы проектирования сводятся к реализации. Плохие / неэффективные проекты на архитектурном уровне имеют последствия, которые часто обходятся дорого.

Понятие «честный» здесь не имеет значения. Это собеседование.

Они не могут отклонить вас, основываясь на вашем цвете кожи, религии, этнической принадлежности или некоторых других подобных вещах. Но они могут отклонить вас по любой другой причине, такой же глупой, как цвет обуви, которую вы носили на собеседовании. И вы никогда не узнаете истинную причину.

Важно быть устойчивым во время интервью. Я понимаю склонность к чрезмерному анализу, и я делал это сам достаточно часто. Но самое лучшее , что нужно сделать , это признать , что жизнь не является справедливой, и держать достаточное количество интервью в трубопроводе , что вам не нужно , чтобы повесить все свои надежды ни на одном из них.

Как и другие говорили, вопросы полностью актуальны. Тем не менее, было бы странно, если бы интервьюер решил, нанимать ли вас полностью на основании этих вопросов. Возможно, они хотели выслушать ваши рассуждения о предмете, с которым вы, возможно, незнакомы, и это правильная методика интервью.

Если бы я нанимал, я не исключил бы вас, если бы вы сказали: «Извините, я не очень разбираюсь в оптимизаторах запросов, но я могу учиться». Я бы исключил вас, если бы вы начали жаловаться на вопросы.

Чувак, позволь мне сказать тебе прямо: нет никакого способа обойтись без БД как разработчика программного обеспечения. Каждый отдельный проект, в котором я участвовал, занимал как минимум половину времени разработки. Разработка БД является неотъемлемой частью разработки программного обеспечения, и чем больше вы знаете, тем лучше вы можете решить проблему. Кроме того, не расстраивайтесь из-за типа вопросов и их контекста. В большинстве случаев работодатели просто хотят узнать, способны ли вы думать на ногах, чтобы решить имеющуюся проблему, или у вас есть уверенность, чтобы хотя бы сказать что-то разумное по этому вопросу. Поскольку вы являетесь выпускником, они понимают, что им все равно придется потратить время на то, чтобы научить вас всем этим вещам, но они хотят знать, будут ли вы стоить времени и усилий. Будь острым и скромным!

Я хочу написать в компанию, чтобы сказать, что эти вопросы нецелесообразно задавать на собеседовании с разработчиком программного обеспечения, и просить, чтобы мое собеседование было закончено.

Как вы думаете, что в мире произойдет, если вы отправите это письмо? Вы представляете, что они скажут: «Хм, у этого кандидата есть смысл. Мы должны вернуть его, и давайте зададим ему более простые вопросы»? Я гарантирую вам, что они не будут. На самом деле, то, что они будут делать, это разослать письмо и посмеяться.

Преодолей свое чувство права. Вы выходите в реальный мир.

Как вы считаете, вопросы о базах данных несправедливы? Вы думаете, что программистам не нужно знать базы данных, но эта компания, очевидно, знает. Вот почему они задают вопросы! Интервьюеры не задают вопросы только для этого. Они задают вопросы, чтобы узнать, знаете ли вы то, что им нужно. Если вы не знаете, что им нужно, значит, вы не подходите для этой работы.

Если вы не хотите изучать базы данных, это нормально, но не жалуйтесь, если какая-то компания не хочет вас нанимать. Вы не должны работу.

Как эти несправедливые вопросы? Разработчики работают с базами данных. Не думаете ли вы, что они должны, по крайней мере, знать факторы, которые влияют на эффективность и скорость выполнения запросов к базе данных? Не в каждой компании есть собственные администраторы баз данных ... и даже если это так, это не снимает с себя ответственность за написание эффективных запросов от разработчика.

Если они задают вопросы всем кандидатам, то они честны - все кончено.

Неважно, считаете ли вы, что вопросы соответствуют позиции, важно только то, чувствует ли потенциальный работодатель, что они уместны - и если они спрашивают, то, вероятно, они это делают (либо потому, что они отражают необходимые навыки, либо потому, что они нашли что ответы, которые они получают, рассказывают им интересные вещи об интервьюируемом).

Наконец, у вас, кажется, есть некоторые странные представления о пределах полномочий разработчика - я никогда (насколько я могу вспомнить за 25-летнюю карьеру на сегодняшний день) не работал с выделенным администратором базы данных ...

Глядя на вопросы, я думаю, что это может быть моя компания - мы задаем такие вопросы КАЖДОМУ кандидату в рамках телефонного интервью. Всегда. Это дает нам стандарт для работы.

Большинство ответов выше суммируют это довольно хорошо ...

а) Мы хотим людей с большим опытом, а не людей, которые могут делать только несколько вещей.

б) Вопросы предназначены для того, чтобы помочь нам проверить ваши знания. Возможно, вы не знаете ответа полностью (или вообще не знаете). Эти вопросы являются отправной точкой для расширения ваших знаний и опыта.

c) Помните, что собеседование предназначено для нашей пользы и ВАШИХ ... из типов вопросов вы сможете получить представление о роли и компании, а также о том, подходим ли мы вам, а вам - нам ...

г) это работа, если вы не пройдете собеседование, то повзрослей, перестаньте ныть и постарайтесь лучше на следующем собеседовании.

Похоже, у них нет администратора, поэтому они хотели, чтобы вы также выполнили эту роль. Это обычно для небольших компаний.

Я не вижу абсолютно ничего плохого в этом. Почему разработчик, особенно если он в конечном итоге работает в базе данных, не должен быть осведомлен о таких элементах?

Должен ли разработчик программного обеспечения не знать о программном обеспечении для оптимизации или о том, как получить доступ к журналам событий приложений, чтобы выяснить проблему с производительностью? Если так, то почему не то же самое для того, кто является разработчиком базы данных? Почему они не могут быть одним и тем же?

Если бы я брал интервью у кого-то на должность разработчика программного обеспечения, которая также занималась разработкой баз данных, вы чертовски правы, я хочу убедиться, что они знают не только о том, что они делают, но и что они могут повысить производительность своего кода. или существующий код в качестве базы данных может быть огромным препятствием.

Вместо того чтобы развивать отношение, возможно, лучшим вариантом было бы «я не знаю ответа, но вот что я сделаю, чтобы найти его».

Как отмечали другие, в интервью практически любой вопрос является честной игрой, если он не затрагивает какую-либо охраняемую законом территорию (например, возраст, расу, пол и т. Д.), И интервьюеры нередко бросают вопросы на вас, просто чтобы посмотреть, как вы реагируете на вопрос и как вы будете пытаться найти решение вопроса. Кроме того, поскольку кажется, что вы недавно закончили обучение, они немного ограничены в том, что касается возможности спросить вас о вашем опыте работы и о том, какие проблемы вы решили в производственных условиях. Таким образом, если компания выполняет большую работу, ориентированную на базы данных, задаваемые ими вопросы могут также иметь отношение к тому, какую позицию вы будете проводить на собеседовании.

Что касается ваших предположений:

а) Эти вопросы не могут быть справедливо классифицированы как вопросы разработки баз данных.

Может быть, а может и нет. Если вы занимаетесь разработкой базы данных, вы собираетесь использовать оптимизатор запросов и время от времени планировать, чтобы попытаться убедиться, что в ваших запросах нет явных проблем. Если в компании есть администраторы баз данных или эксперты, которые могут просматривать запросы, у них может не хватить времени посмотреть на все, и они также не захотят смотреть на каждый плохо закодированный запрос. Аналогичным образом, разработчики также несут ответственность за поддержку своей среды разработки, за включение любых баз данных и за то, чтобы администраторы баз данных занимались производственной стороной.

б) Я думаю, что вопросы подходят для интервью с DBA, но совершенно нецелесообразно для интервью с разработчиком программного обеспечения (опытным или нет).

Они, вероятно, будут подходящими для интервью DBA; но независимо от этого, они также являются темами, с которыми разработчик должен быть знаком, хотя бы на уровне способности распознавать, где может быть проблема, и самостоятельно выполнять некоторые базовые процедуры устранения неполадок. Как я уже упоминал ранее, если у компании ограниченные ресурсы, они захотят убедиться, что не тратят время людей на что-то, что может быть основной проблемой.

в) Первый вопрос относится только к поставщику базы данных.

Конкретные детали могут зависеть от поставщика, но общие концепции могут применяться в любом месте, и иногда вам может потребоваться показать, что вы понимаете общие концепции. Если вы не хотите быть привязанными к одному стеку разработки (например, LAMP ), то вам нужно будет показать во время интервью, что вы понимаете основные концепции и удобно переходить к различным стекам разработки.

d) Второй вопрос несправедлив, поскольку разработчики программного обеспечения обычно не имеют дело с журналами производительности базы данных, поскольку это работа администратора баз данных.

Обычно это так, но если часть вашей работы заключается в написании программного обеспечения для конкретной базы данных, которое должно быть быстро реагирующим, то вам нужно будет приложить максимум усилий для написания этих запросов, чтобы коллега, который эксперт в данной области не увязает в плохо написанных запросах. Хотя вам, возможно, и не нужно знать подробности того, о чем говорят журналы, вам, возможно, потребуется уметь выявить очевидные проблемы.

Надеюсь, все это поможет!

Тот факт, что вы мягкий разработчик, не означает, что вы должны знать только темы разработчиков программного обеспечения. Наличие широкого спектра знаний от управления сервером до технологий баз данных на самом деле является очень полезным навыком для разработчика. У меня не было бы проблем задавать подобные вопросы кандидатам. Если они не понимают их правильно, хорошо, это не вычеркивает их из списка (я не ожидаю, что они знают все), но если они в состоянии ответить, это показывает мне, что разработчик намного больше, чем просто типичный программист, и это редкая порода.

У меня также есть аналогичный спор с потенциальным работодателем, который задал мне вопрос о крышке люка. Я спрашиваю вас, какое отношение имеет форма крышки люка к программированию!

Ответы формы Ну, я не уверен, но я бы посмотрел это, перейдя на, и они тоже хорошие. Никто не думает, что ты все знаешь, но умение искать вещи - ключевой навык