ProgrammerHumor
averageTechJobInterview
Discussion
If that solution takes anything but O(1) time, you're automatically disqualified
500 If Statements Live reaction:
DataDog told me the next step was leetcode and I told them they can just take my name off the list
Lol, datadog and Komodo health interviews both absolutely suck. I did 5 rounds with Komodo 4 off which were technical. They messaged me with “good news” then never messaged back. I think they were right that was good news
Mr May
Longest common prefix isn't even that hard though. Just iterate through both sequences from the beginning until they don't match. It seems in the same tier as fizzbuzz for a "weed out people who lack basic programming skills" question.
For 2 ordered containers, as you say it's trivial. Literally a one-liner.
For N, not so much.
Why not? It still seems like it could be a one-liner. You just advance until one of the N doesn't match or you've reached the end of one of the strings.
I don't think we're describing the same problem.
Let's do strings.
Blue
Red
Black
Bluegreen
Brown
Orange
Yellow
Periwinkle
Cornflower
Orangered
Pink
Cerulean
Blackpink
Green
Off-white
Cream
Eggshell
What's your algorithm for the longest prefix that appears in multiple strings. Eg, in this case, "Orange".
The longest common prefix of all of these strings is the empty string "" because they do not all share the same first character.
Oh, if it's for every string then that's absolutely trivial.
You'd learn more from "what's an integer" (extra funny if you ask a Javascript dev).
Oh, if it's for every string then that's absolutely trivial.
That's what those words mean, yes.
It's still easy, just more steps, and I still wouldn't want to hire a developer who couldn't figure it out.
Right, but that's an interesting question. That's testing a skill.
Just getting to "you can very easily do this O(n log(n))" is useful. Can you do it O(n)? My way isn't.
With a trie you can do it in O(n), with n the total number of characters.
A more simple solution with hash maps would give you something like O(n*k) with n the total number of characters, and k the length of the longest word. (Or alternatively, O(m*k2), with m the number of words.)
I'm guessing your O(n log n) solution involves sorting the words first?
I think there's another O(n) approach that involves essentially applying radix sort to the words. Then you can even terminate early once each word is in its own 'bucket', meaning you've exhausted the longest common prefix. Though depending on what data structure you choose for storing the buckets, I think you pretty much reinvent the trie-based solution.
So what are we thinking here? I'm thinking a tree with each letter as a node with frequency and then see what's the deepest we can traverse where frequency is 2 or more.
I did it as a tree that I stopped building when the strings diverged and kept track of the leaves, so that I didn't need to write a longest branch algorithm and could instead just backtrack to the root.
“basic” programming skills that are necessary for the job though?
Yes, knowing to loop through things and compare things to each other is necessary.
Why write it in leetcode? They’re running leetcode on their app servers?
I'm not sure what you mean. Leetcode isn't a programming language or technology, it's just a website with coding challenges, so I don't know how or why you would run it on an app server (unless your app is leetcode itself).
I mean - non-prep leetcode is kinda fun tbh. “How would you solve this random problem”, super chill, let’s bash it out together.
Leetcode where it’s like “solve this using the most optimal algorithm from memory” is like bruh what are you even interviewing for
Longest common prefix is something that can actually come up irl and is pretty simple tho
Of two strings, yes. Of N strings... not so much.
And remember you have to do it inplace no extra space and o(1) and same time proving p=np
Leetcode solves a specific problem companies need solving.
The point of the modern tech interview loop is to take a wide funnel and narrow it down. The first rounds need to narrow down the applicant pool by a factor of 1000, that's how many applicants there are to sort through, the vast majority of whom aren't right for the position.
Your engineers' time is very valuable, so you need an easy, standardized, and self-contained interview format that filters out the unqualified en masse. Only after that can the priority be finding the right candidate with positive signal.
Leetcode format interviews aren't perfect, but companies have found they statistically identify a good candidate, even if they don't identify all good candidates. Because that's the thing: you don't need to identify all good candidates, only one, because only one can take the job anyway. When the data set is highly imbalanced (vastly more unqualified applicants than qualified), and your objective is just finding any true positive, not necessarily all, you want to prioritize precision over recall. Your format might reject 90% of good applicants, but if it rejects 99.99% of bad applicants and with high probability nets you one of the 10% good, that's a good interview strategy.
And as the data has borne out, Leetcode style / DSA coding ability is often correlated with coding aptitude that's good enough on balance to make an informed choice, when taken together with signal from other rounds like systems design and behavioral. It does what it needs to for the company.
Stop normalizing it. I don’t know of any other occupation where they test for abilities not even mentioned in the job description. How many ping pong balls fit in a swimming pool, or that nonsense? Your IQ is expected to be higher than your manager’s or even CEO’s. Not a great idea to only put a bunch of IQ-optimized folks on a project that requires teamwork and social skills too. We don’t have ping pong balls in our product. The only reason software hiring is so broken is because of the lack of technically qualified first round recruiters, who have ever witnessed the work floor and processes of the engineering teams they recruit for. I will say it again and again. Founders and team managers are the best interviewers, because they know so well what they look for. Just like in other industries, filter based on actual skills for the job.
How many ping pong balls fit in a swimming pool, or that nonsense?
No one does brain teasers anymore. But if they do, that's not the only thing they test for. They test for coding fundamentals (as best you can) in the coding round, systems design in the systems design round, and past work and leadership experience in deep dive rounds, and personality / culture fit / interpersonal teamwork abilities in behavioral rounds.
the lack of technically qualified first round recruiters
You misunderstand: recruiters don't interview candidates. They just coordinate the interview process and advocate for their candidates, act as their liaison. Engineers are the ones interviewing them, and they need to find out which candidates can actually code, and who looks good on paper but can't code their way out of a paper bag. Sometimes recruiters do an initial screen, but those are so easy as to be gimmes—if you just act normal and if you have any qualifications or potential fit for the role, you'll pass that to the real interviews.
Founders and team managers are the best interviewers
First of all, they do. Engineering managers usually conduct the behavioral round. Execs even sometimes directly interview and sign off on hires at smaller companies. But second of all, it's not scalable to have the founder or some exec interview all 100 low level candidates that need interviewing that week. You need a scalable, repeatable, dead easy standardized process any engineer of yours can be trained to do that produces high hire/no hire signal.
Just like in other industries, filter based on actual skills for the job.
I'ma staff at Google, and one of the things I've seen play out again and again in the industry is that the best predictor of success for new hires is not specific domain expertise with specific technologies or languages or past projects, but technical aptitude. When you join, you're going to have to forget everything you knew, because Google does things differently. But actually, this is true of any company. Why does it take 3mo new hires to become productive at any company? Because every company has their own unique way of doing things, tooling, ecosystem, internal platforms and developer workflows, institutionalized knowledge and patterns you're gonna have to learn as a beginner when you join. Even industry wide, the landscape of technologies abs paradigms shift and evolve rapidly and continually. So aptitude is highly prized over specific expertise for generalist SWE. The skill most needed to succeed in this job is coding fundamentals, technical aptitude, and teachability.
Guess what, the coding round tests for that crucial aptitude and produces high signal for that. It turns out if you're good at DSA interviews, you can code well enough and probably have the fundamentals down. The rest of the skills needed will be tested for in the other rounds. Google makes very few bad hires, because they're so picky and selective. That's why the coding round is language agnostic—you passed the interviews in Python, but our team doesn't use Python and in fact uses languages and tech foreign to any of your direct experience? No problem, you passed the hiring committee, we're confident you can learn very quickly and adapt on the job. And by in large, they do. That's what testing for aptitude gets you.
Thanks for clarifying!
Statistically correct and reasonable, but not scalable. If all companies do this, the 10% that pass will be the only hireables, and there won't be enough fitting candidates for the job pool.
So many people here seem really afraid of being required to show any actual coding competence for a job that includes coding.
Yes, even a fronted dev should be able to do any leetcode easy task pretty much instantly. Even if it will never come up on the job.
Memorizing a bunch of random algorithms has nothing to do with actual coding though.
Why would you need to memorize alogrithms? It's easy leetcode. You look at it a think for a moment. And thinking has something to do with actual coding.
Yeah the easy ones are doable.
Yeah just walk out