Питання щодо інтерв'ю для розробників програмного забезпечення - Справедливе чи несправедливе [закрито]


10

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

  1. Як працює оптимізатор запитів?

  2. Якщо база даних працювала погано, як би ви використовували журнали ефективності, щоб з’ясувати проблему.

У першому телефонному інтерв’ю я запитав, чи задають вони такі питання всім розробникам програмного забезпечення (випускникам чи досвідченим). Вони відповіли, що люблять перевірити своїх кандидатів знаннями щодо розробки баз даних.

Я хочу написати компанії, щоб сказати, що ці питання нерозумно задавати на співбесіді з розробником програмного забезпечення та вимагати закінчення мого інтерв'ю.

Я хотів би перевірити обґрунтованість наступних припущень

a) Ці питання не можна справедливо класифікувати як питання розробки бази даних.
б) Я вважаю, що питання підходять для інтерв'ю DBA, але абсолютно необгрунтовані для інтерв'ю з розробником програмного забезпечення (досвідчений чи ні).
c) Перше питання стосується лише постачальника баз даних.
d) Друге питання нечесне, оскільки розробники програмного забезпечення, як правило, не займаються журналами ефективності бази даних, оскільки це завдання DBA.

Можливо, хтось із вас буде досить люб’язним, щоб прокоментувати мої припущення або, можливо, мати якісь інші пропозиції, перш ніж я напишу в компанію.


23
Я вважаю за краще взяти на роботу розробника, який може відповісти на ці питання справедливо, ніж того, хто не може. Але я не збираюся вирішувати лише виходячи з цього.
Доктор Белісарій

14
У нас був один раз інтерв'юйований настільки незадоволений його інтерв'ю, що він виставив нам рахунок на час консультацій. Ми вже передали йому рішення, але ми раді, що він продовжив свою діяльність, щоб підкріпити наше рішення. :-)

18
видалити з kandidat_list, де ім'я користувача = "user607018";
Мартін Йорк

44
@ user607018 Я думаю, що однією з ваших проблем тут є ваше припущення, що співбесіда на роботі повинна бути "чесною", як тест у школі. Це не правильно; Співбесіда на роботу - це лише перевірка, щоб дізнатись, чи хочуть вас найняти. Якщо в рекламі взагалі не згадували про оптимізацію / ефективність бази даних, то це вже інша історія, вони дозволяють витрачати час на подання заявки на роботу, яку ви не можете зробити, але в іншому випадку справедливість взагалі не входить у неї. . Це поширена помилкова думка, переходячи від штучного шкільного світу до реального світу, щоб насправді зробити речі.
MGOwen

16
Якщо вам коли-небудь доводиться писати запити SQL, ви повинні знати відповіді на ці запитання. Інакше ви закінчите писати банальні запити, і комусь іншому доведеться їх прибирати після вас. Отже, питання справедливі та виправдані.
SK-логіка

Відповіді:


86

Якби я був інтерв'юером (яким я іноді є) і отримав листа від кандидата, у якому скаржився, що питання були несправедливими і вони хотіли переробляти, я б подякував моїм щасливим зіркам, що ми ухилилися від цієї кулі і негайно перенесли заявку на купу "відхилити". Діяти так, це лише показує, що ви є скаржником, і не маєте ставлення «вмію робити», якого потрібно шукати.

а. питання було розумно задати темі розробки бази даних.
б. помилковий. Все, що стосується розробки програмного забезпечення - це чесна гра. Майте на увазі, що неправильна відповідь не автоматично дискваліфікує вас на посаду (чи інші посади в компанії); це може просто допомогти класифікувати вас як людину, яка не найкраще підходить для роботи, орієнтованої на базу даних.
c. помилковий.
г. помилковий. Перш за все, може не бути виділеної DBA; по-друге, розробник програмного забезпечення повинен знати про широкий спектр питань, які можуть вплинути на продуктивність (і точність), і мати принаймні високий рівень розуміння управління базами даних.

