I can't speak for everyone but the whiteboard interview has prevented me from leaving jobs earlier, moving jobs more frequently and left me avoiding certain companies altogether.
I can't speak for everyone but the whiteboard interview has prevented me from leaving jobs earlier, moving jobs more frequently and left me avoiding certain companies altogether.
But if your interview requires you to pair program on real code like you'll do in your actual job, it opens up a lot of room to look dumb in front of an interviewee. You have to handle bugs on the fly. You have to look up (for the 5000th time in your career) whether you should be using Array.slice or Array.splice in this case. You go back and look at a similar implementation in your code base for a template instead of coding from memory.
And that's a shame because the live coding exercise is both a better predictor of hands-on job success and it's a better recruiting tactic: you've just had a vulnerable, collaborative experience with someone who will actually be working with you on a regular basis and you get a sense of whether you'd actually like to work there. But we keep doing these algorithms exercises because they require such little effort or interaction from engineers who are doing this interview in between two meetings with no prep time.
I'm very interested in this claim. Every interviewing-is-broken thread, someone mentions that pairing, or take-home exercises, or work samples, or their favorite method, are better predictors than algorithm problems. On the one hand I doubt any but the biggest companies could conduct studies on this; on the other hand individuals at smaller companies might honestly remember only those times their hires filtered through this method were successful, due to confirmation bias. So it seems like an inherently difficult thing to study.
Whereas, algorithm questions lend themselves easily to a "rubric" and seeing, 1 or 2 years later, if higher "grades" corresponded to better job performance.
There was a long discussion in the GCP thread yesterday about what google has been hiring and promoting for over the last ten years and what culture that produced. Any look-back at hiring methodology vs success at google is going to embed that implicit strategy. Among other things that means another company should very much not extrapolate from Google’s experience—-even if it is based on solid data analysis—-unless they are trying to replicate that culture.
It’s more about building new things vs maintaining / improving existing things.
The problem is any one spending time on this question also has a vested interest in the answer.
FWIW my experience in hiring for my org and in the talent acquisition tech also reflects this . (Not related to the company in the link)
The reason usually this method is not as popular while the efficacy is understood is because it very hard to scale and do inconsistent evaluations and also takes a lot more time per candidate
[1] https://www.qualified.io/blog/posts/truly-predictive-softwar...
What leaves me with a bitter taste is that they don't seem to value the experience on my resume (e.g. OSS and tons of github projects, blog or scientific articles, things written by me they could actually check). It feels like they will favor a candidate who can solve leetcode problems a little bit faster to someone who is a more experienced SWE. Also the whole thing seems pretty random.
Also practicing leetcode feels like wasted time. It's not uninteresting but after you solve 500 problems, it starts to get uninspiring. There are cooler things to do for personal development, especially when you already have a demanding job.
But well, that's part of the game... at least the rules are clear, and the interviewers/recruiter are usually pretty nice.
I think take home assignments are worst in terms of wasted time. At least your leetcode skills are transferable whereas take homes rarely transfer.
Still hoping to find a friendly startup though, since some of the MegaCorps are lifestyle-incompatible and I'm already used to making a lot less than Googlebucks.
Given that top dollar can mean potentially a six-figure raise over median salaries, that doesn't exactly seem like a bad deal.
All things considered, Leetcode is remarkably accessible relative to the barriers of entry in other high-paying fields like law, medicine, certain finance careers, and so on. It's a mostly-free website that you can work through at your leisure from the comfort of your home, with plenty of Google results to walk you through the questions if you run into a problem.
Have you spend some time on Leetcode already? I could see how the questions could be daunting to new grads, but I didn't find it all that painful with several years of industry programming experience.
Don't get discouraged by the sheer number of Leetcode problems. You don't have to do them all to get value out of it. The key is to do a couple per day in your free time (lunch break, while you eat breakfast, whatever). Any consistent practice will add up over weeks or months.
The risk of cynicism is that I've been doing this for 25 years or so and there are some things I'm quite good at that can add a lot of value to a company, but it appears that the highest-paying outfits will judge me on things that are at best very tangentially related to how I can make/save them money.
Sorry if my comment came off as anti-leetcode, I have a low opinion of the thing so many people use it for, not the site itself. Before hearing of my impending sabbatical I was even planning to subscribe to the "pro" level and build it into my work routine, just as way of differently exercising my brain once or twice a week.
IMO, this is a popular misconception but it's not really reflective of reality.
Leetcode is ultra-popular with new college grades and people with a few years of experience who want to break into Big-N. As such, the vast majority of Leetcode discussions online revolve around that demographic.
It's true that the Big-N companies will still be heavy on the algorithmic interview questions, but it's not true that they'll ignore everything else on your resume. The early 20-somethings talking about Leetcode online don't have a long resume to point to, so Leetcode is the focus. If you show up with a 25-year career of successes, you're going to have a very different interview experience.
This is very wrong, leetcode is just the baseline and don't determine your seniority. Even the best leetcoder in the world had to start at the lowest junior level after college. Instead they look at your experience and what value you can bring to determine if you become junior, mid, senior, staff etc, so they very much value experience not related to leetcode. However you still have to pass the leetcode bar.
I strongly dislike having that bar, because I think it is irrational to use it as the baseline hoop everyone has to jump through. And honestly because it’s not my strongest suit, I’m sure I’d be less bothered if it was something I’m good at and your average fresh CS grad is not. Which is kinda how we ended up here I think.
Sometimes due to disconnect for say a week of preparation it takes much longer time to get back into the groove again.
It may be that the algorithms you’re required to come up with are still overkill in that they’re things you would not normally need to write from scratch on the spot without being able to references any resources in your day to day work. But as far as the format goes, this style of actually writing and executing code is clearly an improvement on the write-code-on-whiteboard style of interview.
I feel your pain though, the weeks of study that almost any good engineer needs to put into preparing for interviews can be pretty grueling.
I do not really fit any of the "standard" interviews. I've done the TripleByte interview and other top 100 corporation interviews and they all seem to assume a computer science formation or if not than assume you are a web dev. So yeah, I know how to implement most algorithms efficiently, I just can't remember how to describe exactly Dijkstra's from memory or how to balance a tree on a whiteboard under stress. I've seen them, I learned them, but 7 years after not using them I forgot (and frankly don't care).
Minimising that will give you a better interview, as if the candidate is more relaxed that’s going to be a more accurate picture of a day to day working patterns.
I like pairing for interviews on a simple problem in a real app in the tech stack your hiring for. But really spend effort easing the candidate in rather than barking orders as soon as the come through the door (or join the video call these days I guess).
I absolutely love doing Leetcode/HR myself - and think they’ve made me a better programmer. I’ve frequently found times when coding where a “trick” has improved code in my side projects (I’m really interested in making bits of productivity software so trees, graphs and ways of speeding up searching over large portions of text are a real help).
Just grinding them out probably isn’t helpful to everyone but go in with an open mind and you’ll be surprised what you learn.
If you have to solve something, and can't because it's dumb, or partially dumb, then just explain your opinion to the interviewer.
If they weigh that against you, then it's not a good company for you anyway.
Example: An interviewer once asked me details about POSIX-portability of shell-commands in devops-pipelines. I didn't know the answer, but I had done devops successfully for many years so I replied: "I'm not sure, but I don't really need to know that, because I put all my scripts in http://shellcheck.net/"
Which was a completely satisfying answer for him and one he didn't hear before. So points for me.
Try broadening your search to things like aerospace and medical technology companies.
Not sure what the correct name is, but most job listings I've seen for these industries strongly prefer people with prior experience in them because they have to follow strict frameworks / processes for safety reasons.
Assuming this is true then to me it means that universities and work experience are too heterogeneous as a measure of job performance.
In my experience that is true. Not sure how well the argument holds up if everyone is simply going to study algorithms though.
[1] clement mihailescu says it on his YT channel somewhere in a vid.
The "co-founder and CEO of AlgoExpert, a website that helps Software Engineers prepare for technical interviews." argues that algorithmic / technical interviews are the best predictors for future job performance?
Well color me shocked.
Example: if you want to work for a cloud service provider you need to jump through these hoops, even though regurgitating Rabin Karp or Tarjan's has little to do with day to day engineering.
Another example: Canonical (Ubuntu) Microsoft (windows) and Apple (OSX) all ask these questions. If you want to have a part in building an OS you will get asked these questions.
Basically if you want to work at "big tech" start grinding and don't stop until you move into management.
I have a lot of interesting projects and I can talk a lot about OS kernels and bluetooth. To get to companies working on such interesting projects the gate will be leetcode type judges website. The questions they later ask are rudimentary and none of your effort on going deep into the such interesting topics matter.
Unfortunately, Leetcode only has one of the two languages I'd like to learn, and the one I'm probably less likely to find a job doing.
https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...
Competition is ill defined in the labor market because people aren’t fungible. So it’s hard to really point to hard evidence, so and so practice leads to so and so change in salaries or increase in retention.
Aside, nobody said this guy was looking for a low paying job. High paying ones want leetcode.
Google will pay a higher salary to a 21 year old than a Miami firm will pay to someone with 10 years of experience. Nobody will ask you these puzzles outside of ~5 markets in the US. They also pay way less.
Many young people (age 20-30) I know are in a situation where they are paid large sums of money ($100k-$200k) for extremely dull work. I've seen most of my friends from college quit their FAANG job in search of something more fulfilling, often at a 50% or more pay cut.
It is a game of cat and mouse between candidates and companies. The candidates want high pay and interesting work, and the companies want only the top n% of candidates for their work, for some metric of their choosing. However many candidates a company has to choose from, they will devise some way of choosing the best among them. The methods for determining the best become (in my opinion) increasingly pathological as the surplus of candidates increases. In tech, the result is that the past decade has seen a supermajority of the most lucrative, mainstream jobs moving to a local maximum: whiteboard interviews based on data structures and algorithms. In response, candidates have gamified the process of studying for these metrics using Leetcode, and so a cottage industry of adult test prep was born.
Other industries use extreme credentialism or other methods to cut down on the vast majority of resumes they see, and there likewise emerges a cottage industry of professional preparation to break into these careers at the highest level. The companies use these methods because they see an absolute glut of candidates and become risk averse to bad hires - because after all, if they can attract so much talent with high pay and prestige, why should they suffer possible duds? This is how we end up with the, "Google is okay with passing on false negatives but can't tolerate a false positive in their hiring process" reasoning.
I hope the parent makes the best of it and becomes good at the craft, it will make the job a lot more enjoyable even if it may not be the fastest way up the ladder.
Exactly this. I suggest learning how to fabricate (or at least exaggerate) "impact" to get promoted. It's the fastest way to make money once you're in the door. Show how much of a team player you are to deliver cross-team, impactful results specifically by stepping on bodies to get there--it'll make you rich!
But having worked at both FANG and non FANG you can see the rigor of the interview process reflected in the quality of your colleagues. That’s something that is hard to deny having experienced it.
I'm personally very wary of using algorithms questions as a proxy for how "adept" someone is at software engineering. If I were running a business, I'd personally want to make sure people could manage technical debt and build decoupled systems.
I have had multiple positions at FAANG companies, and despite being "adept" according to these algorithms questions the systems built by these highly-paid (and, around me, generally experienced) people are pretty awful in terms of quality and maintenance.
Learning a proprietary stack also hampers effectiveness in future positions if wanting to opt-out of FAANG later on.
I guess what I was trying to convey is different: being good at algorithms doesn't give much of a signal (positive or negative) about other things I think really matter more on the whole.
(Of course, having enough people being aware of algorithms subtleties is important ... everyone, not so much)
Where the managers have incentivized quality and stability my team mates have moved mountains and I’ve seen some really good stuff but otherwise not.
The logic being if you can pick up leetcode in few months you can pick up most things on the job fast.
Understand that interviewers are first and foremost are looking for ability to learn and understand complex topics , it is not all that important which specific topic it is.
nobody really knows what you will be working on by the time you join or 6months later , even if the interviewer wanted to it he is not able to ask the right questions beyond the basgics.
Also university education in IT is woefully behind the industry. Functional programming, or dev tooling is barely covered in most places . Maybe they teach MVC a bit , I don’t expect most kids to understand CQRS or event programming .
Similarly I would be pleasantly surprised if you have setup a simple app, I wouldn’t expect you to know nuances between different cloud vendors , or have experience with zipkin,istio, helm , grafana or similar tools or be able to grok a explain analyse and fine tune a 500GB dB.
it is unlikely a fresh grad has production experience at best they may already know some frameworks and maybe developed a few small apps of their own, however working in large project with 1m+ lines and complex tooling is a skill that takes time to learn , there is a lot of gotchas in every area you will learn only when you see it .
So all I am left with is, does this candidate know the basics , can he understand and learn fast .
That is why these questions make sense for junior developers and never for senior devs.
So let's look at my university experience and use your post as a checklist, for funzies! :D
Functional programming: covered
Dev tooling: covered to some extent through electives where you'd teach it yourself (I also call it the Magical Course) [1]
MVC: Magical Course
event programming: never heard of it :) Reading the wikipedia page, the following courses will probably help in aiding understanding:
+ Hardware interrupts: kernel programming, binary and malware analysis and hardware security
+ User events (e.g. via JavaScript): The Magical Course and Computer Graphics
CQRS: never heard of it :D And while I get the need when reading the article from Martin Fowler, I do not have a backlog of knowledge where I've encountered this before.
Simple app: computer graphics, the Magical Course, Distributed Multimedia Systems (the practical assignments were in HTML5/JS).
Cloud vendors: nope, I learned about that when I started teaching for a coding school
zipkin, istio, helm, grafana: never heard of it :D
be able to grok a explain analyse and fine tune a 500GB dB: No. We did learn SQL though and how to model relationships with UML and entity diagrams.
it is unlikely a fresh grad has production experience: I do, because my thesis was harder than whatever production experience I was acquiring. Going to work as a web dev and web dev instructor was my form of fleeing for my much more difficult thesis. Also, computer graphics taught me volume as my OpenGL engine was 10K lines of code. The Magical Course allowed me to produce an app that I sold for 2000 euro's.
Diving into a 1 million line codebase: We did that way too briefly (the Linux OS) for just 15 minutes, unfortunately. The startups I've been at had about 100K lines of code for their complete product. In other words, a lot of companies don't have a 1M+ codebase.
Anyways, when you have someone from the Vrije Universiteit Amsterdam, you can have some idea of what they do learn ;-)
[0] My knowledge of the curriculum is a bit stale, so it could've changed.
[1] Whenever I use this sentence, I happen to refer to one course where the teacher decided not to really teach but coach and the goal was to teach yourself whatever you wanted. I happen to have learned a lot of practical stuff that otherwise wouldn't be covered. So did many others. What did I specifically do? I created an iOS app by following Hegarthy's Stanford-based iOS course online ( https://www.youtube.com/watch?v=gI3pz7eFgfo ).
Yours is above the par learning experience than most fresh graduates I have encountered. When we hire in Eupope I would very interested to try and convince some of your juniors to join!
> The startups I've been at had about 100K lines of code for their complete product. In other words, a lot of companies don't have a 1M+ codebase.
Most large companies who are also large employers sadly do have such complexity. In a startup it may not a single repo at 100k+, however overall 100+k lines for the product is very low for Saas product over two-three years it easily goes beyond.
My N=1 in a startup: we went from one monolithic 300-400k+ L repo to a ton of repos with each one perhaps < 100k . Traditional large codebases are not designed for releasing 4 times a day, even builds can take a lot of time [1], Smaller repos does not mean complexity goes away, developers need to still document, read and understand how it works. It applies also when you use libraries or third party services, while number of lines have become less, you need a lot more domain understanding.
> be able to grok a explain analyse and fine tune a 500GB dB: No. We did learn SQL though and how to model relationships with UML and entity diagrams.
The reality is that most jobs are not developing new apps from scratch, it is lot more likely to work on older codebase that has its fair share of kinks.
That means I am going to throw you deep end into large sized DB. Schema perhaps has evolved over time as product vision keeps changing, a dozen 'architects' have messed about it. In a typical job, you will be fixing bugs more than developing new features, handling tech debt - it doesn't matter stupid mistakes were made before, you still to work with/around those mistakes as someone will have to work with yours.
Even on theoretical level NoSQL is not well taught in universities. Purpose built dbs for graphing, Time Series, KV , document DBs, search indices are all important to really understand. Each has solutions to specific problem set and come with their limitations. In a typical basic storage stack there is going to probably be something like Redis|PostgreSQL|ElasticSearch: all of them solve more than one type of storage problem in more than one way.
This isn't to say the that is it all bad. Education is evolving , universities are more open to longer internships, while most don't think software engineering (not CS) should be treated as vocational course, there are positive trends. Alternative learning avenues have opened up like Coding Schools and Bootcamps who do lot better job at focusing on job skills.
[1] https://news.ycombinator.com/item?id=18442941 This is infamous post, and of course the extreme example, but you get the idea.
Thanks for reading my comment by the way. I wish I had more time so I could write succinctly. If you're ever in the position to hire people from my uni send me an email if you'd like some introductions to professors and what not.
> Alternative learning avenues have opened up like Coding Schools and Bootcamps who do lot better job at focusing on job skills.
Ah, got you there! ;-) *
* Probably not, but it's fun to imagine that I did for a second.
My first job out of CS was being a web development instructor. You might think I wasn't qualified, since I never touched NodeJS in my life and wasn't super familiar with JavaScript. I told them this but my teaching skills were really good so they gave me a unique challenge.
My challenge: make one NodeJS app in one month. I pried a bit what they wanted me to showcase, and they'd be happy with a custom blog that had user login, CRUD on blog posts and user registration.
In that month I made:
- A voting app for the game Werewolf of Miller's Hollow / Maffia
- An online sentiment analysis app based on my bachelor thesis
- A simple CMS designed to list all the hackathons in The Netherlands (though you could also retrofit it into a job board or party calendar)
- A blog app with the extra feature of adding markdown to it (what they actually wanted)
When I showed all this to them they asked me: you learned this in a month?! The thing is, I think most of us CS grads would have. And I think a lot people with a master in CS wouldn't be surprised that I created 4 apps within a month instead of the blog app only.
It's all function calls, for loops, if-statements and variables in the end. Sure, JS has closures, but we had compilers in class, so understanding on a high level the JS engine internals work, it isn't that hard. The same goes for callbacks, promises and all the other fun JS stuff that makes JS quite unique. *
* I use the debugger a lot when I learn a new language. I do think this is a super power since not many programmers seem to do it, but it gives a lot more context. It's the only way how I was capable of getting a foothold to understand X86-64 in binary and malware analysis. I'm pretty bad at simulating code in my mind, but now that I've seen it 1000's of times in debuggers, I'm a lot better at it.
Moreover, even in 2017, the resources available to self-teach how to do it were available and I self-taught everything via the official NodeJS documentation, code school and random YouTube tutorials.
So, in my case, I've seen both sides. Ironically, I became one of the best JS teachers by virtue of my CS education (and my upbringing, had to teach family members a lot of stuff). I know what coding schools teach, IMO the CS education I had was superior to that. Maybe not in time effectiveness though, but of those 6 years I spent on it, I'd say that 1.5 years was super useful, 1.5 was useful and the other 3 years is where I got C's anyway and did other things to enrich my life (such as a course on Buddhism) :)
As you point out your strong background in CS helps a lot, which is why tech interviews want to filter by that skill, it is however not essential to be a good developer.
To be a good mechanic you don't need to know engineering, knowing engineering certainly helps and give you an edge over someone starting the same time as you, but not much for senior skilled hiring. I would rather have my car serviced by experienced high school dropout mechanic than MIT graduate out of college.
Personally, I have a background in electrical engineering, I started hiring tech startup right out of uni, neither knowing tech or hiring. It is been 7-8 years and we are now 150+ strong. My brother has PhD in CS and multiple post-docs, studied in top universities and now teaches at one. Between the two of us, you would hire me any day to build a real application. If both of us started careers as developers at the same time perhaps he may have become a better developer, however today my experience would count lot more than foundation knowledge his education will bring.
tldr: The background in CS helps early on as fresh grad, but it should not be a factor for senior hires, that is problem in FAANG hiring.
I agree with everything you said. Perhaps it might be interesting to remark that I feel this picture changes in the startup landscape were things aren't always that complicated, but where the people that hire you do seem to hold you to the same standards. This is why I'm always wary about the title of "senior" at a startup.
They still pay better than finance all things taken together or am I wrong ?
Stock maybe but you can't pay the bills with that or get a mortgage even can make it more difficult.
And you absolutely can pay the bills by selling the stock when it vests. Agreed on the mortgage part though.
I think the packages in US are just much better compared to UK/Europe or maybe they just gave me shitty deals. My offer at one of the FAANG in UK was £85k + 50 stock + discretionary bonus (they didn't give details).
The one exception is Amazon which is notorious for its backloaded vesting schedule.
Bonus is not guaranteed only if you're about to get fired. Even lowest ok performance grade at google (CME) will get you 15+% bonus. But it's not a whole lot of money anyway. Stock is where you make bank.
> Stock maybe but you can't pay the bills with that
Only at private companies. FAANGs are all public and their stock is as good as cash. You can trade it for raw cash any moment the stock market is open (except during trading blackout windows before earnings) and pay your bills with it
Tell that to the tax man
Depending on the company and how much the stock appreciates this can easily be +50% of your total take home so I’m not sure why you’d discount it.
I have yet to be invited for so much as an HR call when it comes to FAANG (bachelor/master CS from a Dutch university). Maybe I'm not getting past the application tracking system?
I almost wonder if throwing “leetcode” in your skills section would get you interviews at these companies...
Simply uploading your resume to a large tech company's website will rarely get you anywhere, is what I've heard from recruiters.
If you were capable of studying Leetcode so hard that you mastered the interview process at one of the most selective software companies in the world in only a few months, it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.
Arguably, this is one of the benefits of Leetcode-style interviews. They focus on core software engineering aptitude, while not arbitrarily excluding people because they didn't use the right VCS at their last job.
But you already have your reward, right? I’m not sure how much ambition is left after you actually get the job.
In reality, it's a legal way for:
1. Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps.
2. Making switching jobs harder - for every next job one has to prepare again, because nobody is using Competitive Programming stuff during real work, so you forget.
Keep in mind that CP != CS.
And CP is not everyone's cup of tea. It is a separate discipline/subject with its own trivia knowledge & tricks. CP uses Computer Science the same way as e.g. Physics or Biology use Math.
Unless you're implying a set of companies are all in league with each other to reduce churn/competition for talent
They have been caught doing so in the past. [0]
[0]: https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...
This is a proven reality, and has been out in the open for a long time.
This was 10 years ago and involved 8 companies.
Concluding from one crime that they all do it, and that's just what those people are like, you can't trust them etc, is an impulse we all do well to resist.
Of course, concluding that nothing like this will ever happen again is also naive. The incentive to cooperate is certainly still there.
My impression is that since the 2010 case, wages have gone up dramatically in that class of companies. There are also more big companies with owners who aren't pals from before. I think. Just guessing, relly.
What they need is that somebody who passed the interview believed it was a lucky break and would not tempt fate trying a similar interview at another company. If they considered the interview just a filter, they probably would not be so lenient with letting people to apply many times and even encouraging this.
Obviously, each company can't blindly trust the interviewing practices of everyone's previous employer.
> Ageism - not many seniors are desperate enough or have a free time for Competitive Programming preps.
In my experience, senior developers don't need anywhere near as much prep as junior developers for these interviews. Leetcode problems are difficult when you're a new college grad with zero years of programming experience. They're significantly easier after you've been programming for 10 years.
> Making switching jobs harder - for every next job one has to prepare again
Companies aren't going out of their way to make it harder to hire good employees into their own companies.
Leetcode isn't an industry-wide conspiracy. Companies are using it because they believe it's a good filtering mechanism for candidates. When the Big N companies have higher rejection rates than Ivy League universities, they can afford to be selective.
> Keep in mind that CP != CS.
The problems are designed to test CS skills.
How else would you suggest reorganizing the interviews to test for CS skills?
I don't have a CS degree so I think that might be the difference, I didn't get to spend four years thinking about algorithms and data structures. Leetcode interviews are a form of gatekeeping that CS degree people use to filter out non-CS people.
Yet, they copycat each other on this.
> after you've been programming for 10 years
...as I said, you're not desperate enough, so you become picky how you spend your time.
> Companies aren't going out of their way to make it harder to hire good employees into their own companies.
Lowering the churn rate has a higher priority.
> The problems are designed to test CS skills.
No, these problems are designed to test CP skills. Even Norvig admits it has nothing to do with being a good dev/hire: https://www.youtube.com/watch?v=DdmyUZCl75s
> How else would you suggest reorganizing the interviews to test for CS skills?
How Caltech, MIT, Harvard, ETH, etc... test for CS skills? Certainly not with CP riddles - unless you take a CP course, which indeed is a separate [optional] course at some of those universities for interview preps specifically.
While CP skills also aren’t terrible useful for most companies, they are closer than CS skills. What’s really needed are software engineering skills but unfortunately our most prestigious institutions think it’s beneath them to teach that.
But even two teams within the same company often don't trust each other's interviewing practices though.
Transferring from one team to another often requires doing the same algorithm interview that new hires go through, even though you were good enough to get hired in the first place and are ostensibly a better engineer than when you started with the company.
So by that logic, why not just create some game for candidates to master. If all you're testing for is "how much they want it" and how quickly they pick up on some arbitrary system that they'll never use in their actual job, then the subject shouldn't matter, right?
You have reinvented the Chinese civil service examinations, congratulations. More generally the higher stakes a test gets the less the subject matter matters. If you make admission to Harvard or Cambridge based solely on interpretation and knowledge of pre 2000 rap it won’t be long until the same people who would have done well on a test of English literature are intimately familiar with Tupac.
Your job is to be a clever code monkey. The Process will take care of turning your coding into engineering.
Leetcode interviews are great at testing for just that. A high IQ willing to solve arbitrary puzzles just because someone said “solve this”
The list goes on and on and if someone doesn't do any of these things, the whole operation will grind to a halt. And absolutely none of these procedures involve reversing a linked list or traversing a binary tree inorder (maybe git does but that's an implementation detail hidden from me ^.^)
At my last interview process (in June) I was being hired into a more seasoned role where experience matters more than code chops. There was an algorithms question but the biggest weight was put on the “Can you design a distributed microservice infrastructure with good tradeoffs and solid relational modeling”
Series A company so it’s conceivable that I’ll be involved in all parts of the stack.
If I just did well on algorithms (I didn’t) and nothing else, it would be a hard no hire. But they were very impressed when I said “Eh for this load, you don’t need horizontal scaling except for redundancy”
Edit: assuming it's not your strong area based on the list of things you claimed not fluent with.
I keep coming back to leetcode every few months but I always get stuck on mediums so I'd appreciate any tips you can share!.
You'd probably get a pay-cut vs. FAANG or whatever, but it wouldn't exactly send you tumbling into the working class.
I really enjoyed working on software in biotech, for example, where I started my career... and sometimes think about returning with all my software-company chops to see if it's still as fun!
Maybe you should find a startup with no layers of bureaucracy and no cost centers yet? This being HN, there are plenty of them around.