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 "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.
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.
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.
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.
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.
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.
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.
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.
Not to mention in general Javascript does some pretty not intuitive things with objects: https://archive.org/details/wat_destroyallsoftware
It's (knowledge of falsy values) been a very representative indicator of how well they know the language itself. It's not an indicator of understanding software as a whole, or a given UI framework or library.
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.
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 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.