Прийміть це як урок, що є речі, які ви ще не знаєте. Тепер ви знаєте, що слід вивчити наступного разу.


31
+1 для "тепер ви знаєте, що вчитися". ОСТАННЕ, що працедавець хоче - це персонал, який вдосконалив свою мову "не моя робота"
Дейв

7
+1 - підняв би +100, якби тільки я міг ... занадто багато "розробників" в наші дні знають присідання про бази даних та про їх роботу - все ж вони ними користуються весь час ...
marc_s

+1 Ви повинні розраховувати на що-небудь інше під час співбесіди. Це їхня гра, їх інтерв'ю та їхня компанія

Я б дав більше підсумків, якщо б і міг, ви сказали те, що хотів сказати, лише більш тактовно. Я також зазначу, що питання, на які, можливо, не знатимеш відповіді, іноді задаються питанням, як ти відповідеш під тиском. Але я взагалі не знайшов нічого дивного в цих питаннях, якщо розробка бази даних є важливою частиною роботи.
HLGEM

5
Додатково я б сказав, що "Як працює оптимізатор запитів?" не обов'язково означає, що вони хочуть, щоб ви могли створити оптимізатор запитів з нуля. Це може означати, що вони хочуть перевірити ваше розуміння того, в який момент працює оптимізатор, при роботі із збереженими документами, adhoc SQL запитами тощо. Це абсолютно відповідні знання для розробника, який пише код, який потрапляє в базу даних.
Carson63000

17

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

Коли мені постає таке запитання, якщо мені не вистачає конкретних знань про дану базу даних, я думаю, почалася б справедлива відповідь: "Ну, я не маю багато досвіду роботи з цією технологією, але в загалом я перегляну журнали ефективності, щоб знайти операції, які виконуються найчастіше, і спробувати класифікувати їх за часом обробки. Таким чином я міг би оцінити, які операції є найдорожчими та можуть бути хорошими кандидатами на оптимізацію ".

Для відповіді вище вам не потрібні якісь технічні знання, але це показує вашому інтерв'юєру, що ви готові вирішити нову проблему.


4
Очевидно, що компанія може віддавати перевагу розробникам, які мають певні знання щодо оптимізації запитів. Моя дружина не DBA, але вона зробила багато хорошої роботи, оптимізуючи запити. DBA занадто зайняті, щоб оптимізувати всі запити, які могли б використовувати його.
Девід Торнлі

16

Якщо це справедливо чи не справедливо, це не питання, вони наймають, щоб вони склали правила, і їм дозволяється запитувати все, що вони хочуть (добре не все, але майже все;))

І якщо ви все ще хочете роботи, я не думаю, що ви зробите собі послугу, якщо напишете їх.


Технічно вони можуть запитати у вас що завгодно, вам належить відповісти чи ні (а якщо вони запитають у вас щось абсолютно нерозумно, ви все одно не хочете цієї роботи).
o0 '.

16

Дуже поширеною стратегією на співбесіді з роботою є задати питання, яке виходить за межі рівня займаної інтерв'ю, і бачити, як кандидат проникає. На запитання, на які можна попросити відповісти, можна відповісти:

Ну, моє знання баз даних є рудиментарним, але я думаю, що це щось подібне ...

Або навіть:

Вибачте, що це далеко поза моїми знаннями, мені потрібно перевірити деталі журналів ефективності з DBA

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

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


12

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

Ви визнаєте, що вони не знають? Добре. Створення спина / BS для відповіді? Двері.


9

Ролі IMO, розробника програмного забезпечення та DBA в багатьох компаніях недостатньо класифіковані. Як правило, ви також можете знати хоча б деякі частини Баз даних, якщо ви розробник програмного забезпечення. Отже, питання мені здаються справедливими, якщо їх не задають свіжішими.


8

Я думаю, що це справедливо. Я не працюю у постачальника баз даних, але дуже важливо знати, як читати плани запитів (і менші журнали ефективності). Знаючи, як працює оптимізатор запитів, також добре знати.

