Hacker News new | ask | show | jobs
by austenallred 2723 days ago
Yes. I am the co-founder of Lambda School - (YC S17 - a CS education where the school doesn’t get paid unless you get a good job). Right now we see about 3 students/day get hired.

You’ll likely hear a lot of people talking about how the market for juniors is flooded. That is partially true, but it’s flooded with people who cannot code. If you can actually be a productive employee I literally know 100 companies that will hire you today. As a self-taught engineer you have to convince them of that, which mostly means a solid portfolio, but there is insane demand. And if you get even one year of experience you won’t believe how many opportunities open up.

There are individual companies whose annual growth in engineer hiring is greater than the total number of CS and bootcamp grads combined.

9 comments

>If you can actually be a productive employee I literally know 100 companies that will hire you today. As a self-taught engineer you have to convince them of that, which mostly means a solid portfolio, but there is insane demand. And if you get even one year of experience you won’t believe how many opportunities open up.

This just isn’t true.

The industry has become insanely competitive for anyone but the top level seniors who are above the whiteboard/coderpad interview. I’ve been on the market for 4 months now without so much as an in-person interview. It’s absolutely brutal. And that’s with 3 years experience + solid references.

For every job posting now there are a hundred freshly minted CS grads applying who can pass LeetCode exams in their sleep. It seems companies are far more interested in these people than those with self taught skills and practical experience.

This is the result of poor tactics. If you're not a CS grad, quit the CS grad hiring path.

Get off the job boards and use services like Vettery and Hired, do outreach on LinkedIn with recruiters and startup CTOs/VP Engineering/Engineering Leads, go to more popular tech meetups consistently and network. Every job I've gotten has been through this.

> This just isn’t true.

Yes it is (but you need to be overall personable and have good communication skills). After 1 year at a small dev shop I started with 0 years of experience, I got an offer at a big company you've heard of (not FAANG but public) for double. I didn't take it because I got bad vibes from the management but it was great to know I could. I say this not to brag that I'm brilliant because I am decidedly NOT brilliant - there have always been better coders than me everywhere I've worked since.

However, I had some PM experience before learning development which helped my "business" bona-fides. If you are 19 going from taco bell to a bootcamp I imagine proving that you can fit into an actual business culture is more important to getting you a job than coding ability (which is the min bar).

Truthfully, if you have 3 years exp with solid references, you should have recruiters knocking down your door with (mostly) bad offers of underpaying shops. There's no reason you shouldn't unless theres big red flags on your resume.

I hate to break it to you, but you're just not trying hard enough - keep trying.

During my last round of looking for a job I never applied to a single company, I let all of the recruiters come to me. In five months, I had a total of five interviews and three offers.

I have an active github portfolio which shows a professional picture of myself and I have React skills which might set me apart (React is very hot right now, won't be like that for much longer though as the market is starting to saturate), but aside from that I'm self taught and have about 3 years of professional experience, ten if you include personal/self-taught experience.

I had to go through some BS phone screens though, it was to the point where I had to buy books specifically on C# design patterns and architecture just to pass them, I had managers grilling me on some pretty esoteric aspects of the language, but it was worth it. (I have ten years of self-taught .NET development experience)

Notice you guys are in the UK! I'm a self taught engineer (more back end focused though) and I'm trying to help my younger brother enter the industry. Is there a minimum earning threshold for the 10% salary deduction for UK courses? I think something like this would do him the world of good, especially looking at your curriculum, but don't want to saddle him with debt if it doesn't work out.
>>> there is insane demand

I am seeing it as well. And am recommending Lambda School to just about everyone who asks ;)

The main problem I see is the steep learning curve. The intro lessons are facile enough. Anyone can setup VS Code, and install an App Engine SDK. But by the time they get to modules 3-4 ("designing the data schema"). They are ready to throw in the towel.

At some point, a student requires one-to-one mentoring and repeatable reinforcement. Like learning a second language or playing the piano.

Also check out this nice write-up in Dealbook today on Lambda's model:

https://www.nytimes.com/2019/01/08/business/dealbook/educati...

> At some point, a student requires one-to-one mentoring and repeatable reinforcement. Like learning a second language or playing the piano.

It’s entirely possible to be a self-taught pianist. It’s also entirely possible to learn a second language without ever speaking to someone else in that language. What you can’t realistically do is become conversational, because you cannot practice that skill in isolation.

Similarly, it’s entirely possible to learn to develop software independently. You can learn languages and SQL normalization and good design all by yourself. You might learn faster with a teacher, but you can do it independently. You cannot learn to work well with others (properly subdividing designs, dependency ordering, giving good feedback, etc) in isolation, but honestly these are the things you generally learn on the job, because schools also suck at teaching these things.

Case in point: I'm self taught and have a junior manager job in software engineering. I had a lot of good resources and got some guidance, but I never went to a boot camp or had a dedicated mentor. It was just a lot of "learn something, apply it as much as I can to the job I have, keep learning, keep trying to understand the big picture." Eventually I developed enough knowledge to get hired as a programmer and moved up from there.
Good job. I think determination and willpower like you have is fairly rare, at least where I'm from (Midwest US).
I think it depends... I've worked on interviewing and hiring candidates that come out of coding schools. It's generally those that go above and beyond the assigned homework that get hired. When you're working as a developer, most of the time you don't have a prescriptive answer and you need to figure it out. Sometimes it's not the best solution, but that is the point advice can be given on how to improve/mentor.

Self-drive is probably 50% of success as a software developer. 35% is knowing what some of the options are (prescriptive or otherwise) and the last 15% is aptitude. You can be a solid B level developer without any aptitude, but it requires more drive. YMMV.

Different people have different personalities. When I was 4yo, I broke the training wheels off my bicycle and figured it out myself because it felt like they were more in the way trying to ride. In my early career, I spent time removing obstacles and learning literally everything I could. I am self-taught, not higher education at all. Other people need more hand holding. Once you start working, you need to be able to jump into the deep end and at least tread water.

One on one dedicated mentoring is very beneficial but not a requirement. You can also obtain mentorship/advice just by visiting various communities and asking questions online as well.

Over the past decades, many developers are self taught. And online communities and resources have only improved over time.

I wanted to PM you but don't know how, hence throwaway. I apologize for not using my real hacker handle.

I've just graduated (did 3 IT study programs in total -- 6 years of studying, overkill yes, I didn't have any good career advise via my friends, family or uni).

Do you help people from the EU to work in the US? If so, then I'd really consider applying to your school since I am noticing that I can't get there myself and US companies aren't noticing me.

I am also pretty open to learn basics again since right now algorithms and data structures has been years away. And for advanced topics I only needed that knowledge on a surface level.

Not just the U.S. but in most cases, short of a Masters degree or equivalent, it's almost impossible to get hired in another country (some countries have easier migration treaties). Even then it will be difficult. You might be able to come into the U.S. under an H1B program, but there are down sides there.

I'm in the US and have looked into moving overseas in the past. Good luck, I wish I had contacts that could help/share, I just don't.

We just launched in the EU yesterday, but immigration is very difficult right now, for obvious reasons.
Will you have classes in EU timezones as well? I have friends who would be interested in that.

Also, I noticed on the website that when I check a course it says that ISA option is available for EU citizens as well, but your FAQ says that it is for US only.

Is there anything similar to Lambda School in Spanish? Looking for a family member who would be a great dev, but her English isn't quiet strong enough to join Lambda School.
Start there, learn English. I know so many potentially good devs that cannot be hired at good paying companies because of lack of English skills. (Speaking of Mexico, btw.)
>Right now we see about 3 students/day get hired.

Do you have some salary statistics (maybe broken down by market) for your grads?

https://lambdaschool.com/outcomes

We need to do a better job of breaking it down geographically, but it’s what you’d expect. $100k+ in SFBA, big salaries in cities, lower salaries (but actually higher standard of living) in smaller cities.

If you were getting started today, would you choose the data science or web dev track if you were looking for most long-term career stability?
I would say it depends on whether you enjoy the data engineering part of data science. E.g. writing SQL queries, writing scripts to scrape data from APIs, tracking down edge cases and verifying correctness, designing clean and scalable pipelines, writing scripts to make messy data cleaner, automating report generation, data warehousing. This is very detail-oriented work and requires a certain kind of personality to excel at (imo). But if you build this skill set there is extreme demand for you that will be timeless. This is also the foundation for all data science.

If what you have in mind is feeding data into TensorFlow or PyTorch, and tuning parameters to get some magic out the other end, I don't think there's as much of a market (there are many juniors looking for work from bootcamp programs), and you risk yet another "AI Winter" backlash making companies go sour on these sorts of approaches.

I think you could also easily getting a job as a master of a particular analytics tool, like MixPanel or Google Analytics. But I'm not sure how timeless this will be: in my experience sooner rather than later you'll want deeper and more customized tools and run into the limitations of simple event-based analytics services.

It depends on where you want to start out, or go. Most developers of all types will wind up working in a dozen different environments and tools that weren't even a thing when starting.

In the end, you will never be able to stop and rest on your laurels, as you will be unable to find work if you do. Constantly learn, constantly grow, and when starting out, go above and beyond any assigned work.

You're probably correct (I don't know enough about the junior applicant pool myself but I am going to speculate nonetheless), but 'cannot code' is vague, and I think this precise sort of vagueness creates confusion around: a.) What companies need. b.) What companies think they need. c.) What prospective programmers think companies need.

What companies actually need (or should need, if they're solving some problem), I'd argue, is people who are capable of solving domain problems in structured ways. This has everything to do with logic and almost nothing to do with 'programming' or 'coding' in the sense that I believe most people understand those words today. This is a skill that has very little to do with knowing xyz language, framework, or even paradigmatic abstraction and everything to do with having familiarity or mastery of both recent and ancient mathematical and logical principles (algorithms, data structures, computability theory, set theory, lambda calculus, etc.) Of course, the way we actualize these skills is through programming languages, but programming languages themselves are not the important part (at a high level).

I think a lot of hopeful and ambitious autodidacts unfortunately miss this, as the bulk of (I'd wager) free resources for learning 'how to program' do not do an adequate job of conveying the fact that programming is ultimately the application and encoding of abstract principles into a concrete solution for a particular problem domain. This effectively leads to a pool of job-seekers that are well versed in the latest lower order abstractions (as these are encoded in programming languages, e.g. iterators or a particular framework or paradigm) and not higher order abstractions (e.g. what makes a particular construct iterable, what structural properties suffice to assert 'iterability' of a set or structure, or e.g. how should one compare paradigms and select between paradigms for a particular problem).

At the end of the day, a lot of this doesn't matter. Most people in the programming field do just fine without diving too deeply into the heart of computability or information theory (some demanding positions in the field, of course, are exceptions to this). But I think if we want to produce better 'coders' an important step lies in disambiguating logical/mathematical/programmatic problem solving from the concrete practice of 'programming' (using a particular language with particular resources, paradigm support etc.) From what I can tell, University CS programs do an effective job at this (e.g. classes on algorithms and data structures and architecture are all distinct) but many free resources, I feel, do not. This may be the culprit in the production of that bevy of people who 'cannot code'--they can program, but they can't problem solve computationally or model problems well (I can't do this myself). And I think it leads to the following common realizations on a.) b.) and c.):

a.) Companies need people who can determine and analyze sets of potential structured/logical/computational solutions to problems. b.) Companies think they need people who are good at using xyz tool in particular because xyz tool/language/paradigm etc. is popular, new, generally thought to be useful, etc. c.) Prospective developers think they must learn xyz tool/language/paradigm/framework because companies seem to want that. They do so, never exploring the fundamentals behind xyz tool/language/framework and move on to learning the next xyz ././. next year to stay relevant.

The result is that many companies are bound to the solutions, abstractions, patterns etc. that xyz tool/language/whatever supports and thus they're actually quite okay hiring people who cannot really 'code'.

In truth you probably only need a few smarty-pants engineers behind the important stuff. The majority of folks can enter the workforce only having a basic knowledge. The ones that are curious enough will start to dig into the general/abstract principles behind computation and eventually learn enough to fill the shoes of the big boys. Most entry level programmers can get by just fine with a thirst for further knowledge, the ability to notice, adapt to, and use patterns that are already in place, and some very basic analytical skills. Of course, many hiring practices don't necessarily reflect this, which leads to the classic condition of "in the interview I had to show that I could do abcd with data structure xyz and implement algorithm hjk to solve problem p in t time but on my day job I just write against apis."

Disclaimer: I am not a programmer or software engineer. This is just my sense of the state of affairs as a curious outsider (I do work in the software field, but my job role is different).

You voice a lot of similar conclusions I've come to, as someone who's mid-level and came through the bootcamp/practical application route.

One of my coworkers has a Math/CS degree and I feel like he's light-years ahead of me when it comes to solving algorithms, to address just one facet of your comment. He can see the underlying problem/solution at a much deeper level. At the same time, I think that teaching the deep theory first would have been too abstract to me; it makes more sense now that I have some practical experience and have encountered real-world problems that need to be solved.

From my experience, it's often what should be simple understanding of workflow logic or specifics to the language/environment one is claiming knowledge of. My expectations at an interview level are extremely low, but still would pass at least 2/3 of candidates by.
That is partially true, but it’s flooded with people who cannot code.

I no longer believe this.

I think “people who cannot code” is a myth perpetuated by those who gain something out of it. People who’s business or job is to filter candidates, people who’s business is to sell their own “improved” version of training, people in need of an ego boost and actually, mainly by people who just repeat it cause they heard it somewhere. I’m off that train.

But, then again, I just might be old and wrong.

I literally know 100 companies that will hire you today. As a self-taught engineer you have to convince them of that, which mostly means a solid portfolio, but there is insane demand.

I’d like to test that.

That’s my homesite: https://www.ronilan.com

I’m in the market.

Thanks,

Ron

As a hiring manager, my experience has been that the average unsolicited resume belongs to someone who can't implement fizzbuzz. (this has a lot to do with the population that spams resumes though i believe)

My experience has also been that most raw junior candidates need significant handholding to implement anything into a typical production system at first, and that the learning curve from there varies greatly.

What do you think?

Last time I was involved in hiring I created a very simple coding challenge. I've seen far worse on the other side. The goal was to read in a CSV file, read and transform it to a different format (newline separated json) node.js preferred and put it on github. There were no restrictions on what libraries could be used, no requirements for unit tests, etc. It's something that literally took me about half an hour to write at the time. Only one candidate had a working example, even then there were a couple bugs in the transform, but at least the process worked. It's surprising to me how many junior devs cannot do a simple ETL in a scripting language.
Last year, I took a contract leading a dev team at a top company here in Austin. The team, largely educated in India, said doing substantial ETL-like cleanup of the pipe-separated 15GB input file would take then about 3 days: 1 day to write the Scala & Java code, and 2 days to process it through the Spark cluster. I shocked them when I called B.S.! I spent the rest of the afternoon showing what you can do with pipelines of grep, cut, paste, and awk. Took 2-3 hours to build the proper pipeline and only 15 minutes to run it on my local laptop hard disk. The sad thing is they were impressed, but still inclined to use the ridiculously complicated cluster pipelines instead, since that was "the way we were taught..."
This sort of stuff isn't taught anywhere though, you have to either be shown it by someone else in a previous job, or have it annoy you enough to figure it out with some serious google fu (and the freedom to follow that path).

It's an unknown unknown, a lot of programmers will simply not know you can use quick and dirty scripts to process data if you're only going to do it once.

I work mainly in .Net and the similar problem I see is devs who don't even know that console apps exist, let alone how to make them, which simplifies prototyping new code immensely.

>This sort of stuff isn't taught anywhere though, you have to either be shown it by someone else in a previous job, or have it annoy you enough to figure it out with some serious google fu (and the freedom to follow that path).

