استخدام بدون آزمون های الگوریتم – انجمن DEV

مشکل

من به شدت از مصاحبه های تکنیکی الگوریتمی بیزارم. من ارتباط آنها را در شرکت های بزرگ به عنوان یک آزمون اساسی برای ارزیابی توانایی های مهندسان درک می کنم. با این حال، در Plank، ما یک تیم فشرده متشکل از 13 توسعه‌دهنده هستیم و سؤالات سبک الگوریتمی با آنچه ما به دنبال آن هستیم همخوانی ندارند. ما به دنبال توسعه دهندگانی با مهارت های ملموس هستیم که می توانند برای مشتریان ما ارزش به ارمغان بیاورند. از آنجایی که هر یک از توسعه دهندگان ما در نهایت رهبری و معماری پروژه را بر عهده می گیرند، ما به توانایی های انتزاعی نیاز داریم که فراتر از حل ساده مسائل باشد.

همانطور که یک یا دو توسعه دهنده جدید را در سال استخدام می کنیم، ترجیح می دهیم ارزیابی های فنی خود را بازتر نگه داریم. با این حال، برای آخرین استخداممان، به رویکردی برخورد کردم که معتقدم ارزش دارد و می‌تواند به روشی جالب برای استخدام‌های آینده تبدیل شود.

راه حل

تصمیم گرفتم معاینه فنی را پس از یک مشکل واقعی که یک توسعه دهنده ممکن است با آن مواجه شود مدل کنم – هیچ چیز انقلابی در آنجا نیست. اساساً، من از نامزد می‌خواهم که یک نسخه فوق‌العاده ساده‌شده از پروژه‌ای را که قبلاً ارسال کرده‌ایم، مانند دایره‌المعارف کانادا، پیاده‌سازی کند (مطالعه موردی ما را در اینجا بررسی کنید). از آنجایی که انجام تمام این کارها به تنهایی بسیار طاقت فرسا خواهد بود، ما با نامزدها همکاری می کنیم تا یک نمونه اولیه را با هم بسازیم.

می‌شنوم که فریاد می‌زنی، “اما ماسیمو، چطور می‌توانی این همه کار را برای این همه نامزد مختلف تحمل کنی؟!” خوب، دوست من، پاسخ کاملا واضح است – من آن را خودکار کردم!

روش ما شامل ایجاد مخزن با نصب جدید لاراول و افزودن من به عنوان یک همکار از نامزد است. هنگامی که این کار انجام شد، اسکریپتی را شروع می کنم که سه موضوع را باز می کند که ویژگی هایی را که باید اضافه شوند را توصیف می کند. سپس، دو شعبه جدید را با کد برای حل دو مورد از سه مشکل متعهد می‌کند و دو درخواست کشش (PR) را برای آن شاخه‌ها باز می‌کند و ویژگی‌های اضافه شده را به درجات مختلف توضیح می‌دهد. در نهایت، این وظیفه کاندیدا است که دو PR را بررسی کند و همانطور که در صورت استخدام انجام می‌شد، نظرات خود را ارائه کند. سپس برای موضوع نهایی یک روابط عمومی باز می کنند.

من تلاش کرده ام تا تجربه کار در پلانک را به ثبت برسانم تا نامزدها بتوانند طعم آن را بچشند و در عین حال به آنها فرصت های زیادی برای درخشش به طرق مختلف بدهم.

پس اتوماسیون چطور؟

آه، اتوماسیون! همانطور که قبلاً ذکر کردم، آن را برای اولین تکرار ساده نگه داشتم. من یک اسکریپت bash ایجاد کردم که پروژه کاندید را شبیه‌سازی می‌کند، از Git برای commit کردن فایل‌ها و ایجاد شاخه‌ها استفاده می‌کند، و از ابزار GH CLI برای ایجاد PRها (از جمله موارد دیگر) استفاده می‌کند. من نام این فیلمنامه را “Autodev” گذاشتم. شاید زیاد نباشد، اما من کاملاً دوست داشتم از آن استفاده کنم. حال، بیایید نگاهی دقیق‌تر به آنچه انجام می‌دهد بیاندازیم.

اسکریپت

اول از همه، ما باید مخزن را بگیریم و مسائل را ایجاد کنیم:

#!/bin/zsh

echo "Enter the target repository name (e.g., plank/repo-name):"
# shellcheck disable=SC2162
read repo

# Grab the repo
cd target || exit
git clone "git@github.com:$repo.git" project
cd project || exit

# Create issues to be solved.
gh issue create --title "Users need to be able to view or create articles" --body-file ../../issue_1.md  --assignee "@me"
gh issue create --title "Users need to take and create quizzes" --body-file ../../issue_2.md --assignee "@me"
gh issue create --title "Users need to be able to browse event timelines" --body-file ../../issue_3.md

