I've never written a sort from scratch since my college days, over 30 years ago. Also never had a job interview that asked me do to so, or any other coding questions. I'm planning more for retirement than a next job at this point, but I shake my head at what my younger colleagues need to go through these days for the opportunity to write JavaScript with IDEs that do most of the work for you.
I sometimes have to implement a sorting algorithm when I write bare metal code that doesn't have any sort of standard library available. Of course, being a 1337 hacker, I then resort to the state of the art bubble sort. Or maybe an insertion sort if I'm feeling fancy. But enough bragging.
OT: I wish I could relocate a blog post (on Microsoft’s site, I think) about a very a naive and “obviously wrong” sorting algorithm that a dev identified in their (Excel?) codebase. Turns out the code was naive because the vast majority of their users were sorting very small sets of data and the implementation actually performed much better in those circumstances.
Funnily enough, if you're sorting small amounts of stuff it does not matter what algorithm you use. If fact your O(n log n) sorts are probably a lot slower on less than some millions of elements.
I liken it to what lawyers go through with the bar here in CA. It's gatekeeping.
Just like I don't think the CA bar should have a pass rate in the 20% range, I don't think coding interviews should ask riddles that are nearly impossible to solve on the fly unless you get lucky and memorized THAT riddle in your studying.
A big part of the problem that usually never gets discussed is how the lack of institutional trust between tech companies affects hiring and interviewing. There's no licensure in SWE, so in a sense your reputation is based on the companies you've previously worked for. But it seems like even if you have "name brand" corporations on your CV, other companies have no trust that your experience indicates competency. So engineers are forced to go through the leetcode grind every three years (or whenever they change jobs). Seems highly inefficient to me, especially when it's advocated by technologists who say they want to "automate all the things."
This is definitely true. But, let's be honest here: anyone who's done at least 10 or so standard, ~1-hour technical interviews has probably run into a candidate who looks great on paper, but just can't demonstrate enough basic skill to do the job.
One such candidate I interviewed seemed like they'd be really great for the role: PhD in graph theory, publications, projects listed on the résumé, couple of different programming languages (including ones we used). To me, this person's résumé screamed "solid mid-level developer." I would have probably been willing to pass them at a junior level, had they been able to perform at that level, though.
The interview itself was a pretty familiar story. For the technical portion, I introduced the problem (not a LeetCode-type problem, a more practically-oriented problem), we talked about requirements, drew some stuff on the board, and then got to coding.
I had a feeling when we were going through the requirements discussion that this might not go as smoothly as I'd hoped, but I pushed that feeling aside and did my best to let them shine.
We let people code in any reasonable programming language, but they must write actual code. They can fill in stuff like dummy helper functions, if necessary, but we want to see some kind of running, syntactically correct, and, preferably, at least lightly tested code.
They chose to code in Java, which, while not a terrible choice, seemed to me kind of like they were just handicapping themselves when stuff like (IIRC) Javascript and Ruby were listed on their résumé.
To make the long-ish story a bit shorter, we muddled through trying to implement the requirements we'd talked about earlier in Java, meanwhile the candidate was showing me a distinct lack of familiarity with basic facilities of the language, such as "what sort of methods do lists have that might be helpful here?"
Needless to say, this person did not pass my interview, and we did not end up hiring them. But, I really, really wanted them to succeed. Like I said, on paper, they look great. And, I'm sure they could have gotten through a culture fit interview just fine. I'm just not sure how well they would have done on our team, working on our rather large, pre-existing, and somewhat crufty code bases.
If you can figure out a good way to automate the task of "filter these developers down to the ones who can write some semblance of code," in a way that goes deeper than just "Write some code and run it against our automated test cases," I'd like to hear about that. And, I'm not doubting that it could be done, in theory. For instance, maybe something like the engine behind GitHub's CoPilot could provide a way to analyze and grade the candidate's code on things like style, testability, test coverage, modularity, &c.
But, AFAIK, there's nothing like that out there now, so, a structured process consisting of ~1-hour technical interview sessions, one-on-one with the candidate, attempting as best as possible to simulate the real work environment, is about the best I can think of.
My first degree was civil engineering and I took the California Engineers in Training exam back in my college days and boy was it tough even though I had stellar grades from a top university. You could bring mountains of reference books to the exam but you had no time to use them. You had to solve endless problems based on fundamental techniques you already learned during your education.
Oh, I'm not about to claim that these licensing exams people in other professions take once and then never worry about again (bar exam, medical boards, etc.) compare in difficulty to a typical SWE interview.
But, here me out here:
Suppose the CA bar exam were changed in format to be more like a SWE interview. That is, instead of being a 2 day affair consisting of 5 essays of 60 minutes apiece, a 90-minute performance test[0], and 200 multiple choice questions, let's shrink it down to a format that fits in one day and under 5 hours.
Now, let's nix the performance test right away, because it would be incredibly difficult to shoehorn in any kind of real, practical task in under 90 minutes.
According to [1], it looks like 100 multiple choice questions are allocated 3 hours worth of time. So, basically, our cut down format could be 100 multiple choice and 2-3 essays. So, that's about half the amount of testing that's done currently, more or less.
Now, if you have half the amount of testing available, you have a choice: you can cover half as many areas of law, you can cut down the depth of coverage in each area, or some combination of the two. In any case, what you've done is increase the variability in the test. In other words, passing is now more likely to be influenced by exactly which version of the test you get.
If there's an area of law you're weak in (say, bird law), it might not even be covered. Conversely, if you're a real expert in bird law, you won't get as much of a chance to shine in the new format. That means our new format both allows somewhat more marginal candidates to pass, and gives up some sensitivity in detecting people who are really, really good.
So, in summary, the new format omits any sort of practical task, increases the variability of the test, increases the probability that marginal candidates will get through, and decreases the ability to distinguish truly excellent candidates.
Seems to me that's sounding more and more like a typical day-long SWE interview, isn't it?
While I do agree the CA bar is tougher than it should be, a lot of the low passage rate comes from graduates of less-than-stellar schools. If you look into passage rate per school it’s naturally much better at the higher ranked universities.
Isn’t that almost the definition of gatekeeping? Make the process to enter the law profession so difficult that only students from select universities have a good chance.
Of course prospective lawyers should clear a certain level of knowledge before they are allowed to practice, but the passing rate is puzzlingly low. CA law schools, as a group l, really only prepare such a low number of their students to practice?
Law school teaches you theory. The practical part is supposed to come from competitive internships.
The bar is hard for CA because we go to school for the theory and then no one really teaches you the formulaic way to answer bar essays. Add on top of that it's a lot of memorization and study. Most students I went to school with had egos and thought they had it in the bag only studying on the weekends.
shitty law schools has become a huge problem in the last couple decades. similar to ITT tech or phoenix online. They drastically lower the lsats needed to get in, then almost no one becomes an actual lawyer from that school, but they do get 100K in debt.
also, gatekeeping has a negative connotation because it is usually used when it seems unwarranted. If only schools with high quality education are passing students, that doesn't seem like a problem with the gate, but instead with the other schools. I absolutely want lawyers and doctors to be required to pass certain criteria.
Well, not exactly. You need to have a certain level of competancy to be an effective lawyer. Those who arent “good enough” for the better law schools are often preyed upon by overpriced and underresourced schools to give false hope those who couldnt cut the mustard. Not saying you cant be successful if you go to a crappy school, but the chances of it happening are slim to none. Just look at pass rates of Whittier (I think they’re shut down now) or Thomas Jefferson and then look at the tuiton rates. And this isn’t even counting the non-ABA approved schools...
many people including myself believe that availability of legal services is broadly lacking in the US. not necessarily a shortage of attorneys, but a shortage of attorneys that can do work for anything but top-quintile clients. artificially restricting who is and isn't allowed to perform certain jobs often has that sort of effect.
attorneys multiply when left to their own devices, which is often bad for society.. (since like law enforcement and middle management, LOTS of new people every year want the job for all the wrong reasons) so California Bar limits the new attorneys, which both lessens the total number of attorneys, and also advantages the incumbents.
Not all younger developers have to jump through those hoops. There are plenty of companies that don't do that kind of nonsense, because they're trying to hire good engineers, rather than, specifically, engineers -- good or bad, that'll get sorted out later -- who will happily sacrifice their spare time to figure out how to jump through the arbitrary hoops that their jobs entail.
Holding this kind of bullshit interview isn't a bad idea if you're a megacorp with chaotic teams and fourteen levels of management hierarchy where people spend most of their time on infighting and career building. You need people who jump through hoops, because successfully delivering most projects in these environments is 10% difficult technical work (which the good engineers can handle, and you can typically hire enough of them via recommendations), 40% YAML-poking bullshit work, and -- optimistically -- 50% jumping through all sorts of technical and non-technical hoops, most of them self-inflicted.
I navigated this kind of process successfully early in my career, and the only thing that made me more miserable than interviews like these was the work I got to do afterwards, after accepting the offers. Once is happenstance, twice is coincidence, three times is probably just how these things are -- I'm now pretty convinced that the quality of the interview is (barring statistical accidents) highly correlated with the quality of the actual position.
It's very difficult, because making sense of the examples would require explaining all the convoluted decisions and corporate mechanisms behind them, and that would make it trivial to identify the companies in question.
I can give one example, I guess, since it's been a long time, it's a very common scenario, and this is an internal thing, so anyone who can identify it is either already there (tequila's on me this evening, mate) or has worked there before (I'm still up for tequila).
The buggiest component in one of the projects was the testing framework. It was a home-grown testing framework, incredibly slow (think "takes about 5 seconds to send a 20-character string over a 115200 UART line"), and it had a huge bug backlog.
Virtually all bugs got closed with WONTFIX. The person who'd written that monstrosity had made it up the management line, and his minion was now in charge of the team that allegedly maintained it. Since all sorts of bullshit metrics like bug fixing rate and total number of bugs and whatnot came up during quarterly operational reviews, a low bug count was nice to have. And since no customer ever complained of a bug in the testing framework, for obvious reasons, all that was required to keep the bug count to zero was an understanding between these two guys that all bugs would just get closed.
So you had to spend a few hours finding creative workarounds, since the two-line fix you'd come up with in five minutes would never get applied. And I mean creative. We had code that literally eschewed non-functional framework code by exploiting a race condition in its code in order to do RPC calls without going through the buggy framework code.
Now imagine you have to do something like this for every single task you do and you have a pretty good idea about how it goes. I mean you technically spend 100% of the time doing what you're supposed to do, but only about 30% of it is actually what you're supposed to do, everything else is mostly fighting cargo cult practices, senior engineering ego, and management disinterest.
I had one interview where they asked me to write out some fairly complex SQL joins on a white board. This was for a Java dev gig, NOT a SQL admin gig. I decided to really lean into how awful it was by putting in notations for three different implementations (Oracle, MSSQ, and Postgres). I was subtly making fun of them but they didn't pick up on it.
I got the offer and took it because I do contracting and had just unexpectedly gotten a contract canceled early, so I was unemployed and have a family. At the end of the 3 month contract they offered me a full time position and I declined.
I do my own Graph algorithm implementations sometimes
Especially when I'm not sure the Graph approach is the right one, it's easier than either
1. Getting the Boost.Graph in the source tree to actually compile
2. Dealing with the bureaucracy of getting some, other, Graph library requiring feats of compilation possible for mere mortals into the source tree
This is, however, not something I do from memory - much like the ancestor comment I see the relevant skill as closer to recognizing positive-weight Shortest Path and knowing you want Dijkstra than being able to write Dijkstra without wifi
I happened to have, by chance, practiced writing sort from scratch right before an interview where they asked me to do just that. Doing it correctly in just a few minutes gave me pretty high status. Higher than I deserve. The randomness cuts both ways.
> I've never written a sort from scratch since my college days, over 30 years ago
I didn't study CS at college, and I've never needed to write a sort on the job, so I've only ever written sorts in job interviews! I think I worked out a basic bubble sort, and told them it probably wasn't the fastest way of doing it but that it'd do the job.
