Hvordan man nærmer sig ethvert algoritmeinterview uden panik

Lad os være ærlige, algoritmeproblemer er stadig meget en del af jobsøgningen. Mens der er en stadigt voksende liste over virksomheder, der ikke får dig til at hoppe gennem kodende bøjler, vil den gennemsnitlige udvikler støde på en live algoritmeudfordring engang i deres jobjagt. Især hvis du vil arbejde for en Big Four eller en etableret opstart. Så gennem bøjlerne hopper vi.

Jeg behøver ikke tale om, hvor stressende tekniske interviews kan være. Jeg er sikker på, at de fleste af os kender frustrationen ved at gå ud af et interview, vi bare bombede og cyklede gennem alle de måder, vi kunne have vendt det på. Det er ikke en sjov følelse.

Derfor skriver jeg dette. For de af jer, der ender i en algoritmeudfordring, kan det, hvordan du nærmer dig det, gøre hele forskellen. Er du den type person, der dykker i første række og finder ud af det undervejs? Eller har du en proces, du følger for at nedbryde problemet i håndterbare stykker? Mens den førstnævnte metode måske virker for nogle, udøver jeg den sidstnævnte.

For mig er det afgørende at have et sæt trin, der skal bruges til at nedbryde et problem. Selvom det ikke garanterer mig en løsning eller et jobtilbud, giver det mig mulighed for at styre mit stressrespons. At holde min panik på et acceptabelt niveau hjælper mig med at fokusere. Når alt kommer til alt, skal tekniske interviews dreje sig om at demonstrere din evne til at løse problemer - ikke din evne til at håndtere flere mennesker, der dømmer dig uden lyd.

I denne artikel vil jeg vise dig den proces, jeg har finpudset gennem flere tekniske skærme og snesevis af mock-interviews. Det er stærkt påvirket af Launch Schools PEDAC-system. Jeg bruger det hver eneste gang, og det har tjent mig godt.

"Bliv forelsket i processen, og resultaterne vil komme." - Eric Thomas

Den bedste måde at vise min proces på er at demonstrere den i aktion. Så lad os arbejde igennem et problem sammen. Og for at gøre dette så autentisk som muligt, vælger jeg et problem, jeg aldrig har løst før. Selvom du bliver nødt til at tage mit ord for det.

Ifølge Leetcode er String to Integer-algoritmen et populært interviewspørgsmål. Det har også den laveste færdiggørelsesgrad for ethvert medium ranking problem. Dette burde være en god udfordring.

Jeg valgte også dette problem, da det er noget praktisk. Dette er en faktisk algoritme, der er implementeret på de fleste programmeringssprog. I modsætning til mange andre interviewudfordringer (ser på dig Coin Change), har ingeniører faktisk brugt denne algoritme i det virkelige liv.

Når det er sagt, lad os dykke ind. Følg med på det sprog, du ønsker. Jeg bruger JavaScript. Du kan prøve min tilgang eller bruge din egen. Se om du endda kan løse det, før jeg gør i slutningen af ​​dette indlæg. Du ender måske et skridt tættere på at skabe vores eget sprog.

Trin 1: Omskriv problemet med dine egne ord

For mig er dette det vigtigste skridt. Dette er min chance for at stille spørgsmål til mine interviewere for at afklare kravene og analysere alle vigtige oplysninger. Desuden giver omskrivning af problemet til mine ord mig chancen for at danne en mental model og fordøje problemet.

Til dette problem er et spørgsmål, jeg stiller, om jeg har lov til at bruge type casting. Selvom beskrivelsen ikke specificerer det, bruger jeg kun JavaScript's native type casting til at konvertere et tegn ad gangen. Det er den slags begrænsning, som jeg forventer at finde i et faktisk interview.

Efter at have læst beskrivelsen er dette de vigtigste detaljer, jeg kom på.