همانطور که می بینید، من از “فایل های بدن” برای ذخیره جزئیات روابط عمومی استفاده کردم. من می‌خواستم تا جایی که ممکن است چیزهای زیادی را خارج از فیلمنامه نگه دارم و در صورت نیاز در آینده بتوانم آن را به راحتی تغییر دهم. با این حال، هر چه بیشتر در مورد آن فکر می کنم، بیشتر تمایل دارم که این ابزار را به یک ابزار وب کامل یا ابزار CLI تبدیل کنم. اما این یک برنامه برای آینده است. در مرحله بعد، ما نیاز به ایجاد دو PR داشتیم، بنابراین من دو بلوک به شکل زیر اضافه کردم:

# ---- PR #1 ----

# Check out a new branch & set upstream
git checkout -b 1-article-feature
git push --set-upstream origin 1-article-feature

# Commit each feature one by one
## Copy everything into the target folder (the dir we're in), except the routes folder
rsync -av ../../pr_1/* ./

git add app/Models database
git commit -m 'feat: add definition of articles model, migration, and factory'

git add app/Http
git commit -m 'feat: add controller functions for interacting with articles'

cat ./routes/routes.stub >> ./routes/web.php
rm -rf ./routes/routes.stub
git add routes
git commit -m 'feat: register controller routes with RESTful methods'

# Push changes
git push

# Create PR
gh pr create --title "Add Article CRUD feature" --body-file ../../pr_1_body.md

git checkout main

در این بلوک کد، من ساختار فایل فایل های تغییر یافته خود را در پوشه ای به نام نگه می دارم pr_(1,2,...n). من به سادگی فایل ها را در پروژه هدف کپی می کنم و برخی از commit های atomic-ish را اضافه می کنم. در حالت ایده‌آل، من راهی برای فهرست کردن این commit‌ها به صورت خارجی، شاید در یک فایل JSON، و تکرار روی آنها دارم. این امر از نیاز به به روز رسانی اسکریپت در آینده جلوگیری می کند. با پیروی از همان رویه ایجاد مسائل، از یک فایل بدنه برای هر روابط عمومی استفاده می کنم.

در نهایت با موارد زیر پاک می کنیم:

# Delete target repo folder
cd ../
rm -rf project

و آن را یک روز بنامیم!

نتایج

من دروغ نخواهم گفت، از اینکه این رویکرد چقدر خوب کار کرد شوکه شدم. فیلمنامه هرگز برای من شکست نخورد، حتی با وجود تغییراتی که نامزدها می توانستند انجام دهند. این جرقه‌ی بحث‌های معنادار زیادی با نامزدها شد و امیدوارم چالش لذت‌بخشی برای آنها فراهم آورد.

در طول مصاحبه، نظرات آنها و اینکه چگونه آنها می توانند برنامه نویس جفت خود را برای بهبود خطی که روی آن نظر گذاشته اند، راهنمایی کنند، بحث می کنیم. همچنین ویژگی پیاده‌سازی شده آن‌ها را بررسی می‌کنیم و کارهایی را که احساس می‌کنند به خوبی انجام داده‌اند و زمینه‌هایی که نیاز به بهبود دارند برجسته می‌کنیم. برای افزودن یک لایه دیگر، از نامزدها خواستم تا به من کمک کنند تا مشکلی را که در هنگام آزمایش ویژگی آنها با آن مواجه بودم، اشکال زدایی کنم، زیرا من واقعاً معتقدم که اشکال زدایی بخشی ضروری از فرآیند مصاحبه است.

چیزی که در مورد استخدام آموخته ام این است که تنها یک راه “درست” برای نزدیک شدن به آن وجود ندارد. این یک فرآیند ذاتی انسانی است و به همان اندازه که از تلاش (و شکست) برای رفع خودکار مشکلاتم لذت می برم، ایجاد تعادل بسیار مهم است. من معتقدم این رویکرد با کاهش کار ارزیابی بیش از حد و در عین حال حفظ ارتباط شخصی، به آن تعادل دست می یابد.

ما به قدرت ارتباط انسانی و بهبود مستمر اعتقاد داریم. همانطور که فرآیند استخدام خود را تکامل می‌دهیم، متعهد به ایجاد محیطی هستیم که هم ارزیابان و هم کاندیداها بتوانند شکوفا شوند. به اشتراک گذاشتن تجربیات و بینش ما برای بهبود جمعی چشم انداز استخدام برای همه افراد درگیر ضروری است.

ما به همه کسانی که این مطلب را می خوانند تشویق می کنیم که فرآیند استخدام خود را نیز به اشتراک بگذارند. به نفع ماست که آنچه را که برای بهبود فرآیند یاد گرفته ایم، هم برای ارزیابان و هم برای داوطلبان به اشتراک بگذاریم.