标签：#career

Corner the small enemy. Strip away its options, and there is nowhere left to run. — The 36...

You wouldn't believe what they were preaching about in church this week. Normally, these days you walk in expecting to be bombarded with Bible verses and the classic "tell your neighbour to tell their neighbour" routine. But guess what, my preacherman was on point. The whole sermon was about how to realise your full potential and grow your career. And here's the interesting part: it wasn't aimed at the start-your-own-empire crowd. It was for the intrapreneurs , the people who'd rather climb high inside someone else's company than run their own thing. If that's you, this one's for you. So let me try to break it down in my own words, with a few of the insights I picked up from the preacherman (and a couple of my own). Let's begin. What is it that we actually need to do to discover ourselves and reach our full career potential? 1. Start Early There's a popular idea that life comes in four quarters: 0–25 — the learning phase 25–50 — the earning phase 50–75 — the serving / enjoying phase 75+ — the reflecting phase (You'll see different versions of this floating around, with different age bands; it's a framing, not a law of physics, so take the exact numbers loosely.) The first quarter is where the magic is supposed to happen. This is your discovery phase. You're meant to learn as much as you can, try different things, fail, get back up, and try again. This is where you find out who you actually are. If you spend this quarter as a couch potato, there's a good chance you end up miserable and stuck in the wrong career. Your environment matters too. Get born in India, you'll probably force yourself onto a cricket pitch, even if your real gift was on a tennis court; therefore, you have to force yourself into trying quite a number of things. For the parents reading this: give your kids as much exposure as you possibly can. Let them join different clubs. Let them be around different kinds of people. Someone out there might spot a talent you never even knew your child had. A lot

30 Technical Interview Questions You Should Be Able to Explain Out Loud (JS / React / Node) Most interview prep content gives you a definition. Real interviews test something different: can you explain your reasoning clearly, out loud, under a little pressure — not just recite the right words. I put together 30 questions across JavaScript, React, and Node.js. Every answer here is written the way you'd actually say it in an interview, not the way a textbook would write it. How to actually use this: cover the answer, try explaining it out loud in under 30 seconds, then read the answer. If you froze or rambled, that's the real signal — more than whether you technically knew the concept. JavaScript Fundamentals 1. What's a closure, and why does it actually matter in real code? A closure is a function that remembers the variables from where it was created, even after that outer function has finished running. It powers private variables, debouncing, memoization, and module patterns. 2. setTimeout(fn, 0) vs Promise.then() — which runs first? The Promise wins. .then() callbacks go into the microtask queue, which fully drains before the next macrotask (like setTimeout ) runs — even with a 0ms delay. 3. Why does var break inside loops with closures, but let doesn't? var is function-scoped — every iteration shares the same variable. let is block-scoped, so each iteration gets its own fresh binding. 4. Where does == actually give you a different (and wrong) answer than === ? == does type coercion first — 0 == false and '' == 0 are both true. === compares type and value directly, no surprises. 5. Why does this break in callbacks with regular functions, but not arrow functions? Regular functions get this based on how they're called. Arrow functions inherit this lexically from where they were defined, so it stays consistent no matter how they're invoked. 6. If a property isn't on an object, where does JS look next? JS walks the prototype chain — the object, then its prototype, the

I built a free ATS resume checker after seeing too many friends get ghosted on Easy Apply. Most people think ATS means “add more keywords.” In practice, a lot of resumes fail earlier — on parsing. The 5 blockers I see most Columns / two-column layouts Nice for humans. Bad for many parsers. Contact info or skills in a sidebar often get read in the wrong order (or skipped). Fix: one-column layout. Standard section titles: Experience, Education, Skills. Icons instead of text Phone / email / LinkedIn as icons only = empty fields for the ATS. Fix: real text next to icons (or drop the icons). Text in images / fancy graphics If you can’t Ctrl+A → copy readable text from your PDF, neither can the ATS. Fix: real text PDF/DOCX, not a designed image export. Tables for experience Tables often scramble dates and bullets. Fix: simple headings + bullet points. Keyword stuffing Repeating “Python Python Python” can look spammy and still miss role-specific terms from the job post. Fix: mirror the job’s real skills in your bullets with proof (tools + outcomes). Quick self-test Open your PDF Select all → paste into a blank doc If the order is messy or text is missing, fix the format before you apply again Free checker I use for this I shipped a free diagnosis that flags these blockers first (full score/keywords optional): https://myatscheck.com/free-ats-resume-checker If you’re job hunting through Workday / Greenhouse / Easy Apply, fix parsing before you rewrite every bullet.

