Teknisk telefoninterview casestudie: Sådan fordobles en matrix i JavaScript

Tekniske telefonskærme er et afgørende trin i den tekniske interviewproces. Uanset om du passerer den tekniske telefonskærm, dikterer det ofte, om du bliver inviteret til et stedssamtale.

Tekniske telefonskærme kan være hårde, fordi du skal tænke højt, mens du arbejder igennem et problem uden at have fordelen ved at være der personligt med din interviewer. Når du interviewer med nogen over telefon eller video, kan det være svært for hele din tilstedeværelse at komme igennem. Normalt arbejder du i en delt editor, så mens du arbejder igennem et problem, vil intervieweren kun være i stand til at høre dig og se, hvad du skriver. Mange mennesker har det vanskeligere at kommunikere på denne måde end personligt.

Den gode nyhed er, at tekniske telefonskærme er noget, du kan øve dig på og blive bedre til. Ligesom enhver færdighed, jo mere du gør dem, jo ​​bedre får du. Til sidst begynder du at se resultater, da du bliver inviteret til at interviewe på stedet med flere og flere virksomheder.

Selvom alle tekniske telefoninterviews er forskellige, vil de fleste kræve, at du tænker på dine fødder. Så den bedste måde at forberede sig på er simpelthen at øve sig på at arbejde igennem spørgsmål. Du kan gå igennem dem alene ved at tale dem ud, og du kan også øve med en ven. Hvis du træner alene, kan du endda optage dig selv, så du kan lytte tilbage til optagelsen og se, om hvordan du forklarede din tankeproces gav mening.

Endelig kan du øve dig ved at interviewe med virksomheder! Da jeg sidst interviewede for en ny rolle, startede jeg med at finde virksomheder, som jeg var interesseret i, men ville ikke være ked af det, hvis jeg ikke passerede den tekniske telefonskærm. På denne måde følte jeg stadig pres på at forberede mig, men jeg forventede først at mislykkes et par gange. Det var så mindre skuffende, da jeg ikke gik videre til næste fase.

I dette indlæg vil jeg gå gennem et spørgsmål, jeg har modtaget på en teknisk telefonskærm for at give dig en ramme for at nærme dig disse typer af interviews. Jeg håber, det er nyttigt, og jeg glæder mig over dine kommentarer og feedback!

Lad os dykke ind.

Spørgsmålet

Dette var et faktisk spørgsmål, som jeg modtog fra en interviewer. Jeg kan godt lide dette spørgsmål, fordi der er flere måder at løse det på. Den måde, du løser det på, afspejler din programmeringsstil og hjælper intervieweren med at måle, om du er egnet til stillingen eller ej.

Her er et spørgsmål om interviewinterview:

Given an array, write a function that doubles the array.Example: given [1,2,3,4,5], your function should return [1,2,3,4,5,1,2,3,4,5].You could call it like so: myArray.double().

Besvarelse af spørgsmålet

Her er mine fem trin til at nærme mig et problem under en teknisk telefonskærm:

1. Afklar spørgsmålet

2. Tænk på små testsager, inklusive edge cases

3. Pseudokode din løsning (valgfrit)

4. Oversæt din pseudokode til faktisk kode

5. Test din løsning ved hjælp af de testsager, du kom på tidligere

1. Afklar spørgsmålet

Den første ting du skal gøre, når du får et interviewspørgsmål som dette, er at stille afklarende spørgsmål.

I dette tilfælde er spørgsmålet relativt ligetil: Jeg forstår, at jeg skal skrive en funktion, der tager et array op og returnerer et array, der er manipuleret. Forståelse af input og udgang af en funktion resulterer i, hvad der ofte betragtes som en funktionssignatur.

2. Tænk på små testsager, inklusive edge cases

Derefter vil du tænke på nogle mindre eksempler, som senere vil tjene som dine testsager:

// What happens when the given array is empty?[] => []
// What happens when the given array has only 1 element?[1] => [1,1]
// What happens when the given array has only 2 elements?[1,2] => [1,2,1,2]
// What happens when the given array has N elements?[1...N] => [1,2,3,4,5...N,1,2,3,4,5...N]

At tænke på disse sager, før du begynder at kode, hjælper dig med at lede efter og etablere mønstre for det, du prøver at løse. Det hjælper dig også med at tænke på plads eller tidskompleksitet, som måske kan komme som et opfølgningsspørgsmål senere. Dette hjælper også med at sikre, at du har forstået spørgsmålet tilstrækkeligt, da det giver din interviewer en chance for at rette op på misforståelser.

