Uncategorized

For prospective and new software engineers

(I originally wrote this in response to one of my alma mater’s FB CS group alumni posts touting the best classes to take for a “successful” career.)

A reminder that you shouldn’t treat anyone’s Buzzfeed-like “Top 10 CS Classes that will make you rich!” as the word of god. And just because you don’t work for FAANMG (Facebook, Amazon, Apple, Netflix, Microsoft, Google) doesn’t mean you are a failure. Your course selection and performance from college and your first job aren’t going to be the primary indicators of your success later on. Your drive to improve yourself through hardship, technical and non-technical, is what will take you to the moon.

It’s almost summer time. Many of you will be starting internships, many will be starting new full time jobs, and many of you will not yet have a job in hand at all. For those of you who do not yet have a job, it’s OK. This does not mean you are inferior to your peers and it does not speak about your abilities as a software developer.

Please do not beat yourself up over this. Finding a job is not as easy everyone else may make it look. What a lot of people don’t mention in addition to the technical skills that companies want, a large amount of soft skills, and especially LUCK of all things play a part as well. Finding the right company is a lot like dating. Many of your dates will go horrifically wrong. Some of them will be OK. Some of them will be great. You may not find the right fit for several months, and perhaps even years. But it isn’t the end of the world. It’s about finding the right fit. Sometimes things look like a right fit and they turn into a nightmare. Sometimes things look terrible but they turn out wonderful. You can be the best version of yourself and still get rejected a hundred times over. Don’t take it too personally.

The truth is you really have no idea what’s good for you and what isn’t until you work somewhere (multiple places, usually) for some amount of time and see for yourself. It has taken me working 5 years full-time across 3 different companies to understand this better, and I am still figuring it out.

Everyone is going to go down a different path in their career, and some classes will be more relevant to some people than others. Some people will do web development. Some people will do embedded systems. Many will do a combination of many different things. High level or low level? These are relative terms – today’s high level might be considered low level tomorrow. Niche spaces can make you a ton of money. Non-niche spaces can make you a ton of money. You can take advantage of startups and large companies, and you can bet they can and will take advantage of you.

Realize that the classes in undergraduate will only cover a sliver of the problems and depth of detail you will face in the future. This is especially true if you work in a space that is the intersection of multiple domains, where you might end up having to constrain and define the problem space yourself.

Don’t just blindly follow the advice of someone who looks like they have “made it”. There are many paths to “success”. Introductory CS classes are important, but that’s the same as saying fundamentals matter. Fundamentals do matter; you may not use all of them all the time, and your skill for each one can vary over time. Different jobs will end up using different subsets of your fundamentals. And some fundamentals are more important to specific domains. Fundamentals are harder to master than they seem. I think I might be approaching basic proficiency now for data structures and algorithms for the sake of passing technical interviews, but also recently orthogonality, testability, and avoiding premature abstractions in heavily trafficked applications.

Look, do your best in a few courses or skills that interest you, and pay attention to ones that others speak fondly of. If you find that missing knowledge in some area is obstructing your progress, then take the time to get better in that area. This is easier said than done and can be very time-consuming. Grades mean something, but they aren’t the ultimate indicator of learning. Something you will realize is that this career (like all others) requires a lifetime of self-learning.  There will no longer be any grades to tell you if you did a good job or not. You will have to find ways to wring honest feedback out of your peers and managers, and sometimes you will have no one to turn to at all.

My GPA at university was not particularly high, but I want to stress to students that my many academic failures are what taught me the most about myself as well as what and how I needed to improve.

Getting the lowest rank on a midterm or final? Been there, done that. A professor told me that he was actually impressed that I managed to get the lowest score on his exam. Flamed out in an interview? Oh yeah, plenty. I’ve failed to code a simple O(N) algorithm that was just supposed to add spaces after numbers once because I was so nervous, right after the introductory CS classes. I’ve made similar mistakes even years out of school over simple list merges. Thank you, nerves of shit.

Don’t be afraid to fail. I was really depressed for a good portion of my life because of this fear. At school, I was approaching academic probation. I was sick all the time. I knew what was wrong with me, but I hesitated and sandbagged on changing the things. Why? I was afraid of what would happen if I failed trying to fix them:

