Étude de cas d'entretien téléphonique technique: Comment doubler un tableau en JavaScript

Les écrans de téléphone techniques sont une étape cruciale dans le processus d'entretien technique. Souvent, que vous passiez ou non l'écran technique du téléphone déterminera si vous serez invité à un entretien sur place.

Les écrans de téléphone techniques peuvent être difficiles car vous devez réfléchir à voix haute tout en résolvant un problème sans avoir l'avantage d'être présent en personne avec votre intervieweur. Lorsque vous interviewez quelqu'un au téléphone ou par vidéo, il peut être difficile pour toute votre présence de se manifester. Habituellement, vous travaillez dans un éditeur partagé, donc pendant que vous travaillez sur un problème, l'intervieweur ne pourra que vous entendre et voir ce que vous tapez. Beaucoup de gens trouvent plus difficile de communiquer de cette manière qu'en personne.

La bonne nouvelle est que les écrans de téléphone techniques sont quelque chose que vous pouvez pratiquer et améliorer. Comme pour toute compétence, plus vous en faites, mieux vous vous améliorerez. Finalement, vous commencerez à voir les résultats, car vous serez invité à interviewer sur place de plus en plus d'entreprises.

Bien que tous les entretiens techniques par téléphone soient différents, la plupart vous demanderont de réfléchir sur vos pieds. La meilleure façon de se préparer est donc simplement de s'exercer à travailler sur des questions. Vous pouvez les parcourir vous-même en les parlant, et vous pouvez également vous entraîner avec un ami. Si vous vous entraînez seul, vous pouvez même vous enregistrer afin de pouvoir réécouter l'enregistrement et voir si la façon dont vous avez expliqué votre processus de pensée avait du sens.

Enfin, vous pouvez vous entraîner en interviewant des entreprises! Lors de ma dernière interview pour un nouveau rôle, j'ai commencé par trouver des entreprises qui m'intéressaient, mais je ne serais pas contrarié si je ne passais pas l'écran technique du téléphone. De cette façon, je ressentais encore de la pression pour me préparer, mais je m'attendais à échouer quelques fois en premier. C'était alors moins décevant de ne pas passer à l'étape suivante.

Dans cet article, je vais parcourir une question que j'ai reçue sur un écran de téléphone technique pour vous donner un cadre pour aborder ces types d'entretiens. J'espère que cela vous sera utile et j'apprécie vos commentaires et vos commentaires!

Plongeons-nous.

La question

C'était une question réelle que j'ai reçue d'un intervieweur. J'aime cette question, car il y a plusieurs façons de la résoudre. La façon dont vous le résolvez reflète votre style de programmation et aide l'intervieweur à évaluer si vous seriez apte ou non pour le poste.

Voici l'exemple de question d'entretien:

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().

Répondre à la question

Voici mes cinq étapes pour aborder un problème lors d'un écran de téléphone technique:

1. Clarifiez la question

2. Pensez aux petits cas de test, y compris les cas extrêmes

3. Pseudo-coder votre solution (facultatif)

4. Traduire votre pseudo-code en code réel

5. Testez votre solution à l'aide des scénarios de test que vous avez créés précédemment

1. Clarifiez la question

La première chose à faire lorsqu'on vous pose une question d'entretien comme celle-ci est de poser des questions de clarification.

Dans ce cas, la question est relativement simple: je comprends que j'ai besoin d'écrire une fonction qui prend dans un tableau et renvoie un tableau qui a été manipulé. Comprendre l'entrée et la sortie d'une fonction aboutit à ce qui est souvent considéré comme une signature de fonction.

2. Pensez aux petits cas de test, y compris les cas extrêmes

Ensuite, vous voudrez penser à quelques exemples plus petits, qui vous serviront de cas de test plus tard:

// 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]

Penser à ces cas avant de commencer à coder vous aidera à rechercher et à établir des modèles pour ce que vous essayez de résoudre. Cela vous aidera également à réfléchir à la complexité de l'espace ou du temps, qui peut être une question de suivi plus tard. Cela permet également de vous assurer que vous avez suffisamment compris la question, car cela donne à votre intervieweur une chance de corriger les idées fausses.

3. Pseudo-coder votre solution (facultatif)

Maintenant que vous avez clarifié le problème et pensé à quelques exemples de cas de test, il est temps de réfléchir à la solution réelle. C'est là que le pseudo-codage peut être utile. Si vous n'êtes pas familier avec le pseudo-codage, c'est l'idée d'écrire ce que vous voulez faire en langage clair ou en syntaxe de code simplifiée avant d'écrire le code de travail. C'est un moyen de vous aider à organiser vos pensées avant de vous lancer directement dans le code.

Le pseudo-codage peut être incroyablement efficace pour vous aider à rester sur la bonne voie pendant votre entretien. J'aime personnellement le faire, car cela m'aide à rester organisé. Si jamais je suis bloqué, je peux me référer aux étapes que j'ai écrites en pseudo-code pour me remettre sur les rails.

Une fois, j'ai eu un entretien téléphonique où j'ai écrit les étapes en pseudo-code avant d'écrire le code réel. L'intervieweur a pu m'aider à me guider en indiquant l'étape de mon pseudo-code que je devais franchir ensuite. Dans ce cas, l'intervieweur a également mentionné qu'il n'avait jamais vu personne faire cela auparavant et qu'il était incroyablement impressionné. Ainsi, le pseudo-codage a également l'avantage de montrer à votre intervieweur que vous êtes organisé et de l'impressionner avec ces compétences!

Donc, pour revenir à la question posée, voici un pseudo-code que vous pourriez écrire:

// 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. Traduire votre pseudo-code en code réel

Maintenant que vous avez écrit un pseudo-code, il est temps de coder. Pour cette question, la première solution (incorrecte) que j'ai trouvée ressemblait à ceci:

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

Always remember to thank your interviewer via email preferably by the end of the same business day that you interviewed with them. Even if the company isn’t your top choice, someone took time out of their busy schedule to interview you, so it’s important to thank them. And, if you learned something new, a quick thank you email is a great way to reiterate that.

What has your experience been like with technical phone interviews? Do you love them? Do you hate them? What has been the most interesting problem that you’ve been asked to solve? Leave a comment below or let me know by emailing me at jane [at ] fullstackinterviewing [dot ] com.

Did you like this article? Are you interested in landing your dream job in software development? Sign up for my mailing list.