Conversation Starter
Related Posts
Is Yelp a good firm to work for?
Additional Posts in Jobs in STEM
I recently interviewed for L7 EM at Google and had 4 great interviews and one not so great system design. I submitted external referrals all of which gave great feedback. The recruiter said the next step is team match/interviews and then the HC. Anyone in a similar situation? What was the result? Google
New to Fishbowl?
Download the Fishbowl app to
unlock all discussions on Fishbowl.
unlock all discussions on Fishbowl.
Critical thinking and problem-solving separate us from the AI, at least. Of course, I’m sure we’ve all worked with people who lacked those skills.
Learning how to learn. The specific skills/tools/tech will always change. Being able to pick them up quickly is vital. My 1B answer would be communication. It seems obvious, but there are tons of technically brilliant people who stagnate because they're god awful at getting their point across and getting along with others.
So many! I have been building tech systems professionally for 25 years.
#1 Big picture thinking and understanding the customer/user. The best possible technical implementation to the wrong problem still sucks from the user/customer perspective.
#2 Understanding the inherent trade-off that always exists like CAP theorem or PACELC theorem. New tech/tools doesn't change this. Some things, like the speed of light in fiber, don't change.
#3 Communication: between people, project, teams, and users. So many system problems start or are exacerbated by problems communicating or understanding. Mars Climate Orbiter is a classic example. The newest DB or AI Tool doesn't solve this problem.
#4 Latency: Also covered by #2. Modern distributed, highly available, systems frequently have significant latency challenges. Knowing how to build systems like this transcends tech tools.
#5 Understanding tradeoffs: Language, design, architecture, location, tool, OS, DB, deployment strategy, complexity, availability, cost, etc etc etc. A real system has dozens and dozens of trades off. Very frequently they are over/under engineered and/or trade-off were not fully considered. There is no free lunch, cool tech doesn't eliminate this need. Sometimes it makes things worse. For example, consider the complexity, cost and latency tradeoffs of kube cluster vs server less function.
#6 Understand technical fundamentals. You don't need to build a CPU from scratch however you do need to understand that there is an OS, CPU, RAM, and storage somewhere running your tool/code/system. There is a network between them. On top of that is your application doing things. In the real world compute, networks, and storage are being used for everything we do in tech. They directly or indirectly impact everything we do.
#7 Security. Security sucks, it makes life hard, yet it's required. Protecting your systems, information, access, integrity, etc is independent of specific tech. Ignore at your perel.
Chief
Long term, I think the real skill is knowing how to work with AI. If AI can personalize answers and do the heavy lifting, the value shifts to asking the right questions, understanding the output, and applying it to real problems.
What do you think of M olt boo k?
Busines fundamentals. Ai can still hallucinate and return wild results. The man in the middle and guardrails can identify data skews and be the sober second thought on actioning ai recommendations.
Chief
I think critical thinking and communication matter most. Tools change fast, but being able to frame problems, question assumptions, and explain decisions clearly survives every technology shift.
Rising Star
Fundamentals stay the same. Basic contextual things have remained the same for me across all tools.
Think through your code to make sure the first and last time through the loop will always work, before you check it in.
Never switch on string variables - convert them to enums - that way typos won't compile, let alone run and sneak into production.
Worked extensively with AI programmer: the AI is trained by overconfident, lousy programmers. The only way to keep programmers with 20+ years exp from guiding software dev is to use "senior" after only 5 years experience. Oh, we're already doing that.