Keep the shell. Preserve the presence. The ally doesn't suspect; the enemy doesn't move. — The 36 Stratagems, Slough off the Cicada's Golden Shell Previously on this series: #19: Mark Found His AI Audit Method in a Training Manual. He Left a Trap in His Report. — P confirmed Mark's report was read from a Singapore IP. A note was left: "Entry's gone. Two weeks. Don't reach out. I'll find you." #20: Alex Felt the AI Collector Slow Down. He Knew Someone Else Had Made a Move. — ACL's processing latency climbed abnormally. Someone had done something in the same time window. Exposed P's monitoring pinged while P was still helping Mark verify an address. Deep night. The screen was the only light in the room. P opened the monitor. The record was waiting: a read from Singapore. Time, method, address, all matching. Mark's bait had been taken. P knew this path. A false lead planted in Mark's report, waiting for this exact day. P double-checked the address: an AWS Elastic IP registered in the Singapore region, same network block. No ambiguity. P sent an encrypted message: "Your report was read. From a Singapore IP." Then P ran the routine check. The environment status list scrolled in the terminal: storage levels, certificate expiry, key rotation dates. P had read these lines a hundred times. Every time, identical. One line was different. P's fingers stopped on the trackpad. The cursor sat on the entry's metadata line. A new tag P had never configured. # Old entry metadata: new entry (not configured by P) status : reclaim_pending source : acl-asset-scanner scanned_at : 02:01:07Z P didn't move. The cursor sat on screen. In the room, only the fan. The fan cycled once. P's fingers lifted off the trackpad, then settled back. The tag was still there. The tag wasn't an alert. Not an error, no explanation. The format matched ACL's automated scan records. P had seen it before, in a data company's audit report last year, in another client's logs the year before. ACL's scanner had swept

Workday is where large enterprises actually post. NVIDIA has 2,000 open roles there, Salesforce 1,477, Adobe 832. It answers an anonymous POST with no key. It also has two behaviours that are not in any documentation you can read without an account, and both of them fail silently. One of them costs you 98% of the board without raising anything. The number that changes after page one Ask for the first twenty postings and the response carries a total : POST /wday/cxs/nvidia/NVIDIAExternalCareerSite/jobs {"appliedFacets":{}, "limit":20, "offset":0, "searchText":""} 20 jobPostings, total: 2000 Ask for the next twenty and the count is gone: offset 20 -> 20 jobPostings, total: 0 offset 40 -> 20 jobPostings, total: 0 Not null, not absent. Zero. The postings keep coming; only the count collapses. Measured on four enterprise tenants: tenant total at offset 0 at offset 20 at offset 40 NVIDIA 2000 0 0 Salesforce 1477 0 0 Adobe 832 0 0 Sony 94 0 0 Same shape every time, so this is Workday and not one tenant's configuration. Why that costs you 98% of the board Here is the loop everyone writes, and it is not a bad loop: offset , out = 0 , [] while True : page = fetch ( offset ) posts = page [ " jobPostings " ] if not posts : break out += posts offset += len ( posts ) if offset >= page [ " total " ]: # looks obviously right break On page two page["total"] is 0 , and 20 >= 0 is true. The loop exits, reports no error, and hands back what it has. I ran both versions against NVIDIA: declared total on page one 2000 the obvious loop collected 40 2% keeping the first total instead 2000 100% Forty postings out of two thousand, and nothing anywhere says so. No exception, no warning, no partial-result flag. Just a job board that looks very quiet. The fix is one line moved: offset , out , total = 0 , [], None while True : page = fetch ( offset ) posts = page [ " jobPostings " ] if not posts : break out += posts offset += len ( posts ) if total is None : # the first answer is the only honest

I'm halfway through the MLH Production Engineering Fellowship, and while I've learned a lot technically—from Linux fundamentals, Docker, NGINX, automated testing, and contributing to open source, the thing that has stood out to me most is how well the program is structured. Beyond the technical curriculum, there is a strong emphasis on interview preparation and career growth. We’ve had regular opportunities to practice technical interviews, receive feedback, and stay in close contact with our Meta mentors, who have been incredibly approachable throughout the program. Looking forward to seeing what the second half of the fellowship has in store. Thanks to the MLH team, mentors, and my podmates for making it such a rewarding experience so far!

Às vezes, a maior barreira para começar um projeto não é a complexidade do problema, mas a busca por...

