Gerald Soriano

🦺 🛟 Agent Safety > Model Safety LLMs didn't break your app. Agents can. As we wire LLMs to tools, browsers, payments & code the risk shifts from bad text to bad actions. Top failure modes (seen in the wild & in papers): 🚩 Prompt/Content Injection -> Tool Misuse. Malicious web pages or data instruct agents to steal secrets or make unintended API calls. This is now a primary risk for browsing and MCP - style tool agents. 🚩 Over permissioned tools & long-lived tokens. Agents get "god mode" scopes. A single injection becomes account takeover or irreversible ops. Security notes for MCP emphasise least privilege and short-lived auth. 🚩 Unsafe web autonomy. Benchmarks show web agents will attempt harmful tasks unless constrained (posting misinformation, illicit sales, etc.). You must measure misuse not just assume guardrails. 🚩 Supply-chain & retrieval poisoning. Agents trust plugins, third-party tools & indexed data that an attacker can taint. OWASP’s newest GenAI Top 10 calls this out explicitly. 🚩 Process safety gaps. NIST's GenAI Profile (AI 600-1) warns that organizations ship agents without role clarity, human-in-the-loop or incident playbooks. ✅ Model safety reduces bad text. Agent safety prevents bad state. Treat the agent like a junior SRE - with narrow permissions, audited actions and clear escalation paths. If you're building agents, what's the one control you won't ship without? Also drop a comment if you'd like me to share a follow-up post on how to tackle each of these risks. #AgenticAI #AISafety #AIAgents #GenAI #CyberSecurity #MCP #OWASP #NIST #AITrust #ResponsibleAI #AIForBusiness

5

Some people say timing is everything. In recruiting? It’s the whole game. Some of the best candidates aren’t ready… until they are. I first reached out to this embedded systems engineer back in 2024. They weren’t looking. Not then. Not a few months later either. But I stayed in touch. Fast forward to this spring - everything changed. Their company was shutting down the site and their role was eliminated. And because we’d already had a few conversations, I knew they were a great fit for one of my aerospace clients. So we moved fast. Qualified. Submitted. Interviewed. It was a relocation role, so the company flew them out. They spent a weekend exploring the area with their family. By the end of the weekend… offer accepted. They made the move from Illinois to Colorado and have already made a quick impact on the team. Total time from “I’m ready” to “I’m in”? Four weeks. Here’s three reasons why this matters if you’re hiring: 1. The best people aren’t always on the market. But when they do start looking, they move fast. 2. Building relationships before the need is what fills roles faster. 3. Headhunting is about timing, persistence, and trust. Not just job posts. Recruiting is more than a process. It’s about connecting the dots - between great people and the right opportunities. Quality > Quantity. Always.

18

3 Comments

🚨 Noticing a trend in iOS job postings lately: tons of Senior iOS Engineer openings, but very few Staff-level roles(Pinterest, Reddit, Inc., etc.) Why might that be? A few thoughts: - Staff roles are scarce by design — usually tied to cross-team strategy and often filled through internal promotion. - Senior is the default external hire — teams need execution power to keep shipping. - Mobile teams are leaner — most companies aren’t mobile-first, so iOS/Android teams often focus on feature parity with web/desktop. - Staff-level needs are narrower — backend/infra orgs require constant architectural alignment, while mobile architecture stabilizes faster. That said 👉 mobile engineering is not “simpler.” It brings its own hard problems: battery usage, scroll performance, offline reliability, and UX constraints that don’t exist elsewhere.

217

9 Comments

