This was back in 2003, way before the Leetcode crap had taken on small companies.
The FAANGs brought this style to the EU but it's not as [dynamic programming-level] crazy yet. Interviewing in Europe feels more humane while here in the States it's gives you a distinct mechanical taste. And Europeans are more likely to discuss relevant tech and previous experience with it.
From what I have seen take home tasks had been popular in the EU before they became more common here.
It's not even a glass ceiling, it's a full on concrete slab over your head. Management is completely sealed off depending on your Alma mater.
So yeah sure, the interview process is relaxed and gentle because you basically wouldn't even be given a chance if your education/credentials weren't enough for a given position/salary .
At least the American way gives you a chance to get your feet through the door at almost any level. That's why the interviews are harder, you get a chance to get a really high paying job without having to go to say, Polytechnique Paris. Obviously graduating from Stanford will probably help you a looot still, and your Alma Mater... matters. But you can get by just fine with a diploma from a state university, it doesn't completely shut you off from those very high end jobs. And if you don't want those SV-tier jobs and aim for something less competitive, the interview process is usually just as "humane" and laid back as in europe.
I don't know about the rest of europe but I don't think americans realize how "hierarchically stiff" France is. Like sure you won't get to leetcode for a 300k job, but that's because you won't even make it past the CV screening.
I can't preemptively learn every framework that someone might ask you to use in these practical assignments, but I still think that I'm a fairly strong candidate (let's say top 10% of my graduating class).
I ended up at a company that asked more generic (but harder) questions that I could actually answer.
And so it is with interviewing techniques. You say "[leetcode] interview processes are not the only way," which is of course true. But it is also true that all other interviewing techniques are also unpopular on HN and with programmers in general. Of course each programmer has one or more techniques that they prefer, but there is no single technique that has even simple majority support amongst engineers as a whole.
Let's review some common techniques and what HN would say. NB: not expressing my opinion on any of these, just compiling common complaints you can find in any HN thread about interviewing.
Leetcode problems: rewards rote memorization over real ingenuity, not relevant to job, high stress.
Take home problem: company not incentivized to respect candidate's time; bias towards candidates that are unemployed, not engaged at current job, or otherwise able to devote large amounts of time to the task; easier to outsource; basically asking candidates to "work for free"
Review of github profile, OS projects, blogs, etc...: bias against candidates that "have a life" and don't program 24/7.
Discussion of previous work: highly subjective, susceptible to frauds and/or exaggerators, prone to false positives (complaint usually phrased in a form like: "we did this at my last company and we hired a bunch of people who couldn't code.")
“I don't know what the l̶a̶n̶g̶u̶a̶g̶e̶ interview technique of the year 2̶0̶0̶0̶ 2030 will look like, but I know it will be c̶a̶l̶l̶e̶d̶ ̶F̶o̶r̶t̶r̶a̶n̶ unpopular on HN.
But if this method was widely adopted, I’m certain HN would hate it.
Very much this. I worry that those relatively new to this industry may now only have seen the leetcode-style interview disfunction madness and get the impression it's the only way.
Absolutely not! It's not how it used to be, it's not how it needs to be. I was closing in on 20 years into my career before ever hearing about this type of whiteboard algorithm memorization-style interview. It's common now, but it's not really normal and shouldn't be.
I for one take no part in that charade. I interview a lot of people and have never done a whiteboard algorithm dump question and never will.
I don't hire people to memorize algorithms from a book and write them on whiteboards all day, so I'm not going to interview for that irrelevant skill.
I'll read your resume and let's have a chat about projects you've worked on and what you'd like to work on.
A doctor, lawyer, public accountant, and, well, many types of engineers obtain public or private certifications. As a result, it is much, much, much easier for hiring companies to find and interview qualified candidates.
I suppose, in the "old days" universities kind of, sort of, filled this role. A hiring manager looking at a resume might have said, "Oh, he's got an EE/CS from Berkeley, there's a good chance he's qualified.
Your run of the mill dev would be more like a studio musician hired to play a specific instrument in a specific genre.
Surely, he/she needs to be able to come up with lines/hooks/riffs/solos (when asked) and play part in the arrangement but composing from scratch and for multiple instruments would be rather out of scope.
While there's no direct audience for studio musicians (only the output matters) there are definitely performance expectations and the studio musicians are expected to be efficient.
Some employers ask for your personal github. That’s just like a portfolio of past work.
Wrong audition can be worse than no audition.
If you hire a piano player for large symphonic orchestra, or a famous band, and they are not already famous, you want to hear them play. Maybe one piece they chose themselves, but maybe also a piece everyone in the genre is expected to know.
And if they have to improvize a bit, that may tell you a lot, too:
https://www.youtube.com/watch?v=HtI3IMlGRMY
Sometime you meet programmer like this, than you can jam with on almost any topic. Those that can repeatedly improvize their way to "leetcode" solutions, while you observe their thinking process.
The "problem" with "leetcode" is that it has become too common and formalized. When people start to practice leetcode just to land the job, it suck the fun out of it, and it becomes harder to tell if the candidate is able to solve similar, but novel problems.
https://www.quora.com/How-does-seating-and-hiring-firing-in-...
My former teacher (he's been a concertmaster of a major city symphony for years, and is also well versed in the different ways in which one can ask "Did you actually practice?") wrote this explanation:
Think of it as management and labor. Management is Executive Director, Music Director, Principal Guest, staff, etc. Labor is orchestra musicians. Then you have the Board, which is there to raise money. Then you have the volunteers. Bear in mind, orchestras are non-profit, 501(c)(3).
So between management and musicians there is a CBA, or collective bargaining agreement. Just like the Major League Baseball has one between players and owners. In the CBA, you'll find chapters on hiring and firing. Each Symphony has its own CBA.
Usually, hiring is done by auditions behind a screen. If you're hired, your first year is the probationary period (sometimes two years). At the end of it, if management deems you fit for the job, you are granted tenure, just like at a university when you're applying for a teaching position. You don't need to re-audition, unless it is for a different title (from section to title chair, etc.), in which case you do. Firing, if it must come down to it, is also explained in the CBA.
The big symphonies are part of AFM (American Federation of Musicians). Then you have regional orchestras, community orchestras, etc. Some might be unionized, some not, but essentially it sort of works the same way.
Some concertmasters, like in England, are contracted outside the CBA, so they may be on a 3 or 4 yr contract, or more. But I think it the US, most are part of the CBA.Orchestra musicians indeed are routinely hired via a process that involves auditions, but my understanding is that applies only to those at the beginnings of their careers.
Popular/rock/jazz band formation process IMO is indeed similar to how start-ups are created (i.e. rather informal process generally based on networking, though audition jams also happen to fill a specific position). I fail to see how corporate staffing is similar.
Except that audition is to heavy on theory and minutia and the performer isn’t really showing (not given the chance) their better performance. There’s a variety of skills that leetcode style interviews flattens into a narrow category.
Engineering is overwhelmingly an applied science, not an art.
Sure, arts have elements of science and sciences have elements of arts. But, there's a reason we don't normally call scientists artists and vice-versa.
Birds are not fish, even though some birds swim and some fish fly. See?
This objection would be better addressed to the comment I was replying to, since I was just accepting the premise for the sake of argument.
Almost like fashion. At least in Europe, young people dress like a Stranger Things inspired mashup of 70s, 80s and 90s nowadays picking the best parts of those decades while leaving the 2000s and 2010s fashion in the dust.
Are you gonna do a certificate on microservices? And what's that gonna help when suddenly everyone starts building some shape of monoliths again because people keep running into the "no free lunch" issues?
On the other hand, open source culture is vastly different from proprietary culture.
So many times in proprietary culture I've churned out craptastic code to meet a deadline that didn't matter for a project whose customers were straw-persons. There's definitely some projects or features I've coded which I'm glad to hide from public view.
That said, artists can curate their portfolio, and unless they're presenting to a public forum, their turds won't have to see the light of day again.
As a software person I don't know enough about the scheme to comment on the quality of the article, but knowing Wikipedia I imagine it's on point.
edit For a broader context than just the UK, see https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...
Nothing like that exists in programming, not even languages or platforms. Which is why there exist multiple proprietary certifications instead focusing on specific details.
I agree.
After enough bridges fell down causing massive human fatalities, standards and accepted practices almost certainly "emerged."
Standards and accepted practices in software engineering will emerge, as if by magic, once enough "bridges fall down."
You are a diplomat sir; I'm merely a common street brawler.
That assertion is blatantly wrong.
Software engineers are like civil engineers and mechanical engineers because, ummm, yeah, of that word engineer. See?
I found the following on The Internets...
"California licenses Professional Engineers in the following engineering disciplines: Agricultural, Chemical, Civil, Control System, Electrical, Fire Protection, Industrial, Mechanical, Metallurgical, Nuclear, Petroleum, and Traffic."
It's almost certain that software engineers will be licensed... just like many other engineers. Why? Because certification helps to ensure people who call themselves "software engineers" meet certain standards.
Just like blind people normally aren't able to obtain a driver's license, people who can't solve FizzBuzz shouldn't receive a license to be software engineers.
You are always free to launch a revolution in the hopes of overthrowing your national government so that you can make the regulations and laws you would like.
In the meantime, when the jurisdiction you are in creates a requirement for certain software engineers to become certified (not "if" but "when"), even if the law were to apply to software engineers like you (the arrogant artistic types, you know what I mean, right?), I suppose you'll probably be grandfathered in because governments usually don't want to fight too hard to initiate new regulations and laws.
Grandfathering the "crusy old-timers" like you keeps you off their collective back because, at the end of the day, you probably don't really care about the issue generally. You probably simply don't want to be bothered to spend the time and energy to become certified.
Before leetcode, we had people asking puzzles which had nothing to do with your coding abilities, like "How many balls could fit on a Boeing 747" or "If you have 9 balls, a see-saw, and one ball weighs more/less than the others, what is the minimum number of weighings to find said ball".
Alma matter also used to matter a bunch more, and non-traditional schooling devs were much harder to come by.
Leetcode isn't perfect, but it's better than what we had before. That said, I don't think it's the "final form" or optimal template for interviewing. What I would love to see are more constructive suggestions for objectively evaluating candidates that don't devolve into things easily bullshitable or biased.
I don't think the certificate days would be much use today, given how fast frameworks change and just how many different technologies are involved with modern development.
This is also the problem with Leetcode: it often doesn't test 'can you code' but 'have you learnt this trick'.
And yet you can probably fluently juggle for loops and if statements to your heart's content; and can figure ways to bend them to your will (and to the problems at hand).
Similar goes for algorithms (the things leetcode questions ask about.) You'll probably never encounter the exact toy problems that get asked in an interview. The real world is always messy, you you need to be creative and imaginative. Knowing algorithms helps with that because you've already practiced, and have a head start in knowing what works and what not.
In fact, I am taking a short break from a problem that reduces to graph coloring with 2 colors. [1] If you interview with our team we will absolutely ask LC style algorithmic problems because one will definitely use that knowledge with us, a lot.
The problem is not LC style interviews per se. The problem is not enough companies tailoring their interview to the role they're trying to fill.
Think again.
>> given how fast frameworks change and just how many different technologies are involved with modern development.
That is not a problem.
There could be theoretical and applied certifications.
The theoretical certifications would be "one and done" (take the test once, and you are, for example a "Level 3 Software Architect). Theoretical certifications would be based on fundamental (fungible) abilities.
But yeah, if you had been a certified Level 5 Java software engineer, and then Java became eclipsed by "the new hot language" then you'd need to get certified in the new hot language to claim, "I'm a Level 2 New Hot Language engineer."
The other aspect I would mention is that the LC style interview has made it possible for a candidate not to bother about their relationships with their existing employer. It is not so for other professions. A doctors career can be nuked by unfavorable recommendations by their existing employer.
This is what every "I don't like LC / LC is harmful" post doesn't address. - How do you certify? (and no, a profile of github projects doesn't count) - How do you make the candidate free of any obligation to his current employer? LC interviews are the symptom, not the cause.
for example, go back to training people on the job.
If the company really thinks they need someone that can hit the ground running they could have trained someone that demonstrated other experience far faster than the same 7 months the job opening was there for.
The reality is that there are too many qualified people at the lower end of the pipeline and this is because we don't hire enough people as it is for our current positions, why this happens is really simple. It's to save money. There's a reason why we have terms like rockstar developer and heavily advertise the idea of a developer doing 1000x work of another one, which simply put is not true.
Most improvements to software and technology occur over time with experience and expertise what we see nowadays is an extremely self destructive behavior, at most top companies it results in heavy loss in expertise as most individuals will leave once their stock options can be sold. In order to maximize their profit while providing little to nothing of value to said companies. The idea we pay developers six figure salaries is inflated and has been a net negative. Resulting in inflated egos and an elitist environment which it is debatable to which provides anything of value or close to little at all.
We don't really need certification programs as they're typically used to stop minorities from gaining access to fields due to barriers of entry and the fact they are systemically flawed as it results in people just chasing after their next certification as the "logical" next step instead of actually learning anything of value.
Honestly, companies just need to be comfortable with hiring someone with a credible degree and taking a chance on them, it's basically the same thing as hiring with leetcode anyways according to google there is very little positive correlation. Anything else is ripe with corruption. But even this process can easily be corrupted, e.g. hiring only people from elite universities or select ones you have deals with in the area which already occurs in many places.
I'd be all for it and I have seen some international non-profits hiring like that for junior roles.
But its a hard sell for googol and the likes who 1) have excess supply of qualified candidates 2) are so used to perpetuating the narrative of absolute exclusivity among their staff.
That said: I’m tired of the attitude that there is no effective alternative to this style of interview. You do know we hired people to do engineering jobs for many decades before the industry started cargo culting what they observed a handful of Silicon Valley mega-companies doing. Plenty of very competent people were interviewed and hired before this “relive your algorithms class final on a whiteboard” style interview process became the thing to do.
These interview processes are not the only way. As I said: it’s cargo culting where insignificant companies try to act like Google or some other giant in hopes that perhaps the billions in revenue will start rolling in if they mimic them. To me this behavior is no different than “founders” who adopted dress styles and presentation mannerisms imitating Steve Jobs a decade or so ago. …And bloggers who can’t resist the “considered harmful” trope.