Як ви відповідаєте на питання "пояснити поточну архітектуру вашого проекту" в інтерв'ю? [зачинено]

Додаток, над яким я зараз працюю, трохи величезний. Це не можна пояснити за 15 хвилин.

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

Які основні речі слід виділити, відповідаючи на це запитання?

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

Які ще речі, що не можна пропустити?

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

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

Ви можете заглибитись у конкретні компоненти, якщо відчуєте, що це потрібно. Але я ніколи не заглиблювався набагато глибше, ніж "через цю причину ми використовували Workflow Foundation для цієї частини бізнес-логіки". Це дало мені можливість зазначити, що ми використовували певну технологію , що не використовується , не витрачаючи часу на тривіальні речі, такі як прості об'єкти POCO.

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

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

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

Усі ці відповіді чудові, але я помітив, що дуже складна діаграма компонентів на високому рівні, перелік технологічного стеку (напр. Java, JSF, Primefaces тощо) та впевнена посмішка та відкрите ставлення - найкращі відповідь на це запитання.

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

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

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

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

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

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

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