دراسة حالة مقابلة هاتفية تقنية: كيفية مضاعفة مصفوفة في JavaScript

تعد شاشات الهاتف الفنية خطوة حاسمة في عملية المقابلة الفنية. في كثير من الأحيان ، ما إذا كنت ستجتاز شاشة الهاتف الفنية أم لا ، فسوف تملي ما إذا كنت ستتم دعوتك لإجراء مقابلة في الموقع.

يمكن أن تكون شاشات الهاتف الفنية صعبة لأنك يجب أن تفكر بصوت عالٍ أثناء العمل على حل مشكلة ما دون الاستفادة من التواجد شخصيًا مع القائم بإجراء المقابلة. عندما تجري مقابلة مع شخص ما عبر الهاتف أو الفيديو ، قد يكون من الصعب على حضورك بالكامل أن يتحقق. عادة ، ستعمل في محرر مشترك ، لذلك أثناء عملك على حل مشكلة ، سيتمكن القائم بإجراء المقابلة فقط من سماعك ورؤية ما تكتبه. يجد الكثير من الناس صعوبة في التواصل بهذه الطريقة أكثر من التواصل الشخصي.

الخبر السار هو أن شاشات الهاتف الفنية هي شيء يمكنك التدرب عليه وتحسينه. تمامًا مثل أي مهارة ، كلما قمت بها أكثر ، كلما تحسنت. في النهاية ستبدأ في رؤية النتائج ، حيث ستتم دعوتك لإجراء مقابلة في الموقع مع المزيد والمزيد من الشركات.

على الرغم من اختلاف جميع المقابلات الهاتفية التقنية ، إلا أن معظمها يتطلب منك التفكير مليًا. لذا فإن أفضل طريقة للتحضير هي ببساطة التدرب على حل الأسئلة. يمكنك أن تمشي من خلالها بمفردك عن طريق التحدث معهم ، ويمكنك أيضًا التدرب مع صديق. إذا كنت تتدرب بمفردك ، فيمكنك حتى تسجيل نفسك حتى تتمكن من الاستماع مرة أخرى إلى التسجيل ومعرفة ما إذا كانت طريقة شرحك لعملية التفكير منطقية.

أخيرًا ، يمكنك التدرب من خلال إجراء مقابلات مع الشركات! عندما أجريت آخر مقابلة لي لوظيفة جديدة ، بدأت بالبحث عن الشركات التي كنت مهتمًا بها ، لكنني لن أشعر بالانزعاج إذا لم أتجاوز شاشة الهاتف الفنية. بهذه الطريقة ، ما زلت أشعر بالضغط للاستعداد ، لكنني توقعت أن أفشل عدة مرات في البداية. ثم كان الأمر أقل إحباطا عندما لم أنتقل إلى المرحلة التالية.

في هذا المنشور ، سوف أتناول سؤالاً تلقيته في شاشة هاتف تقنية لإعطائك إطار عمل للتعامل مع هذه الأنواع من المقابلات. آمل أن يكون هذا مفيدًا ، وأرحب بتعليقاتكم وتعليقاتكم!

دعنا نتعمق.

السؤال

كان هذا سؤالًا حقيقيًا تلقيته من المحاور. يعجبني هذا السؤال لأن هناك عدة طرق لحلها. الطريقة التي تحلها تعكس أسلوبك في البرمجة وتساعد القائم بإجراء المقابلة على قياس ما إذا كنت مناسبًا لهذا المنصب أم لا.

إليك نموذج سؤال المقابلة:

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

الإجابة على السؤال

فيما يلي خطواتي الخمس للتعامل مع مشكلة أثناء شاشة الهاتف الفنية:

1. توضيح السؤال

2. فكر في حالات الاختبار الصغيرة ، بما في ذلك حالات الحافة

3. كود زائف للحل الخاص بك (اختياري)

4. ترجم الكود الزائف الخاص بك إلى كود فعلي

5. اختبر الحل باستخدام حالات الاختبار التي توصلت إليها سابقًا

1. توضيح السؤال

أول شيء يجب عليك فعله عند طرح سؤال مقابلة كهذا هو طرح أسئلة توضيحية.

في هذه الحالة ، يكون السؤال مباشرًا نسبيًا: أفهم أنني بحاجة إلى كتابة دالة تأخذ مصفوفة وتعيد مصفوفة تم التلاعب بها. يؤدي فهم مدخلات ومخرجات الدالة إلى ما يُعتبر غالبًا توقيعًا للوظيفة.

2. فكر في حالات الاختبار الصغيرة ، بما في ذلك حالات الحافة

بعد ذلك ، سترغب في التفكير في بعض الأمثلة الأصغر ، والتي ستكون بمثابة حالات اختبارية لاحقًا:

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

