راهنمای استخدام برنامه نویس اندروید!!!

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

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

استخدام برنامه نویس اندروید

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

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

مصاحبه‌ها سخت هستند، برای هر دو طرف میز

داوطلب مصاحبه بودن موقعیت اعصاب خوردکنی است. هم می‌تواند تهدیدآمیز باشد و هم در موارد خاص تحقیرآمیز. خیلی ساده است که یک بیماری خاص داشته باشی و در طول مصاحبه نسبت به زمانی که در مصاحبه نیستی ضعیف‌تر عمل کنی. من یک بار فراموش کردم نقشه‌ها (google maps) چه هستند.

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

مصاحبه‌ها باید گفتگو باشند

از شیوه‌ای که برخی مردم مصاحبه میکنند اعصابم خورد میشود.

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

البته این مثال خیلی مبالغه‌آمیز بود، مطمئن هستم که حتی مصاحبه‌های نوشتاری به داوطلب اجازه خواهند داد (مسلما در آخر) تا هر سوالی داشته باشد بپرسد. اما باز هم چه فایده؟ قطعا این روشی نیست که شما در تیم خود گفتگو میکنید. اگر میخواهید برآورد کنید که کار کردن با این فرد چگونه خواهد بود، آیا نباید مصاحبه کمی نزدیک به آن شرایط باشد؟

من دوست دارم مصاحبه مانند یک گفتگوی واقعی باشد. درست است، یک نفر تلاش می‌کند تا طرف دیگر به او کار دهد، اما به این معنی نیست که نمی‌تواند یک گپ دوستانه باشد. اگر شما با کسی مصاحبه می‌کنید، شانس بالایی وجود دارد در صورتی که قبول شود با آن فرد به طور نزدیک کار کنید. این به معنی نشستن کنار آنها ۸ ساعت یا بیشتر در روز، ۵ روز در هفته، برای همیشه است. یا ممکن است که دائما با کدهای همدیگر سروکار داشته باشید. یا هر چیز دیگری. شما باید بتوانید با آنها آزادانه و راحت گفتگو کنید.

چگونه گفتگو کنیم

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

زمانی که آماده شدیم، من از سوالات برای باز کردن یک بحث یا سوالاتی در ادامه برای روشن کردن جزئیات استفاده میکنم. سوالات بسته با جوابهای صحیح و غلط معمولا کمتر مفید هستند.

شروع‌کننده‌ها: مقدمات اندروید

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

  • آیا می‌توانی چرخه حیات Activity را توضیح دهی؟
  • آیا می‌توانی تفاوت بین Sevice و ContentProvider را شرح دهی؟
  • چگونه در اپلیکیشن اندروید اطلاعات را ذخیره میکنی؟
  • چگونه یک فرآیند طولانی را در اندروید اجرا میکنی؟
  • چگونه بین دو Fragment ارتباط برقرار میکنی؟

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

ابزارها و تکنولوژی‌ها

همیشه فکر خوبی است که بدانید افراد از چه ابزارها و تکنولوژی‌هایی برای انجام کارهایشان استفاده می‌کنند. اگر آنها هنوز از Eclipse استفاده می‌کنند، یا vim یا چیز دیگری به جای Git، من میخواهم بدانم چرا. اکثر افراد پاسخ خواهند داد Android Studio و Git. این عالی است، اما پیدا کردن افراد خارج از محدوده هم خوب است.

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

 

– شبکه

OkHttp و Retrofit این روزها بسیار متداول هستند. Volley هر از چند گاهی بالا می‌آید و من همیشه کنجکاو هستم بدانم دلیل علاقه فرد به آن چیست. من هنوز راجع به Spring RestTemplate کابوس می‌بینم.

 

JSON serialisation/deserialisation –

این روزها اکثر افراد از Gson استفاده میکنند، اگرچه Moshi هم در حال رشد است. من Moshi را موضوع خوبی برای بحث میبینم، از آنجایی که برتری‌های آن نسبت به Gson در وحله اول دیده نمی‌شود، مگر اینکه کسی آن را بررسی کند. من نمیتوانم بگویم کدام یک برایم بیشتر به منظور چراغ قرمز است، استفاده از Jackson یا دستی انجام دادن آن. تعداد توابع Jackson قطعا دیوانه‌کننده است، و نوشتن کلاس دستیار Json شخصی هم کاری بسیار زمان‌بر، شکننده و غیرضروری مطلق است.

 

– مدیریت سورس کد

همانطور که بالا اشاره کردم، برایم بسیار عجیب خواهد بود که کسی امروزه و در این دوره از Git استفاده نمی‌کند (یا استفاده نکرده است). گذشته از این من کنجکاوم بدانم مردم چگونه از Git استفاده می‌کنند، هم از جنبه فرآیندی و هم از جنبه ابزاری. آیا آنها از قابلیت branching استفاده می‌کنند؟ آیا از pull request استفاده می‌کنند؟ آیا شاخه develop و master دارند یا فقط master؟ من شخصا، به طور معمول هم از ترمینال و هم از ابزار اندروید استودیو Git برای انجام کارهای خودم استفاده میکنم (ساختن/تعویض شاخه، commit کردن، rebase کردن، ترکیب و …) و گاهی از SourceTree برای نمایش تصویری استفاده میکنم. اما وقتی چیزها به هم میریزد و من به حالت تضاد گیج‌کننده‌ای میرسم که باید حل شود، تمام رابطهای کاربری گرافیکی را کنار میگذارم و به سراغ منبع نهایی حقیقت میروم، یعنی ترمینال. برخی افراد هیچ وقت از Git با command line استفاده نکرده‌اند. من بحث در این مورد را مفید میدانم.

 

