Roshan J

5 things I learnt spending 2 years in corporate - and I learnt them the hard way 🧵

🧵 If you’re in your early 20s, hungry, and actively looking for hustle culture (with real upside, not fake “startup vibes”), here’s a 2026 list of companies I’d aim for from India. Remember, this isn’t a “safe” or “complete” list ;) 🔖 Bookmark for later

I am not talking CXO level, but people w 7-8 years experience are also lost. Maybe they mask it better. I have seen people not knowing what they want to prioritise - should it be work-life-balance, money, satisfaction, title, influence, impact. Often, at this level, people are also stuck in a career they are not even sure they like overall - and often lack the understanding why do they like / dislike their jobs unless it's too obvious. And ofcourse junior people should def do it. But I think a lot of mid-senior career folks would benefit from it too.

A career advice to keep in mind for myself and you too : Keep a private career journal - what you did that day (doesnt have to be too detailed or technical) - did you like what you did, how did it feel - what could have gone better or what do you need to learn over time. Often time, I find people struggling with ambiguity because they have not reflected enough to grow an awareness. Do you really enjoy creating that wireframe or writing that doc with AI? It will also keep a track of all good things you achieved over time or “nice job”s you received. And track of what helps you go in a flow state and what feels like a chore. And what skill you need to build. It will help you figure out what you want from a career. Career journaling is underrated.

#REFERRAL, IF YOU ARE HIRING A TALENTED ENGINEER: @Palakgupta2712 is one of the talented devs that I have worked with for multiple years. Would highly recommend anybody looking for a great engineer to work with. This is what I wrote to endorse recently below. LinkedIn - linkedin.com/in/palakgupta2… cc @Narayani07 @hijunedkhatri @akkiex007

very unfortunate! folks who got laid off -> we @atlassian are hiring across all the roles in engineering, i am happy to refer if you can find something that excites you here: atlassian.com/company/career… and then dm with the job link and a quick 2-3 liners about why you are fit for the role. all the best! i am sure a lot of other tech companies would see this as a chance to hire talented engineers 👍

When HR asks what the salary expectation is, try to avoid a specific amount. For example, if your current salary is KES. 50,000 and the target for a new job is KES.70,000, avoid continuing to say KES70,000. Why? Maybe the company can actually negotiate a salary of KES.70,000 to KES.90,000 for the position you are applying for! So, give the opportunity to negotiate more wisely. Here's an example you can make: 1. Ask for a salary range "What is the salary range for this position?" - Usually HR will give you a salary range, or they may ask you to provide your own budget. 2. If you don't want to give your own budget, you can say "I need to know the range before we move forward, or I'm sure your range will be something I'd be amenable to." 3. But if HR urges you to state your estimate, try to talk "Based on my research and experience, I believe a fair range for this role would be around KES.70,000 to KES.100,000, but I'm open to discussing further based on your budget and expectations." This way, you can still maintain your room for salary negotiation while it shows that you have done your research on the salary range for the position. For CV revamp, email your current CV via cv@oyk.co.ke with subject 'Revamp '

Every engineer I know has asked this at some point: "How deep should I actually go?" According to me, the decision to go deep down the rabbit hole comes down to two things: 1. curiosity - what genuinely pulls you in 2. career direction - where you want to be in the next 2/3 years, not where the internet says you should be My honest take: depth works best when it serves at least one of those. Ideally, both. If something aligns with your career direction, going deep is an obvious win. One simple way to test this is to think in 2/3 year windows and ask yourself: Does understanding this layer actually move me closer to where I want to be? If you are building web apps, you do not need to master CPU instruction sets. If you are working on databases, B-tree internals matter far more than knowing every Linux kernel detail. Context changes what "deep" really means. Abstraction layers exist for a reason. They let you build without getting overwhelmed. A frontend engineer who understands HTTP is usually more valuable than one who has memorized TCP packet headers but struggles to ship features. If something does not align with your career direction, curiosity still matters. Learning out of pure interest is not wasted time. You do it because it optimizes for motivation, long-term learning, and happiness. What does not make much sense is going deep in areas that serve neither curiosity nor direction - often driven by comparison or fear. So keep checking in with yourself. Ask questions. Course-correct often. Depth is most powerful when it is intentional.

Not just BE and FE. Try different areas around SRE, Data Engineering, ML, Search, Payments, etc. In my first six years, I worked in SRE (managing ES clusters and staging/deployment infrastructure), did UI work for internal tools, was a platform engineer (building a couple of central services), wrote data pipelines to cold-tier data (which gave me exposure to embedded databases and MapReduce), and rewrote the entire search. Explore various domains and get exposure to a bit of everything. This helps you (at least it helped me) come up with projects that impact multiple verticals at once, creating a wider impact. Any opportunity that comes your way, grab it, while making sure you do not sabotage your career. Hope this helps.

no new app to open. no complicated setup. just text, and it's logged. built after many bugs, rewrites, and one mid-way identity crisis 🙈 opening beta users now. iampenny.com | Or, DM me

Definition of "Done" in @RealDevSquad

🫶

Today I made my Uber driver wait for 2 min as I was getting out of my house. And suddenly I received a notification from Uber "I am facing the threat of murder" Strap in for a thrilling story 🧵👇

Compilation thread of @tailwiinder's banger tweets which are, according to me, a must read:

