Dhirendra

Final Part of Python + SQlite series In the last part, we saw how Python interacts with the SQLite engine, and how the journey goes all the way from Django ORM operations to the raw SQL queries executed by SQLite

An Important Note for Freshers: I've reviewed quite a few resumes over the past few days, many of them belonging to freshers. One thing I've noticed, and have advised candidates to remove, is listing Class Representative (CR) as an achievement. Being a CR isn't an achievement, highlighting on a technical resume. Companies are primarily interested in your skills, projects, problem-solving abilities to the role. I understand that as a fresher, filling up your resume can be challenging. But adding unrelated college responsibilities just for the sake of adding something can dilute your actual strengths. The same goes for mentioning memberships in communities or clubs that have no meaningful connection to the role you're applying for. Even if an AI tool suggests keeping these things, use your own judgment. If someone tells you that being a Class Representative or a member of some college community automatically demonstrates leadership, communication, or some other impressive professional skill, honestly, it doesn't. A designation doesn't prove a skill. Your actions and actual contributions do. It's a little harsh, but here's some food for thought: Don't fill your resume just to make it longer. Make every line earn its place.

The philosophy of Jeet Kune Do is adaptability. It says, Don't become a prisoner of one technique. The same applies to tech. Don't become a prisoner of one language, one framework, or one way of thinking. Adapt to the situation and its demands. Adaptability doesn't mean abandoning everything you know whenever something new appears. It means understanding your fundamentals well enough to change your approach when the situation demands it. As Bruce Lee famously said, "Be water, my friend." Water takes the shape of its vessel. "Learn to adapt without losing your essence" Not just in your career, but in life itself

A system design interview should be like a conversation between interviewer and interviewee, not a monologue. There’s no one-size-fits-all answer to a design problem. The right solution depends on the requirements and trade-offs. Instead of trying to guess the “perfect” answer, try to involve interviewer in your thought process. Ask questions, discuss trade-offs, and explore possible solutions together. Try to collaborate not just present

Small update: Increased the nos of goroutines from 5 to 15 to see how the application behaves under higher concurrency, but so far, all tests passed with 59% code coverage as of now Also Added a test command to the Makefile to make running the test suite easier and run tests just by typing "make test"

Switching between C++ and Go is causing me some serious syntax fatigue. These days, I'm constantly switching between the two for problem-solving and development both, and sometimes I literally end up writing Go syntax in C++ and vice versa. So I created this basic cheat sheet with some common syntax and methods that I can quickly look up when needed. Nothing extraordinary, but it saves me time and brain bandwidth, helping me focus on solving the actual problem instead of fighting the syntax. If you also have to switch between the two,then, this might come in handy

Did you know Redis stands for REmote DIctionary Server?