مصاحبه استخدامی

  • یوسف مهرداد بی‌بالان

پیش‌گفتار:
از نگاه من، مصاحبه‌ی استخدامی کار بسیار دشواری است، هم برای مصاحبه‌شونده و هم برای مصاحبه‌کننده. دشوارترین بخش آن از نظر من، “قضاوت شدن” و “قضاوت کردن” است. مصاحبه‌ی نامناسب می‌تواند “فرصت” یک همکاری موفق بین متقاضی و تیم/شرکت را بسوزاند. برداشت من این است که هزینه و هزینه‌ی فرصت مصاحبه با هر متقاضی، اگر به پول تبدیل شود، مبلغ آن کم نخواهد بود.

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

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

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

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

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

حسن جان می‌گفت من هاج و واج به گفتگوی استاد و هم‌شاگردها گوش می‌کردم! وای!
با خودم فکر کردم که اگه در مصاحبه‌ای شرکت کنم و از من همین پرسش‌ها را بپرسند، پاسخ من این خواهد بود:
– من ورزش رزمی کار می‌کنم و ورزش اصلی من هم کاراته است!
– از بین تیم‌های ملی فوتبال، آلمان رو از همه بیشتر دوست دارم!
در نتیجه تحلیل مصاحبه‌کننده از شخصیت من این خواهد بود: علاقه‌ای به کار تیمی ندارم (کاراته) و عاشق نظم و انضباط هستم و تفکر دفاعی دارم (تیم آلمان)! 🙂

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

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

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

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

من کماکان داشتم می‌خندیدم! دیگر به جایی رسید که بدنم از شدت خنده درد گرفته بود!

پس‌گفتار:
امیدوارم فرصت همکاری موفق افراد با شرکت‌ها/تیم‌ها با “الگوسازی” پرسش‌ها و “ساده‌سازی” پاسخ‌های مصاحبه‌های استخدامی از دست نرود!
امیدوارم یادم بماند که حسن‌هایی هستند که ورزش مورد علاقه‌شان، ورزش انفرادی است ولی استاد کار تیمی‌اند و با این که عاشق تیم آلمان هستند ولی مانند یک برزیلی زیبا بازی می‌کنند!

گزیده:

I had a job interview at an insurance company once and the lady said ‘Where do you see yourself in five years?’ and I said ‘Celebrating the fifth year anniversary of you asking me this question. 🙂 Mitch Hedberg

مسافر بی‌قرار

  • یوسف مهرداد بی‌بالان

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

خط: دوست بزرگوار، ابوالفضل

یادگیری ماشین با گراف

  • یوسف مهرداد بی‌بالان

چند وقتی است که به همراه یکی از دوستان، درس Machine Learning with Graphs دانشگاه استنفورد را هم‌خوانی و دنبال می‌کنیم. چند نکته به نظرم رسید که مناسب دیدم اینجا یادداشت کنم.

  • همان طور که در خود درس گفته شده است “گراف‌ها مرزهای جدید یادگیری عمیق (ِِDeep Learning) هستند
  • چرا گراف؟ گراف‌، زبانی عمومی برای توصیف و تحلیل موجودیت‌ها و روابط / تعاملات بین آنهاست.
  • آموختن یادگیری ماشین گرافی برای من به مراتب دشوارتر از یادگیری ماشین رایج و غیرگرافی است.
  • کاربردهای یادگیری ماشین با گراف “شگفت‌انگیز” و تا حدی “ترسناک” است. باور کنید!

در اینجا فهرستی از نمونه کاربردهای یادگیری ماشین با گراف را می‌توانید ببینید.

  • Node classification: Predict a property of a node /Example: Categorize online users-items
  • Link prediction: Predict whether there are missing links between two nodes / Example: Knowledge graph completion
  • Graph classification: Categorize different graphs / Example: Molecule property prediction
  • Clustering: Detect if nodes form a community / Example: Social circle detection
  • Other tasks:
    — Graph generation: Drug discovery
    — Graph evolution: Physical simulation

اجازه دهید یک کار روزمره را به یک مساله گراف تبدیل کنیم:
فرض کنید که کاربران یک پیام‌رسان مانند تلگرام، واتس اپ یا اینستاگرام را به مانند گره گراف و پیام‌ باز-ارسالی (فوروارد شده) از یک کاربر به کاربر دیگر را هم به مانند یال گراف و تعداد پیام باز-ارسالی رد و بدل شده را مانند وزن یال در نظر بگیریم. اگر مدلی به کمک یادگیری ماشین با گراف طراحی کنیم، به نظر شما این مدل به چه سوالاتی می‌تواند پاسخ دهد!

و اما آخرین نکته‌ی جالب‌: آموختم که “گوگل اولین شرکتی بود که اینترنت را یک گراف دید“!

Reading more:
CS224W: Machine Learning with Graphs, Stanford / Winter 2021 (Slides, Video)
CS224W: Machine Learning with Graphs, Stanford / Fall 2019 (Slides, Video)