Dependency injection –

با آمدن Dagger (۱ و ۲)، در برنامه‌های اندروید dependency injection بسیار متداول‌تر شده است. و هرکس که از آن استفاده کرده باشد می‌تواند بگوید که فوق‌العاده است. اما دانستن این مهم است که dependency injection چیست، چگونه پیاده‌سازی میشود، و اصلا چرا ما میخواهیم این کار را بکنیم. چه چیزی Dagger 2 را بهتر از Dagger 1 کرده است؟ آیا راهکارهای دیگری برای dependency injection در اندروید وجود دارد؟ چه چیزهای خوب یا بدی درباره آنها وجود دارد؟

 

RxJava –

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

 

Kotlin –

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

 

– کتابخانه‌های Support اندروید

بخشی از راهکار جزئی گوگل برای نسخه‌های قدیمی؛ کتابخانه‌های support و design support که بسیار رواج پیدا کرده‌اند. ظهور متریال دیزاین فقط این را سریع‌تر کرد. اما آنها با خود مشکلاتی هم به همراه می‌آورند. اینها ارزش بحث دارد. همچنین خوب است راجع به بخش‌های کمتر متداول یا جدیدتر سوال کنیم. در حال حاضر ConstraintLayout یکی از چیزهایی است که خواهم پرسید. همچنین VectorDrawable.

 

Google Play Services –

من اخیرا با GoogleApiClient و برخی از Api های Google Play Services مشکل پیدا کرده‌ام. آنها از برخی جهات برای استفاده ناشیانه هستند، اما وقتی به درستی استفاده شوند قدرت بسیار زیادی برای برنامه شما ایجاد می‌کنند. من دوست دارم از تجربیات داوطلب در مورد Google Play Services بدانم.

 

تست کردن

من تست کردن را به عنوان یک مبحث مجزا در لیست موضوعات مدنظر قرار می‌دهم. تست کردن اهمیت دارد. اوایل، تست کردن در اندروید بسیار ضعیف بود، اما با جست و خیزهایی در سالهای اخیر توسط تستهای JVM JUnit و Espresso و کتابخانه support تست اندروید، ممکن شده است. صحبت در مورد تست کردن، به طور طبیعی صحبت درباره معماری اپلیکیشن را در پی خواهد داشت. یک اپلیکیشن قابل تست نیست مگر اینکه قابل تست نوشته شده باشد. پس این مبحث با dependency injection که بالا بحث شد هم‌پوشانی خواهد داشت، اما همچنین پتانسیل این را دارد که MVP را با برداشت‌های متفاوت MVVM و هر استراتژی دیگری که افراد ممکن است برای ساختار کدهای برنامه‌شان استفاده کنند را به وسط بیاوریم.

برای داوطلبان بالاتر از سطح کارآموز یا برنامه‌نویس تازه‌کار، میخواهم بشنوم که آنها تجربه این کارها را دارند:

  • Unit testing
  • Instrumentation testing
  • UI testing with Espresso

و میخواهم بشنوم نظر آنها در مورد تمام این چیزها چیست.

پروژه‌های رزومه و خاطرات جنگ

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

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

برخی چیزها در رزومه قرار نمیگیرند اما میتوانند بسیار مرتبط باشند. پروژه مورد علاقه‌ات یا بهترین پروژه‌ای که بر روی آن کار کرده‌ای چیست؟ چرا؟

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

علایق شخصی در اندروید یا تکنولوژی

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

من تلاش میکنم یک سوال براساس داوطلب و تجربه‌های او (یا علایق او) از جنبه‌های وسیع‌تر دنیای اندروید یا تکنولوژی مطرح کنم، ترجیحا چیزی جدید. آیا ساعت روی مچ دستت Moto 360 است؟ در کنفرانس Droidcon هفته گذشته کجا بودی؟ آیا دیروز گوگل I/O را تماشا کردی؟ تمام این سوالات می‌توانند یک مبحث جدید برای مکالمه بیشتر باز کنند. من شخصا میخواهم بشنوم که داوطلب جذب چیزی در گوگل I/O شده است. آنها باید حداقل یک نظر راجع به یکی از اعلان‌ها داشته باشند، و چیزی که کنجکاو باشند راجع به آن بیشتر بدانند.

چگونه خودت را با اخبار اندروید به روز نگه میداری؟ من همیشه این را در پایان میپرسم و مطمئن نیستم به خاطر خودم است یا آنها. هر وبلاگ، سایت یا پادکست خاصی، من به سختی می‌توانم تمام آنها را دنبال کنم، اما همیشه کنجکاوم بدانم بقیه مردم از چه چیزی استفاده میکنند.

پایان

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

 

لطفا نظرات خودتون رو در کامنت مطرح کنید.

 

منبع

https://android.jlelse.eu/interviewing-android-developers-435ce69b06fa

 

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

حجت ریحانه

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

4 ديدگاه بر “راهنمای استخدام برنامه نویس اندروید!!!

  1. خیلی عالی بود
    به نظرم میرسه یه کمی روش کار میکردین و کاربردی ترش می کردین خیلی بهتر می شد
    مثلا سطح بندی می کردین
    و یا اینکه الزامات اولیه رو می نوشتین که این مصاحبه برای این گروها باید باشه
    ولی بازم خیلی عالی بود
    سپاس

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *