One data point... Senior engineer that founded the local java user group and wrote a published book on the java language. Couldn't code a simple reverse string algorithm, nor explain whether, after with help devising an answer, the method was thread-safe.
Another data point... A self-described expert in SQL with it all over their resume. Couldn't write a simple join, inner outer or other.
Weed-out questions exist because our industry is flooded with people who don't know, nor care to know, their craft. And there are plenty of employers who continue to hire these people, and promote them. I interviewed numerous "architects" (with development experience all over their resume) who couldn't come up with a naive solution, let alone the optimal, to a very simple problem. Want to fix the interview process in our industry? Figure out a way to weed out the liars? I'm all for it. I would rather not have to do basic algorithm questions, but that's the current environment.
Really, it's not fizz buzz or string reversal that causes people to re-study for their algorithms and data structures exam before an interview.
In many ways, I think this is similar to requiring that senior actuaries re-study integration by parts prior to every interview. They don't have to, because they have a proper exam that is widely accepted in their field. We don't. So instead, we are taken through full day whiteboard exams, under conditions of great secrecy, over and over, every time we interview.
Like this is it. As good as it gets.
I actually think all this back and forth, chopping and changing, people arbitrarily weeding companies out, companies arbitrarily weeding people out is providing just the right amount of randomness for everyone to wind up somewhere.
Hiring is mostly random.
It would be unreasonable for me to pass them through an interview that the other members on the team passed through based on "oh, they had a bad day".
Since you haven't been on the other side of the table, have you had coworkers who obviously were at a position above their skill level? Who allowed the rest of their team to carry them?
I've had periods wherey personal life has affected my productivity. That doesn't preclude my ability to write an algorithm that reverses a string nor write a simple SQL join. I don't ask brain teasers. I ask questions related to what the engineers under me will be expected to solve every day.
Also, are your people actually reversing strings by hand every day? I sure hope not!
My policy is to ask about those things instead. The ones you'll actually do rather than the ones that are, at best, tangentially related.
If you can't do that then you should probably worry about your own skills before testing somebody else's.
I lopped off a block of the code, made it run without the rest of the code base and explained what it was supposed to do. This wasn't that simple, but could still be explained in about a minute to somebody with familiarity in ML (assumed; that's what we're hiring for). I then challenged the candidate to spot any bugs and implement a feature.
This really wasn't that hard. I've done the same thing twice before in two completely different industries.
Why would that be impossible for you?
As I read it the main observable difference between your exercise and the kind of exercise you're arguing against is that you are starting with some baseline code that the candidate is supposed to modify. That seems like a pretty good idea, but I haven't used it yet.
I've interviewed well over 300 people, for positions from junior/entry-level to principal. If you read many of the comments to this article you'll hear other people with experience interviewing who also call out that candidates can and do lie. I don't like it, I'd rather it not be the case. I constrain the majority of my questioning to what a candidate claims to know on their resume. Here's a tip... If you don't know it (and I'm not talking about bullshit trivia questions), then don't put it on your resume.
I'm joking. (sorta)
I'm glad to hear that you tailor to the resume, that's actually better than most and my favorite approach.
But if I had a dollar for every time someone walked out of an interview with a braggadocious claim like "they couldn't even do X, they must be lying" but then answer "no" to "did you ask them anything else?". I'd be rich.
Reversing a string is a bad example, it is dead easy. But it seems a lot of people have random substitutions for it of varying obscurity and difficulty.
Just because a candidate fails or falls short in one area doesn't mean they are cut, but it's a pretty large red flag if a candidate purports to know something, both on their resume and in person, yet can't answer some seemingly basic questions. If you state on your resume that you architected and implemented a system end to end, yet can't whiteboard the result and explain bottlenecks or failure conditions, I absolutely will assume you stretched the truth a bit. And if the candidate feels the need to do that to get the job, what will it be like to work with them? Could you trust their estimates? Would you be able to back them if something they delivered fails and you trusted them as a senior to deliver?
I ask follow-ups. I give hints. Honestly I'm dismayed at the skillset of purported "seniors" and "architects", and that's interviewing for small companies up to one of the FAANGs.
Coding: on a whiteboard or with someone watching over you has no correlation with performance on the job.
Data structures: questions usually end up so contrite that they have no bearing to real-world situations. That or based on luck of seeing an remembering the right one. Data structures usually go hand in hand with algorithms.
Algorithms: questions become more like trivia or reinventing something that has likely got research papers on it. Oh, you want me to invent an algorithm I've never heard of on a whiteboard with your clues?
System design and data modelling: the kind of thing you can do in an interview lacks real-world data. No empiricism. It's all about the trade-offs.
Tailoring to the candidate introduces inconsistency and unfairness/luck.
What if these "seniors" and "architects" are frauds?! How else could they hold down a job for 20 years and not be able to answer my questions? They must be really bad!
Lucky my interview process is really great and I always hire the good ones. I track every rejection and I have proof that they never amount to anything!
Thoughts?
I agree that we don't code in a vacuum. What I'm trying to ascertain in the interview is how someone thinks, how they approach a problem and work through the solution. The more they communicate the better, even if part of that communication is "is there a length property on the String class?"
I note, but don't give it too much weight, if there are minor syntax errors. I ask candidates to walk through their code with an example input, especially the ones that have errors. If they catch their errors and fix them, I note that. If they skip over their errors because they assume the code does what they wanted it to, I note that.
Ultimately, can you reason through the problem, come up with a solution, and talk about the tradeoffs you made in your implementation. Any senior should be able to handle that without any preparation.
I worked at a FAANG where in several loop debriefs I was challenged on the complexity of my question. One of the challengers asks a chutes and ladders question (given a random chutes and ladders board, where you can choose between 1-6 for every move, what is the minimum number of moves to get to the end).
It doesn't take a hard technical question to figure out whether someone knows how to think and work through problems.
That's unfortunate, but logically inescapable.
Other hand, I'd suggest instead of "lying" that people are just myopic about their skill sets. I'd been writing JavaScript code for years, for example, but on an interview learned about a whole world of "modern" JavaScript that I didn't know existed. Clearly they thought I was a fraud. But I'd just been living on the 3rd floor without ever visiting the basement where all the pipes and boilers were.
You were interviewing senior engineers with Java experience and they couldn't come up with Assert.assertEquals("radar",StringUtils.reverse("radar"));
I suspect you were actually looking for the implementation of StringUtils.reverse() and if that's the case then you were focused on the wrong skills.
1) not asking clarifying questions 2) not being familiar with some well-known libraries 3) not being able to implement a basic reverse string 4) not being able to explain whether or not a simple method was thread safe (with multi-threading experience all over his resume)
I expect engineers, senior or otherwise, to be able to write code. If you can't do that, don't put it on your resume.
If you honestly think implementing a reverse string method is "too complicated"...
Edit: sorry, leaving the response as-is, but I recognize you didn't state "too complicated". You stated "focused on the wrong skills". I posit that an engineer that can't reverse a string, as a litmus test, will be likely unable to solve a more complicated problem.
In an interview, there is an unspoken assumption that you won't be using third party libraries to implement algorithms, and certainly not a third party library that implements it in one function call. Using that as a red flag will yield a LOT of false positives.
Also, I have over 10 years experience in Java, have used Apache commons extensively, and had no idea that a string reversal method even existed. You can't use that knowledge to judge anything useful.
A fail is not a red flag. A senior candidate not asking clarifying questions does not disqualify them (what I would call a red flag) but it is brought up in the debrief as a potential gap. I don't expect them to state this could be implemented using a single call to Apache commons. I call those candidates out in the debrief as being aware of the library, as a bonus. But not saying it isn't a negative.
It's not that I think the question is too complicated, just not the best marker.
In my mind, more relevant questions are ones that demonstrate real life experience in the field. For example, populating a tree of objects in a high level language like Java from a DB where the tree of objects are stored as many to many relationships. You'd be surprised how many times I've run across production code which does this via SQL calls inside nested loops.
This whole infatuation with algorithm questions like you'd find in SICP might be good for new grads but misses the mark for Senior level engineers.
I didn't ask them to implement dijkstra's algorithm, or even something as "hard" as breadth-first or depth-first search (which I feel any senior that deals with trees should be able to do).
It's a marker of this... Can the candidate solve a basic problem? Once they solve it, can they explain their solution? Do they understand the memory/time tradeoffs they chose? Do they know whether the code they wrote is thread-safe? If you don't feel a senior engineer should be able to answer those questions, to a very basic problem, how do you expect them to tackle something more complex?
As for the interview itself, well I've never needed to ask someone to reverse a string to determine if they're going to be of value with the criteria mentioned above.
But to be fair I've never worked on a project where implementing StringUtils.reverse() was required. If I were interviewing someone to work on Apache Commons or the JDK then I suppose that would be a relevant question.
What I'm interested in from a senior engineer is how many systems they've designed, implemented, deployed to production and supported in their careers and what their specific roles were in those projects. If I can't get an idea from their resume I wouldn't contact them for an interview.
And when their resume looks good and claims they are an expert, and you call them in and talk to them and they say they are an expert, and you start by opening a warmup question on the most basic levels of their expertise and they totally flunk it on multiple levels - unable to even handle the situation with tact or diplomacy in any way, are you still going to trust what they say about the systems they've "deployed and supported"?
And yet, despite how easy the question is people still fail it. It's frankly absurd to me that a senior software engineer can fail this question. It's practically a freebie slam dunk for anyone with basic competency. Briefly drop that you can use your language's core function or method to do it. Then declare a new array and iterate through the string backwards, appending each character to the new array. When you're done, collapse the array to a string.
In other words, it's testing if you can write a for loop. How many times in your job do you expect to implement a for loop? I use for loops quite often.
What about multi-byte characters?
If you were interviewing with me, I'd ask you to do the (usually expected) ASCII/array-of-graphemes version first. If you did that, you'd pass, and get a positive shout-out in the feedback session for asking about multibyte chars.
If you, after solving the array-based form, had some ideas or even working code for how to handle multibyte characters directly, without falling back to the standard library of $language's idea of "what is an iterable character-equivalent unit in a string", and demonstrated similar insight in your other interview problems, I'd give a positive shout-out with the addendum that we might be interviewing you for the wrong (too junior) position.
In my experience, most people don't ask about multibyte chars. That's fine, if they solve the problem. It's not a positive or negative. If an interviewer is building questions with hidden "must-ask" gotchas like that, I think they're doing themselves and their candidates a disservice.
Something interesting does happen occasionally when candidates do ask about byte-width (or equivalent less-common but still very important gotchas like pointer/word size, endianness, etc. in relevant problems): some people ask the question, solve the naïve form of the problem, and then offer some thoughts as to how they'd handle the broader multibyte case. But some other people act as if knowing that gotcha means they won't or shouldn't have to continue solving the problem. I've had candidates tell me that they "figured it out" and wanted to go on to the next challenge at that point, without writing a line of code. I've had candidates tell me flat out that writing non-Unicode aware string processing algorithms was unrealistic and a waste of time, and that they wanted a problem that was more real-world or suited to their level of skill. Those things will also get you a shout-out in the interview review session, but not the good kind.
a. You can't iterate a 'String' backwards. You need to know the length first. And that requires traversing the string forwards at least once.
b. Once you reach the end you are wasting the effort of revisiting the elements, since you visited them already once.
c. A better option is build a build a double linked list, as you are traversing the list forward.
d. Once you have the double linked list ready, you have pointers to both start and end, and you traverse the way you like.
e. An even better way would be to design a data structure that contains all this meta data at String creation itself.
Class CustomString {
char* headPointer;
char* tailPointer;
int length;
bool isPalindrome;
char* string;
/* Add your interview acrobatic things here */
}
Now even though the answer in your comment is correct, they could reject you for not coming up with the answers I gave from point a through e above.
Now imagine some one telling you that, on these grounds, you don't know a semicolon worth programming and are probably a liar.
I hope you understand what's going on here. Every body can be rejected if they don't cut through your cookie cutter.
That's not at all true in many languages. If a candidate asked "is this string's length known without an O(N) operation on the number of characters in it?" (or knew the answer for the default string constructs in the language they were using for the problem) I'd consider that a positive indicator. If they said what you just said, without consideration for the context, I'd consider that a negative.
This is not a case of someone expecting a given "cookie cutter" solution. Interviewers who do that are doing themselves and their candidates a disservice. This is a case where statements like "I know how strings work because I know how they work in $context" where $context is not what the interview expects you to work in will make a bad impression.
usize len = strlen(foo);
char* bar = malloc(len);
for (int i = 0; i < len; i++) {
bar[i] = foo[len - (i + 1)];
}
The only competent programmers I can think of that wouldn't be able to come up with that off the top off my head work in embedded or FPGAs where strings are rarely relevant.
They may exaggerate claims - yes, that is why you gave them a call in the first place. But then again you exaggerated your claims in the job posting of which skills are required for the job.
The one thing that I noticed is that only the US companies have this awkward parallel reality 'technical-interview' hiring process. In other countries like Germany or France the interview process is mostly focused on the person and the desire to work for the company and the willingness to learn the skills needed for the job. Just because you fail to answer immediately to a random question it does not mean you are unqualified for the job.
When I conduct an interview I try to only ask open questions like: * What is your favorite IDE? - Whatever the person answers, tells a lot about how he works, what tools he uses, and if he is aware of the common tools * What feature of the new Version of <Programming Language> do you like the most? - A) you may learn about some weird feature, b) you can discuss how that feature will improve code * Do you prefer JavaScript or TypeScript (dynamic vs typed language)?
There is no right answer. It is all about how the candidate argues his answer. You learn more about the person and if you can deal with him on a day to day basis (and if he has the brains to think about things).
In my experience, firing someone takes multiple months. Months in which they are mutating the codebase (with review, but it's a time sink that shouldn't exist for a decent senior), influencing other engineers, etc.
Passing on a good candidate is cheaper in the long run than hiring a bad candidate. Or said another way, false negatives are preferred over false positives.
> You would be astonished how little people lie on their CV.
This has not been my experience. From something as white-lieish as "I designed and implemented" vs. "I was a peer on the team that did it" to flat out fabrications. You learn alot by simply asking "what was your role on the project" and asking follow-ups to dig into their contributions.
Don't most companies have a probation period these days.
There was a blog post "Adventure in the Low Status of Software Engineers" by Michael Church (apparently taken down now), basically if you're interviewing for "low status" positions you're assumed to be a fraud but for "high status" positions (VP-level) you're assumed to be a great candidate even if your resumes are almost identical in both cases.
That is no doubt your experience, but I assure you it is not universal. I have heard, and in some cases personally seen, some truly shocking things!
> In other countries like Germany or France...
Perhaps the gold digging nature of Silicon Valley entices far more scammers to cook up a SWE resume and roll the dice, but I think it's a very different hiring world here.
http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz....
The point of fizzbuzz though is to make someone create a very simple algorithm on the spot. In my experience, there are some people in this world who simply lack the ability to structure their thoughts and plans into a complete set of ordered instructions. That's why you sometimes find recipes online that follow a structure like:
1. Dice the onions
2. Brown the mince for 5 minutes
3. But first, add the onions and tomato paste to the mince
It's the same personality type that cleans a room by walking backwards and forwards to the cupboard of cleaning supplies as they need them rather than grabbing all the cleaning supplies they can predict needing first.
Now, everyone does these kinds of things to a certain extent, but you can't program anything significant if you can't drop into an ordered mindset on command. Fizzbuzz tests your ability to do that without requiring you to know any apis or frameworks or computer science or even a programming language, since you can just as easily do it in psudocode.
Here's another one: when does the abs operator return a negative number?
I'm thinking the former without checking now.
Meanwhile, my last project has been to set up an entirely self hosted CI/CD pipeline using digital ocean, docker, jenkins, gitea, and docker registry to make changes to my websites I build with erlang, react, html and sass, so I _think_ I can create projects! (No guarantees).
The interview process is tough, and what do you want to root out more false negatives or false positives? It may depend on the size of the company. Google can probably shell out a few bucks to some putz who sounds impressive but isn't in the hopes they'll nab a few more great engineers at the loss of a few paychecks.
An early phase startup may not have that luxury.
Edit: must be tired since just thinking about fizzbuzz for two seconds clearly gives me the answer to what modulus returns ;-)
They actually take the opposite approach. Supposedly there is compelling research that low-performing members of a team provide large negative contribution to team performance from knock-on effects of their low standards and low quality work. Google has consequentially structured their interview process to minimize false positives rather than false negatives so as to minimize firings and the associated psychological stress caused by working in an environment in which people are regularly fired.
Knowing that yes, you master compilers (that's usually quickly determined, potentially fast enough for you not to notice it since you live and breath compilers), have basic knowledge in smashing together enough html tags to build a simple dashboard but you never had to deal with processes that spanned multiple computers, allows more flexible allocation:
Ideally, they'll give you a compiler related task, but if they find someone even more suited for that one open position in compiler internals, they might offer you a job in the adjacent compiler-as-a-service team where you'd start out doing dashboards and then move to whatever more complex task needs work.
But they won't need to bother offering you the distributed systems position that scales up the compiler-as-a-service product across the whole world without sending you to some training first.
The job opportunities are definitely out there, but many of them really require a referral (the JDs aren’t posted), and even then you might have to do a generalist interview because the company is not capable of doing anything else.
The minimum length will be the number of dots without a quantifier (i.e. exactly one character). If there is any dot followed by an asterisk, there is no maximum length. Otherwise, the maximum length will be the minimum length plus the number of dots followed by a question mark.
Writing the code for this is left as an exercise to the reader. ;)
def matches(pattern, s):
if len(pattern) == 0:
return True
c = pattern[0]
assert c not in ("*", "?")
if len(pattern) > 1:
if pattern[1] == "?":
return (
len(s) > 0 and c in (".", s[0]) and matches(pattern[2:], s[1:])
) or matches(pattern[2:], s)
elif pattern[1] == "*":
for i, d in enumerate(s):
if c not in (".", d):
break
return any(matches(pattern[2:], s[j:]) for j in range(i, -1, -1))
return len(s) > 0 and c in (".", s[0])After about 5 minutes of this I literally said:
"Dude, have you seem my resume? I literally built a petabyte scale full text search engine and wrote 1.5M lines of code to do so and a HTTP framework that parses fetches more than 2PB of HTML per month. If there's some edge case that I might miss I can Google it in 30 seconds".
I no longer keep small tactical issues in my head. It's pointless. Now I try to understand the system as a whole.
Or they could just be asking gotcha trivia. It’s hard to tell.
It sucks, but this is what happens when the job you’re interviewing for has no license or certification requirements (but pays six figures).
1.5M lines is the output of a team of hundreds of developers over years. I don't believe anyone would write a million lines during a job.
2PB a month, is 125B documents at 16kB each, or 50k documents per second. That's decent. That's where it starts to be interesting in elasticsearch or hadoop.
About 200K lines of code is auto-generated.
A more appropriate estimation would probably be about 400k lines per year as some of this code did a big mass migration and refactoring during this time but I wrote that code as well. Just in the past.
KLOC is a shitty metric anyway.
I'd rather write 100 KLOC that worked vs 10000KLOC that was horrible.
But in most cases. Its not very difficult to write 1.5 million lines of code for any project if you are writing code of the style AbstractClassFactoryFactorySingletonDispatcherFacadeInitializer
That sort of the code is basically 90% auto generated by the IDE. You write the remaining 10%.
As a matter of fact I would find it a tad little hard to believe that some one wrote that much(1+ million LOC) and didn't find a way to template it or do some metaprogramming work.
Patterns always emerge from that kind of pile.
I don't think a developer would write a million line at work in their entire lifetime.
I'm not saying it's impossible to achieve. I've seen outsourcing agencies deliver 100k lines with just a few block copy/pasted many many times, but that's neither working nor maintainable software.
;)
I would like to speak to this after interviewing at a few places recently, including Google. I don’t think a single interviewer looked at my resume. I’ve developed a sizable open source project that is used by real people for over a decade. If the company really wanted to know if I could write code they could just go and look at it. Instead they ask puzzle questions that I have no interest in and end up failing. These companies expect the candidate to spend weeks preparing for their hoop jumping, but can’t be bothered to actually read the CV. Multiple people didn’t seem to realize where I lived even when my address was at the top of the paper.
1. Make sure you actually know what’s on your resume
2. Make sure you have the strategic thinking and interpersonal skills to own the system you’ll be working on
3. Make sure you’re a good match for their fairly unique work culture
It’s a relatively simple project with a skeleton of a class and failing unit tests. They have to fix the code to make the unit tests pass.
If they get through that, I give them a second set of failing unit tests that they have to make pass by fixing the class without breaking the unit tests.
But, just because a company gets big, doesn’t mean that you can take hiring less seriously. You still have to be sure that you hire the right people. A false positive - hiring someone that can’t do the job - is worse than a false negative - not hiring someone who would be a good fit.
- There are usually HR policies around firing people that takes awhile and a lot of paperwork.
- You open yourself up to lawsuits whether they are successful or not, it still a hassle and has costs.
- you increase the amount you have to pay to your states unemployment insurance fund.
- It puts a chilling effect on other employees. They think they can easily be fired to.
- if the employee is really bad, they do “negative work” and put more work on the other employees who have to work around them or redo their work.
Very rarely will one employee that you don’t hire make or break an established company.
Everything I know about management, hiring, firing and organizational theory comes from the Manager Tools/Career Tools Podcasts.
As far as hiring, this is my go to guidance.
https://www.manager-tools.com/2007/04/effective-hiring-set-t...
That's bad interviewing.
I can do the problem easily without someone looking over my shoulder, and I need more than 10 minutes just to think about the 8 or whatever rules he gave me.
He failed me, and I ended up working there anyway a year later after the guy quit (true story).
Fundamentally: Why are you having the "Can you code your way out of a wet paper bag" conversation instead of the "How much value can you add to this company" conversation?
Perhaps my experience as a consultant/freelancer is breaking my perspective. It's been several years since I last had a coding interview as an applicant.
You don't want to "apply" for things. You want your google VP to be having a beer with your ex-boss and worrying that his pet project was going to fail because they just can't find a guy who can really $X.
But your ex boss knows a guy who absoulutely can $X, and just finished $X'ing his company back from the brink of disaster. Lets give him a call to see if he's available.
HR will be told to give that guy an offer and, optionally, collect a resume to keep on file.
That's what we're talking about here, and it's where you want to get yourself if you want to build a career as an individual contributor.
Edit: I see from your other post you haven’t interviewed since 1999. Sounds about right. The hiring process does not work how you think it should.
From talking with other devs in my peer group, this doesn't seem uncommon.
No, HR will be told to get that guy into the interview pipeline as soon as possible, so he can go through the same process everybody else does for a similar position.
If they buy the company that you built specifically to get access to you, do you think you'll still end up getting screened out by some junior dev on a whiteboard? All policies have exceptions. Your goal is to be exceptional.
In this case probably not, but you'll have to do several rounds with the VPs. Of course the tenor is very different, more conversational / situtational instead of technical questions. But you're still being sniffed out. Unless you're already pals with the VP.
Could you elaborate on that? Do you mean being a contractor should be your goal as "the guy" or the hirer?
It can make sense for consultants, doing short gigs here and there. People can refer you elsewhere when the current work is completed, they ain't gonna keep you anyway.
Some people will be at the top of their field. Most people won't.
Because people lie. It's that simple. Referrals lie, CVs lie, friends lie to get friends in a position. Do understand that there's a fundamentally different set of problem a 40.000 FTE company has to deal with in comparison to a 30 person startup.
Also is doing a full day interview really such a horrible sacrifice for most paid jobs in the world? Professions like laywers and doctors need to go through significantly longer hazing rituals to get to FAANG income... is a month of study to be essentially among the most paid people in the world REALLY such a horrible thing?
I have to do a little more to satisfy the process, of course, but I'd be more satisfied if more interviewers didn't just accept the process (as you kind of have to do as an interviewee if you want certain jobs) and continuously asked themselves how they can make things better within their own influence. I could only throw up my hands and sigh when a coworker asked me for interviewer advice, we had a big discussion about interviews, and in the end he just grabbed a random problem off some interview problems site that he hadn't even tested if he could solve himself in the time limit and gave that.
too-strong fear of a
lying false positive
Summary: the cost of a false positive almost always outweighs the cost of a false negative.
And any company that has thought about their hiring process for more than 30 minutes will have a probationary period of 30 or 60 days or so, after which employment can be terminated if the employee is not able to do the work.
https://www.alphr.com/business/1005261/silicon-valley-swipin...
https://www.statista.com/statistics/273744/number-of-full-ti...
https://www.statista.com/statistics/219333/number-of-google-...
At least for doctors this isn't universally true. There's continuing education/certification, (which you have to do every $period) there's public reputation, there's lots of networking. From what I've seen the interviews take few hours in one day and people usually already know each other.
I'd much rather deal with whiteboard interview bullshit a few times in my life, then go through residency in the medical field.
This has nothing to do with how programmers are hired, and everything to do with the business cases that building software serves. Even if programmers were hired like doctors, they'd still be cyclically losing their jobs, because their jobs are closely tied to the willingness of the economy to spend large amounts of money on custom software.
If you want a job for life, then you want to be in a profession that does something unconditionally useful. Healthcare, garbage pickup, teaching, farming, being a janitor. We're going to need people doing all that long after <insert Silicon Valley fad of the month> is dead and buried.
Since then every gig has come via an introduction by a former boss or co-worker, or by introducing myself to somebody with hiring authority and using a pile of impressive artifacts to skip the "can this guy do the work" questions.
The first several years of your career should be getting yourself into a position where nobody would ever dare ask you to sort things on a whiteboard.
Right.... so if you have a mismatched role, that's it, you're done for, huh? Please.
Also, fizzbuzz isn't anything you really need to study for (certainly not for days or weeks). It's something you should be able to work out during the interview if you truly have developing experience. But then again, I've known people with amazing resumes who couldn't even understand the fizzbuzz question itself.
Because cheap stuff you can run away with on 1mil users suddenly falls apart when you need to serve more across continents and suddenly you kinda need to know what all those words in documentation actually mean.
Also, as for CV, everytime I've interviewed people I've gotten more than I few people that lied in their CVs. Persumed "senior developers" who couldn't do a fizzbuzz in their chosen language and tooling. CVs are utterly worthless from interviewers perspective - there will always be someone with exact same CV like you have but will be utterly incompetent.