У відповідь на ваші кулі:

а) Так ? Звичайно, вони пов'язані з розробкою баз даних, і якщо ви пишете код і програмі потрібно запитувати дані, то це актуально.

б) Не дуже. BBA краще знати відповіді, але хороший розробник повинен знати і відповідь. Я не очікував би такої детальної відповіді, як від DBA, але я чогось очікував. І якщо розробник не знає, я просто міг би прийняти як відповідача "я б попросив DBA навчити мене", якщо розробник все ще був відносно новим у роботі з базами даних.

в) Ні, це не так. Це стосується всіх, хто стурбований виконанням запитів до їх баз даних. Якщо вам не байдуже, наскільки швидко працюють ваші запити, ви можете проігнорувати це. З іншого боку, ваші клієнти, які мають все більш низьку ефективність роботи на своїх веб-сайтах, можуть не погодитися.

г) Можливо. Не всі розробники бачать журнали ефективності, але якщо є проблема, ви можете сподіватися, що DBA надішле вам відповідні частини та пояснить проблему, якщо ви не знаєте, як її інтерпретувати. Як мінімум, розробник повинен мати можливість переглянути план запитів і побачити основні проблеми (Повна сканування таблиці => Погано, Швидке сканування індексів => Добре).

Оскільки ви не здобули школу, і ви, можливо, не висвітлювали цей матеріал у своїх класах, ви можете відповісти, сказавши: "Я б поговорив із старшим розробником або DBA і попросив допомоги в розумінні цього". Інтерв'юери можуть погодитись з тим, оскільки це принаймні показує, що ви готові вчитися новому, оскільки у вас ще не було досвіду, щоб їх дізнатись. Інший варіант - піти і вивчити їх самостійно.

Успіхів у наступному інтерв'ю!


7

Вони мають повне право запитати, що вони хочуть. Ви, можливо, не висвітлювали ці теми у своїй навчальній програмі коледжу, але це не означає, що інші респонденти не мають або не мають достатнього інтересу до цієї теми, щоб вийти за рамки навчальної програми. Вони шукають найкращого. Я сподіваюся, що ви хоча б спробували відповісти на запитання і не отримали оборони. Якби я був ними і отримав від вас примхливий лист, ви потрапили б у чорний список.


2
Або з цього приводу, тільки тому, що це було не в школі, це не означає, що компанії не потрібні ці навички!
GrandmasterB

3
І якщо кандидат якось отримав другий шанс, очікувати того ж питання (або навіть чогось невиразно схожого) було б серйозною невдачею. Одне, що я роблю, щоб перемогти розподіл запитань (особливо прихильників рекрутерів) - це суттєво змінити "дивне" питання. Наступного разу очікуйте щось про інтеграцію телефону чи сканування штрих-коду.

7

Розробка програмного забезпечення - це багатопрофільна професія. Я не думаю, що ви отримаєте будь-який пробіг, просячи провести інтерв'ю. "Розумним" у цьому контексті є те, чи дана компанія позбавить вас від розгляду лише на основі вашої недостатності навичок DBA. Задавати питання цілком розумно.

Чим далі ви прогресуєте у своїй кар’єрі, тим більше вам потрібно буде знати. Якщо вам цікаво, чому розробник програмного забезпечення повинен дбати про оптимізацію запитів, розгляньте дизайн додатків. Нові проекти часто передбачають обговорення моделювання даних. Це призведе до нормалізації дискусій, що призведе до роботи над розробкою бази даних. Хороші принципи дизайну переходять до реалізації. Погані / неефективні проекти на архітектурному рівні мають наслідки, які часто дорого усунути.


5

Поняття "справедливого" тут не має значення. Це співбесіда.

Вони не можуть відхилити вас на основі вашого кольору шкіри, релігії, етнічної приналежності чи кількох інших подібних речей. Але вони можуть відхилити вас з будь-якої іншої причини, настільки дурну причину, як колір взуття, яке ви носили на співбесіді. І справжню причину ви ніколи не дізнаєтесь.