سيساعدك التفكير في هذه الحالات قبل البدء في الترميز في البحث عن وإنشاء أنماط لما تحاول حله. سيساعدك أيضًا على التفكير في تعقيد المكان أو الوقت ، والذي قد يأتي كسؤال متابعة لاحقًا. يساعد هذا أيضًا في التأكد من أنك فهمت السؤال بشكل كافٍ ، لأنه يمنح القائم بإجراء المقابلة فرصة لتصحيح أي مفاهيم خاطئة.

3. كود زائف للحل الخاص بك (اختياري)

الآن بعد أن أوضحت المشكلة وفكرت في بعض حالات الاختبار النموذجية ، فقد حان الوقت للتفكير في الحل الفعلي. هذا هو المكان الذي يمكن أن يكون فيه الترميز الزائف مفيدًا. إذا لم تكن معتادًا على الترميز الزائف ، فهذه هي فكرة كتابة ما تريد القيام به بلغة بسيطة أو بناء جملة كود مبسط قبل كتابة كود العمل. إنها طريقة لمساعدتك على تنظيم أفكارك قبل القفز مباشرة إلى الكود.

يمكن أن يكون الترميز الزائف فعالًا بشكل لا يصدق من حيث مساعدتك على البقاء على المسار الصحيح أثناء المقابلة. أنا شخصياً أحب أن أفعل ذلك ، لأنه يساعدني على البقاء منظمًا. إذا علقت يومًا ما ، يمكنني الرجوع إلى الخطوات التي كتبتها في رمز زائف للعودة إلى المسار الصحيح.

لقد أجريت مقابلة هاتفية ذات مرة حيث كتبت الخطوات في رمز زائف قبل كتابة الكود الفعلي. كان القائم بإجراء المقابلة قادراً على المساعدة في إرشادي من خلال الإشارة إلى الخطوة الموجودة في الكود الزائف الذي أحتاج إلى اتخاذه بعد ذلك. في هذه الحالة ، ذكر المحاور أيضًا أنه لم ير أي شخص يفعل ذلك من قبل ، وكان معجبًا بشكل لا يصدق. لذلك ، فإن الترميز الزائف له أيضًا ميزة إظهار المحاور الخاص بك أنك منظم وإثارة إعجابهم بهذه المهارات!

لذا ، بالعودة إلى السؤال المطروح ، إليك بعض الرموز الزائفة التي يمكنك كتابتها:

// 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. ترجم الكود الزائف الخاص بك إلى كود فعلي

الآن بعد أن كتبت رمزًا زائفًا ، حان الوقت للقيام ببعض الترميز. بالنسبة لهذا السؤال ، بدا الحل الأول (غير الصحيح) الذي توصلت إليه كما يلي:

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);

الآن ، هذا يبدو واضحًا جدًا ، أليس كذلك؟ ومع ذلك ، هناك خدعة صغيرة لهذا السؤال اكتشفتها فقط من خلال ترميز الحل ومحاولة تشغيله. هذا يقودني إلى الخطوة الأخيرة!

5. اختبر الحل باستخدام حالات الاختبار التي توصلت إليها سابقًا

إذا كنت مبرمجًا متمرسًا ، فيمكنك بسهولة اكتشاف الخطأ في الحل أعلاه. لكن لم أدرك أنني قد أنشأت حلقة لا نهائية مخيفة حتى قمت بتشغيل الكود الخاص بي!

لماذا هذا يخلق حلقة لا نهائية؟ إن array.lengthما كنت أستخدمه لمعرفة متى forستتوقف الحلقة الخاصة بي كان يتزايد ديناميكيًا حيث كنت أقوم بدفع عناصر جديدة إلى المصفوفة! لذلك ، عندما forبدأت الحلقة ، array.lengthكانت تساوي 5. ولكن بعد التكرار الأول forللحلقة ، array.lengthكانت تساوي 6 ، وعلى وعلى إلى ما لا نهاية.

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

تذكر دائمًا أن تشكر القائم بإجراء المقابلة عبر البريد الإلكتروني ويفضل أن يكون ذلك بنهاية يوم العمل نفسه الذي أجريت معه المقابلة. حتى لو لم تكن الشركة هي خيارك الأفضل ، فقد استغنى شخص ما عن جدول أعماله المزدحم لإجراء مقابلة معك ، لذلك من المهم أن تشكره. وإذا تعلمت شيئًا جديدًا ، فإن رسالة شكر سريعة عبر البريد الإلكتروني هي طريقة رائعة لتكرار ذلك.

كيف كانت تجربتك مع المقابلات الهاتفية التقنية؟ هل تحبهم؟ هل تكرههم؟ ما هي المشكلة الأكثر إثارة للاهتمام التي طُلب منك حلها؟ اترك تعليقًا أدناه أو أخبرني عن طريق مراسلتي عبر البريد الإلكتروني على jane [at] fullstackinterviewing [نقطة] com.

هل أعجبك هذا المقال؟ هل أنت مهتم بالحصول على وظيفة أحلامك في تطوير البرمجيات؟ الاشتراك في قائمتي البريدية.