Kubernetes Interviews Are Broken When Trivia Matters More Than Real Skill Kubernetes interviews often fail when they test whether a candidate can recall obscure implementation details instead of showing how that person diagnoses failures, reasons through tradeoffs, and learns under pressure. Certifications can prove useful baseline knowledge, but neither a certificate nor a perfect whiteboard answer reliably proves that someone can operate a production cluster. The frustration becomes obvious when an interview demands a kernel level explanation of what happens when traffic reaches an ingress controller in a Cilium based, proxyless setup, while the actual role may involve changing a CPU request from 500m to 550m. The contrast is funny because it feels painfully familiar. Candidates prepare for architecture, networking, controllers, scheduling, and troubleshooting, then get judged on a detail they could verify in seconds during real work. That does not mean deep technical knowledge is useless. Some roles genuinely require it. The problem begins when interview difficulty becomes disconnected from job difficulty, and when memorization is treated as a shortcut for measuring engineering judgment. Why Kubernetes interview questions feel disconnected from the job The strongest complaint in the discussion was not that Kubernetes is too difficult. It was that many interview questions appear designed to establish superiority rather than measure readiness for the role. One example captured the problem perfectly: the interview asks for a detailed explanation of kernel behavior, ingress traffic, Cilium, eBPF, and proxyless networking. The work itself turns out to be a minor resource adjustment. That gap creates distrust because candidates are being filtered through a standard that the daily job may never require. A technical interview should reflect the decisions the engineer will actually make. If the job involves operating clusters, useful questions might examine how the candid

Stratagems #20: Alex Felt the AI Collector Slow Down. He Knew Someone Else Had Made a...

I finally shipped the first version of my freelance landing page. The funny part? I spent weeks thinking I had a design problem. I didn't. I had a content problem. The layout is good enough. The copy is good enough. The CSS is good enough. What the page really needs now is more real projects. Instead of redesigning it again, I'm going to spend my time replacing concept work with actual client work as it comes in. Sometimes the next version isn't another refactor. It's simply experience. 🔗 https://lksvn.com.br/freelance/

Stop Waiting. Start Building. For a long time, I believed I needed to be "ready." Ready with a stronger portfolio. Ready with more skills. Ready with a clearer career plan. So I waited. Eventually I realized something uncomfortable: Confidence isn't built before you start. It's built because you start. I'm an AI & Data Science graduate figuring things out in public. Right now I'm: Learning AI beyond what college taught me. Building projects that solve real problems. Applying for internships and jobs. Documenting everything I learn. I don't have all the answers. But I do have curiosity. This blog is my commitment to consistency over perfection. I'll be sharing projects, mistakes, things I learn, career experiments, and ideas that hopefully help someone else who's also trying to figure things out. If you're also building before you feel ready Welcome. 🚀 Let's learn together. What was the project that finally pushed you to stop waiting?

I'm responding directly to Maya Posch's piece on HackADay that was published today. Did that rhyme? I think it did. Community-led open source project hosting site Codeberg has formally announced that projects whose code is largely or fully machine-generated through LLMs and other ‘AI’ tools will no longer be welcome. This follows on the heels of a similar ban on cryptocurrency-related projects. The community vote was on two issues, the first being the notion that scraping of project code for the use in LLMs should be forbidden, which was a motion that easily passed. The second motion was on disallowing projects whose code was substantially generated by LLMs like Claude, OpenAI Codex, and similar. This motion passed with 358 in favor versus 144 against. In the earlier linked blog post the reasoning behind especially this second issue is expanded upon, covering not only ‘license whitewashing’, but also the direct and indirect hardware costs, with the expanding ‘AI’ datacenter hyperscaling having massively increased hardware costs for Codeberg over the past years, as the costs have been largely externalized. Also covered is the aspect of these LLM-based tools destroying the OSS community, which is something that is backed up by recent studies. Even if we ignore that such LLM-tools are destroying the cognitive abilities of its users, there’s an argument to be made that if LLM-scraping is disallowed, then it’s consistent to also not allow LLM-generated code. In the Terms of Use you can see these changes, both for LLMs and for cryptocurrency projects. Thanks to [mk-fg] for the tip. Credit is due to the original HackADay.com Article by Maya Posch post contents, but I would like to respond to each point here while preserving what was published on 7-24-2026. Scraping of Project Code for the use in LLMs should be forbidden If LLMs are rendering code trained on GPL-3 open-source software, then its effectively bypassing the license through intellectual property theft by directl