گزیده:
شاید ریاضی به ما یاد ندهد که چگونه عشق را “جمع کنیم” یا نفرت را “کم کنیم”، اما به ما امید می‌دهد که هر مساله‌ای راه حلی دارد.
ناشناس (مرجع)

Establish a Baseline When Playing Planning Poker

  • یوسف مهرداد بی‌بالان

… relative estimating like with Planning Poker suffers from a bootstrapping problem: How does a team select the initial estimates to which they’ll compare?

My recommendation is that when a team first starts playing Planning Poker, team members identify two values that will establish their baseline. They do this without playing Planning Poker. They do it just through discussion. After the baseline is established, team members can use Planning Poker to estimate additional items.

Ideally, the team is able to identify both a two-point story and a five-point story. There is evidence that humans estimate most reliably when sticking within one order of magnitude.

Identifying a two-point product backlog item and a five-point item does a good job of spanning this order of magnitude. Many other items can then be more reliably compared against the two and the five.

If finding a two and a five proves difficult, look instead for a two and an eight, or a three and an eight. Anything that spans the one to 10 range where we’re good estimators will work.

Avoid Starting with a One-Point Story
I like to avoid starting with a one-point story. It doesn’t leave room for anything smaller without resorting to fractions, and those are harder to work with later.

Additionally, comparing all subsequent stories to a one-point story is difficult. Saying one product backlog item will take two or three times longer than another seems intuitively easier and more accurate than saying something will take 10 times longer.

I made this point in my 2005 “Agile Estimating and Planning” book (now also a video course). In 2013, it was confirmed by Magne Jørgensen of the Simula Research Lab. Jørgensen, a highly respected researcher, conducted experiments involving 62 developers. He found that “using a small user story as the reference tends to make the stories to be estimated too small due to an assimilation effect.”

Why Use Two Values for a Baseline?
Establishing a baseline of two values allows for even the first stories being estimated to be compared to two other items. This is known as triangulating and helps achieve more consistent estimates.

If a team has established a baseline with two- and five-point stories, team members can validate a three-point estimate by thinking whether it will take longer than the two and less time than the five.

Citing again the research of Jørgensen, there is evidence that the direction of comparison matters. Comparing the item being estimated to one story that will take less time to develop and another that will take longer is likely to improve the estimate.

Reference: Mike Cohn, mountaingoatsoftware.com

Quote:
“The higher the price of information in a software team, the less effective the team is.”
― Yegor Bugayenko, Code Ahead: Volume 1

The Story of XP

  • یوسف مهرداد بی‌بالان

from: www.extremeprogramming.org

The author of this website is Don Wells. He learned about how teams become unproductive while at Honeywell and General Electric. He then learned a great deal about teams becoming super productive while building expert diagnostic systems for the US Army and Ford Motor Co. Many artificial intelligence practices are now common in software development.

The turning point in current software development came in the mid-1990s. Many people were re-examining the idea that software must be built like hardware. Jeff Sutherland and Ken Schwaber were formalizing a new process called SCRUM. Alistair Cockburn was working on Crystal Clear. Chrysler was doing its part by trying to build traditional business systems using object-oriented technology. This is a common approach now that Java is used in almost all domains, but was very advanced in the previous millennia.

Don was hired on to the Chrysler Comprehensive Compensation (C3) project as an expert in object technology and GUIs. It didn’t take long for him to spot some serious trouble. The team was splintered into 3 groups that worked in competition instead of cooperation. The project was becoming overdue. Estimates were showing it way over budget. It was also way too complex and riddled with redundant code (Conway’s Law) to ever work reliably in production. His assessment of the situation was to start over. There was time to make the deadline but only if the team worked together in cooperation and sharing as opposed to competition and isolation.

You can probably imagine that starting a project over after millions of dollars were already invested is a tricky situation. Don had to wait for exactly the right moment. That moment came when a consultant named Kent Beck was hired to optimize the C3 system’s performance. Kent decided to spend a half hour with each of the developers to get an idea of what needed to be done. When he began talking to Don he ended up spending 3 hours. At the end of that time Don had convinced Kent that the current code base would never make it into production. Kent presented that result to Chrysler management and they agreed.

The project was halted and Don began not just mending fences but completely tearing them down between team members. Chrysler management noticed what he was doing and offered him the position of chief architect. Don graciously refused while explaining his concept of everyone owning and contributing to the system’s design. No one understood his goal yet.

Kent Beck was hired to spend a couple days each month on the C3 project. Chrysler also hired Ron Jeffries to join notable agile proponents Martin Fowler and Chet Hendrickson on the project. Kent mixed together the best practices Don Wells is on the left from several emerging agile processes with things he had learned while working with Ward Cunningham. The C3 team created a new process formulation by watching what helped or hindered. Doing more of what helps and less of what hinders resulted in a minimal process with high flexibility.

