Home of software engineers

‏یکی اومده راه‌حل سوالایی که برای آمادگی برای مصاحبه گوگل حل کرده رو توی گیت‌هاب گذاشته. برای آمادگی، حدود ۲۲۲ سوال از leetcode حل کرده. برخی از نکاتی که نوشته: ۱. حل مساله فقط بخشی از آمادگی برای مصاحبه است، هرچند این بخش خیلی مهمه، ولی علاوه بر اون به نکات بعدی هم دقت کنید. ‏۲. با مفاهیم علوم‌کامپیوتر آشنا باشید تا زبان مشترکی بین شما و مصاحبه‌کننده برقرار باشه ۳. سر مصاحبه باید بتونید «روند فکر کردنتون» رو توضیح بدین. برای آشنایی با این بخش، کتاب «Cracking the Coding Interview» رو توصیه کرده. و یه سری مطلب دیگه که توی گیت‌هابش می‌بینید. https://github.com/mgechev/google-interview-preparation-problems @DevTwitter | <hadi/>

نکات مهمی درباره رزومه نویسی قسمت اول قسمت دوم قسمت سوم قسمت چهارم قسمت پنجم قسمت ششم قسمت هفتم قسمت هشتم

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

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

what is SQL injection? good article for security ... good for architectures and developers

یکی از کار های مفیدی که براش میشه از هوش مصنوعی کمک گرفت اینه که یادگیری پروژه محور رو برامون راحت تر کنه مثلا بعد از این که مبانی GO, redis, rabitMQ و ... رو یاد گرفتیم از gemini یا chatGPT بخواهیم که برامون نقش منتور رو بازی کنه و یک پروژه خوب که شامل این ابزار ها باشه رو تعریف کنه، پیشنیازاشو بگه و خروجی مورد نظرش رو هم تعیین کنه . برای این مثالی که زدم هم gemini و هم chatGPT یک سری پیشنهاد دادند که نقطه مشترکشون اپلیکیشن todo-list بود. حتی در موارد پیشرفته تر میشه ازشون خواست پروژه های مشابه پروژه ای که تعریف کرده رو بهمون معرفی کنه تا بتونیم ایده هم بگیریم.

یکی از چالش‌های اساسی در مدیریت داده‌ها در پایگاه داده، مشکل اسکیل کردن در دیتابیس‌های SQL هستش که احتمالا باهاش آشنا هستید. دو عملیات اصلی رو در نظر میگیریم، عملیات خواندن (read) و عملیات نوشتن (write) وقتی ما در حال خواندن هستیم درطی این فرآیند خواندن، یک کلاستر ایجاد می‌شود که ترکیبی از چند سرور است، که یکی از آن‌ها به عنوان master و بقیه به عنوان slave عمل می‌ کنند. وقتی ما کوئری میزنیم در واقع نیاز به تغییر داده ها داریم و این کوئری رو داریم به سرور master ارسال می‌کنیم و سرور master تغییرات را به سایر سرورها اعلام میکنه. اما وقتی که عملیات خواندن انجام می‌شه، ما این امکان رو داریم که به هر یک از سرورهای slave به‌ طور مستقیم کوئری بزنیم. خب حالا وقتی درخواست‌های خواندن ما زیاد بشه میتونیم سرورهای اسلیو رو زیاد کنیم و سیستم رو Scale Out کنیم و در واقع اینجا مشکلی نداریم. اما به همین راحتی نمیتونیم عملیات نوشتن رو Scale Out کنیم چرا ؟ چون امکان پخش داده را بر روی چندین سرور وجود نداره scaling in sql اینجا ترجیح داده میشه که از NoSQL ها استفاده بشه ولی CockroachDB به عنوان یک راه حل از دسته NewSQL مطرح میشه. این دیتابیس یک دیتابیس رابطه ای محسوب میشه که امکان اسکیل کردن داره، به طوری که با وجود خصوصیات دیتابیس‌های رابطه ای، این امکان وجود داره که اون رو به عنوان یک دیتابیس توزیع شده استفاده کنیم. cockroach db

یکی از چالش‌های اساسی در مدیریت داده‌ها در پایگاه داده، مشکل اسکیل کردن در دیتابیس‌های SQL هستش که احتمالا باهاش آشنا هستید. دو عملیات اصلی رو در نظر میگیریم، عملیات خواندن (read) و عملیات نوشتن (write) وقتی ما در حال خواندن هستیم درطی این فرآیند خواندن، یک کلاستر ایجاد می‌شود که ترکیبی از چند سرور است، که یکی از آن‌ها به عنوان master و بقیه به عنوان slave عمل می‌ کنند. وقتی ما کوئری میزنیم در واقع نیاز به تغییر داده ها داریم و این کوئری رو داریم به سرور master ارسال می‌کنیم و سرور master تغییرات را به سایر سرورها اعلام میکنه. اما وقتی که عملیات خواندن انجام می‌شه، ما این امکان رو داریم که به هر یک از سرورهای slave به‌ طور مستقیم کوئری بزنیم. خب حالا وقتی درخواست‌های خواندن ما زیاد بشه میتونیم سرورهای اسلیو رو زیاد کنیم و سیستم رو Scale Out کنیم و در واقع اینجا مشکلی نداریم. اما به همین راحتی نمیتونیم عملیات نوشتن رو Scale Out کنیم چرا ؟ چون امکان پخش داده را بر روی چندین سرور وجود نداره