// Given a string, return its appropriate number value.
// Ignore all white-space at the beginning of the string.
// Number may begin with a negative or positive.
// All characters that come after the number should be ignored.
// String is invalid if a character that is not a white-space or sign comes before the number.
// If string does not contain any integer values, it is invalid.
// The return value for any invalid string is 0.
// Resulting integer cannot be larger than (2^31) — 1 or smaller than -(2^31).

Bare ud fra disse krav begynder jeg allerede at forestille mig, hvordan jeg opretter denne algoritme. Det vil sandsynligvis kræve noget looping og en hel del betinget logik.

Nogle mennesker vil sandsynligvis begynde at kode efter dette trin. For mig er det stadig lidt for tidligt at formulere konkrete planer - men mine gear drejer.

Trin 2: Input- og outputtyper

Mange mennesker vil se dette som et meningsløst skridt, men jeg sørger altid for at få input og output fra algoritmen. Enten som en kodekommentar eller i hjørnet af tavlen.

Det tjener to funktioner. For det første størkner det, hvad parametrene for min funktion vil være, og hvordan signaturen vil se ud. Leetcode oprettede allerede funktionssignaturen for mig, men dette vil ikke være tilfældet i et faktisk interview.

For det andet holder jeg en påmindelse om de typer, jeg vil arbejde med. Det er ikke uhørt for en kandidat at mislykkes i alle testsagerne, fordi de glemte at returnere en streng og ikke en matrix. Jeg taler måske eller måske ikke af erfaring ...

For vores problem er input og output pænt defineret i titlen.

Input: stringOutput: 32-bit signed integerSignature: myAtoi(str)

Trin 3: Eksempler og kanttilfælde

Nu hvor jeg er sikker på input og output, vil jeg komme med nogle testsager. Disse eksempler skal dække alle de edge cases, jeg kan tænke på. Jeg kan kun forestille mig, hvor mange gange en kandidat har skabt en fungerende løsning, kun for at få intervieweren til at komme med en edge-sag, de savnede - hvilket får deres løsning til at falde fra hinanden.

Det er muligt, at din interviewer giver nogle, men jeg ville komme med endnu mere - især hvis de ikke er udtømmende. For eksempel har Leetcode givet mig nogle anstændige testsager.

In: “4193 with words”Out: 4193
In: “words and 987”Out: 0
In: “-91283472332”Out: -2147483648

Imidlertid mangler disse eksempler nogle muligheder. Hvad hvis tallet starter med et +? Eller hvad hvis flere tegn kommer foran et nummer, såsom -+-50?

Lad os lave nogle bedre.

Input: “+50.890”Output: 50
Input: “ -+100”Output: 0
Input: “ !another invalid -10”Output: 0

Step 4: Data Structure(s)

Most, if not all, algorithm code challenges involve using a structure to keep track of your data. It’s important to consider which data structure(s) you will use as it will impact your implementation.

I know from the problem description that I will be dealing with strings and integers. But will I use another data structure to help convert from one to the other?

One issue I can already foresee is keeping track of the places of each digit (tens, hundreds, thousands, etc). Since I will not know the length of my integer beforehand, I will use an array to keep track of the integer characters. The array will serve as the interim placeholder for each character before they are converted into the final integer.

While there is most likely a more space efficient solution, I can optimize my solution later. Right now, I just want to go with what makes the most sense for me. It’s better to get a working naive solution than to shoot for the moon and not finish anything.

Step 5: Pseudocode

My penultimate step is to spend some time laying out my algorithm in pseudocode. Interviewers want to see how you think and approach problems. Pseudocode is perfect for that.

An added benefit is that the interviewer will know how to assist you ahead of time. There have been times where I’ve gotten stuck on a problem only to have my interviewer provide subtle hints to keep me going. If you jump into coding without a plan, you could end up confusing both yourself and your interviewer. Do each of you a favor and create an action plan.

This is what I came up with.

