Big Tech Coding Interview Framework – Pt 1. Inspect
fangprep.substack.com
fangprep.substack.com
I did a fair share of problem solving on whiteboard, replying to very specific questions about libraries and frameworks. But I've also accumulated some experience. And if my experience isn't enough, if you can't tell by having a discussion with me if I fake it or not, then with all due respect I will tell you that I have better things to do with my time.
I've started saying no to these though
The previous answer he disliked was to the question of what would I do if something happens and he is not available for me to ask him to take a decision. He expected that I'll fire him a mail. But instead the answer was that I will assume the responsibility and take the decision myself.
After the interview I was glad I did not work for them.
Your coworkers have feelings and you want them to have positive feelings towards you since that makes it easier to work together. Deliberate rudeness kinda breaks that.
By that point I was looking to terminate the interview. Looking retrospectively, I should just have stand up and thank them for their time. That person rubbed me in the wrong way and I couldn't support the belittling.
I'm not surprised he didn't have time for your bullshit.
I agree that other question is stupid. Clearly it depends on what the something is. He shouldn't expect an email for every decision so either he's a crazy micromanager or there's no valid answer.
Why can't the business just say "the policy is that you email a manager/call another manager/assume responsibility" and that's the end of it? Getting quizzed on the "correct" answer to their business policies is absurd.
Maybe part of the problem with these threads is that posters don’t clarify exactly what they’re complaining about.
Depending on details, it's similar to asking an author to recite, verbatim, Shakespeare verses and calling gotcha on every mistake.
There are situations where it is legitimate, but for app/web/db devs it's just a rigged trivia competition.
Take home small project? "Half" hates that.
Leetcode? The other "half" of population can't stand that.
Fizzbuzz? Too easy.
No code? How can they tell you can code, naturally?
Framework specific questions? Write something in Flask? What if you're looking for someone who's good at development but have not used a specific tech stack?
I’m not even sure the Leetcode style needs to be abolished, so much as it can be tweaked to remove some of the additional pressures of the format (time limits, stress from monitoring, overuse of memorization)
> What if you're looking for someone who's good at development but have not used a specific tech stack?
Then you have an interview specific to that use case of candidate. It doesn’t invalidate the format used in interviewing other types of candidates.
There will always be, I think, people who don't like whatever way you choose to do software job interviews, because they're not good at it, and then, some of them don't like it.
> Take home small project
Hmm yes it's unfair that some people don't have the time. What if everyone got to start at the same time, say, 12:00 UTC the 1st Saturday each month, and everyone got exactly 2 hours. Maybe that could work also for people with kids -- after all, 2 hours isn't much more than travelling to and back from an on site interview (in the same city).
Time and days could vary, trying to make it work for everyone
Before the interview, I tell them to bring whatever materials they want to the interview, whether it is virtual or not. Books, notes, videos, whatever, I don’t care. The materials are to support them showing off to me, in their favorite language, with their favorite ecosystem (editor, IDE, compiler, version control, etc.), solving a typical task they address that takes up about half a page (or more) of code on a standard US letter or international A4 sheet in 12-point Courier New, 1.5 inch or 3.8 cm borders, no lines that are entirely a comment (when counting just code).
The hyper-specific layout specifications were emerged by all sorts of crazy responses I got in the early years when I started this approach.
Could be a standalone program, a function, a code fragment, a library, really anything. I’m pretty comfortable in a very wide range of coding environments, and always happy to learn new ones, so I’ve been comfortable navigating the responses I get.
I even tell people I don’t care whether it is their own code or something they literally copy and paste off the Internet. But they need to be ready to talk about it, and take it in different directions. Just tell me ahead of time the toolchain, materials and code they chose.
I tell them I’m going to ask them to teach me about the code, and ask questions to clarify for myself along the way as if I’m going to take it over and maintain it myself, and customize the code and they will help me troubleshoot the customizations.
Through this approach I’m looking for the ability to communicate about code. Without springing surprises upon them. Being able to code is table stakes and this approach quickly flushes out who cannot code at a specific level required for the position. But I work exclusively in settings where there are teams of coders, and even “lone wolf” coders must be effective at conveying what they’ve built to others in case they win the Powerball/Lotto.
I can work with a variety of levels within a certain band of coding ability. I can work with someone who isn’t familiar with my clients’ specific toolchains. I can work with poor documentation, commenting, and writing skills. What I’ve been unable to solve for so far though, is someone not only utterly incapable of communicating what they’ve coded, but completely indifferent to improving.
And in the event of the [rare] mistake in hiring someone who does this, you will know quite quickly after they start and you will fire them. Problem solved.
It might be a different place, a different market from yours, etc. But at least here (and I've verified this anecdote with numerous people), many people who have very high experience levels simply can't code, at all. Or at least, can't do it given the coding task we give them (2 hours with a computer and full internet access, to do a few tasks in Python).
I'm not saying that people are lying on their resumes - just that supposed experience in an impressive sounding company doesn't necessarily translate to real world coding ability.
In the times that I have seen it happen, though, I almost always wonder how the heck it's possible? Either they really did lie about their experience (possibly but let's assume not) OR they have worked at places that didn't interview well (?) somehow just skated by for years on end? Or maybe there is another possibility for why this happens.
So many companies try and do the FAANG thing now, that if they aren't going to compensate you accordingly for the same work, when really what they should be looking for is experience and general competency, then you might as well not interview with them. It's truly an unbelievable amount of time and energy involved in some of these, and there's so much variability in how you're evaluated, that it's probably not worth it.
Personally, I like to continuously implement and clarify in small tight loops. It might look something like: implement a rough structure with lots of empty functions and very basic control flow. Ask questions. Restructure. Ask more questions. Restructure again and add implementation detail. Etc etc.
This way of working is tied with my thinking. It reveals the problem to me over time instead of all at once. I get a deeper understanding this way.
There is an assumption by some people that my process is wrong. They would argue that I should instead break the problem down on paper, or in my head, or using test driven development, or with design documents etc etc. But this is the process that I've found works best for me.
I can enforce a particular process to please interviewers (and I have). But solving the problem becomes much harder.
I get that Big Tech jobs are glamorized the way high-paying jobs in Big Law, High Finance, etc. have historically been glamorized, but unlike professions like law and finance, there are lots of opportunities for people with even decent development skills to make really good money today even if they don't work for Big Tech.
As an example, my friend's son is making well over $120,000 annually as a freelance PHP developer with a few years of experience. He's in his late 20s, doesn't have a comp sci degree and lives in a lower cost of living city where he's probably at least in the top 5% of earners.
On the flip side, I know people who are hiring for developers and they're more and more flexible, especially in regards to location and remote work, because the demand for decent developers greatly exceeds the supply.
Why someone should feel compelled to pretend that they problem solve differently to ace a whiteboard in this market is beyond me.
There are lots of people working in tech-related jobs at/for companies not named Facebook, Amazon, Apple or Google who earn well above average incomes.
How to make this look like underachievement? Claim that these people are fewer in number than they actually are and suggest that there are hoards of 20-something FAANG engineers making $500,000/year+ such that a freelancer pulling in $120,000 is somehow a loser compared to his peers.
> There are other routes to moderate wealth but few as easy and reliable.
If it was as easy as showing up with a comp sci degree and a heartbeat, why is prepping for whiteboarding interviews even a thing?
> "Why someone should feel compelled to pretend that they problem solve differently to ace a whiteboard in this market is beyond me."
and I'm making observations that I feel adequately explain why someone might want to pass a whiteboard interview at a big tech company. It's completely valid to not want to do that as well, but you said that you couldn't understand why someone would want to, and I've explained why someone might.
> If it was as easy as showing up with a comp sci degree and a heartbeat, why is prepping for whiteboarding interviews even a thing?
I didn't say it was easy. I just said there are not other routes I'm aware of that are easier.
I was only pointing out that there are a lot more people who earn really good incomes in tech-related fields who don't have formal STEM educations. This isn't as uncommon as your comments seem to suggest.
Frankly, a lot of web and mobile app development doesn't require a computer science degree, nor is a formal computer science education the only form of "training" there is. Heck, assuming computer science curriculums are the same as when I was college-aged, I wouldn't even consider them "training" for a typical development job today.
> I didn't say it was easy. I just said there are not other routes I'm aware of that are easier.
I've dated both a lawyer (who worked at a Big Law firm) and an investment banker (who worked at a bulge bracket firm) in the earliest stages of their careers. Frankly, I don't think making a really good living in these professions is any more difficult than "FAANG worker". Different people have different aptitudes and when someone aligns his or her aptitudes to his or her career choices, everything sort of looks "easy".
That doesn't match the reports of work life balance I have heard from practitioners of those professions vs. practitioners of programming. But I don't have any reliable, objective evidence to share on this point of view.
It's actually great advice for solving any programming problem — not only in case of a whiteboard interview.
Not that you need to write down everything explicitly for any problem. But you should in any case think through all of the mentioned things at least.
The other thing I've noticed is that a strong type-system will from the get go force you to describe exactly—down to the details—at least 80% of that stuff. Refinement types for example let you constrain further types with a lot of inhabitants. But even the usual things like optional or, for the contrast, non-empty types can help greatly. With some formal verification capabilities on top you could likely even codify more than 90% of the things mentioned in that spread sheet. Add some meaningfull comments with the reminder of the answers and you'll get almost perfect code in my opinion.
I would bet bug count in software overall would go down by more than 90% — if only all code would look like that in reality…
¹ https://docs.google.com/spreadsheets/d/1gy9cmPwNhZvola7kqnfY...
However, it's really important not to behave in a way that is overly formulaic or comes across as being heavily "coached". If your interviewer is engaged and competent, coaching like this will entice the interviewer to mix things up and ask questions that force you to break out of the coached pattern. If the interviewer isn't as good, it's more likely they will just give you a lukewarm score and say that you were coached.
For example, if a candidate said something like "can strings be multicharacter?", I'd probably ask why that would matter. In the example question, it doesn't matter at all because we're just looking for equality of members (could be arrays of any type and the question would be the same), and would be a weird thing to seek clarification on. Maybe a better example would be if the candidate asked if there's an upper bound on the size of the input array. In real programming, that's not the sort of thing that usually matters, so I'd expect the candidate to explain why that matters in this case (maybe they have a O(n^3) algorithm in mind that would be untenable if the input can be large).
I've done a few hundred interviews, over 100 at Google.
And yet, why are these interviews so difficult? I don't think it's simply an issue of many people having gone through these programs and failing to absorb or retain the material. Neither do I think there is a severe mismatch in the material covered and the interviews. Yes, some interview questions are awfully close to logic puzzles - having to know the two pointer trick for detecting cyclic graphs, what CS program covers that industry-specific technique? - but others are fundamental applications of trees, graphs, dynamic programming, etc.
Could it just be that academic CS doesn't approach solving problems in the same way as these interviews do? Are there meta-problem solving techniques that these courses simply don't cover? Heuristics that must be applied when one approaches a general problem before the topic is narrowed down? "Ah this involves a tree, ah this requires sorting, ah we should use a hash table?"
At the very least, these interviews require the applicant to be immediately familiar with any of the topics that might span a semester (or two) long course, so recall could be an issue.
Also, recall would only be an issue if they didn't truly master the material. Do you need to recall how to ride a bike after you've learned to do it?
https://blog.cognifit.com/motor-memory/
https://www.vanderbilt.edu/olli/class-materials/Neuroscience...
Where are you getting this concept that humans never forget skills? That's completely false.
So from this rule, if you just learned the rules for chess you would forget them. But if you started trying to win chess games and viewed the rules as building blocks for strategies, then you will remember the rules for chess. Then you start to compose strategies etc.
I never said humans never forget skills, I said humans never forget skills they master. Most people never master much at all, maybe 90-99% of software engineers would be in the never master bucket. Which is why I get downvoted, most people never get good and get angry when you tell them that they can work to improve.
In terms of working to improve, given the excellent filtering capabilities of algorithmic interviews, surely if people were taught right and knew how to master it not to mention what they should master in the field, then it would not be so difficult to improve (though this would render the filter ineffective)? Because then more engineers would have known from day one what they should focus on (not that they don't at present, because these interviews are now broadly known to the public), and thus having mastered the material, be passing the interviews easily.
Interviews are not an exam, they're a filter.
No one is testing your ability to do cutting edge original CS research in these interviews. It's just basic fundamentals
That's still a problem with CS programs. They're passing people who haven't learned the material.
And then these students graduate, think that the paper is proof that they actually learned these things, but if you prod their knowledge then it all just falls down since there is no substance there.
Proofs are great if you learn to write your own, but courses mostly just wants you to memorize proofs which isn't terribly useful. If your tests has a lot of problems where you need to write your own proofs then it is a pretty good course, but the normal case is that the test wants you to write down proofs from memory.
My comp sci degree covered this, and it isn't a particularly prestigious university either. Most leetcode problems are just extensions of (or exact duplicates of) problems covered in my Data Structures and Algorithms class.
It seems like some of the skill involved for passing leetcode interviews is pattern-recognition to quickly recognise the kind of problem and what the likely tools to solve it are.
Not all schools picked up these tricks, unfortunately.
Not everyone covers the same things. Loads of Leetcode tests and interviews apparently cover linked lists and tricks with linked lists. I got zero exercises on linked lists. Some structures require specific approaches, so if you have trouble getting a foot in, you'll fail miserably at any questions related to those structures no matter how simple or difficult.
There are other obvious points, but CS is simply too large a field. What one considers fundamentals is something another never uses, not even in libraries or frameworks. Easier is to prove that the student can learn what is deemed on an equal level as something else, and give them the tools to learn more on their own should they require to do so.
This all assumes the student in question has actually proven to know the material of the course, and the course covers some part of what people consider fundamentals. Things obviously change when considering some people get by despite not having proven they know the material, or CS courses missing these.
I also can't help but feel there is some irony in CS courses trying to accommodate an ever increasing need for more practical skills, ditching CS fundamentals and practicing them to do so, only to be met with interviews which test CS fundamentals despite the work not needing any of it.
There is a reason why recent graduates perform better at these interviews than seasoned engineers. Even for computational math where you have all the basics of calculus 1-3 and bunch of other things where you have to prove the theorems in the exams it doesn't mean you recall all of it forever. It's like saying if you really know how to use a fork you create one yourself.
I also had countless experiences where I ended up either rewriting from scratch or massively refactoring code that was written by computer scientists that dumped all their algorithm ideas into code without understanding a thing about performance, the underlying infrastructure or how to trace it.
Your sorting algorithm will mean jackshit when you spend all your time doing I/O reading files in and out of memory for example. Your super cool distributed algorithm means nothing if you don't understand CPU P-States(I guess that's irrelevant nowadays) or NUMA and didn't setup the machine properly.
I for one have opted out of this BS and will actively avoid mediocre programmers trying to boost their ego with cookiecutter algorithm questions.
I worked on low level machine learning infrastructure and distributed algorithms at Google. I know pretty well what challenging engineering problems looks like.
> No I don't. AT ALL.
You don't think your inability to visualize computation affect your ability to come up with solutions to problems at all?
Edit:
> Your sorting algorithm will mean jackshit when you spend all your time doing I/O reading files in and out of memory for example. Your super cool distributed algorithm means nothing if you don't understand CPU P-States(I guess that's irrelevant nowadays) or NUMA and didn't setup the machine properly.
I understand those things well, it isn't hard to learn, we run benchmarks using proper prod setups and see what works faster and we know about CPU caches, memory overhead, file reading speed etc. The only difference is that I am fluent in algorithms and you aren't. I'm not sure why you'd think that I wouldn't know those thinks just because I know algorithms, it takes like a few months to master algorithms, there is still plenty of time to learn the other things.
You don't have to implement, you just need to know the theory of why it works. Then you just code it up based on that theory, it isn't hard to do at all.
For example, merge sort explains itself, you partition and merge. That is all you need to remember. Hashmap is the same, you use a deterministic function to label objects and then put those into buckets, then you find them in the bucket with the same label later. These are like the basics of the basics.
Identifying that you need to use some variation of that algorithm and then writing flawless and optimal code that handles all corner cases in a 20 minute job interview, is an entirely different thing.
Perhaps one approach is to allow the interviewee some time to think it over themselves.
It is much more stressful than a real work situation, true, but people work much harder to appear nice and helpful in an interview setting as well so having a harsher test than real world situations to test soft skills seems appropriate.
The "niceness" of the interviewers is irrelevant. The power differential at stake sparks a survival instinct that leads to stress. (e.g. they literally hold power over your future meal prospects.) Though perhaps in others, it invigorates them with a sense of purpose, cool, and collectedness. Perhaps that is truly the 10x engineer.
My Google interviews was basically me coding up a solution in 10 minutes and explaining what I did and proving it works with runtime etc. Then we spent the rest of the time talking about engineering problems, testing, what I did at previous jobs etc. I am rustier now many years later, but It is still good enough that I don't fail, it might take 20 minutes instead of 10 but there is still room to spare. So the limit is that you are maybe half as fast as I am when I'm rusty, doesn't seem like an overly high bar to me.
Not every great engineer can be good at this stuff to do well in international level competitions, by definition that's a very small group.
I assume you're not on the same level as William Lin or tourist, so it would be like them wondering why you struggle on a particular problem when they can do every one easily.
> I assume you're not on the same level as William Lin or tourist, so it would be like them wondering why you struggle on a particular problem when they can do every one easily.
Those have spent more than 10x as much time as me on that though. I got to my level in about 6 months that I spent to pivot from math to programming, that isn't unreasonable effort for anyone, most computer science grads have spent more time learning algorithms than I had.
If you had realized that
* in 90+% of job openings, whiteboard leetcode interviews optimize for the wrong thing, and neither the candidate nor the interviewer should be honored for its inclusion in the process
* live coding exercises are just as much an exercise in psychology - your willingness to submit to unreasonable demands and their willingness to subject you to them
* negative discrimination (i.e. weed out requirements) create biases in your hiring process and ultimately skill gaps in your personnel base
You would potentially be self-aware enough not to post this cavalier and self-aggrandizing comment.
(According to one prominent speaker on the subject, Temple Grandin, this is an aspect of how autistic people tend to process things.)
Quicksort - pivot - i <= hi mergesort - merge - auxiliary array
When I started practicing DSA, I would code these algorithms from scratch ever week, to try and memorize them. Then as I did more general leetcoding, I realized that these are just solutions to problems, and there's no need to memorize the code exactly, just knowing the key idea is enough.
People dump on leetcode because they think it's memorizing solutions to problems, but it's not practical to do that. It's more like memorizing one sentence per problem, than memorizing a page of code. And when you see a new problem, you just adapt one of the "sentences" you memorized for a similar problem.
But if you've never looked at an efficient algorithm for dependency resolution, it's going to be impossible to come up with a good solution for a related problem in an interview.
Right, my pictures are what the code is supposed to do, not the code that is executing it. Then I can just take pieces of it and compose it with other things, you need some kind of intuition to do that, for me that intuition takes the form of pictures.
But yeah, the trick to solve leetcode properly is to not solve leetcode, but to learn to get better than leetcode, that way leetcode problems will feel trivial for the rest of your life.
Asking engineers to take leetcode for exams is like asking journalists to take the SAT exam. Obviously they will need to study a few months for such things.
It's a lot easier for me to do a Leetcode problem if I can explore and experiment a bit without having to verbalize my whole thought process.
Also, this is nothing unique to SW. I come from an engineering background, and we had to do calculus in almost every engineering course. Yet I'm sure within 12 months of graduation, most of my fellow grads would struggle with most calculus problems. I was once criticized by my peers for asking a basic calculus question while conducting an engineering interview.[1]
Just as with algorithms, you usually don't need calculus on the job. Looking at most of my SW development career, beyond the very basics (e.g. dictionary lookup is O(1) in Python), I probably needed algorithm knowledge on average once a year. And since almost none of my peers in most of the jobs have that knowledge:
1. Knowing it doesn't put me at an advantage within the company. It's a blind spot for everyone. Unless I happen to solve a serious business problem with that knowledge, which is very rarely the case (and likely why most people forget this knowledge).
2. My not knowing it won't put me at a disadvantage when it comes to career growth in the company.
This is the reality for most non-FAANG SW jobs. I suppose the one benefit of all these Leetcode interviews is that a lot more people have an incentive to review/learn this material.[2]
[1] Analogously, I was once criticized for being too tough when I asked a candidate to write a factorial function for a SW job.
[2] Although perhaps not really. Last week I interviewed a candidate who knew the theory really well - he understood complexity really well and seemed to understand data structures quite well too. But he couldn't write a basic function to split a string of numbers that were comma delimited, and return it as a list of integers. In both the languages he claimed proficiency in, there is a standard function to split a string, and not only didn't he know the functions, he had know idea of the concept. A classic example of textbook knowledge vs experience (of which he had 3-4 years).
(I have been a victim of this myself.)
And these clarifications are mostly dumb. If you pass an emoji into my string function I'm okay with it not working. Similarly if you pass in a negative number then that's your own dumb fault if it does something unexpected.
That's how the real world works. You go to the extent that covers 99.99% of cases. If that means it doesn't work in your crazy scenario, well, create a ticket and it'll sit in the backlog until we clean up old tickets.
If a negative number isn't valid input that should be gracefully handled by the program (e.g. by responding with an appropriate error indicating what is valid and/or invalid) instead of doing something unexpected.
I'm not much of a fan of the current state of tech interviews but seeking clarity around validity of input and how to react to invalid input is one aspect that does (or at least should) mimic "real life"
One of my simplest questions is that you have 2 files, one with vendor_sku and price and another with sku and vendor sku, I want a file with sku and price. People will just start coding from there or just assume they're getting in arrays.
Really, that 2nd 5 minutes is for YOU, the candidate. You can test out if I'm even going to accept your solution, also by talking it through I'm going to give you partial credit even if you have issues coding it as at least you could code it out.
Partial credit isn't a thing to sneeze at, stuff happens in an interview. Network issues, software issues. I've had interviews where many things happened and the interview went sideways or just had to end over the 1k or so interviews I've given.
I had an interview where I was the candidate recently where the system wouldn't log correctly, or log what failed, and wouldn't debug correctly. My code was correct except a flipped check, but the interviewer wanted it to run all the test cases. It took 15 minutes to debug the web ui to even see what test case was failing.
If I was the interviewer in that case, the partial credit for explaining the answer and the 98% code would have been fine and I would have called it the instant the candidate found an issue with the tool, and moved onto other questions.
I've also had interviews where the interviewer admitted they were trying out a new question and couldn't guide me or grade me well, that first 10 minutes counters that. Sure that's not really professional, however it happens.
I don't want to doxx myself, but more than once I have been rejected by companies that were looking to do X, while I was demonstrably one of the world's foremost experts on X. Once I was rejected because I didn't know a tiny detail about CPU cache coherence protocols, for example. Something that I learned on my way back to my car in the parking lot. Makes zero sense to reject people with deep domain expertise over the trivia questions like that.
Another thing you'll see is that not every rejection is a downside. When we look forward to something we tend to paint an overly idealized picture in our minds for how it's going to be. But it rarely turns out quite like that, and you sometimes find out much later how much of a bullet you've dodged, thanks to a rejection you were super bummed about at the time. It's just work. It doesn't matter _that_ much.
Just wait until you hear about people wasting 16 years learning mostly useless things they will never need again in their life... I'm not sure why spending a few months more is such a big deal, you only need to learn these things once if you do it properly. If you don't do it properly then you deserve to waste your time, not sure why you'd take that route though. I guess it shows you don't know how to learn things properly, that is also a filter.
College (at least for me) was darn near useless - 95% of the skills I use daily were self-taught. I could just take calculus, linear algebra, and differential equations and call it a day. Most people don't even need that much.
I _really_ wish college wasn't a requirement in our field. There is no doubt in my mind whatsoever that for a sufficiently motivated, moderately smart person looking to learn how to code, college is a horrible waste of time and money, unless they're looking to learn something highly specialized, and/or are looking for an advanced degree. They'd be much better off pair programming with someone experienced, as an apprentice, and they'd be making money and acquiring real experience while learning. The same is true for quite a few other professions as well.
Doing leetcodes once or twice a week for the rest of my career (if these tests persist) seems like a really cheap price to pay to make over 400k a year.
What's unfortunate is there being a handful of companies that pay 2-3x what everyone else pays.
The very existence of such companies should ring 'ding ding ding anti-trust' but seeing how Microsoft is still kicking, better than ever with its disastrous operating system plaguing humanity, I don't have much faith in future legislators.
That said… the article offers good advice for people going through the process. I’d add that it’s not much different from type- and test-driven development. Which, conceptually, might help readers who are reading this advice and feeling overwhelmed by the idea of trying to gather the information discussed while “buying time to think of a solution”.
Which is to say, if that feels like a lot of cognitive load on top of trying to navigate “soft skills” and/or other challenges in an interview, you may find it more grounding if you map the advice to ways you already work.
Another way to look at it that occurred to me: it doesn’t feel very different from a very short sprint (or new Kanban card or choose your working cycle abstraction).
1. Planning meeting to clarify user intent, acceptance criteria, whatever you need to get started.
2. Definition of smaller tasks and any feedback loop that might entail.
3. Implementation and its own feedback loop.
The point of a coding interview is to eliminate, as fast as possible, people who simply can't code. I'm being completely serious here. They can even have a CS degree (or will claim to but if you look closely they were in an easier program to get into and took CS electives) but cannot write a simple program on the board in an hour.
If it was just a matter of determining if they can code or not references and prior work should be sufficient.
The real reason they exist is to filter for culture fit without having deal with the associated law suits if this was done outright.
I sincerely don’t believe this is true or that there’s any supporting evidence for it besides people repeating it. The point is to eliminate employment discrimination claims for large companies and this is what baseline they established to support the claim.
The point for everyone else is: we have too much to do, figuring out how to interview effectively and fairly is too much more work. Let’s use what everyone else uses.
Now they very much care about your credentials and the way you got those credentials, but also jump through these extra hoops. No doctor, lawyer, nurse, etc is asked to do this asinine shit in their interviews (and yes, an RN in the bay area can bring in 200k/year...I know some).
What started out as a great idea has turned into an even more employer-centric way to sort the working class.
I don't understand this example, which immediately leads to imposter syndrome kicking in because this is supposed to be basic, right? But as I gain more experience I begin to expect this is just poorly written.
So can anyone help me understand what is meant by this question?
For instance, a large number of emojis are formed by combining two Unicode characters with a zero width joiner character. Skin tones are a notable instance, along with gendered occupation glyphs (female doctor, say).
It would be a simplifying (and usually correct) assumption to ignore such composite characters in a basic processing task.
The input is in the form Array<Str>, not Array<char>, yet the example is ['a', 'b', 'c', 'd']. By the API, an input could just as easily be ['apple', 'banana', 'cherry', 'durian'] by the types provided.
For this problem, I also think that's a weird clarification, because it doesn't really change how you approach the problem, which should be to construct a hash table keyed by string and whose values are the number of appearances. In python this would end up being something like `return max(collections.Counter(strs).values()) > k`. Whether the strings are single- or multicharacter isn't relevant unless you're doing something weird.
It's something that's taught to first year engineering students (map and understand all the constrains of a problem before attempting to solve it, or else pay the price later...).
The system is generating thousands, sometimes tens or hundreds of thousands of events per hour. And the api that is to receive this data can only receive 100 “records” (events) per request, and the system that generates the data can’t do any sort of multi threading or multiple requests simultaneously…it can just fire off one request after another..
I did the math and on our busiest day this process would take something like 827 years to send all of the event data…
I say all of this to highlight your point that it’s a foundational skill to gather requirements..and yet I’m working with sr engineers that created this mess…
Engineers or "Engineers"? I'm asking because there's a trend in this industry to call everyone engineer (6 months bootcamp front-end engineer). But then you see things like that...
Which is ironic but it also means that applying for a company that uses such interviews is a completely different task to becoming a better engineer.
Personally I avoid such places, there is sufficiently good compensation available elsewhere from people that don't expect me to perform parlour tricks on a whiteboard for their amusement.
I would say even if you had a good background in how to implement a proper production ready database, i.e b+trees, bloom filters, journaling, etc. This while certainly enough to do the job of building a database would be insufficient to pass the interview to build a database.
Which to me seems like the system is broken.
I've actually had interviewers apologize for their lame test during the interview to me; probably because they sensed my annoyance. Usually it's a thing that HR insists on as a screening mechanism because they've heard that that is a thing they should do. Also a work culture where that is a thing breeds employees that believe it is actually a good thing. It's the old A's hire A's, B's hire C's thing. Usually, screening becomes necessary when you have recruiters supplying you a lot of C's with the occasional B. Those recruiters don't have access to either good candidates or good projects, typically.
Either way, there's a class of engineers that will happily decline to take coding exercises because they have better options to choose from because they just are that good and are probably not even answering the spam that your recruiter is shoveling out by the thousands. That's actually the kind of people I'd like to hire. I don't waste my time with doing interviews for jobs a lot and any hint of a coding exercise is a sure way for me to loose interest. I mostly ignore recruiter spam. Just like most half decent engineers I know.
It's actually a good way to screen projects; there is a lot of mediocrity in this industry. I look for a certain level of quality in projects I join. Coding exercises as part of the process is a red flag. Not necessarily fatal but a red flag still. Especially when interviewing seniors with decades of experience. Never really ends well and I tend to end the process early when that happens.
Good engineers don't come begging for a position on your project/company. You actually have to work hard to get them onboard. I know, because I've actually hired a few people that were genuinely very good. Better than me even. I love working with smart people and I love it when I find someone that is clearly razor sharp. When you come across such a person, you become a sales person. It's a time critical process where during the brief moment this engineer is actually not busy working for somebody else, you have an opportunity to convince them to work for you. That's how I interview and that's what I'm looking for when I'm being interviewed. Anything less than that signals to me a level of indifference and mediocrity that I probably need to walk away from.
Confronting candidates with some lousy coding exercise is not a great way to sell them on the opportunity. It screens candidates alright: you lose many of the good ones that you probably don't even get to talk to. Beware the candidates that get really enthusiastic about your coding exercise. They might still be good but it's something to explore further during the actual interview.