In November 2014 I gave an Alumni Lecture at the University of North Carolina at Chapel Hill Computer Science Department about lessons learned when undergrad/grad school ended & I entered the "Real World".
software engineering at big and small companies. • This isn’t about teaching or academia or if you should go to grad school. • YMMV (your miles may vary) @ J E W E L I A
your expectations for the person in this role?” • “What don’t you like about working here?” Q U E S T I O N S F O R T H E I N T E R V I E W @ J E W E L I A
People like people who remind them of themselves. They often promote people who have the same attributes as themselves. C U LT U R E F I T @ J E W E L I A
people who do it come across as more senior and competent • Don’t disclose previous salary information. Companies want it to get data points about what other companies pay. S A L A RY N E G O T I AT I O N @ J E W E L I A
last forever! —> • The better it is the shorter it will last. • Great ppl are often on a rocket ship. Other ppl know they are great, so maximize the time you spend with them, and hopefully your paths will meet again. PA R A D I G M S H I F T @ J E W E L I A
isn’t to be the Best Engineer but to make sure we are making the right technical decisions that are best for the business. • So what do I do everyday? @ J E W E L I A
OS Fundamentals: processes, threads, CPU vs I/O bound, event based programming, caching algorithms. • Networking: TCP/IP, HTTP, DNS, sockets, • Databases: SQL, atomic transactions, latencies of queries, implications of write often vs read often applications. @ J E W E L I A
E N ! ! • Debugging. Logging. • If you want to really understand how something works, break it. • Pattern recognition from seeing similar problems in the past, developing good intuition. @ J E W E L I A
Distributed Systems: N processes and the execution order is non-deterministic. • Databases: Syncing data across large systems, backup, recovery. • “Someone unplugged the machine”: how to build fail-safe systems that rely on pieces of infrastructure that you don’t completely control (e.g. cloud) @ J E W E L I A
are hard skills to learn in school. • Experience: Learned on the “streets”, building stuff that broke, then building stuff that didn’t break, repetition. Working newer, less mature technologies. • Networking: In the people sense - talking to people who have solved similar problems in the past. • General maturity from being burned: Urging the risk to start writing code before planning/thinking a feature through. @ J E W E L I A
“I’ll fit this function on 1 line! But WTF is it doing? Who knows!” • You are likely not going to be the maintainer of your code forever. @ J E W E L I A