Важливо бути стійким під час співбесіди. Я розумію схильність переаналізувати, і я робив це сам досить часто. Але найкраще зробити це - визнати, що життя не є чесним, і тримати достатньо інтерв'ю, що вам не доведеться покладати всі сподівання на будь-яку з них.


5

Як і інші говорили, питання цілком справедливі. Однак було б дивно, якби інтерв'юер вирішив, чи найняти вас цілком на основі цих питань. Можливо, вони хотіли вислухати тобі причину теми, з якою ти можеш незнайомий, і це дійсна методика інтерв'ю.

Якби я приймав на роботу, я б не виключав вас, якби ви сказали "Вибачте, я не знаю так багато про оптимізатори запитів, але я можу навчитися". Я б виключав вас, якби ви почали скуготати з питань.


5

Чувак, дозвольте сказати вам прямо: Бази даних як розробника програмного забезпечення немає. Кожен окремий проект, в якому я брав участь до цього часу, займав принаймні половину часу на розробку. Дизайн БД є невід'ємною частиною розробки програмного забезпечення і чим більше ви знаєте, тим краще ви зможете вирішити проблему. Крім того, не хвилюйтеся за типом питань, і це багато в чому контексту. Більшу частину часу роботодавці просто хочуть побачити, чи ви здатні думати на ногах, щоб вирішити проблему під рукою, чи у вас є впевненість хоча б сказати щось розумне з цього питання. З вами, як випускник, вони розуміють, що їм все одно доведеться витрачати час на навчання всіх цих речей, але хочуть знати, чи будете ви коштувати часу та зусиль. Будьте гострими і скромними!


Я розробник, і я не торкався бази даних протягом багатьох років. Деякі з нас не роблять WEB-карти CRUD. Це сказало, що для багатьох (можливо, навіть більшості) ролей ваші аргументи.
Крістоф Простой

5

Я хочу написати компанії, щоб сказати, що ці питання нерозумно задавати на співбесіді з розробником програмного забезпечення та вимагати закінчення мого інтерв'ю.

Як ви думаєте, що у світі станеться, якщо ви надішлете цей лист? Ви уявляєте, що вони скажуть "Хм, у цього кандидата є пункт. Ми повинні мати його назад, і давайте задамо йому простіші запитання"? Я вам гарантую, що вони цього не роблять. Насправді те, що вони зроблять, - це пройти навколо листа і посміятися.

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

Як ви вважаєте, що питання щодо баз даних є несправедливими? Ви вважаєте, що програмістам не потрібно знати бази даних, але ця компанія, мабуть, це робить. Ось чому вони задають питання! Інтерв'ю не задають питань просто для чортви. Вони задають питання, щоб з’ясувати, чи знаєте ви речі, які їм потрібні. Якщо ви не знаєте, що їм потрібно, то ви не потрібна людина для роботи.

Якщо ви не хочете дізнаватися про бази даних, це добре, але не скупіться, якщо якась компанія не хоче вас наймати. Вам не заборгували на роботі.


1
Я міг би здійснити мільйон разів, якби міг
HLGEM

4

Як це нечесні запитання? Розробники працюють з базами даних. Ви не думаєте, що вони повинні бути принаймні ознайомлені з тими факторами, які роблять ефективні та швидкі запити до бази даних? Не у кожної компанії є внутрішні DBA ... і навіть якщо вони це роблять, це не бере на себе відповідальність писати ефективні запити подалі від розробника.


4

Якщо вони задають питання всім кандидатам, то вони справедливі - закінчено.

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

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


Тоді ви уникали великих корпоративних корпорацій, які не входять до ІТ :) Вам потрібно слідкувати за нашими нацистами DBA!
ozz

@james "Уникати" - це неправильне слово - але так ... справа в тому, що більшість цього часу я був "розробником" і як такий вимагав принаймні деяких навичок типу DBA (хоча я не припустити, що я DBA ... але в рівній мірі не завжди потрібно бути / мати спеціальний dba для більш скромних проектів, хоча визнання прогалин у наборі навичок може бути болісним часом)
Мерф

