با توجه به این خبر یا این خبر مرکز پژوهش های مجلس اعلام کرد که در خوشبینانه ترین حالت ساعات کار مفید در ایران در هر روز تا 2 ساعت است که میزان هفتگی آن به بیشتر از 11 ساعت نمی رسد. البته برخی آمارهای دیگر نیز این میزان را 6 تا 7 ساعت در هفته برآورد کرده است ، که این از بسیاری از کشورها پایین تر می باشد .با این حال میزان ساعات کار مفید هفتگی در ژاپن 40 تا 60 ساعت و در کره جنوبی نیز 54 تا 72 ساعت برآورد می شود.

متاسفانه آمارهای ارائه شده در مورد میزان ساعات کار مفید کارکنان شاغل در بخش دولتی کشور به هیچ وجه قابل قبول نیست چرا که برآورد شده است متوسط ساعت کار مفید افراد در بخش دولتی در طول یک روز فقط 22 دقیقه است...

نگاهی هم به این جدول بیندازید: 

جدول وضعیت ساعات کار مفید در 11 کشور جهان

حال سوالی که مطرح است برای بسیاری از مشاغل (کارمندان شعب بانک ها ، پرستاران و ...) این ساعت کار مفید روزانه بسیار بیشتر از متوسط آمارهاست ، آیا عده ای هستند که اصلا کار نمی کنند؟

با نگاهی به آمار حسرت بر انگیز  ژاپن و  کره جنوبی این سوال مطرح می گردد که آیا ژن ما موردی دارد!؟ ، یا باید فرهنگ کار و میهن پرستی اصلاح گردد؟

-----------------------

پ.ن : در بدترین حالت روحی کار مفید متوسط خودم از نیمی از زمان کاری فکر نکنم کمتر شود که با زمان اضافه کاری بر آن زمان بهبود می یابد ، حال نمی دانم این آمار ها چگونه تهیه می گردند!؟

منبع خبر : خبرگزاری مهر

قبلا در مورد عادت های بد برنامه نویسی و کارمندی در اینجا ، اینجا و اینجا نوشته بودم ،آن زمان از خودمان انتقاد کردیم ، اکنون زمان آن رسیده رفتار هایی از مدیران پروژه ها و مدیران و مشتریان نرم افزاری را با نگاهی انتقادی مورد بررسی قرار دهیم ، من خود نیز باز در این دایره قرار می گیرم که تجربه مدیریت پروژه را نیز داشته ام و جدای از این نوشته از گذشته خود انتقادات بسیاری در این امر دارم! در بالا وقتی نوشتم "مشتریان"، این جور نبوده که ذهنم مشروط عمل کرده باشد و در متن بی دلیل این کلمه بیاید ، دقیقا مشتریان در ذهنیت برخی مدیران و در شرکتهایی که مشتریان خاصی دارند در قلب مدیران جای دارند ، اصولا در برخی از مدل های کاری شرکت ها این مشتریان هستند که تمام قواعد شرکت را می سازند و این می شود که رفتار های آنان در خط به خط کد نویسی شما متجلی می گردد.

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

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

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

از اینها که بگذریم همواره دست و دل برنامه نویس برای تغییر کوچکترین الگوریتمی در برنامه های موروثی خواهد لرزید و چون مسئول ایجاد باگ جدید خود او خواهد بود نه مدیرانی که با بی درایتی یا کم تجربگی یا دلایل دیگری مستندات برای این برنامه نویس به جا نگذاشته اند ، کد باد کرده و بی دلیل بزرگ و پیچیده می گردد ، به مرور با کد هایی برخورد خواهید کرد که تماما یک کار می کنند  و هیچ کس هم نمی داند یعنی نمی تواند) به طور قطع بگوید که این تابع را حذف کن و از این یکی استفاده کن. این می شود که روز به روز کد های ناخوانا شده ونگهداری دشوار و دشوارتر وتهیه مستندات ناممکن! دوست برنامه نویسی می گفت در تکه کدی کد می زنم که 5-6 نفر بر روی آن کار کرده اند و من جرات تغییر برروی جاهایی که حتی مطمئن هستم را هم ندارم! این یعنی فاجعه برای کد نویسی.

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

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

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

از این رو تهیه مستندات کدنویسی همزمان با وجود تمام فشار های موجود بر روی پروژه های بزرگ  می تواند هم به سود شرکت هم کارفرمایان هم مدیران گردد و به چابکی شرکتها کمک کند ودر نهایت از دردی از دردهای این قشر زحمتکش -کسانی که با ذهن ، روح و دل کار می کنند- بکاهد.

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