// Start with index = 0
// While character at current index is white-space // increment index
// Check if next character is invalid // return 0
// Check if next character is positive or negative sign // If negative sign, mark number as negative // increment index
// Loop through characters starting at current index // If current character is integer // Unshift into front of array // Increment index // Else, break out of loop
// Loop through string integer array // Cast string character into integer // Multiply integer by (10^index) and add to return value
// If string contained negative sign, multiply result value by -1// If result value is less than min, reassign to min// If result value is greater than max, reassign to max
// return value

It may seem like I came up with this out of nowhere, but there was a lot of deliberation and trial-and-error behind the scenes. This is the most time-consuming step because this is where the algorithm is created.

Read over the requirements, inputs/outputs, and edge cases. Ask questions, clarify concepts, and isolate areas of uncertainty to focus on. Find the simplest solution you can think of and work from there.

Will you need a depth-first search? Sliding window? Divide and conquer? Something else?

If this is the step you struggle with the most, don’t worry. It will get easier with practice. And practice you should. A thorough algorithm design in pseudocode will make the next step fast and easy.

Step 6: Code!

Finally!” You’re probably thinking. “That took forever!

Faktisk bruger jeg meget tid i planlægningstemning. Hvis en interviewer giver mig 45 minutter til at afslutte, bruger jeg 15-30 minutter på at tænke og fordøje mentalt.

"Giv mig seks timer til at hugge ned et træ, så bruger jeg de første fire på at slibe øksen." - Abraham Lincoln

Faktisk er kodning det mindst vigtige skridt for mig. Alle de tunge løft er allerede gjort. Nu skal jeg bare fortolke min mentale model til kode.

Derudover, hvordan jeg koder denne løsning i en interviewindstilling, vil ikke være den samme som hvordan jeg koder den i det virkelige liv. Heck, en rigtig interviewløsning ville se anderledes ud end det svar, jeg kom på med til denne artikel. Flere faktorer påvirker, hvordan jeg kode i et interview, såsom tid og lydhørhed hos intervieweren.

Without access to Google or sufficient time to refactor, I just want to write something that works. And there’s no guarantee I would even achieve that.

But that’s not the point of this post. Yes, it’s possible I wouldn’t have solved this question in an interview. But up until this point, I have de-structured the challenge into its key components. I know I can solve it and I have put myself in the best position to do so. A good interviewer will see that.

In a technical screen or onsite, it’s not about the code. It’s how you come up with it.

If you are interested in comparing solutions, here’s the one I came up with:

This solution is not the most efficient. According to Leetcode, it only beats 25% of the other submissions.

However, it would pass most technical interviews. An interviewer might ask me to optimize it for space or time, but those are things that can be included on further iterations if time permits. You don’t need to come up with them on the first try.

The point of using a process is to have a systemic approach to break down any challenge. It works whether you use in your job on a daily basis or in a technical interview. By using it in an interview, you can keep your panic at bay by focusing on the challenge and not your emotions.

If you don’t have a process, start making one. You can use PEDAC or develop your own. Just make sure it helps you create solutions in which you’re confident.

For eksempel har du måske bemærket brugen af ​​konstanter, hjælperfunktioner og regex i min løsning. Det er alle tricks, jeg har hentet, der hjælper mig med at isolere kompleksitet i et interview. Jo mere min kode læser som engelsk, jo mindre forvirret bliver jeg, når jeg skriver den, og jo hurtigere arbejder jeg. Det kan være lidt detaljeret, men jeg kan godt lide det. Gør hvad der virker for dig.

Hvis der allerede er en procedure, du bruger, skal du øve og perfektionere den. Vent ikke til dit onsite-interview for at starte finjustering. Eksperiment i mock interviews. Pramp og Interviewing.io er perfekte værktøjer til det.

Husk, hvis alt andet mislykkes, stol på processen.

Hvis denne artikel har genlyd hos dig, bedes du efterlade nogle klapper? !

Som altid glædelig kodning!