Sure it is taught. It's taught by some people ( including me - plug here for my Linux and Python courses, with testimonials: https://jugad2.blogspot.com/p/training.html ) in their Unix / Linux courses, as examples of how to really put the classic (and oft-quoted) Unix philosopy + command-line tools + shell scripting to good use, synergistically ("write small tools to do one job each, well, and connect them by pipelines and I/O redirection, etc. etc.").

It's not even rocket science; bread-and-butter EDP/IT folks (programmers and even operators) (not just clued-in software engineers in product companies) have been using such scripts for decades, routinely, without thinking they are doing anything great or out of the ordinary. (And similarly for other OSs, I'm sure, such as Rexx on some platforms. Not sure what was used on Windows before PowerShell, maybe Perl and/or one of the Unix toolkit clones like MKS Toolkit or Cygwin or UWin - apart from clunky batch file language and DOS/Windows command-line commands).

It's just that it is not so well known nowadays among the (often mainly JS-using) generation, who even write CLI apps in Node.

>It's an unknown unknown, a lot of programmers will simply not know you can use quick and dirty scripts to process data if you're only going to do it once.

It's their loss (and that of the industry), comes from not trying to learn about prior art.

There's even a name for it: NIH syndrome [1], and heck, even that is not new :) Dates from early IBM days or earlier ...

https://en.wikipedia.org/wiki/Not_invented_here

Because for some, tools like awk, sed and perhaps grep are unknown skills.

The focus is on pumping out Java or C++ folks who never were given assignments using said tools and therefore never knew or learned them. Python is the new Perl, not sure what the new awk is.

>Python is the new Perl, not sure what the new awk is.

Red, said sed.

Unfortunately, the reason they probably chose their own solution is that it was probably the easiest way to get it into production in a repeatable way in their mind with the least risk they would mess it up.
My guess is that he's taking issue with this argument that I'm not quite sure was made:

"The market is flooded with people who cannot code, therefore it's easy to find a job as a junior engineer"

