We live in an age of almost infinite resources for learning whatever you want, whenever you want. This, however comes with some drawbacks.
What are the upfront costs of going to university vs going to a coding bootcamp vs going solo? Let’s do a quick back of the napkin calculation.
4 years tuition at a good public institution + living expenses: ~$40,000 x 4 = $160,000
4 years tuition at a good private university + living expenses: ~$75,000 x 4 = $300,000
Coding bootcamp: ~$10-20,000 (we’ll split the difference and say $15,000 here)
Udacity Nanodegree: ~$1356(assuming you pay upfront and complete in 4 months)
Self Learning MOOCS etc: $0-??? (can probably assume somewhere around the cost of the Udacity Nanodegree if you end up paying for certificates)
As you can see, being self taught is a bargain… in theory. There are many hidden opportunity costs, and intangibles that go along with some of these things.
In this series of posts I’ll try to list out all of the pros and cons that you may come across.
In my next post I’ll be tackling university education as a path.
A lot of the difficulty in preparing for coding interviews comes from deciphering the the mess of problems presented to you. You might be asking, “where do I start?” during this whole process. Fortunately, a lot of ‘difficult’ coding questions are actually fall into a few predictable buckets. The major categories are as follows:
Linked lists
Recursion
Sorting
Trees
Graphs
Strings
Sorting
Dynamic Programming
With some ad hoc categories thrown in + problems that combine multiple instances of these. If you can manage to nail some of the more difficult problems in here, then you can make a lot of headway.
Practice… a lot
There is a good amount of learning science that dictates that we learn complex subjects as chunks. These chunks can be as atomic as you like, and combine to form larger and larger chunks. This should make sense to a software engineer, as we often think in abstractions. Instead of thinking about an entire system as a mess of discrete parts, we understand it as a unified abstraction. Studying for coding interviews should work the same way. Remember that list above? What we want to do next is compile 3 tiers of questions for each of these subjects (we can think of them as easy / medium / hard). The main goal is to create a list and tackle as many easy problems as possible for each subject (think about 5 – 10 per section). If these are all a breeze then we move to the next tier (medium). The idea here is that each level of problem is usually a sum of constituent parts. That is to say that a medium difficulty problem (barring ones with special ‘tricks’) are often combinations of slightly easier problems. The same goes with hard problems. Usually they combine a few different ideas / motifs that you’ve already seen before in easier problems.
Time Yourself
This can be coupled with practice. Once you’ve gone through enough interview problems in the format mentioned above, you need to start treating bouts of your preparation like real interviews. That means timing yourself when going through interview problems. Only do this in direct preparation for an upcoming interview. If you do this during your study session you will put unnecessary time bounds on yourself, and this will likely hamper your improvement.
Meditate
Some of the noted benefits of this are:
Focus
Stress regulation
Ability to stay in the present
On a more anecdotal note, the real benefit that meditation confers is that of a clear headspace. While that may seem mystical at first glance, the practical benefit worth highlighting here is really that meditation can help lower your anxiety and help you see problems more objectively.
Sleep Well
The most important thing to do before any major life event. Sleep deprivation has a lot of negative effects. It is estimated that being awake for 18 hours is comparable to having a blood alcohol content (BAC) level of .05% (about 2 drinks). Being awake for 24 hours gives you a an equivalent BAC of .10%… so not good. Worse yet, if you have a poor week of sleep and multiple compounding days they add up. You can sabotage a lot of hard work by showing up to an interview extremely tired.
Negotiations suck, nobody likes doing them. Due to the combination of lack of information on your end, this is generally a nerve wracking experience. One of the most common traps people fall into is the old “what are your salary expectations?” question trap.
Don’t be fooled, this is a trap to gather more information from you. Otherwise people wouldn’t lead with this, they would instead tell you what the expected pay is, or at least the pay range.
If a recruiter knows that the range of a role is between 100-200k for your experience, they have no incentive to pay you close to the upper end of that range. So what do you do when asked this dreaded question?
Be aware of your state laws. If this is California (for instance) the question about salary history is banned (See here).
Do not answer this question (ie say that you don’t have a figure in mind), be adamant about this / say that you want to be paid fairly for your role and experience, but never ever give a number
Be well aware of the market rate of your position (even better if you can get exact figures by level and YOE)
If you cannot avoid giving an answer you could answer in the following way:
First as mentioned above you MUST know the range for the position and level in question (say it is 100k-200k)
Say something like “I know this position generally pays 100k on the low end and 200k on the high end for a candidate like myself based on <a, b, c> data I’ve found. I want to be paid as close to the high end as possible based on <x, y, z information + internships etc>. What can we do to get me there?”.
Also watch this video to learn how NOT to negotiate:
A somewhat critical look at the most popular software engineering interview prep resource
First… the good
There is a lot of good in Cracking the Coding Interview (CTCI), especially if you’re coming from a nontechnical coding background, or making a career switch into software engineering.
That’s because going through CTCI is almost like going through a condensed ‘greatest hits’ session of undergraduate CS, and is arguably more comprehensive than many algorithm classes you may take in college.
If you haven’t gotten up to speed on most data structures and algorithms, this is a really good primer, with a lot more practice than you would probably get through interview courses.
My positive review ends here, not because I don’t think there is anything else good to say about the resources (there almost undoubtedly is, the 6th edition book is almost 700 pages!), but because it’s the best selling software engineering prep resource out there. Many people, including myself, have used it to prepare for interviews, so it hardly needs someone to sing its’ praises.
My Critique
My critique mainly falls into 4 categories:
A decent amount of ‘useless’ information
Not frequently updated enough
Specialized interviewing isn’t available
Architecture is pretty bare bones
‘Useless’ Information
There are a decent amount of chapters that are thrown into CTCI that don’t seem particularly relevant for engineering interviews in 2020 and beyond. Namely the ‘Math and Logic Puzzles’, C++ and Java sections. These all feel like afterthoughts and are placed rather randomly in the book.
Furthermore I have never seen any of these concepts tested in an actual live interview with FAANG type companies, larger funded startups or otherwise. These questions seem to focus on a smattering of concepts like primality and probability, but not thoroughly enough to be useful to someone like an actual Data Scientist or AI Researcher, and lord knows when you would get them as a general purpose SWE.
The same goes for these oddly language specific questions UNLESS your role / interview is highly language specific… in which case you likely need an entire other book dedicated to that. Interviewers these days will let you code in any language you’re comfortable in, so it seems strange to dedicate entire chapters to these concepts.
Not Frequently Updated Enough
Unfortunately there isn’t much that can be done about this when it comes to media like CTCI. It’s a book… that needs new editions every so often.
Unfortunately a lot of the content in CTCI needs to be updated frequently to change with the landscape. I mentioned that the book is a good primer, however I’ve noticed a significant uptick in the last few years in the difficulty of problems amongst large tech companies. Frequently companies are now asking ‘hard’ style dynamic programming questions even in technical screens as the bar has been raised. That means that ‘easy’ questions are borderline useless (except to teach a concept for the first time).
Furthermore, because many of the problems are ‘categorized’ (until you get to the moderate and hard sections) you have the initial hint of what the problem subject area is, which can give a false sense of confidence. One of the most important areas of practice is actually categorizing the ‘type’ of problem.
I have seen a bit of a deviation in some companies in terms of the style of interviews they give. While many of the largest companies still adhere to the straightforward white-boarding style interview, I have seen a significant uptick in pair programming / debugging in a codebase style of interview.
It would be great to at the very least touch on these other interview formats.
Specialized Interviewing Isn’t Available
This is the most nitpicky of these sections. CTCI in many ways is obviously aiming to be the one stop shop for ‘generic’ programming interviews. That means that it serves best as a primer and practice for things like Algorithms, Data Structures and the like.
It is curious then, that CTCI contains sections on things like Java and C++ specific knowledge. Most engineering interviews at top companies now let you choose any language of your choice: C++, Java, Javascript, Python… you name it (unless the language in question can’t handle a particular style of question, ie Javascript for multithreading questions).
I find these sections to be almost wholly useless as it should be fairly apparent whether or not this knowledge will be tested… in which case there are far better in depth resources on languages out there than CTCI. These sections of the book would be better filled with additional content (see my next point on architecture) or omitted altogether. Along with the brain teasers and math section they feel like filler.
The solution to this might be to add more specialized sections to CTCI that focused on subject areas (as opposed to language specific questions). We are now living in a time where things like specialized questions for Front End, Mobile and Machine Learning engineers exist. Primers for these subjects would be wholly useful depending on which specialized interview loop you enter into.
In the case of Front End interviews the knowledge of CS concepts is VERY tightly coupled with knowledge of Data Structures as they relate to the DOM, and Javascript language questions. As a result questions found in CTCI very superficially resemble anything you would receive on such an interview.
Similarly an ML interview will have questions on statistics, probability, tuning models, and optimization (math will actually show up during an interview).
I understand that it may be out of scope for this book, but then so are the sections on brain teasers and languages.
Architecture is Pretty Bare Bones
The architecture section of CTCI is… well it just isn’t very good.
All of the superfluous sections mentioned above should be ripped out for a far more thorough review of this section. There is a very low likelihood that studying this section will help you ‘crack’ anything.
In CTCI’s defense: architecture is hard… really hard. A lot of knowledge in this domain is built up through years of experience or by supplementing experience with a deep understanding of systems. However the suggestions here are VERY high level (with only passing mention of something like MapReduce, which would be beneficial to know about on a deep level).
I highly recommend that someone studying for this portion of the interview do their study in 3 main ways:
Pick up a copy of Designing Data Intensive Applications
Watch architecture videos of ACTUAL important systems on a place like InfoQ
Try and design a system (preferably one that has a detailed blog post) and compare… how did you do? Did you think of all the edge cases? Did you make the same tradeoffs? How robust was your system. I’ve found this to be the most illuminating.
Revisit your own career and think about the systems YOU made and the tradeoffs that were taken
This post will cover some of my favorite resources for problem solving. There will be a software bent to the suggested books, however my intent is not to simply provide the “best interview prep resources” but rather those which will help make you a more effective thinker in the field.
How to Solve It
If you must own one book on problem solving, it’s this one
I’ve saved the best for first. This book is the most ‘general’ problem solving centric book of the group. “How to Solve It” is a classic, written by legendary mathematician George Polya.
While there is a mathematical bent to the book (especially in the examples given), the math is rudimentary. It is mostly a stand in for general problem solving techniques.
Some of the general ideas in this book involve looking for smaller problems to solve (that are similar to the one at hand), knowing whether you have seen similar problems before, thinking of a corollary to a problem and solving that… etc. The topics are too numerous to list here, and Polya does an exhaustive job of listing all the possible ways one could try and digest a problem.
What stands out to me about this book is not its place as a problem solving manual, but Polya’s love for problem solving as a path to deeper discovery. Polya advocates for deconstructing and revisiting a problem even after you’ve solved it for deeper insight. This in turn will lead to a deeper toolkit.
Indeed, where you might be able to, for example, pass a programming interview through sheer brute force of solving A LOT of problems, Polya reminds us that some of the joy of problem solving is not always about results. He instead reminds us to treat problem as an art.
The Algorithm Design Manual
As is the case with Polya’s “How to Solve It”, “The Algorithm Design Manual” is fun. If you had to choose a well rounded but descriptive book on Algorithms, I would recommend this one above all others. While the famous Cormen “Introduction to Algorithms” is more thorough (giving detailed mathematical analysis of all algorithms presented in this book) it is often dense and unwieldy for the budding computer science student.
Where Skiena’s book shines is in its depth of content (covering all major topics you would expect in an Algorithms textbook), engaging writing, and the inclusion of “War Stories”, and practice problems.
The “War Stories” sections in particular stand out because they highlight real world practical use cases for many of the presented algorithms. Somehow, with this book, Skienna managed to find some perfect intersection of academic textbook, interview prep book, and technical blog post without losing much of anything in the process.
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
Boars are definitely data intensive
Ok, so this one isn’t a ‘problem solving’ book per se. But, it’s the first book that comes to mind when someone asks me how to ‘learn’ about application architecture.
The truth is, this is a domain where there is no shortcut. Unlike algorithms there often are no ‘best’ solutions to the infinite variations of architecture problems you may encounter. Worse yet, I often find example prep problems to be shallow in their solutions.
Algorithmic problems are neat little packages which contain many small techniques strung together. Even when solutions to these problems becomes ambiguous it is because there is a time / space tradeoff. These tradeoffs are the precipice of architecture problems.
Therefor, the best I feel I can provide in this domain is to give the best / most concise resource of possible solutions, which are contained in this book. The truth is answering canned architecture interview questions well usually depends on: – how much depth of experience you have at work- how well you know what the possible options are (where this book comes in)- Conference talks (think infoQ) or in depth technical blog posts by some of your favorite engineering teams
Phew! If you made it this far give yourself a nice pat on the back. That was a lot of information to digest!
This last part is the hardest to implement yet most straightforward. At some point you’re going to have to prove that you have the chops to do the job. Unfortunately what that means depends on the size / style of the company.
There isn’t a one size fits all interview for every company. Most interview styles will fall into one of the following buckets:
Algorithmic / Whiteboarding
Take home projects
Pair programming
Algorithmic
This is pretty straightforward. There are a billion+ resources on how to prepare for one of these interviews, so I won’t belabor the point very much. Chances are if you have an interview with a large tech firm they will share these resources with you as well. Google “Coding Interviews” and you’ll see recommendations for a litany of books.
Take home projects
This style of interview generally gets mixed reviews. I hate them. They generally mean that you have to do a lot of extra coding work outside of normal work hours. If I can, I tend to avoid these like the plague as they are hard to prepare for. They also interrupt your normal work schedule and need a significant time investment. For Algorithmic interviews you go through many screens before going to an onsite. That usually means 1-2 hours max before having to spend a full day interviewing. By juxtaposition a take home project can take up to 10+ hours. So you’re committing to the same time spent on a full interview loop. IMO this style of interviewing is a nightmare, and the opportunity cost is way too high.
Pair programming
This is a pretty loose designation. Pair programming can crop up in many forms. It all depends on the style of interview the team wants to deliver to you, but when they work our they are fun. The most standout interview I ever had of this sort was one where I was presented with a prompt in a language I was not familiar with. We spent the interview debugging, and solving problems in the codebase as if we worked together, and I loved every moment of it.
At the end we talked through the steps needed to take to fix the problem (it involved using a Heap data-structure / priority queue). The whole experience felt very collaborative, and even though I didn’t get the job in the end it left a very positive impression.
Yes We’re Talking About Practice…
Practice, practice, practice. That’s what most of this boils down to. In an upcoming post I’ll list some of my resources for problem solving practice (not just interview preparation).
This part segues well from part 1 (https://alexdajani.com/top-5-reasons-youre-not-getting-hired-part-1/). Most people do not know how to craft a narrative about themselves. They either underestimate their accomplishments, or state their accomplishments in vague, lazy terms.
Two Phases of Writing Your Narrative
Phase 1: How You Got into Software Engineering
I’m leading with this because a lot of people I speak to have nontraditional backgrounds. This is an important part of your identity, and your narrative matters. So share it!
You don’t have to be too complicated at this stage. Have a clear vision in mind of how you charted your path. Were you completely nontechnical before? Came from a different STEM background? What did you do to get your skills up to par? These things matter!
Example:
“Originally I started my career out as a lion tamer. After many years of near death experiences I realized I was ready to make a career change. I started by auditing programming courses at my local Community College and I was hooked! I loved the excitement of writing code and seeing my work come to life. I started my career by building small websites for my fellow circus performers, and eventually worked my way to an entry level position at Ringling Bros. Corporate.” etc.
Phase 2: Your Projects in Greater Depth
For your resume we highlighted the usefulness of the CAR model (Context Action Result) to turn something like this:
“Rewrote an e-commerce app with React and Javascript”
Into something more like this:
Worked for major e-commerce company and built a new application that surfaced to 30+ different locales
The application was refactored from BackboneJS to React to improve improve usability and decrease application load time by ~40%”
The second example makes for a couple of good bullet points on a resume and gives us a better picture of the A-Z journey. But, it does not tell us about everything in between.
Your next step in this process is to take all the projects you worked on and step through the decisions you made. Why did you choose the technologies you used? How many people was this product surfaced to. What were some of the challenges you faced. What about interactions with coworkers?
A good interviewer will be looking to gauge your depth. They will figure out if you made major decisions while working on your project.
Don’t worry if you are early into your career, or if these are small projects. There is value to at every level. What matters is that you’ve siphoned all the information possible from your projects, and that you have a clear picture of why you made the decisions you did.
For both of these examples I would highly suggest you write these narratives out, tweak, and refine them.
Note: This should be categorized as more general career advice. I know things are particularly hard in the Covid-19 era. Finding a job will be hampered by factors well outside of your control. With that said here are the things that ARE in your control:
There are many tiers to the job hunt process:
Getting interviews with recruiters
Getting past the recruiter screen stage
Getting passed the initial technical screen
Getting past the onsite
If you are failing at getting a new job, you are failing at one of these steps. But I would classify the first steps as the most frustrating, especially to new candidates trying to make a career switch. My experience in this domain is in Software Engineering but I would posit that most of my suggestions would be applicable to other careers.
The reason this part of the process is so difficult is because there isn’t a very strong feedback loop. If you fail a technical screen or an onsite interview, you can generally pinpoint where you went wrong. But if no one will even give you the time of day you can’t rely on feedback.
My hope is to help cut some of the guesswork and give you a solid path forward. 1 Rule for even getting to TALK to a recruiter:
Referrals Referrals Referrals
Getting referrals outweighs almost everything else you could do. That goes for inexperienced and experienced candidates alike. Recruiters are lazy (sorry recruiter friends!). They have to sift through a ton of qualified candidates to find ones to put in their pipeline.
That means that when you apply you go to the bottom of the stack. Unless you happen to meet some identifiable criteria like a name brand CS program or company. It’s not fair but it’s natural human behavior to sort based on qualities like prestige (think Ivy League Schools or FAANG companies).
If you’re a self taught engineer from a no-name college (or without a formal education) how do you circumvent this then? By trying to expand your network and ask people who work at a given company for a referral before you apply there. It sounds obvious, but most people are so afraid of rejection that they would rather lazily send out a million resumes into the ether than contact someone and have a conversation with them on somewhere like (god forbid) LinkedIn. However, if you apply through a referral recruiters will often bump you to the top of their pile, at least for a reachout. Why? Because:
They trust that the companies’ employee has more data on your experience than they do
Referrals are a form of social proof
Retention rates go WAY up for referred candidates.
Fortunately I’ve found that far more random people you reach out to for a referral are likely to get back to you AND refer you than a recruiter is to just accept your cold resume. Plus there is nothing stopping you from submitting your resume if you don’t get referred… just be prepared for your resume to be sucked into the ether.
This post will likely be the shortest. The question is… do you need a portfolio? The answer (unsurprisingly): It depends.
I often see conflicting advice on this topic so I think it’s best to break this into two buckets:
Cases when you do need a portfolio
Cases where you don’t
Cases when you need portfolio (or one may be beneficial)
If you’re a brand new developer switching careers… you have literally no reason for anyone to believe you’re competent unless you can show them projects and code you worked on (and a lot of them)
If you have SOME (1-2) years work experience, but little to no academic experience to help bolster your resume
If your type of work is highly visual (ie Front End Engineer or hybrid Design / Engineering type role)
Cases where you don’t need a portfolio
If you’ve had a lengthy-ish career (3-4+ years), your developer war stories should take precedence at this stage
You have a strong academic CS background and are just looking at new roles (a portfolio might help, but hopefully you’ve already had some internships along the way)
That’s it… seriously. To recap, if you are just starting out a portfolio is REALLY CRUCIAL. I can’t count the amount of posts of despair I’ve seen that read something like this:
“I can’t get a dev job anywhere! I keep sending my resumes and they get rejected. Here’s my resume:” ** Proceeds to show resume with 0 relevant work experience except for that one webpage they built for Joe Schmo’s crab shack, and purported knowledge of Javascript** “I don’t know what I’m doing wrong!”
The reason no one is contacting you is because they have no reason to trust you. You need large meaty projects you’ve built on your own time to fill in your lack of work and academic experience.
DISCLAIMER: I know that Covid-19 is impacting peoples’ job search. However, I’m still noticing a lot of remediable issues with resumes I’ve been reading. I’m sharing these tips because I realize not everyone has heard this advice / has the privilege or access to someone to professionally review their resume for them.
Your resume sucks
This is the number one reason I see people get rejected at the door. It seems stupidly obvious, however I’ve come to realize that ‘understanding’ what a good resume should look like is in many ways a position of privilege.
Many people who have good resumes have refined it diligently over time, and gotten peer or professional feedback.
So how do you know if your resume falls into this category? You don’t until you start asking other people.
What do I do then?
Be brave and share your resume with everyone and anyone who will look at it. If you have a close friend or family network that you trust, start with them. If you don’t then start on the internet. Share it with people on forums. If you have the money hire a professional to review your work. BUT YOU NEED TO DO THIS STEP.
Many people get stuck here because they are TOO afraid to show other people their work, please ‘get over this’, because cold applying to 100 places with a resume that’s horrible won’t get you anywhere.
With that all of that being said here are some quick tips you can apply to your resume to make sure it isn’t horrible the first time out:
One page only please – Unless you have over a decade worth of experience, no one wants to read your 3 page resume. If you aren’t sure what to cut, focus on the most temporally relevant sections (ie what have you done for me lately?)
No stupid or distracting designs – That’s right, no cares about your artistic flare on your resume (especially if you’re an engineer). They want something that is clear, concise, and easy to read
Lead with what’s important – If you’ve got a decent amount of work experience, lead with projects and experiences first. If you’re a new engineer lead with your projects with Github links etc. DON’T lead with your education if you’re trying to show off what you can accomplish on the job, no one cares, put that at the end.
CAR – Context. Action. Result. It’s ridiculous how many people I see fail when writing their project descriptions. Frequently I see entries like this: “Built an application in collaboration with designers and product.” This entry sucks, it tells me almost NOTHING about what you’ve accomplished, or how you’ve collaborated. Instead it should be something like “Business project x needed a new service built, I built an application using XYZ tools and helped drive ABC metric. The resume was a 100x increase in revenue because of key feature 123.” This example is obviously contrived, but next time you read a line on your resume ask yourself, “Did this tell me anything about what I actually did?”
You’re underselling yourself – To my point above, many people (especially engineers) fall into this trap because they feel like they ‘didn’t do anything’. Don’t be that person, either tell the minutiae of your story or don’t bother writing it out. If you end up at an onsite a good interviewer will be probing you for details either way, so you better understand what you worked on.
