Чи погано в етикеті запитати потенційного роботодавця, як вони оцінюють тест Джоела? [зачинено]

Інтерв'ю для розробників відрізняється від більшості інших місць, тому що ви не тільки турбуєтесь про людей, з якими працюєте, переваги, опис вакансії тощо, у вас також є EXTRA, про які потрібно потурбуватися після отримання роботи. Написання двох додатків із точними вимогами може сильно відрізнятися, якщо ви працюєте в умовах гучного та тихого, використовуючи VS2003 / .NET 2.0 проти VS210 / .NET 4.0., Використовуючи SVN проти VSS.

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

ПРИМІТКА. Під "Тестом Джоеля" я маю на увазі певний перелік речей, які є важливими для вас (не обов'язково Джоела), але ви, можливо, не встигнете вийти, використовуючи традиційний випадковий "розмовний" спосіб запитати їх , тож ви вирішили або надіслати електронною поштою, або запланувати іншу зустріч, або запитати інших людей тощо.

Співбесіда на роботу йде обома способами - компанія опитує вас, і ви опитуєте компанію. Я б не виходив буквально з "яким вашим балом Joel Test?", Але я б задавав окремі питання, які були особливими для мене в роботі.

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

Чи є тест Joel на вашому пристрої, щоб оцінити, наскільки хороший потенційний роботодавець?

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

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

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

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

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

(Ніяких призів за здогадку, хто був роботодавцем!)

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

Тест Джоеля надихнув мене на запитання "так". Що таке управління версіями, відстеження помилок, тестування, ...

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

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

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

PS: просто переконайтеся, що ви знаєте, про що говорите, а не просто бездумно перебираючи якийсь список.

У мене є 3 запитання про середовище розробки, на які негативна відповідь на будь-який із них - шоу-пробка.

Яке програмне забезпечення для управління версіями ви використовуєте?

Яку проблему / помилку відслідковуєте?

Чи нагадує ваш процес розробки Scrum?