Бреакинг Ит Довн: Како приступити било којем проблему са техничким интервјуом

Сигуран рецепт за проналажење начина да учините било који проблем лакшим за управљање.

1. Када добијете питање (пре него што напишете једну линију кода)

Најлакши начин да осигурате да разумете питање је пролазак кроз тест случајеве.

Ствари које треба разјаснити са вашим анкетером:
Који је очекивани унос? Који је очекивани резултат?
Било какве претпоставке о одређеним тестним случајевима

Након проласка кроз тест случајеве, забележите све променљиве које би требало да пратите и које би структуре података имале највише смисла за овај проблем.

Увек размислите о начинима на који можете да разрешите проблем. Постоји ли мањи, лакши подпроблем који можете решити? И ако је тако, како би изгледало то решење?

2. Писање кода (и шта урадити ако вас заглави)

Након што смислите свој алгоритам и објасните своју логику, следећа ствар коју треба да урадите је да преведете своју идеју у код.

У овом тренутку је груба сила потпуно ок. Стварање радног решења (чак и ако његово време извршавања и искоришћеност простора није савршено) далеко је боље од залагања у покушају преурањене оптимизације вашег кода.

Док пишете свој код, запамтите:

  1. Јасно изговорите о ком делу кода тренутно радите и зашто га додајете у решење
  2. Покушајте да користите очигледна имена променљивих и учините да ваш код буде читљив за читање
  3. Разговарајте са саговорником кроз ваш мисаони процес и које су предности и недостаци вашег решења
  4. Учините код модуларним кад је то могуће (помоћне функције су вам пријатељи!)

О руковању са том неспретном тишином ако се заглавиш или ти треба времена да размислиш ...

То се дешава свима нама и потпуно је нормално да се на то сусрећемо током интервјуа. По мом искуству, за скоро све моје техничке разговоре долази тренутак када морам да размишљам о себи и нисам у могућности да наставим да разговарам са саговорником. Кад се то догоди, обично кажем нешто по принципу:

Треба ми секунда да размислим о свом рјешењу и видим да ли има смисла
Нисам сасвим сигуран да ли је то прави приступ, дозволите ми да два пута проверим свој рад
Чини се да можда (убаците део предложеног решења) заправо не делује (убаците неки рубни случај) ... Размишљам о томе како да се решим томе

Интервјуер је обично на вашој страни и жели да видите да ли сте успели - само се сетите да ли вам он даје наговештај, никада га не игноришите!

3. Преглед вашег решења и додавање оптимизација

Када завршите са писањем кода, пронађите га помоћу тестног случаја како бисте били сигурни да се програм понаша онако како очекујете.

У овом је тренутку добро размотрити:

  1. Могући рубни случајеви које сте можда пропустили
  2. Искључивање једне грешке (посебно када се индексира или користи петља)
  3. Постоји ли понављање у вашем коду које можете очистити?

Питања која треба да поставите приликом покушаја оптимизације:

  1. Која је сложеност тренутног времена и простора?
  2. Постоји ли простор за побољшање ако сте користили другачију структуру података или мало измијенили свој приступ?

Када прегледавате код, имајте на уму да је потпуно могуће да сте направили ненамјерну грешку - покушајте да пратите кроз свој програм као да је то нечији посао који видите први пут!

Завршавајући све

Интервјуисање је вештина, а као и свака друга вештина може се побољшати вежбањем! Радити кроз техничке проблеме, бити удобан са вашим језиком одабира и структуром података може бити посао који претходно радите како бисте повећали своје шансе за јаке перформансе током интервјуа.

Списак питања, структура података и ресурса за преглед можете видети више овде: Четврти план за забијање следећег техничког интервјуа

Имајте на уму да је сваки разговор искуство учења и без обзира на исход стекли сте драгоцени увид који нисте имали пре. Остати позитивно и учити на повратним информацијама одличан је начин да се континуирано побољшава! Срећно!

Ако вам је овај водич успео да помогне на било који начин, пошаљите ми пљесак или два :), то ми заиста много значи - хвала и пуно среће на путу!