The market could in fact be flooded with people who cannot code (I don't know for sure). Assuming that's true, that doesn't necessarily mean it's easy to get a job as a junior dev (speaking from someone on the interviewing side).

On the market being flooded, I think it varies greatly depending on where you are and whom you are with. With my current job I am part of a competent team of smart people but on my last job it seems that IQ was in short supply, for candidates, vendors, and even our "partners".

Even though the last job ended months ago, I'm still trying to unconvince myself that everyone in this world is stupid and incompetent, because that was what it felt like.

Yeah totally. I have a friend who mostly works with the IT in big banks and pretty recently he told me he had to explain what "Git" was to a more senior eng. That was shocking to me but then again maybe I'm too steeped in webdev.
This company I'm working in right now has recently migrated from CVS to Git. Still stuck in XML hell though. And nobody understand the ginormous Ant build script.
The market being flooded with poor talent may even make it worse than it being flooded with good talent. Companies now need to invest a lot more time filtering out the people who can't code to hire junior candidates. Instead companies may just decide they will invest that money in the salaries for mid-level and senior engineers instead of time spent hiring juniors.
> I no longer believe this.

You should try interviewing "software engineers" that claim to have 10 years of experience architecting and coding in various languages and cannot write a function that doubles the value of each number in an array.

You should try interviewing as a software engineer with 10 years experience. They never ask you to double the value of each integer in an array. They ask you to find all matching subtrees in a binary tree, or to find all sub-matrices in an NxM matrix with a positive determinant in a matrix of arbitrary size, or find all words in a dictionary that can be constructed by concatenating other words in the dictionary.

The easiest questions I've been asked are unimaginative but straightforward things (build a binary tree, print inorder, find all permutations of a string, code a hash map).

There's also a particularly pernicious trend toward asking for on-line assessments or homework assignments, things that save the hiring company time but put an even greater time burden on the applicant.

I'd say "cracking the coding interview" is a good reflection of the kinds of questions you need to be prepared to answer in an interview, and they are miles away from doubling the value of each integer in an array.

I think this is why there's such a disconnect between us. You do see self-described software engineers with 10 years of experience who can't do fizzbuzz, I really do believe you. But we (the applicants) never see this, instead we see a vastly higher standard applied. Which would be fine if the companies acknowledged that they are having trouble hiring because they're extremely picky. But instead, we hear people claiming that there's a "shortage" and that they can't hire because all these supposedly senior people can't code fizz buzz.

Which would be fine if the companies acknowledged that they are having trouble hiring because they're extremely picky.

Exactly this. I'm mid-level, trying to switch jobs. Several front-end javascript positions I interviewed for asked me anything from pretty tough algorithms to "how does Angular do namespacing" to object-oriented questions relating to Java to how to style a page and add event listeners to it without ability to reference the docs, etc.

The questions per se are not undoable, but the the sheer magnitude of the corpus they can ask questions from is what's so difficult. I accept this and try to cover as much as I can in self-study and outside courses, so I can better in future interviews. But it is a substantial burden timewise, and seems to be of diminishing marginal utility regarding actual, on-the-job performance, which is pretty annoying. Oh yeah, and then they reveal that they want to pay me $75k per year for a mid-senior position, in California. I know people who make that starting out of college as Account Managers for bigger CPG (consumer packaged goods) or pharma companies, with a company car and cell phone. (Granted, I think those jobs would be boring and also at-risk over the long-term, but the time spent/compensation difference seems out of whack.)

If there really were a shortage, companies would check for fundamentals but relax their standards and offer more on-the-job training for candidates. And wages would be significantly higher! Should get rid of H1Bs as a start, and see if that helps.

Amen on getting rid of the H1Bs! Not only would doing soclear out the deadwood, the improvements in skills, capabilities, communication ability, and critical thinking would dramatically slash the true cost of software development.
I've worked with amazing H1Bs. The problem is the great ones are always underpaid and by the time and the bad ones are encouraged to do anything to keep their jobs because their entire future is on the line.
I don't doubt that you've had poor interviewing experiences with companies that ask you to do things that are not representative of the job you're interviewing for. This is a well-known problem in our field, and as a fellow engineer with 10 years of experience, I've also encountered it.

It's also not my point at all.

The comment I was responding to was advocating that there is a myth surrounding the flood of people who don't know how to code. This is not a myth.

Doubling an array of integers is one of the easiest questions I can possibly think of, and use it to build interviewee confidence as a warm-up before diving into pragmatic questions related to the job.

Unfortunately, there is a not insignificant number of candidates who claim experience and yet are unable to write `.map(x => x * 2)` or use a for loop.

I'll agree, you were making a more narrow point that there are in fact a lot of candidates who can't do extremely simple coding exercises (I agree about that as well)

This assertion is often mis-used (a slight of hand to resolve the question of why companies reject so many candidates yet claim that anyone competent will find "100 companies that will hire you today".)

However, you were not making that second assertion, you were insisting that something that is real is not a myth, fair enough.

I've seen both sides a number of times. Even when interviewing specifically those coming out of code-camp style organizations, there's probably 2/3 that never did anything in terms of discovery beyond what they were assigned. I'm not saying that anyone has to spend all their free time coding, but a bit of passion when starting out is the single best indicator of how a junior level developer will perform.

This other is title inflation where someone at junior-mid level has a senior title after 2-3 years of experience. It's all over the map. For every good developer, I've seen 2-3 bad developers. For every 10 good developers, you might get 1 great developer. For every 2 great developers, 1 has a personality that doesn't work well with others.

It's a challenge to build a team where you need to balance ability, room for growth with need. I also agree that the hiring practices outlined in "cracking the coding interview" are excessive for most environments. Most line of business applications will use tooling that abstracts some of the more difficult challenges. Cloud environments offer services that take care of many of the rest. In reality, there's more need for someone to have an understanding of when you might use a given SQL variant, Mongo or Cassandra (or any number of others), vs even thinking of creating your own systems.

In general, for "senior" javascript developers, I ask a single question. Something that's in every JS book from beginning to advanced that I've ever seen. And less than one in 10 give a complete answer, and less than half get it half right.

What's the question?

I like to ask them to explain either the concept of closures in javascript, or how `this` works.

I don't even need them to know the word closure, knowing why you can't reference a variable written inside another function, the difference between var and let, or what does bind/apply do.

What are the values that equate to false in an if statement?

false, null, undefined, NaN, "" (empty string), 0

Bonus: An object with a toString() method that returns one of the above won't evaluate directly, but will roughly equal (foo == false).

sometimes I'll ask for a function that returns input as a whole number or null, if it's a string, attempt to parse base 10, return null if invalid, return null if the input isn't already a number or a string. 0 is usually what will trip people up.

> You should try interviewing as a software engineer with 10 years experience. They never ask you to double the value of each integer in an array.

You shouldn't extrapolate your own experience into "never" or "always". I have twice your experience, and I've had insultingly simple questions like this. Amazon asked me to do fizzbuzz, for crying out loud.

we ask almost everyone the same thing, which can be resolved to one of the unimaginative but straightforward things above, but is not necessarily obvious at first glance. We fail the people who evidently can't code, not the people who fail to resolve it to the magic answer.
Well, it's pretty common to have 10 x 1 year of experience. Lots of jobs require the repetition of a relatively shallow set of skills.

When I started my current job I remember the announcement said something like 15 years experience and I thought "I've been doing lots of things for a long time, but I don't feel like I have 15 years experience in any of them" at least no the same way someone in a more stable domain might...

I've been interviewing several engineers over the last year, for the first time ever. It's _amazing_ how right you are.

I would look at a resume and think "wow this person is gonna be amazing". And then I would ask them very very basic questions, and they would get them wrong.

I still don't know what to make of it, because it doesn't make any sense to me.

I just want to thank you for your perspective.

I'd also add that "junior" can mean very different things for different companies. A junior engineer at Google could very well be "mid level" or even "senior" at a different company. Maybe even a CTO at a startup.

The industry is still relatively new and I think we're still in the early stages of grappling with how to best match programming expertise with company needs.

I've personally worked with a number of "web developers" who can barely code HTML/CSS. They tend to fall into two categories, people who use Wordpress themes/plugins to take care of everything they need, and people who outsource cheap programmers to do all the coding for them.

I don't know exactly how common either is, but I've run into both categories multiple times doing freelance work.

I agree with you. I code a lot at my current job as a network engineer. I use logic in just about everything I do - that being said, I'm actually really good at what I do and I consider coding and evaluating really old code to be my strong suit, among other things. I certainly couldn't do some of these 'tests' I see people talking about - such as import a CSV and convert it to a JSON file then upload it to github...If I sat down for an interview and they asked me that, there's no doubt that I would fail. I guess I'm lucky that I like my current job.
I'm skeptical of that trope also. I remember that stack overflow fizzbuzz post, but I never encountered a interview candidate so bad that they couldn't program fizzbuzz. I've also never been asked to do anything as basic as code a fizzbuzz example in an interview.

Most people seemed to have workable skill levels. A pretty good portion of people seemed to still be in the novelty phase of programming where they would be slightly too excited and surprised at themself, and perhaps slightly unconfident, in answering a fairly basic question correctly.

> I never encountered a interview candidate so bad that they couldn't program fizzbuzz

Me neither, in the real world, but I have seen a couple of excruciating mock interview videos where the "candidate" was unable to complete the fizzbuzz task. I think this might be a result of people thinking that learning to be a developer involves following along with video tutorials on Udemy, and that as soon as some threshold is reached, they should be ready to look for work.

By now, I think fizzbuzz has been around enough that people know it, have heard of it, and prepare enough to solve it. I have started using variations of fizzbuzz or additional questions that builds on it and I find myself catching people who only know the fizzbuzz portion.
I’ve done a version of the fizzbuzz test when zone I interviewed someone - write s function that returns true if a number is even false otherwise.

Even after I explained what an odd number was they couldn’t do it.