For freshers and exp there are a few differences but I can share common tips: 1. Be confident. 2. listen to the interviewer...and ask qs...it is v important 3. Do not jump to answer ; ask clarification (if necessary). 4. Mock interviews (this is v helpful for shy people like me) 5. Research on prev asked questions and: 1. Prepare a short and crisp intro. 2. Every company has core values. Eg: Amazon has leadership principles. Do not learn them by heart but one should know about those. 3. Read about role/JD, and prepare how prev exp can be used. 4. Prepare to talk about projects, success, failure, struggle etc.

50 thousand tweets of mine uploaded as txt in @NotebookLM notebooklm.google.com/notebook/529bb…

Don't ask to ask, just ask. dontasktoask.com

In any interview these could be a few options to answer the question 'Why are you leaving'? - Talk about your career goals. Example: I wanted to specialize in C++, but my role focused on web development. - Talk about financial growth, subtly. Example: I'm looking for a role with more responsibility and financial growth that matches my skills.

When assessing ownership in interviews, I focus on going deep into a candidate’s past projects. I ask them to walk me through a project they’re proud of, zooming in on the key decisions they made at different stages… why they chose one approach over another, how they handled challenging problems, or navigated situations where there were differing opinions or tough calls to make. For example, I might ask, “What was a moment in this project where you had to take a stand or push back on a decision, and how did you resolve it?” Their ability to articulate the reasoning behind their actions often reveals their sense of ownership. I also like to explore their understanding of the broader ecosystem their project lived in. For tech roles, I’ll ask about the CI/CD pipeline… how it was set up, what challenges they faced, and how they ensured smooth deployments. I’ll also dig into third-party services their project depended on, as well as any downstream dependencies that relied on their work. Someone with high ownership typically has a clear grasp of these details, because they’ve taken the initiative to understand the full scope of their project’s impact, not just their isolated piece of it. Of course, some candidates can still fake it… prepared answers are common, as others have pointed out. But I’m willing to bet on someone who can go deep into their projects unprompted, sharing specific examples and showing a bias for action. It’s not foolproof, but in my experience, those who can reflect on their role with clarity and depth are more likely to take ownership when challenges arise on the job. Curious to hear what others think, any other ways to spot this trait in an interview?

Hypotheses on how to talk in interviews link to yt vid in first comment how you are perceived by the interviewer while solving problems - determines whether you are the best candidate or not 1. Use fewer words per 10 seconds to sound mature, thoughtful & composed there are 2 people who solve the same problem in same amount of time one of them speaks very fast, and the other one elongates the words - pauses appropriately, and speaks fewer words per unit time the second person will likely be perceived as someone more mature and articulate sound - less scattered x more structured x less cluttered do not elongate the pauses, instead elongate the words which will likely give you time to think about the rest of the sentence while you speak those words you are not being evaluated for your speed, as much as you are being evaluated to be a partner in the problem solving process - and thus articulation matters a lot 2. Whenever you are asked a question - imagine what a calm and composed person would do they will not be too excited to jump to solutioning, instead they will likely take a couple of seconds to think about the problem and might even ask for a couple of minutes to compile their thoughts first - most people are waiting to speak - they are uncomfortable with silence - and thus want to fill the silence with what they think is an appropriate (though hurried) response you should avoid this - immediate response / reaction habit this will set you apart, because this also means, you are less likely to interrupt the interviewer while they are speaking most people are waiting to say something, do not be like most people you may or may not be a good listener, but by following this SOP - you can at least for the period of the interview try to be a good listener 3. Always validate + clarify assumptions before moving ahead with analysis this is underrated - and surprisingly missed by most folks - because they have often seen the same question elsewhere but if you can slow down the process of problem solving - like a calm and composed person would do, you will be able to impress the interviewer with your thoughtfulness and attention to detail 4. Use low stakes or low intensity or low drama vocabulary to invite better problem solving conversation with the interviewer often problem solving can feel like a deterministic journey - where there is only one way to solve the problem but this is a conversation which is btw supposed to simulate a relationship between 2 colleagues - both you and the interviewer are supposed to behave like colleagues e.g. This will not happen = it has become a binary process 1 or 0 - yes or no so the stakes are higher now, and thus whoever said this - you for e.g. will now find yourself in a game of yes and no with the interviewer - instead of treating your approach as an open ended conversation alternate - I think this may not happen - I think this is a low probability event the above 2 low drama, low stakes expressions - invite a more open ended conversation nobody will find it difficult to back track from their stance because the stakes were not raised too high this is quite important in collaborative problem solving - That won't happen❌Vs. I think that is a low probability event✅ - This is the best way❌ Vs. One of the better ways✅ - I believe ❌ Vs. My hypothesis is✅ - But what happens when the user clicks on A ❌ Vs I am wondering if using this approach we will be able to cover a use case where say the user clicks on A ✅ low dram conversations sound boring - because they are low intensity - toned down - loquacious - but they make the problem solving process less ego-driven because the parties do not aim to prove themselves right using probabilities - instead of absolutes (extreme binary expressions) - you may sound less confident - but you will be perceived as someone who is more open to feedback and more easy to work with summary: you are not there to prove yourself right - you are there to prove that you are a good potential colleague intensity often draws extreme reactions from people around you - and using low drama communication you can avoid that, especially in an interview game where your job is at stake play gracefully - and be a likeable person they are literally trying to test if your future colleagues would like to work with you or not