“I know I need to actually do lots of practice problems instead of just skimming the reading material and creating a study card. Hmmm…but what if I fail at that and my grades get even worse? What if I get kicked out of school? What will my parents and my friends think? Oh man, my family poured so much money into my education, I am going to disappoint them so hard, they’re going to disown me.”

“I don’t sleep well because I don’t exercise and I use all my pent up energy to obsess over all the things I didn’t do today (like my proposed set of study habit changes) and all the ways I am fucking up. ” Cue positive feedback loop of bad sleep begetting bad sleep.

I was a rather despicable person since I was aware what was wrong, but did nothing about it for the longest time. So after this one night of crying my eyes out feeling sorry for myself during my 3 AM pity party, I had this epiphany that things probably couldn’t get much worse no matter what I did.

I started working on the things I was afraid to fail at, afraid to get better at. And failed I did. I failed many, many times. But I eventually found some things that worked. My GPA actually crept up towards the end of my college career, but not too high since the damage was already done. ¯\_(ツ)_/¯

I graduated in 2014 and I have worked for small and large sized companies. I can detail what the interviewing experience is like 4+ years out of school. I have never worked at FAANMG etc, and I don’t consider my career a failure because I haven’t worked there. I know people who work at the big five and surprisingly making 350k a year doesn’t always magically bring happiness to your life. Many, if not all of these companies, are wrestling through some serious ethical issues. Some people spend months waiting for a petition to pass so they can add logging of all things to their god forsaken project. Don’t forget about perverse performance incentives. I’m not saying this can’t happen elsewhere, it totally can. My point is that employment at these places is subject to the same problems as anywhere else. It’s not the end of the world if you don’t work there. I’m sick of this cargo cult mentality that working at one of these companies will instantly fix your life’s problems.

