I see these challenges as a great way for excellent experienced developers to weed out incompetent companies.<p>I'm a kick-ass get-things-done full-stack web engineer. I've never had to deal with one of these sorts of problems in my day to day work; and if I did, I'd just find an existing, tested, stable library that already handled them.<p>A company that needs someone to solve these sorts of problems doesn't want me on their team in the first place, nor would I thrive there. A company that just needs to build damn good web apps is losing out by using these sorts of questions in their interviews.<p>The best interview challenge I've had (actually, it was a take-home, with discussion in the interview proper) was about designing code for re-use and extension. It was a great indicator of the company's practical and mature approach to engineering, and of what they really wanted this hire to accomplish.
In a way I prefer this to "how many ping pong balls can fit in a school bus" that was all the rage in the 90s and early 2000s. But... man...<p>I have a computer science degree, I've been coding for 20 years, and I've held (and kept) a CTO role at two mid-sized startup companies. Currently I'm considering looking for a job at a larger company (where I wouldn't be CTO but I'd be hopefully paid more) and these kind of questions make me think I need to almost go back to school before I can start interviewing.<p>When did it get to the point where we need to read thick books on programming interviews and spend hundreds of hours on HackerRank practicing algorithms to get a job where we probably won't use any of those day-to-day?<p>Edit:<p>For fun the other day I decided to code a linked-list from scratch in C and it took me a half-hour plus... and I have known that data structure for decades. I can't imagine doing a harder problem under the pressure of being an interview.
I'm a C+/B- developer. I've been doing this stuff for touching two decades, and these questions gave me a prickly sweat down my back. There is a part of me that feels very lucky to have plopped onto the Earth right when I did, before there was an organized process to weed me out. I'm entrenched enough that interviews are generally just culture fit interviews. I think I'd need ulcer medicine to get a job with no reputation.
Semi off-topic, but i am curious. How much of CS fundamentals do you expect a backend (or fullstack) developer to recite in an job interview? I did all CS theory stuff many years ago at university, but i could not pass a interview test full with these CS basics.<p>Isn't it far more important to know how to design a modern, maintainable, scalable web application? Know how an when to cache stuff. How to design a API. How to integrate with third party APIs. How to setup logging. How to sanitize data and other common security problems. How to setup test/build/deploy structures. Et cetera, you get the point.<p>If, while building a web application, i encounter a "big data"/"data processing" problem, i will find a appropriate solution using CS best practices. But hell, i would struggle to implement a simple array sorting algorithm under pressure.
Never mind the specifics of the selection process, Silicon Valley's risk-adverse approach to hiring is baffling. Instead of making candidates go through an overly rigorous process, why not embrace California's at-will status and hire and fire often? Employers and employees already view each other with suspicion in terms of loyalty, the former willing to downsize capriciously at any moment, and the latter willing to jump ship every year or two. So accept the mobility and instability of startups. Instead of spending immense resources on the interview process to find the perfect, you focus on getting the good and terminate swiftly if they turn out to be bad.<p>Not to mention, even when you have these types of interviews it still doesn't seem to filter out toxic people, such as the harassers of Susan Fowler at Uber.<p>Of course, it would be easier for workers to be okay with this arrangement if basic needs such as health insurance were decoupled from one's employer. That's another argument for single-payer in CA.
I recently tried for the second time to apply to some agency type place. I have 10yrs of coding, worked with big data, have done micro coding( developed protocols for vending machine transactions), done frontend and backend small and large scale.<p>But this place had 3 of these type of challenges that you had 1hr 30mins to complete all of them. I'm sorry, most of this stuff you will NOT find in any job unless its some specialty. For an backend/angular/react developer you will not find this at all. I feel that companies that do this are out of touch with the correct way to find candidates. But on the second hand I also see why they do this since programming has became so much popular now a days.
I don't understand code challenges. Can you even program without Google and Stack Overflow anymore? And god-forbid being experienced in a dozen frameworks and libraries if it's not the exact combination the company uses.
I have always seen the interview process as a an opportunity to understand how the other person thinks. These questions may do that to some extent but they limit it in ways that make it almost mechanical.<p>I personally find "What is your favorite programming language?" or "What systems architecture to you find more compelling?" to be far more valuable. It gives some insight into their commitment to the trade and gives you an opportunity to make it a conversation to dive into their reasoning process and depth of knowledge about a topic. I think it's far easier to weed out the fakers if they can't express why Erlang is interesting to them than for them to tell you how to implement a linked list which is very easy to google and memorize(but won't necessarily prove any skill).
From what hear about some startups, the challenges are for the general candidate pipelines the company wants to weed out w/o fearing legal repercussions. The inside-track, friends, and frat candidates often get to skip right through the process or have copies of the problems/answers from insiders. (Illusion of merit.)
Somewhat of a tangent, but that "Distributed design" document gives me hives - with the lack of lines from "write" or "async write" back to the readers or cache. The taming of stale data would be a nightmare to manage when it suddenly starts to matter.<p>Also, where's the completed response caching layer? Nothing destroys performance (and hikes costs) like having to recompute every page response from raw data.<p>And that doesn't even touch my annoyance at shoehorning "federated architecture" to mean "sharding with a different algorithm".
The advent of all of these coding challenge excercises makes not being able to do one in an interview a real show stopper. Glad there's all this material to learn from.
To me it is reasonable to presume that a software developer candidate knows the basics of CS: algorithms, data structures and such but for anything that require deeper knowledge I think it should be only asked if it is mandatory for the job.<p>Sure if you want to maintain a certain "prestige" you should maybe use them to limit your applicant pool but in the end if your work is nothing but coding front-end JavaScript it doesn’t matter do you know how to traverse B-trees or not. And if a need somehow arises it is very easily googleable and implementable with good enough CS education.<p>I think what the interviews should be about, and the best that I have been, have involved some basics sure but also one had few “real-life” coding exercises and in another I had a code review about one of my project’s code (which I was surprised by). Nothing tells more about a person than having them to explain what is their passion but if you are only interested in people that can jump through some loops that’s the people you are going get. Maybe in that kind of company that's just how they do things.<p>I’d argue most people can intuitively tell, maybe not why, when a recruitment process feels “right” compared to one that is forced and does nothing but dehumanize you to a walking Wikipedia and ticket-monkey. But maybe in programmers there is also some that seem to like that idea so I’d say it is more of a skill and culture fit than anything else.<p>But in any case the whole process should be based on some structure that actually measures something real. I personally don’t like being reduced to few facts about missing knowledge on a spreadsheet which I could learn in a week or so. It hurts my ego and most of all makes not want to work in the said company in the future so when I’d know those things I won’t be reapplying.
With this type of post I always read comments complaining why they should know those things for an interview. They are not necessary. It is like some more knowledge is going to harm them. I wish I would know more about everything. Sometimes the connection between knowledge and how to solve a problem are not clear when you learn that knowledge. Why is it important to know how is the syntactic structure of a sentence if I want to be a developer? Because you might end working with compilers or natural language processing and that knowledge is gold. But you simple don't know in advance, and you wont be able to discover how to solve a problem if you don't have knowledge about the solution in advance. And there are also different ways of solving problem, some better than other or with different trade offs which you only know if you are aware of other possible solutions.
Thanks for this. Just a mild constructive criticism: not sure how useful the Anki deck is. One thing to keep in mind when constructing cards is keeping the information very short. As it stands, there's no way to really remember the flip side of the card. Aside from that, really solid info!
I've been using Python (among others) at work close to 3 years now. I get these challenges and problems, however, I don't find the solutions here "pythonic". I guess it depends upon the job criteria, but the code here [1], for example, is not a great demonstration of _Python_ language skills. It is a good demonstration that the person knows Mathematics, but if someone is interviewing for a Python dev, it's not what they should be looking for.<p>[1] <a href="https://nbviewer.jupyter.org/github/donnemartin/interactive-coding-challenges/blob/master/online_judges/license_key/format_license_key_solution.ipynb#Code" rel="nofollow">https://nbviewer.jupyter.org/github/donnemartin/interactive-...</a>
Might be slight off topic. But I'm sort of Python enthusiast for a long time but never been able to actually learn how to code. I'm sort of aspiring software developer but a degree in irrelevant engineering.<p>My question is, by studying/doing good amount of Python [currently working on it], going through the entire interview challenges presented here, seeking to gain Master degree in Management Information System [MIS], can I apply for job and be shortlisted which might require CS graduate and maybe graduate with MS in CS?<p>Let's just say for the sake of the comment, I won't be able to obtain a MS in CS because for numerous reasons.
The problem is how much do dev really need to use this in real code. why would interviewer test someone on function he can just use existing lib for. why not think about how he plan an application and how will he design a flow. much more important.
I really appreciate the effort that went in to this. This is a perhaps the most thorough hand holding through a "Cracking the Code Interview" regimen I've seen thus far.
These questions aren't that bad. There's even architecture design questions (under System Design).<p>Looks like a fun bedtime reading material to me.<p>I'd say read this kind of stuff on regular days, not one night before interviewing, and peeps would do just fine.
Why do we test algorithms and not design patterns?<p>It seems to me, after twenty years of building software, that the need for off-hand knowledge advanced algorithms is rare, and the need for knowledge of design patterns is exceedingly common.
This is great! Having an integrated environment with the tests included and solutions in a separate notebook is quite valuable for training to pass technical interviews.<p>I see a lot of people posting about how they dislike the technical interviewing process. The sentiment seems to be that for a certain class of popular developer role it's entirely unlikely that they will ever need to remember how to implement a heap or red-black tree to be effective at their job... so why use problems like this in an interview?<p>I think these sorts of questions should be used by teams that want to set the minimum standards on the team. I'm reminded of a rule used at the Recurse Centre: <i>never feign surprise when someone asks a question</i> (I paraphrase). The idea is that if someone asks you a question about something you think is fundamental, like Bash for example, don't immediately feign surprise and say, "You don't know bash?" It's not helpful. Instead take it as an opportunity to teach them something awesome. However this doesn't generally work in a professional setting where you're <i>required</i> to know Bash in order to function at your job.<p>If on my team we're responsible for the operation and maintenance of several millions of dollars worth of infrastructure that runs our customers' applications then there are certain minimum requirements for operating effectively within this team. I expect you would know Bash at a minimum. I should also expect you to know the network stack of the OS we deploy on, how TCP works, what a hypervisor is, etc. We may write most of <i>our</i> application code in a high-level language that abstracts these details away but that doesn't preclude you from understanding them. It's just a convenient tool. You have to know how to manage complexity and avoid premature pessimization in order to be effective and that means you will be interviewed using technical questions to screen for that <i>minimum</i> level of knowledge.<p>However I think most companies do tend to use this tool poorly. I've interviewed with startups that build consumer web applications that ask questions about radix sort and k-d trees. That's what I call, <i>overkill</i>. This trap is easy to fall into if your motto is something glib and banal like, "We only hire the best." If you don't quantify what "best" is you're just going to negatively filter out potential candidates and hire on bias. You have to scale the screening process to only test for that minimum competency and choose how much risk you want to take in teaching new hires.<p>If I'm hiring a more junior developer to our team I expect that we're going to mentor that person and make them a better engineer by working with us. They can ask questions that may be outside of our minimum standard. However if I'm hiring for a team-lead position I'm much more likely to not accept a candidate who cannot fly through our screening process. Working with them is going to be difficult and if it's 3 in the morning and they're causing more problems than fixing because they don't know how the TCP re-transmission protocol works then we're going to have a problem.<p>The conclusion of all this is: tweak the screening process to set the minimum standards required for effective communication on the team. Don't set the bar unnecessarily high: define what the bar should be and assess the risk of mentoring junior developers. You need a good mix across the spectrum for an effective team.
This feels way over-engineered. I just want to click and jump into a challenge, Project Euler stye. Every single page is overflowing with "Table of Contents", screenshots, code snippets, etc.