4

Дивлячись на запитання, я думаю, що це може бути моя компанія - ми задаємо такі запитання кожному кандидату в рамках телефонного інтерв'ю. Завжди. Це дає нам стандарт для роботи.

Більшість відповідей вище підсумовує це досить добре ...

а) Ми хочемо, щоб люди з широким досвідом не були людьми, які вміють робити лише кілька справ.

б) Питання є для того, щоб допомогти нам перевірити ваші знання, можливо ви не знаєте відповіді повністю (або взагалі) питання - це відправна точка для розширення ваших знань та досвіду.

c) Запам’ятайте, що інтерв’ю існує для нашої користі та ВАШИХ… з типів питань ви повинні мати уявлення про роль та компанію та про те, чи ми підходимо до вас, і чи підходите ви до нас…

г) це робота, якщо ви не проходите інтерв'ю, то виросте, перестаньте скуголити і спробуйте краще на наступному інтерв'ю.


3

Схоже, у них немає DBA, тому вони хотіли, щоб ви також заповнили цю роль. Це звичайно для невеликих компаній.


6
Тільки тому, що компанія хоче, щоб розробник розумів, як точно налаштувати свої сценарії бази даних, НЕ означає, що вони не мають DBA. Я вважаю за краще розробника, який може оптимізувати власні речі, а не перетягувати будь-який сценарій SQL на сервер і сподіватися, що DBA потрапить на нього. У DBA є більше проблем, ніж постійно виправляти сценарії.

1
Не кожна компанія використовує DBA як такі. Розглянемо комерційних розробників, які розповсюджують програмне забезпечення клієнтам. У клієнтів може бути DBA, але розробникам все одно потрібно писати запити, які ефективно використовує їх програмне забезпечення.
GrandmasterB

Я працював у невеликій компанії (близько двох десятків людей, коли я приєднався), яка не отримала справжніх DBA до набагато пізніше. Коли у мене запит проходив від півхвилини до півгодини, я повинен був сам розібратися.
Девід Торнлі

1
У будь-якому випадку, нерозумно бажати розробників, які знають більше, ніж просто програмування.
Андрес Ф.

3

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

Якщо розробник програмного забезпечення не повинен знати про програмне забезпечення для оптимізації або як отримати доступ до журналів подій програми, щоб вирішити проблему з ефективністю? Якщо так, то чому б не те ж саме для того, хто є розробником бази даних? Чому вони не можуть бути одним в одному?

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

Замість того, щоб розвивати своє ставлення, можливо, кращим способом дій був би "Я не знаю відповіді, але ось що я зробив би, щоб її знайти".


3

Як зазначають інші, в інтерв'ю майже будь-яке питання є чесною грою, доки вона не торкається якоїсь законодавчо захищеної території (наприклад, віку, раси, статі тощо), і це не незвично: Питання у вас просто для того, щоб побачити, як ви реагуєте на питання і як би ви намагалися знайти вирішення питання. Крім того, оскільки, здається, ви недавній випускник, вони трохи обмежені, щоб мати можливість запитати вас про свій досвід роботи та які проблеми ви вирішили у виробничих умовах. Таким чином, якщо компанія виконує багато роботи, орієнтованої на базу даних, запитання, які вони задавали, можуть також бути важливими для того, якою буде посада, з якою ви займаєтесь.

Що стосується ваших припущень:

a) Ці питання не можна справедливо класифікувати як питання розробки бази даних.

Можливо, може й ні. Якщо ви займаєтеся розробкою баз даних, ви будете використовувати оптимізатор запитів і плануєте час від часу намагатися переконатися, що очевидних проблем у ваших запитах немає. Якщо в компанії є адміністратори баз даних або експерти, які можуть переглядати запити, вони, можливо, не матимуть часу на все, і вони також не хочуть розглядати кожен погано зашифрований запит. Крім того, також незвично, що розробники нестимуть відповідальність за підтримання свого середовища розробки, включати будь-які бази даних та змусити DBA керувати виробничою стороною речей.

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

