Ace your next technical interview (tool to upgrade your skills as software engineer and get your dream job). #BuildInPublic
New York, USA
- Tweets 549
- Following 595
- Followers 404
- Likes 70
Pinned Tweet
Taking action everyday, rehearsing what you already know or learning something new beats someone doing nothing. Keep learning, keep building. AI may write your codes, but you still need to know how it works under the hood.
1
1
4
143
AI Engineering interview question:
If we need an LLM to answer questions about internal, constantly changing company documentation, how would you decide whether to solve that with prompt engineering, RAG, or fine-tuning?
2
1
51
For constantly changing data, RAG is the standard choice because it fetches the latest documents at query time without modifying the model. Fine-tuning doesn't make sense here since retraining every time a doc updates is slow and expensive, plus it's intended for teaching style or format rather than dynamic facts. Plain prompt engineering also fails at scale because you can't fit an entire company knowledge base into a single context window efficiently.
13
AI Engineering interview question:
If you're building an agent that calls external tools to solve a task, how does the back-and-forth loop between your code and the model actually work from start to finish?
1
4
76
You send the user prompt along with schemas of available tools to the model, and if it needs external data, it returns a structured request naming the tool and arguments instead of a standard text answer. Your code intercepts that, executes the actual function locally, and appends the tool's output back into the message history. Finally, your code sends that updated history right back to the model, repeating the cycle until the model decides it has enough information to output the final response.
2
28
What is the Jev’s alternative everyone is talking about? Laya is an open-weight (Apache 2.0) "System 1" decision model from Convai Innovations, built by Nandakishor M as an open alternative to TypeSafe's closed Jev API. Instead of generating text, it takes a state (text, an email, a ticket, or JSON) plus typed questions (choice to pick a label, score to place something on an ordinal rubric, and noul for a yes/no probability) and answers all of them in one forward pass in about 33–40 ms on a GPU, so there's no output to parse and nothing to hallucinate.
It comes in three checkpoints: a 421M-parameter English model on ModernBERT-large, a faster 322M multilingual model on mmBERT-base covering 100+ languages, and a variant fine-tuned for typed-decisions workflows. A built-in Router detects the input's script and sends it to the right checkpoint. It's trained with RLCD, a reinforcement learning method whose reward uses strictly proper scoring rules, so the model maximizes reward only by reporting honest probabilities; it also has an act-vs-escalate head for deciding when to hand off to a human.
The author reports strong results, including beating Jev on AG News, emotion classification, and the typed-decisions benchmark while running roughly 6–8× faster, though the Jev figures are third-party numbers rather than head-to-head runs. The model card is also candid about its limits: the base checkpoints are near chance on typed-decisions without fine-tuning, accuracy drops sharply with 50+ options (Banking77: 0.425 vs. Jev's 0.870), ordinal scoring is its weakest question type, the English checkpoint fails on non-Latin scripts, and the models ship overconfident, so you need to fit a temperature on your own data before trusting the probabilities.
Source: u/Balance from r/LocalLLaMA
2
2
47
If your package.json already lists all your dependencies, why do we bother committing package-lock.json to git?
3
2
96
The core issue is that package.json typically specifies version ranges with carets or tildes, so running npm install on different machines or on different days can pull in different patch versions and nested dependencies. The lockfile pins down the exact dependency tree and integrity hashes, which guarantees that production, CI, and every developer on the team are running identical code.
1
34
DB: If you're starting a new project, how do you decide between using a relational database versus a NoSQL store, especially when it comes to the trade-offs the CAP theorem forces you to make?
1
2
58
Relational databases traditionally prioritize consistency, meaning during a network partition, they'll block writes to prevent data corruption rather than return stale reads. Most distributed NoSQL systems prioritize availability instead, staying online during partitions at the cost of eventual consistency. The decision boils down to whether your app can't afford to be wrong, which points to relational, or can't afford to go down, which points to NoSQL.
1
34
When you're setting up authentication for a new REST API, how do you usually decide between using traditional session cookies versus tokens?
4
2
104
The practical rule of thumb comes down to your clients: if you're building purely for a browser frontend on the same domain, session cookies are great because the browser handles storage and sending them automatically. But if your REST API needs to support mobile apps, third-party consumers, or separate frontends on different domains, tokens sent in an Authorization header are usually the way to go since they're stateless and don't rely on browser cookie handling.
1
37
DevOps: When you're rolling out a new release to a live service with zero downtime, how would you decide between using a rolling deployment versus a blue-green deployment?
The trade-off here really comes down to infrastructure cost versus rollback speed and complexity. With blue-green, you run a duplicate environment and cut traffic over all at once, which makes rollback instant, but it's expensive because you need double the capacity. A rolling update is cheaper because you replace instances incrementally, but you'll have old and new code serving traffic at the same time, so your backend and database have to stay backward-compatible.
What's your favorite deployment strategy?
2
2
204
AI engineering interview:
If you're building a chat application and a user's conversation gets long enough that it's going to overflow the context window, what strategy would you use to decide what gets kept, summarized, or thrown away?
Check comment
2
3
76
The common pattern is a hybrid approach where you always keep your system prompt pinned at the top and keep the most recent few turns completely intact so the model follows the immediate conversation. For the older messages in between, you either compress them into a short running summary using a secondary model call, or you just evict the oldest messages entirely using a simple sliding window.
1
34
When you're designing an API, how do you decide whether an endpoint should use a PUT or a POST request?
#SystemDesign #LearningInPublic #BuildInPublic #Coding #DSA #LeetCode
1
4
86
CS Interview question:
How would you compare TCP and UDP in terms of the guarantees they provide, and what's the biggest tradeoff you think about when choosing between them?
#SystemDesign #LearningInPublic #BuildInPublic
3
3
135
The core difference is that TCP guarantees reliable, in-order delivery through connection handshakes and retransmissions, while UDP is connectionless and provides no delivery or ordering guarantees at all. The primary tradeoff you're making is reliability versus latency: TCP accepts overhead and delay to ensure every byte arrives intact, whereas UDP trades those guarantees for raw speed, which is why real-time systems like voice calls or gaming prefer it.
2
68
CS Interview question:
why is it totally fine for a browser to automatically retry a failed GET request, but you wouldn't want it doing that with a POST?
#leetCode #DSA #ComputerScience #AI
#Programming
1
2
105
The big difference comes down to side effects: a GET request is just reading data, so fetching it two or three times doesn't change anything on the server. A POST request usually creates or modifies something, like placing an order, so automatically retrying on a network hiccup could end up charging a customer's credit card twice.
59