I’m still not that great at algorithms interviews, but I think I still do good work today despite my college GPA and work history. (If you’re bored, check out my shameless plug for open source contributions: https://github.com/Netflix/Hystrix/issues/1756).

Something I would stress to other students is to give yourself enough time to retrospect and introspect on why you failed, and if you are having difficulty with that to not be afraid to ask for help.

If you are trying to improve yourself, it is fine to look to others and try to emulate their behavior. But just remember you won’t ever be exactly like them, because you are you. You have your own sets of strengths and weaknesses, and you should play to them. If you don’t know what these are then you had better figure them out soon, before you get rekt too hard. And to be honest, sometimes the world does need to eat you alive. Sometimes things need to get worse for you before they get better, you need to have a real failure that shakes your foundations and gives you a wake up call.

This may sound dramatic, and some of you may never have a moment like this because your disposition allows you to succeed indefinitely. Yes, there are real geniuses among us, and they will outdo us at probably everything. Whatever, this is for the rest of us. I’m really not that smart, so take my two cents as you will.

Again, the point of this post is not to say HEY LOOK AT ME AND MY ACCOMPLISHMENTS, my point is that my accomplishments are my own and yours are yours. Don’t use me or anyone else as some kind of yardstick to measure yourself against. You will live a miserable life if you are always comparing yourself to your peers and asking who works where, who is more popular, who is richer, who is more prestigious. I still grapple with this, it is difficult but I recognize that if I cannot make peace with this I “will die a million deaths before they finally grieve [me]” [1].

[1] Taken from “This is Water”, a commencement speech written by David Foster Wallace. I highly recommend this to live a more fulfilling, less frustrating life.

Ask HN: Do you like your company’s interview process? If not, what are the reasons you can’t or won’t change it?

HN (Hacker News) Discussion: https://news.ycombinator.com/item?id=16673369

If you do like it, what does it do well? If not, what are you doing to help change it or why is that difficult?

I’m asking this coming fresh out of a recent series of interviews I did. After spending about 5 months studying for today’s software dev interviews (detailed below) and generally despising the process, it makes me think that most people (?) think that the current state of software interviews is sane and that most everyone else is way better at them than I am. I originally wrote this post for my alma mater’s FB computer science group but would like to get more perspectives on this.

This is my attempt at rebooting this thread in perhaps a more constructive manner: (https://news.ycombinator.com/item?id=12667174)

Welcome to the Tech Interview Torture Chamber

This is what ~140 hours of post-work day interview preparation looks like for a mix of 100+ medium and hard LeetCode problems (left stack): https://i.imgur.com/uaa8T5z.jpg

uaa8T5z
I interviewed at over 10 companies in the period of 2 months. I did over 16 technical screens and 2 take homes. I moved onto on-sites for 70% of these technical screens. I did 4 on-sites and received 2 offers, one of which I accepted.

I have 4 years of work experience in backend and frontend web applications, working mainly in Java and Javascript with a B.S. in CS. I spent 1.5 years at a large company, 2.5 years at a startup / small company. All prep was done after working 45-50 hours a week. I was never great at solving the algorithms and data structures problems in timed situations. The thought of getting stuck while the interviewer interrupts me every 15 seconds with “it can be done in constant time!” still wakes me up in cold sweat at night.

I was asked all sorts of questions that had barely anything to do with my actual day to day experience, often in an arrogant and condescending tone.

Examples of interviewer interactions:

  • After I caught my own logical error and corrected it: “OK, now we’re back to *REAL* engineering.” – 3 years of experience at a social networking company
  • After asking if the interviewer would like me to finish coding the current problem or move onto the next since we only had 10 minutes left: “Well, as a software engineer, I would expect you to produce code that ACTUALLY runs?” – 1.5 years experience S.E. at a ride sharing company.
    I actually solved it and the next problem in the time but I still didn’t make it to the on-site. ¯\_(ツ)_/¯
  • “This isn’t the way I would have done it, but I know for sure that there’s something wrong with your solution, even though I can’t find what it is.” – 4 years experience at some startup, a proud MIT alumni. I just smiled and nodded as I retreated into my inner mind and screamed at the top of my lungs.
  • After whiffing a problem and asking about my experience: “Did you simply configure this application or did you actually code it?” – 20+ years experience at a social networking company. Yes, I did design and implement the whole thing myself. Don’t be an asshole.

Personal learnings

– Much less anxiety when doing interview problems in front of an interviewer. For me this was the biggest thing. A lot of this comes from realizing that people can ask you anything under the sun and if you get a problem you’ve never seen before, you are probably fucked in the sense that it’s sort of unreasonable to solve it in 25 minutes under extreme pressure.

There are so many other factors that are out of your control including the interviewer’s mood, if they like you, laugh at your jokes, are biased toward sex/race/orientation, experience of the interviewer in interviewing, how much they want to help you or make you struggle, etc.

Uh OK. At this point, there’s more to a job than reversing a binary tree in 5 minutes or applying dynamic programming to word break. Does not figuring this stuff in the allotted time limit out make me a bad developer?

– Learned to “play along” to get through the interview. I always try to reason through a disagreement or gap with the interviewer, but sometimes they are hell bent on getting you to do things their way – even if it’s wrong. If it’s not an important detail, see if you can come back to it later. If you are at an impasse, just nod and use the interviewer’s own language on them.

– Did I actually get better at algorithms and data structures?
I suppose…I think it made me more familiar with some algorithms or data structures I don’t normally use. I think it is enough to be exposed to the concepts, know that they exist, and search them up online. If you can code, you are at least capable of understanding arbitrary implementations given enough time. If anything, I think it protects against the “If you always use a hammer, then everything looks like a nail” type ideology. Now, is it really required for you to do 140 hours of leetcode? I’m not sure, isn’t that what design and code reviews are for?

What the current state of our industry’s hiring process tells us about candidates, from my personal experience:

– You are an algorithms and data structures savant and use all of them on a regular basis.

– You studied a lot of the problems in Cracking the Coding Interview, Elements of Programming Interviews, LeetCode, HackerRank, Project Euler, InterviewBit, etc.

– You lucked out because you have already seen or done max-stack before. Congratulations on your 300k / year salary.

What it doesn’t tell me, having been both an interviewer and an interviewee:

– How does this person think when I don’t interrupt them every 30 seconds to “see how they think” while they write code on on the top left part of the whiteboard without IDE support as I stare at them for 20 minutes straight.

– How does this person get unstuck when they have access to multiple resources, instead of relying solely on the interviewer?

– What kind of quality work does this person produce in a normal work environment where someone isn’t breathing down their neck?

– Can I work with this person on projects that span weeks, months, or years?

Some of these issues can be mitigated by an empathetic and experienced interviewer but I still think these interviews are incredibly stressful.

Look, obviously no interview process is perfect because no test is perfect. Take-homes are extremely time consuming and applicants are dis-incentivized to do them in the interest of time*. They are also extremely risky in the sense of burn out. You can easily spend 12+ hours on a project, get rejected, and have zero feedback provided as to why. Thanks for not paying me for my work, shall I publish your take-home on GitHub? Not saying I would do this, it’s just an incredibly frustrating experience.

[* One way to get around this is to give a HackerRank time-boxed for 3 to 6 hours.]

Making the process better

I still think work samples are the gold standard (echoing the sentiments of tptacek). I know people who are trained and/or naturally good at these algorithmic problems that have expressed that this process is not particularly good – just ask the former CTO of Stripe or anyone else who works there.

3-4 hour work sample problem

My suggestion, which I’ve implemented with good success, is to create 3-4 hour problems that allow a candidate to bring in their own laptop (or rent one), get full access to the internet, access to their favorite IDEs, a set of requirements, and let them sit in a room with 2-3 other interviewers who will work on their own tasks alongside the candidate to simulate a work environment. The candidate can ask questions and treat the engineers as PMs, fellow engineers, managers, etc.

Some examples:

  • Implement a service that does X using Y technology, where Y is disclosed to the candidate ahead of time. i.e. Y could be one of {Spring, Kafka, RabbitMQ, Redis, PostgreSQL, MongoDB, Terraform, React, Redux, Webpack, Babel, …}
    • Tell the candidate to look at one of several areas of these technologies so you can constrain the problem and also their time for preparation.
  • Create a rubric for scoring the problem based on what your team cares most about.
  • Dog food your own problem set on your employees. If they can’t pass it under the same conditions as your candidates, re-assess the scope and difficulty of the on-site assignment.
  • Gather empirical data on the performance of your employees hired through this process. If you don’t have a good system for figuring out if your employees are needs improvement, meeting expectations (good), exceeding expectations (great), you need to fix that in parallel if not first.
  • This process is not set it and forget it! You continue to make new problems and rotate them in and out as necessary when someone eventually posts the “optimal” solution online. Every interview question eventually falls victim to Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.”

The Code Review

Show the candidate some of your technical debt. Yes, the nasty garbage code you guys wrote back in the day, not the pristine new microservice you built that connects to the legacy backend anyway. Get the lawyers involved if you need to, or sufficiently distort the original code so proprietary details are obscured. Ask them to code review it by:

  • Reading through it and ask clarifying questions.
  • Suggest improvements and explain the trade-offs. This should give you a good sense of how good a candidate is at analyzing a problem, making technical decisions, and giving constructive criticism.
  • How to evaluate trade-offs: even asking candidates to produce pro con lists for multiple approaches to a problem and forcing them to choose one has been very elucidating.

You must create a scoring rubric and you need to keep rotating the problems in and out. This is not easy and will be an enormous time investment. You have to come up with meaningful on-site projects that will reflect the skills and qualities that YOUR team is actually interested in. Nobody else is going to be able to tell you what to ask your candidates, since YOU have to figure that out because it’s YOUR team.

And this is where I feel like most companies just become completely lazy. “Oh, let’s copy Google/Microsoft/Facebook/Amazon to mimic their success because they hire only the best, we too must hire only the best!” (cue “We only hire the trendiest” https://news.ycombinator.com/item?id=15591441) No, a lot of companies succeed due to a *multitude* of factors. And something that people don’t often tell you is that the biggest factor in success isn’t always the quality of the underlying code, it’s the idea and the sales people. Obviously there is no product without engineering, but you can go a long way running on garbage implementations that are incredibly difficult to refactor or make changes to simply because they *work*. Been there, done that.

If your process actually ends up selecting for ACM championship winners, well that’s fine. That was a conscious decision that your team made because those skills demonstrate a strong, *measurable* correlation with good performance on your team.

Thoughts? Refutations? I’m genuinely interested in how we got to this state of affairs aside from the need to “scale hiring up”.