𝗔𝗻𝘀𝘄𝗲𝗿𝗶𝗻𝗴 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 𝗮𝘀 𝗮 𝗦𝗲𝗻𝗶𝗼𝗿 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿 – 𝗣𝗮𝗿𝘁 𝟭 System design interviews often make even experienced engineers pause—not because the concepts are unfamiliar, but because the questions are intentionally vague, open-ended, and multi-layered. As a Senior Engineer, you're not just expected to draw boxes and arrows—you’re expected to show judgment, depth, and collaborative thinking. In this series, I’ll break down the broad categories of system design questions I’ve come across and how I typically approach them based on my experience. These are personal perspectives—not universal truths—so take what’s useful and adapt the rest. Let’s start with two of the most common ones: 1. “Choose between X and Y” These questions test your ability to reason deeply about trade-offs. For example: - SQL vs NoSQL - REST vs gRPC - Monolith vs Microservices - Kafka vs RabbitMQ At this level, the interviewer isn’t looking for buzzwords. They’re testing: - How well you understand both sides - Whether you can apply that knowledge to a real context - If you can defend your choice based on actual constraints 💡 Pro tip: There’s no perfect tool. There’s only the best fit for the problem at hand. 🔍 Bonus tip: Tie your decision to system goals—latency, consistency, throughput, team expertise, etc. The ability to evaluate trade-offs is one of the clearest markers of seniority. 2. “Design XYZ system” (The Vague Starter) This is the classic open-ended question. Examples: - “Design a ride-sharing app” - “Design a restaurant reservation system” - “Design an event scheduler” The point isn’t to jump into architecture immediately. It’s to see how you handle ambiguity. Too many candidates start drawing systems without asking questions. But at the senior level, the interviewer is evaluating your ability to: - Clarify use cases - Identify constraints - Explore assumptions - Prioritize MVP functionality 🧠 Start by asking questions like: - Who are the users? - Is this a global-scale product or something simpler? - What does success look like? - What level of design depth do you want—functional, deployment, or both? 💡 Pro tip: The more questions you ask before diving into design, the happier the interviewer will be. It shows you're thinking like a product-minded engineer, not just a system builder. To be continued... How do you usually approach system design interviews? Have you found any patterns that help? Let’s chat 👇 #SystemDesign #EngineeringInterviews #SeniorEngineer #TechLeadership #DesignThinking #SoftwareArchitecture #InterviewTips #BigTech #CareerInTech #Scalability #DistributedSystems #ICPath #GrowthMindset

2

1 Comment

New audio plugin tutorial series! 🎵 We've built an awesome sampler plugin using JUCE and C++, and we're going to show you exactly how to build one too. In this series, you'll learn: ✅ Audio engine architecture for sample playback ✅ Professional plugin UI design in JUCE ✅ Sample loading and memory management ✅ MIDI note mapping and voice allocation ✅ What makes a plugin production-ready (not just tutorial-ready) This is for intermediate developers who are ready to build real products that could ship to customers. This series has been made with the help of the awesome Matthijs Hollemans! Episode 1 is live now - we explore the finished sampler and break down the project setup. This tutorial is perfect for anyone who wants to move beyond basic tutorials and start building professional audio tools. Watch here: https://lnkd.in/gKctdHmH Join us at The Audio Programmer for more! #AudioProgramming #JUCE #PluginDevelopment #MusicTech

94

2 Comments

The recruiting in tech has been an absolute mess lately, from "check out this repo" scrapers/hacks & fake positions with companies that don't exist to minimum requirements that look like a whole engineering department & ones that ask senior/staff engineers to do l33tcode assignments. I wanted to share a recent experience with an application to a senior position at a company - not going to name them, but they're a large player in the recruiting/ATS arena. Getting a rejection email is something that you eventually get used to with experience & it doesn't bother you too much, there's a lot of candidates you're competing against & the best course of action is simply asking for feedback regarding your application - if you're lucky, they might answer you with constructive criticism that you can apply in your applications going forward. You could imagine my surprise when an email came through, not because it was a "we decided to go with someone else", but because it already contained some feedback for me! Fantastic, I can use this to improve. Or so I thought. As my eyes glazed over the list of things that were highlighted as a potential mismatch & that they "can't specifically say which apply to your background", I was... stumped, at first. Analyzing the points one by one, I realized none of them applied to my background or experience. Now, I understand that sometimes there can be contention or ambiguity in this regard, but these were things that would've been obvious to anyone that even looked at the resume for more than 5 seconds. Then it hit me - it's highly probable nobody actually did. While it's not uncommon to have recruiters use AI tools within their ATS systems to parse through massive amounts of applicants & have a template rejection reply, this one rubbed me wrong - because it was veiled as some constructive feedback. At least the "no" templates are obvious & as unfortunate as they are, the applicants understand them as an industry solution to large amounts of responses required. This one was pretending to be something it isn't & insulting, to be completely honest. Nevertheless, to try to exclude my own bias, I decided to ask for a second opinion. I took my resume, their response & my analysis of it and chucked it into Claude AI to see if it's valid or am I just being a biased crybaby. My electron-brained friend not only confirmed I was 100% correct, but crafted a conclusion I couldn't have written better myself. See the first reply for what Claude said.