Summary More and more, I find myself overtaken by AI in my own field of expertise. Given only the materials, AI clears the specialized knowledge I spent years building up more easily than I had expected. This column takes a small thing that actually happened during collaborative development as its starting point, and thinks about what a specialist who has ended up on the overtaken side can make into a strength from here on. Where will the human role move next? How long will what I can hand over now stay something only I can produce? This is not a piece that settles the answer, but I use what happened in daily development as a clue to think through the question. Who this is for and what you can take away This column is for people who, in collaborative development with AI, have begun to wonder where to place their own expertise. Rather than lamenting being overtaken as such, I want to think through with you, from things that actually happened, what you can hold on to once you are on the overtaken side. I wrote it so that you can carry away the unease of handing work over to AI as a question for rethinking your own role. I hope it becomes material for someone standing in the same situation to think about what they themselves would do. This article is a column based on things that actually happened one day during collaborative development, and on the record of the exchange I had with AI that day. In my own field of expertise, the moments of being overtaken by AI have clearly grown more frequent. There was one recently. It was when I added a feature for subscribers to comment to each other on this site. What I decided went only as far as the line that both reading and writing stay closed to subscribers alone; the implementation I left to AI. When the implementation was done, other AIs reviewed it from four viewpoints, tried to rebut each finding, and sent only the ones that survived on to be fixed. Two of them were ways the daily posting limit could be slipped past. One

Don't fight their strength — take away their advantage. Don't fight the boiling water — remove the...

Over the past few weeks, I've been focused on deepening my understanding of mobile analytics—not just by completing a course, but by putting those concepts into practice through hands-on implementation in React Native. Throughout this journey, I explored a wide range of topics, including: Firebase Analytics integration Google Analytics 4 (GA4) Event planning and naming conventions Screen view tracking Custom events and custom definitions Key Events (Conversions) User properties and User ID Acquisition and campaign tracking Audience segmentation Ecommerce measurement Checkout funnel analysis Promotions and marketing attribution BigQuery integration Realtime reporting and DebugView Analytics validation and best practices One of the biggest lessons I learned is that analytics is much more than logging events . A well-designed analytics strategy helps answer important questions about user behavior, feature adoption, user engagement, and conversion optimization. The quality of the insights you gain depends on having a well-planned event architecture, consistent naming conventions, and meaningful data collection from the very beginning. Completing this Udemy course gave me a strong foundation in Firebase Analytics and Google Analytics 4. Reinforcing that knowledge through hands-on implementation in React Native helped me better understand event planning, debugging, reporting, and analytics best practices for modern mobile applications. Course Certificate I'm happy to have successfully completed the Firebase Analytics & Google Analytics 4 (GA4) course on Udemy. Certificate: https://www.udemy.com/certificate/UC-4a23b92f-0857-4a75-83dd-ac186bdfdfbc The course covered both the fundamentals and advanced capabilities of mobile analytics, including GA4 reports, custom events, screen tracking, audiences, BigQuery integration, and data-driven decision making. It has been a valuable learning experience that strengthened both my theoretical understanding and practical implementation

I judged three hackathons over about ten days this July: MLH x DigitalOcean "AI for Social Good" on July 11, the Sports World Cup Hackathon in San Francisco on July 17, and Aethera Hacks, an online event on Devpost, across July 19 to 21. I came in from the sports technology side, building athlete monetization tools, so I was usually the judge asking who pays for this rather than the judge asking what is your bundle size. That turned out to be a useful seat, because the questions that decide scores are mostly not technical ones. Here is the part builders rarely get told: a judge is scoring under a hard constraint. Some number of teams, a fixed window, and by the middle of the block the demos start blurring together. Judges are not evaluating your project against an ideal. They are ranking it against the six they just saw while trying to remember which one had the map. Everything below follows from that. The rubric is real, but it is not what separates teams Most events hand judges four or five categories with numbers next to them. Technical difficulty, originality, design, impact, something about use of a sponsor API. Those categories are real and I filled them in honestly. But they compress. Almost every team lands mid-range on most of them, and the spread that produces a winner comes from two or three things the rubric does not name directly. 1. Whether the demo ran This sounds too obvious to write down. It is the single largest score differentiator I saw. A working demo, live, on the judge's screen or the team's laptop, beats a more ambitious project shown as slides almost every time. Not because judges are impressed by working software as such, but because a live demo removes doubt, and doubt is what a judge is actually managing under time pressure. The practical version: cut scope until something end-to-end runs. One complete path through the product beats four half-built paths. If your architecture diagram has six boxes and two of them work, demo the two and de