این زمان خالی برای شروع از صفر بود ،سفری از تجربیات به بی تجربگی ، سفری از عمق دات نت به سطح گسترده جاوا و open source با تمام مخلفاتش ، با همه تفاوت های فرهنگی ، و از همه بدتر با تمام کنایه ها وخصومت ها !(توضیح می دهم)

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

در محیط شرکت جدید کارمندان و مدیرانی از فارغ التحصیل های دانشگاه های شریف ، علم وصنعت و تهران و امیر کبیر را می دیدی و بسیاری با مدرک فوق لیسانس و تعدادی دکترا و این بر میزان دید تئوری در شرکت می افزاید(این نظر شخصی من است) و اینکه خلاصه برای هر کاری یک سیستمی دیده شده

بود که همین انطباق سیستمی هم کار ساده نبوده و نیست.قوانین ثبت گزارش کارکرد ، قوانین حضور نوشته و نانوشته جدید ، قوانین نیروی انسانی جدید ،قوانین دسته بندی براساس سطوح دانش افراد و روش های ارتقاء شغلی ، بر اینها بیفزایید قوانین check-in یا commit  کد های اصلاحی یا جدید با سخت گیری متفاوت از تمام شرکتهای سابق بنده اقلا در قسمت ما اعمال می شد، انطباق با این قوانین را هم بر دشواری کارهای روزهای ماه های گذشته می افزود.

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

این گونه بود که من در گیر یادگیری استفاده از  ابزار های جدید مثل intelliJ idea ، maven ، ant  ، svn ، appache tomcat  و  حتی جیرا شدم  ارتباط همه اینها با هم  ، همین طور یادگیری framework هایی مثل struts ، spring  و ... تا جایی که اقلا بزرگان منطبق بر کارم را در این دنیای به ظاهر بی انتهای آنها بشناسم.

دوست عزیزی که ایشان هم در هر دو زبان و محیط در گیر بود می گفت برنامه نویسی به دو زبان متفاوت خصوصا java و C#.NET  دو فرهنگ مختلف می طلبد و این بحث فرهنگی از آنجا شروع شد. توسعه دهندگان آنها (دست کم در گذشته) سیاست های جداگانه ای را دنبال کرده اند ، شما وقتی در دنیای open source قدم می زنید برای هر قسمتی که فکرش را هم نمی کنید چندین ابزار مستقل در دست دارید مثلا برای build پروژه چندین و چند ابزار در جاوا دارید ولی وقتی با ویژوال استودیو برنامه می نویسید همه چیز را به صورت مجتمع در یک جا دارید و اصلا فکر استفاده از ابزار دیگری به ذهن شما خطور نمی کند.

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

راستش در دنیای جاوا خصومتی دیرین با برنامه نویسان دات نت وجود دارد که بیشتر یک طرفه است ، و می توانی در هر گوشه و کناری کنایه ای بشنوی : "همانطوری که ما به کد های برنامه نویسان دات نت می خندیم ، اگر این کار را انجام دهی به ما می خندند" .

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

خلاصه این شد که کمتر نوشتم و بیشتر خواندم و زمانی که جوابهایم کامل شد سطر اول این نوشته در ذهنم شکل گرفت...

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

حالا چه شد؟ ساعت 1:30 نصفه شب پیام کوتاهی با این مزمون دریافت کردیم : "با شرمندگی ،  قرار را برای بعد از ظهر بیاندازید، متاسفم"، همین!

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

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

"صد میلیارد هم که باشی در صفر که ضرب شوی باز هم صفر می شوی!"

بیایید در صفر ضرب نشویم.