3. Pseudokode din løsning (valgfrit)

Nu hvor du har afklaret problemet og tænkt på et par eksempler på testtilfælde, er det tid til at tænke igennem den egentlige løsning. Det er her, pseudokodning kan komme til nytte. Hvis du ikke er fortrolig med pseudokodning, er det ideen at skrive ud, hvad du vil gøre i almindeligt sprog eller forenklet kodesyntaks, før du skriver arbejdskoden ud. Det er en måde at hjælpe dig med at organisere dine tanker, før du hopper lige ind i koden.

Pseudokodning kan være utrolig effektiv med hensyn til at hjælpe dig med at holde dig på sporet under dit interview. Jeg personligt kan lide at gøre det, fordi det hjælper mig med at holde mig organiseret. Hvis jeg nogensinde sidder fast, kan jeg henvise til de trin, jeg har skrevet i pseudokode for at komme tilbage på sporet.

Jeg havde engang et telefoninterview, hvor jeg skrev trinnene i pseudokode, før jeg skrev den aktuelle kode. Intervieweren var i stand til at hjælpe mig med at pege på det trin i min pseudokode, som jeg skulle tage næste gang. I dette tilfælde nævnte intervieweren også, at han aldrig havde set nogen gøre det før og var utrolig imponeret. Så pseudokodning har også fordelen ved at vise din interviewer, at du er organiseret og imponere dem med disse færdigheder!

Så når jeg går tilbage til det aktuelle spørgsmål, her er en pseudokode, du kan skrive:

// Define a function that takes in an array// Loop over the array// Push each element from the array back into the array// Return the array

4. Oversæt din pseudokode til faktisk kode

Nu hvor du har skrevet pseudokode, er det tid til at lave kodning. For dette spørgsmål så den første (forkerte) løsning, jeg kom på, sådan ud:

var array = [1,2,3,4,5];
var double = function(array) {
 for (var i = 0; i < array.length; i++) { array.push(array[i]); }
 return array;
}
double(array);

Now, this seems pretty straightforward, right? However, there’s a small trick to this question that I only discovered by coding up my solution and trying to run it. That brings me to the final step!

5. Test your solution using the test cases you came up with earlier

If you’re an experienced programmer, you might easily spot the bug in my solution above. But it wasn’t until I ran my code that I realized I had created a dreaded infinite loop!

Why does this create an infinite loop? The array.length that I was using to know when my for loop would stop was dynamically increasing as I was pushing new elements into the array! So, when the for loop started, array.length was equal to 5. But after the first iteration of the for loop, array.length was equal to 6, and on and on ad infinitum.

However, there is a simple change that will make this solution work:

var array = [1,2,3,4,5];
var double = function(array) {
 var length = array.length;
 for (var i = 0; i < length; i++) { array.push(array[i]); }
 return array;
}
double(array);=> [1,2,3,4,5,1,2,3,4,5]

RUNTIME: O(n) = linear

With this change, I’m declaring a variable called length inside the scope of the function and then using that as the delimiter for my for loop. Even though my array size is now changing, the for loop still stops after the 5th iteration, because the length variable does not change when array.length changes.

Now I can test my code with the edge cases I came up with ealier and see that the results are as expected:

// Passing in an empty array yields an empty array correctly:[] => []
// Passing in an array with only 1 element yields the correct array with 2 elements:[1] => [1,1]
// Passing in an array with only 2 elements yields the correct array with 4 elements:[1,2] => [1,2,1,2]
// Passing in an array with 10 elements yields the correct array with 20 elements:[1,2,3,4,5,6,7,8,9,10] => [1,2,3,4,5,6,7,8,9,10,1,2,3,4,5,6,7,8,9,10]

Alternate solutions

The above is one way to solve this question, but there are a couple of other alternatives as well. Remember when I introduced the question above with the suggestion of calling the function by writing something like myArray.double()? If you’re familiar with object oriented programming, you may recognize this syntax. In this case, the general idea is that you would actually add an array method called double using the prototype chain, that you would then be able to call.

Here’s an example of how I could do that using the for loop structure from my original solution:

Array.prototype.double = function() { var length = this.length;
 for (var i = 0; i < length; i++) { this.push(this[i]); }
 return this;}
var myArray = [1,2,3,4,5];
myArray.double();=> [1,2,3,4,5,1,2,3,4,5]

By defining the function using the JavaSacript prototype chain, I don’t actually have to pass anything into it because I have access to the array that the method is being called on with this. To learn more about the this keyword, read the MDN docs.

Now, these solutions are great, but what about answering this question without using a for loop? One way is to use the built in JavaScript method forEach. This is the same idea as a for loop, but instead of us telling the program how to execute our code (imperative programming) we’re going to tell it what the result is (declarative programming). You can read more about imperative vs. declarative programming here.

Here’s an example of the same solution using forEach:

var array = [1,2,3,4,5];
var double = function(array) {
 array.forEach(function(value) { array.push(value); });
 return array;}
double(array);=> [1,2,3,4,5,1,2,3,4,5]

RUNTIME: O(n) = linear

Finally, here’s another solution to this problem, which I found with a few quick Google searches.

There is also a built in array method called concat that you can use:

var array = [1,2,3,4,5];
var double = function(array) { var doubled = array.concat(array);
 return doubled;}
double(array);=> [1,2,3,4,5,1,2,3,4,5]

RUNTIME: O(n) = linear

NOTE: If you’re wondering about Google searching during your phone screen, here’s my take after participating in more than a dozen technical phone screens: usually it’s completely acceptable.

Technical phone screens are often scheduled for 45 mins to 1 hour. Some of that time is reserved for the interviewer to ask questions about your experience, while some is also reserved for you to ask questions. The time you spend coding can be anywhere from 30–45 mins based on the company and interviewer.

In many cases, your interviewer will be able to help you with quick tips and small hints if you have a general idea about how to do something but need to look up the specifics. For example, I once had an interviewer who knew the regex I needed off the top of their head to perform a specific function, so I didn’t need to spend time figuring it out. This allowed the interview to continue more seamlessly.

However, I’ve also had experiences where an interviewer has asked me to refactor my original solution in a different way and explicitly said it was fine to look up documentation. This is usually the case, because many developers spend time daily reading or referencing docs. Being able to follow that same pattern in a technical phone interview is a good sign.

However, Googling for a solution during your interview can also be a time sink, especially if you’re not searching with just the right phrase (this is where the more you search, the better you will become).

For this specific example, if I had already known about JavaScript’s concat method, it might have come to mind when I was confronted with this problem. Then, Googling to remind myself of how concat worked would have been acceptable.

But if I had instead spent time Googling how to double an array before even trying to think through the problem myself, this might have been a red flag for the interviewer. Technical phone screens are a good way for an interviewer to get a sense of how you think, and it really depends what they are looking for in terms of the position they’re hiring for.

On the other hand, some companies will explicitly tell you that you’re not allowed to use Google for help, so in those cases, it’s best not to. Of course, if you’re unsure at all, ask your interviewer.

Conclusion

Why am I showing you all of these examples? As you can see, there is not just one single way to approach this problem. There are several approaches you can take, and how you approach the problem all depends on a combination of what your background is and how you think about problem solving. For me, I often gravitate toward loops since for loops were one of the original programming concepts I learned. But someone who’s used concat before might think of that right off the bat.

I thought this problem was a good example, because it seems relatively simple at first. However, there are ways to get tripped up (as you saw with my infinite loop above), and there are several solutions that demonstrate various levels of specific knowledge. Still, you could also solve this with a solid idea written in pseudo-code and some Googling.

Keep in mind that you won’t always pass technical phone interviews, but the more you do them, the better you will get. And, if you learned something from the interview, even if it was something small, it was probably worth your time.

One final tip

Husk altid at takke din interviewer via e-mail helst inden udgangen af ​​den samme arbejdsdag, som du interviewede med dem. Selvom virksomheden ikke er dit bedste valg, tog nogen tid ud af deres travle tidsplan for at interviewe dig, så det er vigtigt at takke dem. Og hvis du lærte noget nyt, er en hurtig tak-e-mail en fantastisk måde at gentage det på.

Hvordan har din oplevelse været med tekniske telefoninterviews? Elsker du dem? Hader du dem? Hvad har været det mest interessante problem, som du er blevet bedt om at løse? Efterlad en kommentar nedenfor eller lad mig vide ved at sende en e-mail til mig på jane [at] fullstackinterviewing [dot] com.

Kunne du lide denne artikel? Er du interesseret i at lande dit drømmejob inden for softwareudvikling? Tilmeld dig min mailingliste.