Вони, ймовірно, будуть доречними для співбесіди DBA; але незалежно, вони також є темами, з якими розробник повинен ознайомитись, хоча б лише на рівні здатності розпізнати, де може бути проблема, і самостійно виконати основні проблеми. Як я вже згадував раніше, якщо компанія має обмежені ресурси, то вони захочуть переконатися, що вони не витрачають час людей на щось, що може бути основним питанням.

c) Перше питання стосується лише постачальника баз даних.

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

d) Друге питання нечесне, оскільки розробники програмного забезпечення, як правило, не займаються журналами ефективності бази даних, оскільки це завдання DBA.

Це, як правило, правда, але якщо частина вашої роботи полягає в написанні програмного забезпечення для певної бази даних, яка повинна бути дуже чуйною, то вам потрібно буде переконатися, що ви доклали максимум зусиль для написання цих запитів, щоб колега, який експерт у даній області не загрожує погано написаними запитами. Хоча вам, можливо, не потрібно знати більш точні деталі того, що розповідають ваші журнали, можливо, вам знадобиться виявити очевидні проблеми.

Сподіваємось, все це допомагає!


2

Тільки тому, що ви розробник програмного забезпечення не означає, що вам слід знати лише теми розробника програмного забезпечення. Наявність широкого спектру знань від управління сервером до технологій баз даних насправді є дуже корисним навиком роботи розробника. Я б не мав жодних проблем задавати такі запитання кандидатам. Якщо вони не отримують їх правильно, добре, це не перекреслює їх у списку (я не очікую, що вони все знають), але якщо вони зможуть відповісти, це показує мені, що розробник набагато більше, ніж просто типовий набір навичок програміста, і це рідкісна порода.


+1, повністю згоден. І якщо натомість потенційний прокат починає скуголити з приводу «несправедливості» питань, вони належать до більш поширеної породи , яку не наймають .
Андрес Ф.

2

Я також маю подібну суперечку з потенційним роботодавцем, який задав мені питання щодо кришки люка Я запитаю вас, яке значення має форма кришки люка для програмування!


3
Яким було власне питання щодо кришки люка? Б'юсь об заклад, це був мислительний експеримент, створений для того, щоб оцінити вашу здатність думати і не мав нічого спільного з кришками люків.
Kenny Wyland

Хороший інтерв'ю задасть вам такі питання, щоб краще зрозуміти, як ви думаєте та вирішуєте проблеми. (Хоча питання круглих люків сьогодні трохи втомило).

2
Це дуже поширене питання інтерв'ю: "Чому кришки люків круглі?" і очікувана відповідь повинна бути "щоб вони не змогли поміститися в (і впасти) в яму". (а не будь-яка кількість інших розумних причин, наприклад "тому, що отвір круглий (тому, що він просвердлений)" або "таким чином, ви можете згорнути кришку, щоб перемістити її після підняття вгору (інакше потрібно або перетягування, або двоє людей переїхати) "
Джиммі

Це питання, ймовірно, схоже на # м'ячі для гольфу, які можуть вписатись у запитання про автобус. Не обов'язково є правильна відповідь, але інтерв'юер хоче побачити, як ви думаєте, як би ви вирішили проблему. Важливо думати вголос під час співбесіди.

2
Заява, звичайно, жартома, я сумніваюся, чи хтось використовував відоме питання про люк в останні двадцять років. Справа в тому, що в інтерв'ю ви дотримуєтесь правил інтерв'юерів. Якщо питання здається недоречним, тоді поговоріть і поясніть свої міркування.

0

Відповіді форми Добре я не впевнений, але я би переглянув це, перейшовши на це, а також хороший. Ніхто не думає, що ви все знаєте, але вміти розшукувати речі - це ключовий навик

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.