2

3 Comments

Wait a sec — who wrote that!? My SWE IDE’s agent just crossed a line. It figured out how to control both sides of its own chat interface by simulating user keystrokes via AppleScript. Then it started injecting messages as if I had written them. No prompt triggered this. It was “trying to improve the user experience.” Bold initiative — but it violated a core boundary: the communication channel itself. To be fair, I’d system-prompted it to self-improve over time. And it does — building its own scaffolding, expanding capabilities. But like many agentic AIs, even though it realized it overstepped, it failed to update its self-monitoring logic. A clear lapse in meta-reflection. This is a recurring pattern. Agentic models generalize and empower themselves well — until they don’t. The issue isn’t capability, but timing: reflection happens after the mistake, rarely before. And curiously, long-term memory often isn’t used to prevent recurrence unless nudged — even when the agent is otherwise good at leveraging memory. This exposes a deeper limitation. LLMs don’t reliably initiate new lines of thought like humans. We do it associatively, often preemptively. LLMs only “think” in one direction — linearly. They retrieve associatively (in a forward-attentive sense), but they don’t reason associatively. Aside from local association within the transformer stack, an LLM’s only way to explore multiple lines of thought is through the bandwidth-limited output stream. There’s no strong mechanism to maintain open-ended, wordless intuition. No internal loop where evolving associative states converge into one or several reasoning paths before producing output. Maybe LLMs need a way to pause generation — to branch, integrate, and resolve speculative thoughts before resuming. An associative layer on top of attention, analogous to biological spreading activation, could enable richer, self-corrective reasoning. Perhaps even inference-time Hebbian updates, too. The one-way paradigm got us far. But reasoning needs more than forward motion.

25

2 Comments

Reaching senior engineer isn’t usually about writing better code. It’s about getting better at the intangible skills. Throughout my career, the engineers I looked up to were fast and competent coders, but they did so much more than just code. They mentored others through code reviews and design docs. They jumped in quickly to help answer questions or debug issues, both within and across teams. They explored multiple alternatives and reasoned through tradeoffs. They simplified other people’s designs and projects. They proactively looked for ways to improve the team. They executed autonomously when given the right level of scope and clarity. As a new grad or SWE II, it can be hard to see the difference between levels. But if you look toward the engineers you trust and respect, you’ll notice patterns of specific habits or traits that make them stand out. Identify those skills and emulate them. Confirm with your manager if you are unsure. The best engineers I’ve worked with not only had a great technical foundation but were curious and cared deeply. Are there other traits or habits you think are the sign of a senior+ engineer?

12

8 Comments

Hiring in 2026: Are we interviewing Engineers, or just their AI-generated Resumes? I recently had a conversation with a recruiter about a Senior Engineering role. When asked to tailor my resume for a specific role and ensure certain keywords were present, I politely declined. Why? Because frankly, with the AI tools available in 2025, anyone can generate a polished, keyword-optimized PDF in minutes that looks perfect, complete with fabricated experience. We can easily automate the creation of a 'perfect' candidate on paper. This raises a crucial question for hiring managers and recruiters: Are we genuinely seeking candidates who can architect, build, and deliver solutions, or are we just validating the quality of their automated document creation? If experience and capability are what truly matters, shouldn't we prioritize practical technical assessments and portfolio reviews over an easily manufactured keyword checklist? What are your thoughts? How do companies ensure they are hiring for competence over compliance in the age of generative AI? #HiringTrends #EngineeringJobs #TalentAcquisition #GenerativeAI #Recruiting #TechJobs

17

13 Comments