در سری مقالاتی از آقای وحید نصیری در مورد Refactoring می خوانیم:(توصیه می کنم بخوانید(

كارهاي سورس باز قابل توجهي از برنامه نويس‌هاي ايراني يافت نمي‌شوند؛ عموما كارهاي ارائه شده در حد يك سري مثال يا كتابخانه‌هاي كوچك است و در همين حد. يا گاهي هم انگشت شمار پروژه‌هايي كامل. مثل يك وب سايت يا يك برنامه نصفه نيمه دبيرخانه و امثال آن. اين‌ها هم خوب است از ديدگاه به اشتراك گذاري اطلاعات، ايده‌ها و هم ... يك مزيت ديگر را هم دارد و آن اين است كه بتوان كيفيت عمومي كد نويسي را حدس زد.
اگر كيفيت كدها رو بررسي ‌كنيد به يك نتيجه‌ي كلي خواهيد رسيد: "عموم برنامه نويس‌هاي ايراني (حداقل اين‌هايي كه چند عدد كار سورس باز به اشتراك گذاشته‌اند) با مفهومي به نام Refactoring هيچگونه آشنايي ندارند". مثلا يك برنامه‌ي WinForm تهيه كرده‌اند و كل سورس برنامه همان چند عدد فرم برنامه است و هر فرم بالاي 3000 سطر كد دارد. دوستان عزيز! به اين مي‌گويند «فاجعه‌اي به نام كدنويسي!» صاحب اول و آخر اين نوع كدها خودتان هستيد! شايد به همين جهت باشد كه عمده‌ي پروژه‌هاي سورس باز پس از اينكه برنامه نويس اصلي از توسعه‌ي آن دست مي‌كشد، «مي‌ميرند». چون كسي جرات نمي‌كند به اين كدها دست بزند. مشخص نيست الان اين قسمت را كه تغيير دادم، كجاي برنامه به هم ريخت. تستي ندارند. ساختاري را نمي‌توان از آن‌ها دريافت. منطق قسمت‌هاي مختلف برنامه از هم جدا نشده است. برنامه يك فرم است با چند هزار سطر كد در يك فايل! كار شما شبيه به كد اسمبلي چند هزار سطريحاصل ازdecompile يك برنامه كه نبايد باشد!به همين جهت قصد دارم يك سري «ساده» Refactoring را در اين سايت ارائه دهم. روي سادگي هم تاكيد كردم، چون اگر عموم برنامه نويس‌ها با همين موارد به ظاهر ساده آشنايي داشتند، كيفيت كد نويسي بهتري را مي‌شد در نتايج عمومي شده، شاهد بود. 

...

Refactoringچيست؟
Refactoring به معناي بهبود پيوسته كيفيت كدهاي نوشته شده در طي زمان است؛ بدون ايجاد تغييري در عملكرد اصلي برنامه. به اين ترتيب به كدهايي دست خواهيم يافت كه قابليت آزمون پذيري بهتري داشته، در مقابل تغييرات مقاوم و شكننده نيستند و همچنين امكان به اشتراك گذاري قسمت‌هايي از آن‌ها در پروژه‌هاي ديگر نيز ميسر مي‌شود.

ادامه مطلب...

در ادامه نوشته قبلی می خواهم شاخص ترین سوالات تخصصی را که در مصاحبه های شغلی از من پرسیده شده یا خودم برای مصاحبه پرسیده ام را با گروه بندی بیاورم.

البته مشخص است که این سوالات بسته به عنوان شغل درخواستی و کار مورد نظر شرکت نظر انتخاب می گردند از این رو دارای گستردگی زیادی می باشند و ذکر تمامی آنها در این نوشته مقدور نمی باشد.

در قسمت اول سوالات برنامه نویسی را می نویسم ، سپس به ASP.NET ، SQL Server و الگوهای طراحی و دیگر سوالات می پردازم.

(اگر دوستان و خوانندگان عزیز دیدگاهی در جهت اصلاح یا بهبود این نمونه سوالات دارند با طرح آن مرا در تهیه آن یاری رسانند. ممنون).

الف – سوالات مفاهیم شیء گرایی و برنامه نویسی C#

1-      چند مورد از اصول اساسی شيءگرا را نام برده و توضيح دهيد.

2-   اینترفیس(Interface)   چیست؟ و فرق آن با Abstract Class  چیست؟ کجا از اینترفیس و کجا از Abstract Class یا Base Class ها استفاده می کنید؟ مثالی از استفاده از آنها بیاورید.

3-      ارث بری چیست؟ ارث بری چندگانه را چگونه پیاده سازی می کنید؟

4-      فرق بین Reference Type  و  Value Type  چیست؟ Boxing و UnBoxing  چه زمانی اتفاق می افتد؟

5-      Static Type ها چگونه کار می کنند ؟  Static Constructor به چه کار می آید؟

6-      فرق بین کلمات کلیدیRead Only  و Const چیست؟

7-      کلمات کلیدی out  و ref به چه معنایی است و عملکرد آنها چگونه است؟

8-      Delegate چیست ؟ و در کجا از آن استفاده کرده اید؟

9-      آیا با Linq  آشنایی دارید ؟ تا چه حد استفاده کرده اید؟ استفاده از آن چه مزیتی دارد؟

10-  Lambda Expression می دانید چیست؟  ازLambda Expression   در کجاها  استفاده کرده اید؟

11-   آیا با Extension متد ها آشنایی دارید؟ کاربرد آنها در کجاست؟

12-   آیا می دانید کاربرد متدها ، کلاس ها یا اینترفیس های جنریک (Generic) چیست؟

13- چه الگوریتم هایی برای رمزنگاری (Encryption)  و رمز گشایی (Decryption) اطلاعات وجود دارد؟رمز نگاری یک طرفه و دو طرفه چه تفاوتی باهم دارند؟ کدام الگوریتم های رمز نگاری یک طرفه می باشند؟

14- فرق بین یک کلاس Public , Internal  چیست؟ کلاس Private  چه کاربردی دارد؟آیا میتوان یک اینترفیس internal  یا private  تعریف کرد؟

15-برای متدها از چند نوع  Access Modifiers می توان استفاده کرد کرد؟ فرق بین یک متد با دسترسی  Protected  و Private چیست؟ 

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

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

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

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

1-      نمونه سوالات مصاحبه استخدامي برنامه نويس‌هاي ارشد

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

2-      سوالات مصاحبه استخدام در گوگل

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

3-      سوالات رایج در مصاحبه حضوری، شغلی، اداری

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

آنچه می خواهم در ادامه بنویسم سوالات معمول یک مصاحبه تخصصی استخدامی برنامه نویس (به خصوص برنامه نویسان دات نت) است و البته قصد دارم جواب هایی که به این سوالات می توان داد را بیاورم. (از خوانندگان عزیز می خواهم با نظرات خود در این امر مرا یاری کنند.)

ادامه دارد...

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

این شرکت آن طوری که ظاهرا معلوم بود بین 20 تا 30 نفر پرسنل داشت و تعدادی از برنامه نویسان که بر روی موارد مختلفی سخت کار می کردند (از آن جایی که برای خروج قانونی کلی چانه زنی می کردند).

در مورد نحوه محاسبات قیمت پروژه ها ، گفتند که "شما بگویید چه قدر از این مبلغ این پروژه را می خواهید ، ما کیفیت پروژه را با توجه به مبلغ دریافتی شرکت تنظیم می کنیم و پروژه شما را انجام می دهیم".

در نهایت یعنی : چرا خود را برای انجام به درد سر می اندازید یا چرا برخی پروژه ها را  رد می کنید؟ شما می توانید همه پروژه ها قبول کنید و از یک برنامه نویس تبدیل به یک دلال نرم افزار شوید!

با خودم اندیشیدم :" این جور شرکت ها یعنی کارمند داریم ولی کار نه ، یعنی پروژه بی نام انجام می دهیم به هر قیمتی ! ، یعنی برای بقا می جنگیم  ".

هر چند در نهایت کار مشترکی انجام نشد ولی ذهنم مشغول این واقعیت بود که پروژه را با چه کیفیتی تحویل می دهند!؟ یعنی چی که شما هر قدر بگویید از این پروژه انتظار درآمد دارید ما به ازای بقیه مبلغ آنرا انجام می دهیم. کیفیت چه شد ؟ قربانی شد؟

پروژه دار ها و پروژه ندارها

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

اینکه تولید کننده دراین روش به ازای چه مبلغی پروژه را باید انجام دهد. به یاد همان مثال رایج دلالی در کشاورزی می افتم که دم در باغ  سیب  را از کشاورز کیلویی 100  تومان می خرند و در این چرخه تا به مصرف کننده برسد مثلا می شود 2000 تومان و کمترین سود به تولید کننده که بیشترین زحمت را در چرخه تولید متحمل می شود ، می رسد. در نرم افزار به این شدت نیست و شاید مظلومیت در این حد نباشد چون کیفیت کار قابل تنظیم است.

مساله بعدی در زمینه پروژه های سفارشی اخیرا با فردی صحبت می کردم می گفت عرف نرخ دلالی در سفارش تولید نرم افزار 40 درصد است ! این یعنی نرم افزار با مالیات بر ارزش افزوده مخفی ، یعنی افزایش قیمت.

البته کم اطلاعی خریداران نیز به این بازار دامن می زند ، رشوه و باقی مسائل بماند.

اما بسیاری بر این باورند چاره چیست  ، وقتی راه دیگری برای گرفتن پروژه ها نیست ، باید تن به این کارها داد .  برخی هم آن را جزء لاینفک تجارت امروزی می دانند .نظر شما چیست؟