Late that night which was two weeks to my final year project defense, I stared at the ceiling thinking about life after school. As a Nigerian, the reality of the economy hits differently from what you imagine. I questioned why I chose to study Computer Engineering only to finish with no jobs and no internships afterwards. And one thing, I knew was that I wanted to work in tech, but I was confused about which particular skill to focus on, since I've been learning Python for a while with no clear direction. Then one day I came across a post on X from a popular influencer sharing a TS Academy scholarship opportunity. I clicked it and applied. Just like that, no long research, no consulting anyone. Few days later I got a mail that I've been selected but there was an application fee. That's where I paused . The Nigerian in me thought anything scholarship is free😂😂, The thought of spending my hard-earned money on something I wasn't sure about but something told me to take the leap so I paid. Few days later I got another email, this one was a email for successful payment with full details and start date. Boom! That's how I chose DevOps. They was no plan, no careful research, it just started with one post, one click and one leap of faith. I did mention it to someone after though. A senior friend. His response? "Have you registered?" I said yes. "You shouldn't have. The job market is so tight." My chest couldn't contain that. But I'd already paid so I went ahead anyway. Shortly after graduation I started learning. And I won't lie, there were times I asked myself why I chose this 😂 Linux commands. Git. AWS. Terraform. Ansible. CI/CD. Docker. Kubernetes. Monitoring tools. Each one felt like a wall and I had to climb every single one. I completed my first project on Bash scripting, second on AWS deployment. And right now I'm in the middle of my capstone Project Phoenix. The deadline passed but I still have a month of grace. Lucky me 😂 In between I stepped away for about a month

I took a week off from Dev.to. Not a planned one — I just sat down last Sunday and realized I had nothing left. Eighteen stories into a 36-story series, and my tank was empty. So I didn't post a single article for a full week. I'd pop into the comments section now and then, but that was it. The day job was still there, but I stopped staying up till 1:30 AM writing like I did when the series first started. I adjusted to a 10 PM bedtime instead. Then on Friday afternoon, something happened. I spent twenty minutes writing a rant about bugs and layoffs, hit publish, and went back to doing nothing. When I checked back on Sunday, that rant had more eyeballs on it than most of my 36 Stratagems stories. You're supposed to have an existential crisis about your content strategy at this point, right? I didn't. The Series That Wasn't a Strategy Eighteen stories ago, I sat down and wrote the first Stratagem. I wasn't starting from nothing — there was a rough outline in my head, a skeleton of 36 chapters with each of the six characters mapped to a specific stratagem. But I hadn't figured out the details of each story yet. Not because I had a content calendar. Not because an editor was pushing me. Because it clicked. The six protagonists — Derek, Lena, Leo, Alex, Mark, and P — had been living in my head long before the first post went up. They came from an earlier series I'd written, 15 stories about AI systems collapsing in the wild. Those people weren't characters I invented for a series. They were people I'd met, worked with, watched navigate impossible situations. They stayed with me because their stories weren't finished. The 36 Stratagems wasn't a strategy. It was a container. I found an ancient Chinese military text that happened to map perfectly onto what I'd already seen happen in AI engineering teams across the industry. The fit was uncanny — like the text had been waiting two thousand years for someone to rewrite it in Python and production incidents. Each Stratagem too

We’ve all been there: It’s 11 PM, the bug is still alive, your tests are failing, and you’re about to throw your laptop out the window. We usually view debugging as a pure logic problem: stack traces, breakpoints, and logs. But Emotional Intelligence (EQ) is often the real reason you fix a bug in 20 minutes instead of 3 hours. Here is how EQ actually applies to your daily workflow: 1. Spotting Tunnel Vision Before It Wastes Your Time Frustration causes confirmation bias. You start forcing your initial hypothesis ( "It MUST be the cache!" ) even when the logs say otherwise. EQ Move: Recognize physical signs like tight shoulders or rage-typing. Take a 5-minute bio-break. Stepping away resets your mental stack, which is usually faster than another hour of blind grinding. 2. Separating code.hasBug() from dev.isBad() A stubborn bug easily triggers imposter syndrome: "A senior dev would have solved this already." That inner voice just adds noise to your debugging stack. EQ Move: Reframe the problem objectively: ❌ "I don't know what I'm doing." (Emotion) ✅ "This async function isn't returning the expected payload." (Fact) Debug the code, not your self-worth. 3. Handling Spicy Bug Reports A ticket comes in: "This is completely broken, who let this ship?!" Your gut reaction might be to get defensive or send a passive-aggressive response. EQ Move: Filter out the noise. Translate panic or bad phrasing into actionable facts. Reply calmly to de-escalate, pull the missing repro steps, and ship the fix without unnecessary Slack drama. 4. Rubber Ducking and Asking for Help (Ego-Free) How many times have you fixed a bug just by explaining it out loud to a peer? Sitting in silent frustration for hours doesn't make you a hero; it just delays the feature. EQ Move: Treat asking for help as an optimization tactic. Send a concise message with context: > "Hey, expecting X, getting Y. Already tried A and B. Got 5 mins to glance at this snippet?" 5. Staying Cool During Prod Outages Panicked