Kent wanted the team to integrate code often, but it wasn’t working. Kent had appointed an integration czar with integration lieutenants in a hierarchy. Integrating that way put a chief architect back into the project and slowed them down till they were integrating once every three weeks and taking days to do it. A hot spot of complexity was also brewing. Don came up with an idea. It would solve the current integration problem, allow design simplifications, and lead the team to his ultimate goal of collective ownership.

Don proposed to the team that they set up an extra computer on an empty desk where all integration would take place. They would integrate and release new code to the repository when ever they wanted without prior permission so long as it ran all the unit tests. Management hated the idea. The team was mixed about it. Management played their trump card by not allowing Don to have an extra computer. So Don simply moved his own computer to the empty desk and told everyone it was the integration station. He wanted to do more pair programming anyway.
That simple change made a huge difference. People began releasing code at least once a day if not more. Sharing an integration computer made people more cooperative and the design tighter because everyone was responsible for making it better. Anyone could change any code and know changes would not be lost. People began writing more unit tests then they had before because it ensured their code would run even if some one else made some changes.
The real prize in that change was what came to be known as collective ownership. The entire team owns the entire code base. The entire team is responsible for developing and extending the system design. The team worked together cooperatively at a much faster pace than anyone expected. Don has some rough estimates and believes the team was going six and a half times faster than before the project was restarted.
With C3 back on schedule Don moved back to Ford Motor Co. This time he was to help a financial application get back on track. The application was the Vehicle Cost and Profitability System (VCAPS) that calculated how much it actually cost to build a car or truck. It was in trouble because of serious quality and performance issues. More time was spent fixing bugs than adding required features.
The first big change Don made was to write a unit test framework and create the first unit tests. It was a “white knuckle” assignment because he had two weeks to write code and one week to debug. The unit tests and framework took the entire first two weeks to finish. But once the unit tests were in place the actual code only took one week to write, no debugging needed. The assignment was brought in on time with none of the expected bugs. This was a good start.
As the number of unit tests grew management noticed a one third reduction in production bugs. At that time Don was able to set up an integration station and began continuous integration and collective ownership. More Extreme Programming (XP) practices were introduced until the second XP project was running. As production bugs dropped even further the team became more productive eventually reaching a factor of ten times. This second XP project verified that XP was a viable process and C3 was not just an anomaly.
Soon after leaving the VCAPS project in 1999 Don created this website. At that time information on the XP process was either very Extreme Programming Perspectives XP Agile Universe 2002 XP Agile Universe 2003 confusing or biased towards Smalltalk projects. There was also a great deal of discussion going on about whether or not XP would even work. Don perceived a need for a simple explanation of the basics that everyone would agree upon. Having been on two XP transformations he felt qualified to be the author.

افسوس نخورید!

  • یوسف مهرداد بی‌بالان

Never regret a day in your life. Good days give happiness, bad days give experiences, worst days give lessons, and best days give memories
—Richard Feynman

پایگاه داده گرافی

  • یوسف مهرداد بی‌بالان

پیش‌گفتار:
هر وقت گذرم به گراف و اصل لانه کبوتری می‌افتد یاد استاد عزیزم آقای دکتر بهروز قلی‌زاده در دانشگاه شریف می‌افتم. یادش به‌خیر همیشه جاده قزوین-زنجان-تبریز یک پای ثابت مثال‌های گراف و مسیریابی ایشان بود. با وجود علاقه‌ام به گراف، در تمام این سال‌ها گذرم به گراف و مساله‌های آن نخورده بود، تا این که زمستان پارسال برای آمادگیِ آزمون ابتدایی دوره دکترا معروف به Field Of Study، مطالب مربوط به گراف و درخت و مسیرها را دوباره مرور کردم.

پایگاه داده گرافی:
برای انجام پروژه‌ای نیاز شد که با پایگاه داده گرافی (Graph Database) آشنا شوم. به کمک یکی از دوستان باتجربه‌ام (حسین آقا)، کار با Neo4J را شروع کردم و به کمک راهنما و زیرساخت آموزشی Neo4J و البته همراهی حسین جان، توانستم با آن کار کنم. به راستی که چه دنیای متفاوت و جذابی است. آن چه با مشقت فراوان در پایگاه داده رابطه‌ای می‌توان انجام داد، اینجا با یک کد ساده می‌توان به دست آورد. اگر دوست داشتید نگاهی به آن بیندازید می‌توانید از این آدرس (Neo4j Graph Database Sandbox) استفاده کنید. چه زیباست!

 

گزیده:
«پرارزشترین بخش [مطالعه ریاضی] لحظه‌ای است که می‌گویی آها!. ذوق کشف و لذت فهمیدن چیزی جدید. احساس ایستادن بالای یک بلندی و رسیدن به دیدی شفاف و واضح.» مریم میرزاخانی در مصاحبه با گاردین (مرجع)

مرجع عکس: اینجا

 

برای خروج از جستجو کلید ESC را بفشارید