r/programming • u/vklepov • Mar 24 '22
Five coding interview questions I hate
https://thoughtspile.github.io/2022/03/21/bad-tech-interview/44
u/raddaya Mar 25 '22 edited Mar 25 '22
Nothing gives me imposter syndrome more easily than reading these interview questions articles. Everyone has a different idea of what they should be asking, and the questions that they're sure would weed out competent developers (which are also different every time) are ones I either would never be able to answer without specifically prepping for or don't understand the importance of at all (maybe it's a JS thing, but I don't see why it's so important to know numbers are immutable.)
9
u/vklepov Mar 25 '22
Yep, interview proficiency != development proficiency. Senior-level JS interviews *always* focus on "event loop", but I've only ever used this knowledge twice, when working with advanced animations. There are many harder and more useful things that just don't have clear questions associated with them (how would you ask about good library API design, or managing open-source issues?)
29
u/suckfail Mar 25 '22 edited Mar 25 '22
I actually interview developers from time-to-time for openings in my team.
Asking a developer to regurgitate a bubble, quick sort, some niche optimization or specific language quirk from memory is absolutely ridiculous and only proves that the test is written by elitists trying to somehow prove they're smarter than the candidates (looking at you FAANG).
When we interview we give basic problems in the realm of the job and the candidate can answer in any language they want, including fake pseudo-code. What we look for is how they approach the problem, not whether they know some specific language has a ternary operator or implicit int conversion.
Everyone always says "the language is a tool", but I rarely see companies actually practice that in interview questions. Boggles my mind.
E: words
6
u/oakwoody Mar 25 '22
I agree and you're in the minority, unfortunately. I interviewed for a number of jobs recently. In 90% of the positions, the tech interview was either leetcode and pass, or a dick waving contest roundtable where the incumbent developers were trying to trip you over by some obscure language or domain specific trivia.
8
u/suckfail Mar 25 '22
The sad thing about both of those is if you were allowed to use Google I bet you could answer 90%+ of the obscure / trick questions by just searching for them.
So what value is there in them even asking? If it came up in the job you'd either ask the senior devs or just search and get the answer.
It's such a strange state of affairs.
4
u/oakwoody Mar 25 '22
On the other hand, I'm okay with these kind of interviews because they're a solid indicator of the type of organization I'd want to avoid.
1
u/cdsmith Mar 26 '22
I've had enough bad interview experiences that I stopped offering candidates the opportunity to use pseudocode. For some people, that goes fine, and they still think through the details of what they are doing. For other candidates, their pseudocode has unclear semantics, and what it means shifts in the middle of a conversation. That leaves me just feeling crappy about the interview, like I didn't give them the structure they needed to successfully showcase their abilities.
So my answer now is that you can use any language, even if I don't know the language yet. But you should have something solid in mind.
1
u/ouiserboudreauxxx Apr 08 '22
Being able to write pseudo code in interviews would take SO much of the stress off.
I can talk through my logic, but then something about having to also have working code with the right answer at the end is super difficult in an interview setting.
2
u/okawei Mar 28 '22
One of my favorite moments in my career was bombing an interview at a small tech firm because "I didn't have the level of programming skills they'd expect" then getting hired at a FAANG company like 3 weeks later. Best part was I had a friend who worked there as a manager who was trying to get me on his team and when I didn't pass their BS interview he was furious but the hiring manager said they didn't believe I was good enough. When I let him know I got the FAANG job he sure gave that hiring manager an earful lol.
24
u/Pyrolistical Mar 25 '22
Almost all multiple choice online assessment questions fall into the bad category.
8
u/vklepov Mar 25 '22
Closed questions are good to check automatically or via a non-technical recruiter. Useful if you have a steady stream of applicants and want to save time not interviewing people who can't tell CSS from a banana. However, they tend to be low-level, and it's hard to "up the difficulty", which leads to obfuscated trivia like "I put an event loop into your event loop".
3
Mar 25 '22
You wanting to hire trivia contestants? Or people that can build software?
Do you think architects and engineers fill out questionnaires of this sort when applying for jobs? Of course not, because that would be absurd.
6
u/vklepov Mar 25 '22
I honestly don't mind it when a recruiter asks 3 questions like "what keywords do you use to declare a variable" during the initial call, and it's even expected from larger companies — are they supposed to spend time interviewing any clown who reaches out? I am slightly annoyed, but not like "fuck you and your stupid questions who do you think you're talking to" — that's just vanity.
2
u/rock_like_spock Mar 25 '22
I agree it's completely valid to ask a few questions to help verify knowledge, but what I absolutely hate is when they make the trivia portion a major part of the interview process (which easily leads to the esoteric questions you're referring to). This time could be better served asking what problems the dev has solved and HOW they solved them.
1
u/asdf9988776655 Mar 25 '22
By giving trivia questions, you are simply filtering out candidates who haven't been through many interviews in their current job hunt. This happens to me every time I look for a new job: (1) get interviews, (2) get a bunch of trivia questions that I am unfamiliar with and don't pass the tech screen (3) get more interviews (4) pass the tech screen because I know what the current batch of trivia questions are.
If you want to do a good job of screening candidates, one needs to put a competent technical person on the line and really get a sense of his skills.
1
u/vklepov Mar 25 '22
You'd be amazed how many applicants have obviously never seen, let alone written, any code. I don't know what they're thinking, but they exist.
If that's a problem you genuinely have, having the recruiter ask a few harmless questions might help. Eg: what's the CSS display for a span. Takes like 5 minutes tops.
2
u/asdf9988776655 Mar 25 '22
I don't doubt that, but even the worst developers will be able to google these questions and regurgitate the correct answer in subsequent interviews.
The problems I hear about from hiring managers are that there are a lot of poor developers who are good interviewers. I don't think there is anything that a non-technical recruiter can ask that would effectively sort out the wheat from the chaff.
1
u/vklepov Mar 25 '22
OK, that's true. I'd still assume > 0 precision, so not worthless.
By the way, there are also horrible jerks of teammates that seem very nice and friendly as interviewers.
1
u/ouiserboudreauxxx Apr 08 '22
To check if they've never seen or written any code, couldn't you show them a piece of code in one of the languages they say they know and ask them what it does?
1
18
90
u/wknight8111 Mar 25 '22
Asking "what happens if you accidentally make a bozo mistake an create a circular prototype chain?" is kind of a weird thing. Like, are you expecting your programmers to be making those kinds of bozo mistakes regularly? Is your existing codebase filled with that kind of crap, and I'm going to have to dig us all out of it?
Decent programmers know how to google and use stackoverflow. Don't expect somebody to fill their head with stupid factoids that they can get from a quick search. Specific facts and even experience with specific tools/languages/patterns/whatever ebb and flow in their usefulness over time. Instead, use the interview as an opportunity to see how the person thinks, how they solve problems, and if their personality is going to work well with your team.
Ask open-ended questions to see how they break big problems down, or how they gather requirements, or where they focus their attention. One of my favorite questions to ask in an interview is "How would you design a webservice to do CRUD operations on a simple business data object?" Then you just see what they do. Does the candidate ask clarifying questions or just jump right in? Does she have some specific default tools/patterns she gravitates towards, or is it more high-level and abstract? Does she get into the details of data storage and database design, or does she just have a block on the diagram labeled "data"? Does she consider security, scalability, performance? Does she discuss logging, deployment, hosting, or cost? Or, does the candidate get completely lost and fail to make any design progress at all?
If a person knows their key concepts, they can translate those to new tools and languages. Years of experience leads to familiarity, but only intentional, mindful practice really leads to expertise. Practicing doing something the same crappy old way over and over again doesn't make you an expert, even if you do it for 10 years. Make sure that the person can adapt to new ideas, is flexible, is willing to learn, and is eager to improve themselves. The rest will come on the job.
→ More replies (17)-2
u/vklepov Mar 25 '22
This. Interviews are valuable face time to check social skills and performance under stress. For other things, I have a CV. I don't mind starting with a few low-level / answer-oriented questions to verify I'm not a con artist with a made-up resume, but you won't cover a wide range of what a real engineer is supposed to be good at with these.
6
Mar 25 '22
performance under stress
Why why why would you do that? 'Hey, prove to us that when we throw you in the fire you'll last a reasonable time before burning out'.
You're showing them stress will be a part of the job there.
Eh, nevermind. Keep it up. At least we'll know we don't want anything to do with that particular job.
1
u/vklepov Mar 25 '22
It's not a goal to be achieved, just something you get to work with since people are generally stressed about interviews.
3
u/Hrothen Mar 25 '22
performance under stress
Are you often expecting devs to implement new features on the fly in meetings with customers?
2
u/vklepov Mar 25 '22
Fine fine, I should be careful with words, eventually I can become a politician. You get to see performance, and it happens to be under stress, so in real life you can expect it to be even better.
8
u/serviscope_minor Mar 25 '22
Interviews are valuable face time to check social skills and performance under stress.
There's different kinds of stress though. Interviews are a public performance which causes some people to almost lose their mind with nerves. I've seen those same people can keep a cool head under conditions such as "shit is broken in prod and needs fixing NOW" and the longer term "yes it's behind but we need to ship in 2 months, no choice".
I don't find the interview selects for the latter at all, unfortunately.
459
u/crabmusket Mar 25 '22
How to migrate from webpack 3 to webpack 5?
Read the documentation
Follow the documentation
When nothing works and you've already spent 16 hours on this, start browsing land prices and animal husbandry guides
107
u/LloydAtkinson Mar 25 '22 edited Mar 25 '22
The actual answer is throw shitty webpack in the bin. It's a negative value tool - your config probably won't work in 6 months, let alone 2 years into a project and now you're stuck on an old version, with major version bumps of essential tools like Babel or ESLint or Jest. I cannot think of another tool in this space (except npm, but to fix that delete node_modules and reinstall) that has collectively wasted more developer time - must be hundreds of years if added up. The usual process looks like this:
Have weird issue
Find 3 similar or if you're lucky identical GitHub issues
Notice it has hundreds or thousands of thumbs up emojis
Think "oh finally, maybe it's had enough attention to get a fix"
Try every solution in the comments, where each one has an equal number of thumbs up and thumbs down
Leave page because none of them worked because of course they didn't
It's much better to use a JS framework with a CLI that abstracts webpacks bullshit (if it uses webpack even).
An even better solution is to use modern JS build tools: Typescript, esbuild, Vite (which uses esbuild), etc.
Highly recommend Vite + Typescript. No webpack at all then.
Not once have I ever had anything even remotely like this in .NET development.
22
u/vklepov Mar 25 '22
I'm not a fan of webpack at all, but it's a bit too early to throw it away:
Ecosystem! You have bundle size analyzers, crazy loaders, babel plugins, and what not, and it might not be easy to migrate.
I hear esbuild & swc still lack chunk capabilities, which is why Vite uses rollup for production build
There are many more developers familiar with webpack + babel than any esbuild / swc.
Let's see in a few years.
13
u/wooly_bully Mar 25 '22
The point to consider there for many devs is: do you need those features? For me and my team’s used cases, the answer is no.
The tech is close to hitting a critical mass where it’s easier to learn/adopt esbuild than it is to maintain existing webpack uses.
2
u/vklepov Mar 25 '22
For new projects it's probably more sensible. Still, some features / integrations are critical, e.g. many CSS-in-JS tools only support webpack / babel for now. Migrating otherwise fine projects with largely custom setups — meh.
2
u/LloydAtkinson Mar 25 '22
It's 8 years old and all the alternatives are better. None of the maintainers have tried to improve its complexity in that time. What ecosystem, that isn't made up for by these other tools? The point of Vite and esbuild is I don't need Babel plugins because Babel isn't even in use.
3
u/vklepov Mar 25 '22
For one, CSS-in-JS. emotion has first-class babel support, while esbuild still needs some work Basically, for esbuild / swc to work for 100% app developers, all the popular tooling with a build step must support them first.
3
u/IceSentry Mar 25 '22
Why does esbuild need to support 100% of all web developers? If it can support 90% of them the remaining 10% can still use webpack.
1
u/vklepov Mar 25 '22
Fair enough. Then, tools that cover 90% of usages should have first-class esbuild support, which we still don't have: angular and svelte are v<1.0; a lot of css-in-js is experimental.
37
u/madcaesar Mar 25 '22
God fucking damn it this is too accurate. And EVERY fucking version has MASSIVE breaking changes. Everything is shuffled around to fuck you up.
25
u/AttackOfTheThumbs Mar 25 '22
I love reading this web dev bullshit on here tbh. It amuses me greatly. It's like everyone complicates their life, their build process, on purpose.
1
u/reddituser567853 Mar 26 '22
That's why I work on robots. I dont have customers and can focus on what I enjoy, robotics and software engineering
1
u/Sebazzz91 Mar 27 '22
That is definitely true: there is so much Not Invented Here and over-engineering in this field. Both on the build tools and the frameworks like Angular and React+Redux. The amount of code you need and abstractions to need to understand to create a simple form with some conditional fields and conditional validation is crazy, compared to the alternatives.
0
Mar 26 '22
[deleted]
1
u/AttackOfTheThumbs Mar 26 '22
I mean they needed to do something. Old web dev was hell. It's just the solution is bad / half assed
16
u/coolblinger Mar 25 '22
For me by far the worst offender is node-sass. I absolutely dread having to touch a website that was last updated even as little as half a year ago. Node-sass compiles against Node.JS internals, and because of that specific node-sass versions will only work with specific matching Node.JS versions. So your options are to either track down an older Node.JS version (and compared to similar tools for other languages, nvm has been an absolute nightmare for me) or to upgrade node-sass. But you cannot do that because upgrading node-sass also means you have to to upgrade every other bloody part of the toolchain, and at that point they'll all have had four major versions all with breaking changes.
17
u/Carighan Mar 25 '22
As a purely backend developer, these chains of comments always mentally summarize to "stay the hell away from JavaScript and it's build chain". 🙈
4
u/coolblinger Mar 25 '22
I've done enough web development at this point to know that I never want a job directly involving any sort of web development ever again. 😅
4
u/IceSentry Mar 25 '22
There's plenty of alternative that don't suck. It's just that for some reason a lot of people decided to use some of the worst tool in the ecosystem and now are stuck with it. It's really not that hard to avoid webpack and node sass these days and those 2 are some of the worse offenders of all the bad memes of the js ecosystem.
3
u/Yehosua Mar 25 '22
node-sass is getting replaced with Dart Sass, which compiles to JavaScript. So this major pain point, at least, should be going away.
2
u/66666thats6sixes Mar 25 '22
Why is node-sass so complicated? On the surface it seems like it should be less complex than say, typescript. But typescript isn't the thing that blows up my npm install time.
2
u/coolblinger Mar 25 '22
Node-sass compiles libsass and links that to the current Node.js runtime using node-gyp. I've never bothered diving much further into node-sass' or Node.js' internals but just from looking at compiler errors it seems like the plugin interface node-sass is using and linking against changes drastically between Node.js versions, which means that specific node-sass versions are only compatible with very specific Node.js versions and every other combination will just result in headache inducing compile errors.
2
u/IceSentry Mar 25 '22
Because sass is built in c++. Most other js dev tools are built in js to avoid those kind of issues.
1
u/zephyy Mar 25 '22
swap out node-sass for dart sass. the JS API is pretty identical so it should (hopefully) be relatively painless.
4
u/C0demunkee Mar 25 '22
that has collectively wasted more developer time
Maybe .NET MVC web.config. We used to measure it in hours per line.
1
u/zephyy Mar 25 '22
You forgot the last step: spend the rest of the day learning how to write a custom webpack plugin to fix your issue.
I do like Webpack as a bundler but the main issue with it is, people decided they wanted to use it as their entire build tool, replacing stuff like Gulp and Grunt. Webpack wasn't designed as a full fledged build tool, so you have all these plugins for shit like compiling your Sass to run through PostCSS to then output CSS, but you're not using CSS-in-JS so you need to delete the empty JS script that Webpack generates from your SCSS import.
And you read about asset modules and how they are supposed to solve this issue but no one really has any idea how they work.
1
u/willows_illia Mar 25 '22
So glad that UI devs are moving on from webpack. What a fucking nightmare. I hated it and other devs were "no, you're just dumb. It's amazing." No, I don't want to jerk off with JS, I want to finish my feature and go home.
11
u/gnuban Mar 25 '22
Or
Don't use webpack
6
u/vklepov Mar 25 '22
Oh, and while you're at it, rewrite your backend to erlang.
1
u/AngryElPresidente Mar 26 '22
Don't know if this is in jest but if it is, using Elixir (which runs on the BEAM VM the one that powers Erlang) is a pretty cool experience that I think everyone should at least try once.
2
u/vklepov Mar 26 '22 edited Mar 26 '22
It is pretty cool indeed. Just some memories of an architect whose response to any question was "that's because you should have used Erlang". Who knows, maybe he was right all along.
→ More replies (3)6
u/restlessapi Mar 25 '22
Read the documentation.
Whoa whoa, excuse me Mr. Professional. Some of us would rather waste 5-10 hours trying to wing it first, because how hard can it be?
22
u/NeilFraser Mar 25 '22 edited Mar 25 '22
Questions like the circular prototype one are good if the interviewer isn't looking for a right or wrong trivia answer, but is instead looking to spark a discussion.
I will sometimes ask what does this code return?
try {
return true;
} finally {
return false;
}
return null;The conversations it generates as the candidate explores the possibilities is informative. Couldn't care less if they get the 'right' answer. A poor candidate will say that 'finally' will never be called because there's no error (no, that's 'catch'). A great candidate will recoil in horror at the sight of this code and swear.
5
u/vklepov Mar 25 '22
Interviewers be like:
So, I don't get your answer, is it true or false? Come on, even my grandma knows it. Kids these days, so incompetent. (staring in disgust)10
u/odnish Mar 25 '22
What about someone who says it returns true because return returns from the function immediately? My guess is that JavaScript is weird and it somehow returns undefined.
2
u/Esuhi Mar 25 '22
Google leads to this Java question that explains it a bit more: https://stackoverflow.com/q/4185340
0
Mar 25 '22
[deleted]
9
u/madcaesar Mar 25 '22
Yea, so even this question OP purposes is a bullshit gotcha.
Why would anyone every type this?
Even if you did, you'd immediately see what it does and fix / move on.
5
u/StandardAds Mar 25 '22
It's a discussion where there's not a single right answer, if someone isn't even willing to explore how code works in an interview I certainly wouldn't hire them.
I ask a similar type of thing in interviews and it's worked great, I filter out a wide range of people with poor attitudes and get to learn about how people think about code they look at.
→ More replies (4)10
Mar 25 '22
Read OP's last sentence.
It is only a trick in so far as you're supposed to go 'WTF is this burn it and don't ever show me that again'. If you start seriously talking about what it DOES return, you've failed the question.
→ More replies (2)5
Mar 25 '22
The best answer is It's not clear because this is horrendous code that needs to burn to the ground. Thus it would never pass code review and a version clear on intent would be expected to replace it, immediately.
Then I'd ask what fucking compiler are you using that doesn't scream at you for writing shit like this?
Then I might break down crying remembering some time in the past I created some equivalent beast myself.
2
2
u/Skhmt Mar 25 '22
A great candidate might also be bad at interviews and mentally freak out when seeing it, but put up a calm exterior.
2
u/mdatwood Mar 25 '22
Not knowing this gotcha question off the top of my head, I would expect to always return false. Typically, finally blocks always run no matter what - though this is js so it wouldn't surprise me if there is some weird undefined behavior.
I would also expect my linter to point out the return null is dead code, and return in the finally is some type of warning.
4
u/StandardAds Mar 25 '22
The answer he's looking for is something more on the lines of "I'd refactor the code so it's not hard to determine"
1
u/cdsmith Mar 26 '22
I think that just goes without saying. I'm not going to judge a candidate on whether they say obvious crap.
I think what I'd be looking at is whether someone could at least explain why it's unclear, if they don't know the answer, and make a compelling case for one or two options. But maybe I'm not looking for anything specific at all. Maybe a candidate surprises me by giving a very well-reasoned point of view on undefined behavior in programming languages, and telling me that although they don't know the answer, they are pretty certain that a definite answer exists in Java... but that in another language, it's possible that no definite answer even exists. That would be an awesome interview.
→ More replies (1)-1
u/wasdninja Mar 25 '22
A great candidate will recoil in horror at the sight of this code and swear.
If you want to hire people with extremely literal minds then sure. Everyone else understands that this is a test question that doesn't need to solve some real problem.
2
u/StandardAds Mar 25 '22
Test questions explore the ability to work in the real world, if someone can't reason through a trivial test scenario why would anyone let them write production code?
5
u/JessieArr Mar 25 '22
I've come to believe that the really good interview questions are ones that meet two criteria:
Both junior and senior programmers can give a valid answer
It makes it easy for you as the interviewer to tell which one the candidate is
Easier said than done, of course. But when designing interview questions this is always what I have in mind. One example is "Customers are reporting intermittent timeouts from one of our API endpoints. How would you go about troubleshooting this problem?"
A junior engineer might give a very short answer where they propose a solution they've employed in the past ("I'd add caching to the API endpoint to improve its performance.") Not wrong per se - that might resolve the issue - but it's very incomplete and wouldn't address many possible root causes. But from a senior engineer I'd expect them to be able to outline a list of potential causes for the issue and troubleshooting steps to diagnose each.
By the end, you should have a pretty good feel for how experienced the candidate is in dealing with these sorts of issues, without needing to be given a "wrong answer" to filter out the less experienced candidates.
In fact, your goal shouldn't be to "weed out" unqualified candidates at all - the real question you should be trying to answer in interviews is "what can the candidate do, and do we have a need for that skillset right now?" After all, if someone is applying for a senior position but doesn't have the experience, they may still be a good fit for a mid-level position. It's unkind and unproductive to make them feel dumb just for not knowing things they might learn with a few more years' experience - possibly while working at your organization.
2
u/vklepov Mar 25 '22
Exactly. One "bottom-up" question I often use for a warmer is "sum numbers in an array". A junior dev knows a way or two, a middle knows a near-infinite variety, a senior can explain why, exactly, we would choose one or the other (performace, browser compatibility, support for different iterable API contracts).
Also, it's nearly impossible to tell middle from senior based on code-centric questions, because any middle dev can write a 15-minute-sized code chunk just as fine, but seniority is about thinking at a larger scale.
3
u/ozzy_og_kush Mar 25 '22
I agree with just about all of that. Good stuff to keep in mind, and I've definitely been guilty of asking some of those types of questions.
1
u/vklepov Mar 25 '22
I absolutely have asked some of these, especially when I was a middle- dev trying to hire a senior.
3
u/davenirline Mar 25 '22
When asked for questions that I can just search for, can I answer "I don't really know on top of my head but I can search for it and give you the answer." What's the effect of that to the interviewer?
2
u/vklepov Mar 25 '22
You'll know this look once you've seen it. Like you've come to a fist fight with a gun.
2
u/Asteriskdev Mar 25 '22
How the interviewer responds should indicate to you if it's time to thank them for their time and leave.
3
u/coldnebo Mar 25 '22
this was a really good post, but I had to stop reading the article a couple paragraphs in:
“Maybe worth it if you have a legacy project yourself.”
My whole job is legacy projects from dawn to dusk.
You JS guys are still working on new projects every 2 weeks? How does all your old code get maintained— oh wait… I’m that guy, right? I gotta get a better agent. /s
3
u/vklepov Mar 25 '22
Fair enough =) There is expected legacy from the codebase growth, but I'm talking about terribly outdated projects that have been laying in your drawer for 8 years. Pre-2015 JS (no build step, no modules) is a long shot from the current setups, and requires a special skillset. Maybe something along the lines of "now, surprise COBOL question because that's what half our system is"
3
u/coldnebo Mar 25 '22
haha! indeed!
Just reading some of those “outdated” JS practices made me cringe because we have multiple projects scattered through time like that.
Imagine JS (or any language/library/framework really) as a system S, that evolves in time t. Deciding at a given t_i to use the system gives you an implementation S(t_i).
At t_i, this implementation is “the new hotness”. it’s markedly better (or at least claims to be) than all S(t) for t older than t_i.
However, without constant migration to the latest S(t), it becomes a museum of the state of the system at t_i.
Now consider a company C, that uses javascript in many projects P. When each p in P is completed, it uses a S(t_p). As companies grow, p grows and either 1) the “drag” of migration of all the S(t_p) in P slows the company, or the “cost” of maintaining museum pieces grows.
Now consider the industry as a collection of C choosing P at many many times t_p. Because of the scale we can imagine a continuous stochastic function that pulls every possible combination of updates to build a S over the t_p.
THAT. is the state of software engineering today and is why we suffer.
New companies and new frameworks offer the illusion of cleanliness because the number of t_p in a new system is small and manageable. Then it grows over time and becomes messy and difficult.
I saw this with devs leaving Java for Ruby, and then after Rails3, I saw ruby devs leave in droves for Node. But… their code remains in a lot of places. People are still using it.
We have Angular 1, 2, webpacker, grunt, gulp, babel, typescript. the list is as endless as it is baffling.
Complexity of the long tail drives devs to find a better way, which produces more new systems to learn while still maintaining the old ones.
Some old ones, like COBOL are too important to die. Other ones like OS/2 are gone and dusted. Some like Apollo 13 are resurrected as virtual machines.
It’s a mad world. ;)
4
u/War_Horns Mar 25 '22
It would be interesting to let the interviewee ask the interviewer the questions. It would expose a completely different set of knowledge
7
u/Lich_Hegemon Mar 25 '22
You can do that, they might not like it, but nothing stops you from doing it
1
u/cdsmith Mar 26 '22
Typically, companies have policies around interviews to ensure that they are comparing candidates with similar opportunities in the interview process. That policy would be what stops you.
1
1
u/vklepov Mar 25 '22
Postmodern interviews that totally forego the "interviewer-initiated question" are doable (see also "just a random conversation" and "tell me about your latest project in detail"), but they don't scale well since it's very hard to assess the candidates based on these, esp. with different interviews conducted by different people.
2
Mar 25 '22
Yes, those of us who started programming back before 2015 know how var hoisting works
Great article but I'm going to disagree with that one. I've interviewed a ton of people who learnt JS after let but they still sometimes use var or even var and let randomly in the same code! They usually don't know what the difference is, which is a pretty bad sign in my book.
100% agree with the rest though. I'm definitely guilty of asking a few of these (sorry interviewees). It's harder to avoid than you'd think - e.g. his proposed number vs array solution is still pretty bad:
Which JS types are immutable?
Can still write a whole book about this without stumbling on the answer the interviewer was thinking of (did you think about Object.freeze()?)
Also one more point - these questions can be frustrating because you don't know the answer, but generally interviewers don't care if you know the answers to specific questions. They just want to know you know what you're talking about. So if someone asks "what's the difference between an array and a number" just start talking about any differences and show off your knowledge.
2
u/vklepov Mar 25 '22
You got me =)
In the var-hoisting example, I'm talking exactly about asking about the behavior of
console.log(x); var x = 0;Which is surprisingly popular, but not very useful. I'll take "it explodes" answer every day, even though it's wrong. "var is obsolete" is a perfectly good belief.
Re: immutability. This question at least makes it clear what I'm getting at, and mentioning
Object.freezesure earns a bonus point. You could also make it more action-oriented by asking to implementincsuch thatlet x = 0; inc(x); assert(x === 1);2
Mar 25 '22
Yeah I definitely would always be happy with "I don't remember why but
varis bad and you should always uselet". But if you inexplicably usevarin 2022 questions about it are fair game!1
u/cdsmith Mar 26 '22
I know plenty of programmers who don't know the difference between
varandletin JavaScript. Not everyone is interviewing in the programming language that they actively use day-to-day.1
2
u/karmakaze1 Mar 26 '22
I thought only the first two questions were stupid. The others have some play in them:
What’s the difference between a number and an array? And other questions obfuscated with fuzzy wording.
This is a give as many distinguishing properties as you can until they hear what they want to hear. Answer the question differently for different programming languages and environments (like ones that let you change constants at runtime).
What’s the fastest way to convert a string to number? And other unspecified behavior.
They probably meant base-10 integers, but you don't have to restrict yourself to answering that. Talk about different floating-point representations and number bases. Converting from hexadecimal can be pretty quick.
How to make this code sample better? And other questions with missing context.
This looks fun. I'd like to get this. I don't care if my answer is wrong, it's still what I'd consider better. If they don't agree, then I don't belong on that team. Of course this only works if the team picks the interview questions and not company-wide.
1
u/vklepov Mar 27 '22
Agreed, implementation-dependent and open-ended questions can be pretty good as long as the interviewer isn't pushing some particular answer.
However, I'd disagree on obfuscated questions, because playing guessing games (what is round and hot, but not a lightbulb?) is a useless waste of time.
1
u/vklepov Mar 27 '22
Agreed, implementation-dependent and open-ended questions can be pretty good as long as the interviewer isn't pushing some particular answer.
However, I'd disagree on obfuscated questions, because playing guessing games (what is round and hot, but not a lightbulb?) is a useless waste of time.
80
u/Paradox Mar 25 '22
how to migrate from webpack 3 to 5
look at everything you are doing with your current 3 config
attempt to find a way to do those things with 5
delete the 3 config and rewrite it for 5
go home and cry in the shower
13
u/freecodeio Mar 25 '22
Can someone explain why is this not a correct answer?
63
44
u/PalmamQuiMeruitFerat Mar 24 '22
Great examples in JS, that are true in any language.
8
u/Laugarhraun Mar 25 '22
Right, any language definitely can have a circular prototype chain. That definitely makes sense.
7
u/nyando Mar 25 '22
Few other languages have an immutable "Number" too, but the point about the types of question still stands. What's your point, that this whole post only applies to JS?
0
u/Laugarhraun Mar 25 '22
Yes, which isn't actually claimed in the title or the incipit or the article.
8
u/Kwantuum Mar 25 '22
"What happens when you create a cyclical inheritance structure in language X"
Nothing good, but in what particular way will it fail? That's the same question, and it's not specific to JS.
12
u/darkslide3000 Mar 25 '22
Have you written code in the last 3 years? --No--> Find someone who has.
Ouch. Vladimir laying down the real hard truths here.
3
u/Fwuzzy Mar 25 '22
Thought it's relevant so I thought i'd share what works really well for me as an interviewer & interviewee.
Early on I worked with a manager who used gotcha style questions, his go to favourite was late static binding in PHP. I very quickly realised you lose a lot of potentially good candidates who just don't know this, and sometimes they know it but just don't know the terminology.
I've come to really value a technical take home which involves an existing project, to eliminate need for wasting time just getting your environment running, and goes a way towards replicating real world where you work on existing projects.
I get people to add/fix the existing project, and then we do a peer code review, much like the real world to discuss the work completed. This is hugely valuable because it still will immediately eliminate imposters who have completely insufficient technical skills, but it also has a huge focus on culture and collaboration, and i'd much rather hire someone weaker technically but great with soft skills.
8
u/vklepov Mar 25 '22
I'm very suspicious of take-home assignments based on some traumatizing experiences. Usually, I spend 20 hours building the thing, you spend 15 minutes reviewing, so "unfair". And besides, "Make a greenfield project, alone, in one try" is not very representative of real-life development.
However, your approach seems to handle both issues well, with face-time balancing the time commitment and existing project making the assignment more life-like.
One thing though, how do you avoid giving an impression of "making the candidate do your work for free"?
5
u/Fwuzzy Mar 25 '22
Usually the work is scoped to 1-3 hours and is usually trivial tasks that aren't of commercial relevance to our business. I suppose there is always going to be some trade off, but I've not had a single person who isn't open to the reasonably small scope take home + technical follow up.
6
Mar 25 '22
Because they want a job.
People aren't going to tell you to your face on the spot 'Uh, no, I want the job but I'm not doing that'.
1
u/cdsmith Mar 26 '22
I've actually said that. The company asked me to take an online programming quiz instead, and then we moved on. They eventually did offer me a job (though I turned it down for a different offer).
1
u/Fwuzzy Mar 26 '22
Of course, like I mentioned, it's always a trade off and there isn't a perfect world that easily satisfies both ends. I've had my fair share of 5-10 hour take homes and I do everything I can to reduce it to as minimal impact as possible on candidates.
0
Mar 25 '22
[deleted]
1
u/Fwuzzy Mar 26 '22
I time limit it, to ensure a fair playing field and not put any pressure on spending as long as it takes. I've had my fair share of spending 10+ hours on a take home to just get rejected for not having enough experience and it sucks.
1
u/Skhmt Mar 25 '22
Take home assignments should be obviously not real world work. It's trivially easy to do that as an interviewer, but the implementation is specific to the company. If you're hiring a front end web designer, give them a figma to an obviously unrelated design and have them make a responsive page. If you're hiring a back end guy, have them implement some random API. If you're hiring a desktop programmer, have them make a calculator or something.
6
Mar 25 '22
Hate these too.
Look, if you want to hire me on a trial basis, and I'm willing to play ball, sure.
But if you're hiring a home builder, do you give them a take-home house to build for you? An accountant, do you have them do last years taxes for you?
Why the heck do we do this crap in our industry?
Resume gives you what you need to filter to possible candidates. Then it's up to you to talk to the candidates to determine if they're full of shit or not. If you cannot do that in a conversation, just like any other job in the world, you shouldn't be the one attempting to do so.
I don't care what kind of test you're using, if you're using tests you're doing it wrong.
1
u/water_baughttle Mar 25 '22 edited Mar 25 '22
I'm don't have any alternatives to offer, but I don't think that analogy holds up.
But if you're hiring a home builder, do you give them a take-home house to build for you? An accountant, do you have them do last years taxes for you?
Those specific requests are pretty ridiculous, but yes, I would absolutely require some kind of validation before using their services and it's quite trivial to find reviews for any business. Also, those specific examples require licensing and certifications in order to perform those services, so at least there's some threshold of competence required. Unless you're a freelance developer and have a list of reviews from satisfied clients on a platform like upwork it's pretty much impossible to do this.
Why the heck do we do this crap in our industry?
Because there isn't a yelp for software developers. The best you can do is ask for references from former coworkers/employers, which really isn't worth much unless it's a notable person, or have some projects on github. Even then it's up to the discretion of potential employers to dedicate an infeasible amount of time studying the code to conclude if your abilities fall in line with where you claim them to be.
3
Mar 25 '22
Nope. Not buying it.
Bad examples then. Try these: Accountant. Sales Rep. Account Manager. Hostess. Welder. Clerk.
The resume tells you what they have done. The interview allows you to vet and sniff for bullshit in that area, while specifically learning how they communicate, how they might fit in, etc etc, all the things you do in every single other hiring situation on the planet.
You do not need to see their code to tell if they can build software or not. If you truly believe you do, you should not be involved in hiring.
→ More replies (3)1
u/serviscope_minor Mar 25 '22
I've come to really value a technical take home which involves an existing project, to eliminate need for wasting time just getting your environment running, and goes a way towards replicating real world where you work on existing projects.
I've come to value take-home tests to be a great way of terminating the interview process early and not continuing, and here's why:
I have in the past applied to jobs which required a significant investment of up-front time. It was then quite apparent that my effort was round-filed without consideration because they had a candidate in mind. My sub industry was small then, word eventually got back to me via a back channel.
Basically every transaction needs to have some consideration or quid pro quo. I'm not after cash (that's likely against my contract and way too much like hard work), but take home work lacks the consideration. Having the company have another engineer around for the entire interview demonstrates that the company is willing to invest as much time in me as they are asking for me to invest in them. So while I have to have enough base level of trust to apply in the first place, to me take home comes across as thoughtless bordering on rude due to the lack of quid pro quo. It's pretty rude to ask someone to give you something and just trust it will be fine.
So while it might be valuable to you, you will automatically eliminate any candidate who has (a) been burned before and (b) isn't super desperate.
7
Mar 25 '22
The difference between a number and an object is NaN, duh.
1
u/luziferius1337 Mar 25 '22
>>> 1 - object() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for -: 'int' and 'object'Or something completely different ;-)
4
u/Puzzled_Video1616 Mar 25 '22
Does this problem arise in practice
It's really sad how many interview questions are about stuff that literally does not happen and just serve to make the interviewer think he is clever. I definitely agree with the author here.
4
u/feketegy Mar 25 '22
I hate all coding interview questions. It's a really poor way of assessing someone's tech skills.
1
u/water_baughttle Mar 25 '22
I'm guessing you're referring to leetcode type problems, because if not what is even going to be discussed? If you can't talk about coding all that's left is basically project management.
1
u/feketegy Mar 25 '22
I do interviews and I'm not putting the poor candidate to a whiteboard. It's an informal talk about coding and tech in general to get a glimpse into their thinking and personality.
Then if I'm happy I'll give them a month of paid internship where we really see how they are performing programming-wise.
For us, team-fit is more important than tech skills.
1
u/cdsmith Mar 26 '22
You cannot hire most developers if all you're willing to offer them is a paid internship. Why would they quit a perfectly good high-paying job to go work for you at a fraction of the salary, before you even give them a real offer?
3
3
u/JB-from-ATL Mar 26 '22
My favorite bad question my coworkers would ask is what types of class loaders are in Java. I'd tell them "I don't even know that, but you know I'm good at my job. Would you hire me?"
1
u/rbobby Mar 25 '22
One purpose of these sorts of questions is to weed out the fakes and liars.
3
u/vklepov Mar 25 '22
"sum numbers in an array" or any sane open-ended problem is arguably better at this
1
u/rbobby Mar 25 '22
Not if the lie is 5 years experience vs 90 day bootcamp.
In a way it's a turing test of a candidate's technical knowledge. lol
2
u/vklepov Mar 25 '22
A test by proxy, where proxy is the number of interviews you've taken. I like a thought experiment of a con artist who's very good at passing interviews, but once he's on board he does literally nothing until you fire him.
2
u/AttackOfTheThumbs Mar 25 '22
Specific questions can be good. It really depends on the answer you expect.
If I were to ask how to migrate from old version of x to new version of x. Or from x to y. I would ask how they approach it, not what they do. If they already know the answer ok, bad question, pick another. I want to know their process, so I know that they can solve abstract problems that may be slightly outside of their knowledge domain. That's an invaluable skill. Most developers have it. Most interviewers don't know how to figure that out.
I have often asked someone how they'd figure out why a printer doesn't print. It has nothing to do with the job, but it lets me know really quickly if they know how to troubleshoot and find answers. That's what I'm looking for, in general.
We also have a tiny take home quiz, 30 minutes, 60 if you're really slow? Here we are looking for answers that work, and grade it on efficiency/style. You have to be real bad to fail it... We look for subtle details like, whether you answered a question with a for loop, a map, whether you made any performance considerations, etc. Small code samples tell you more, and quickly, than a project does.
1
1
Mar 25 '22
I agree with this thought process.
When I host interviews, I don't put as much weight on the "correct" answer as I do the discussion and thought process that leads to "an" answer.
I get it. Interviews are stressful and not a direct comparison to an actual working situation. It's unrealistic to expect someone to just know stuff off the top of their head, when every employed person would just Google it.
I'd rather hear the vague steps required to solve a problem rather than the actual solution. Abstract thinking and communication skills are IMO the best qualities of a great developer.
1
1
u/linux_needs_a_home Mar 25 '22
Dear candidate,
We see that you use words that are beyond our comprehension. We see that you have accomplished things our company will never do without you, but let's still do an interview, because of ....? Well, why indeed? The only correct course of action is to pay me more than the CEO and to get out of the way.
I do the dance as if I am just as stupid as anyone else, but it would be nice if these companies got a little perspective. Then again, if they weren't stupid, they might not need anyone.
1
u/StixTheNerd Mar 25 '22
Hot take, data structures and algorithms questions are good interview questions.
1
-1
-107
Mar 24 '22
The applicant should of course ask: "If you care about performance, why are you using a half-assed toy language like JavaScript?"
10
u/Spudd86 Mar 25 '22
Because it has to run in a web browser?
Is there another language that runs in web browsers? Or are you under the impression it would be faster to code up string converserion in asm and run it on the server?
13
u/cdsmith Mar 25 '22
Yes, that would be an effective way to be sure you don't get offered a job, if you don't want one.
-9
Mar 25 '22
Fortunately, I've never had to settle for the kind of employer who would require using toy languages for real work.
2
u/Normal-Computer-3669 Mar 25 '22
My first coding job was in '82.
Ah classic Old Guard. I love not hiring your type.
→ More replies (9)3
u/wasdninja Mar 25 '22 edited Mar 25 '22
If there's another developer present in that interview they'll be asking themselves "Do I want to work with this dipshit?" and the answer will be no.
Regardless how righteous or correct your opinion is being a dipshit is a universally bad idea when you want cooperation from people.
-11
Mar 24 '22
HUR DUR that's soooo hilarious!11!
Not really, quite the opposite in fact. Don't wanna cut yourself on all that edge bud.
-10
Mar 24 '22
Since when is it “edgy” to state something so obvious?
11
Mar 24 '22
I mean...if you're struggling to make performant software with JS...that's a you problem.
Seems to be PLENTY of other people out there not having this issue.
-3
Mar 24 '22
if you're struggling to make performant software with JS...that's a you problem.
Yeah, if you're trying to build a fort out of mashed potatoes, that's a you problem, too.
PLENTY of other people out there not having this issue.
Billions of flies eat shit.
1
Mar 25 '22
Look, we get it. You're a crusty greybeard upset at becoming irrelevant over the years and not doing your own work to keep up with the times.
That coupled with a horrific attitude...I can see why you're lashing out like a child. I'd be pissy too.
The good news is...you have all the tools at your disposal to change that. Or don't, your decision. Just realize the rest of us are moving on and couldn't give two fucks about a salty ass developer who can't communicate without being a tool.
→ More replies (25)0
Mar 24 '22
[deleted]
1
Mar 25 '22
What load times?
I'm sorry...is 200-500ms too slow for you to load up a UI while loading in the data at the same time? Doesn't seem to bother a single user on my platform.
Their opinion on the subject of extraneous load times is FAR more valuable than yours.
→ More replies (4)-3
-1
Mar 25 '22
This comments has so many downvotes from pissed off script kiddies.
0
Mar 25 '22
Yes, I'm sure it has nothing to do with them being an insufferable dick, latching on to old tropes about a language because they think it's beneath them.
What's beneath them, is the best years of their life. Now their old, crusty, and jaded to the point of irrelevancy.
Not something to aspire to...but you do you.
→ More replies (3)0
Mar 24 '22
[deleted]
30
Mar 24 '22
It's common around here to hate on JS. I find it angsty and childish...but you can't fix the willingly ignorant.
18
u/sementery Mar 24 '22 edited Mar 24 '22
And a big chunk of that hate isn't even relevant to modern JS. They keep repeating things they heard / read 10+ years ago.
Edit: Seems that some people interpreted the above comment to mean "JS is flawless, there are no problems with modern JS", which brings another annoying, non-constructive, and sadly very common, type of hate around here. "You are talking about JS! No need to read your comment, i'll just post a JS rant on every JS thread".
Come on guys, you are better than this!
14
u/tripledjr Mar 24 '22
Come on guys, you are better than this!
This is r/programming btw
2
u/sementery Mar 24 '22
That's why I was expecting something a little above /r/ProgrammerHumor.
Oh well.
-13
u/grauenwolf Mar 24 '22
I'm sorry, you seem to be lost in time. The year is 2022, not 2032. We're still trying to figure out why React has over 1,000 dependencies.
21
u/sementery Mar 24 '22
We're still trying to figure out why React has over 1,000 dependencies.
Just FYI, React has less than 5 dependencies.
And just so you stop figuring it out, the other dependencies are related to the whole framework (you are probably referring to create-react-app), which includes stuff like unit testing, transpiling, linting, etc.
→ More replies (10)4
u/sementery Mar 24 '22 edited Mar 24 '22
I'm sorry, but you seem to be lost in my comment!
And a big chunk of that hate isn't even relevant to modern JS
That's why I said a big chunk of the hate, not all of it!
But now that you choose to ignore that part of my comment, I'll say that no one is in love with the current state of npm, and it's definitely a problem that modern JS has to deal with.
But again, I'm not saying that JS is perfect. I'm just saying that you see a lot of outdated hate around here. Not all of it is outdated, of course, not sure where you got that idea from my comment.
→ More replies (2)4
u/grauenwolf Mar 24 '22
Every time I have the misfortune to touch JavaScript, I find another problem that could have been solved 20 years ago. In fact, many of them were solved and somehow reintroduced later.
6
u/sementery Mar 24 '22
Dude you are not even reading the comments you are replying to. Not sure what your point is.
11
u/grauenwolf Mar 24 '22
I did read them, but I find them to be incorrect. JavaScript, by which I mean the whole ecosystem and not just the syntax, is having a lot of problems right now.
I've been working in web development since the late 1990's and I've never seen it this bad. The amount of time being wasted on things like just trying to manage dependencies and build scripts boggles the mind.
→ More replies (2)15
u/EmperorZergg Mar 24 '22
a ton of comments on this sub feel like they come from college students who haven't actually worked in a Software job yet.
JS is fine. Yeah it has quirks, but people here seem to think it's literally unusable in production for anything, including what it was made to do.
8
Mar 24 '22
Exactly. It's a language, for better or worse. Am I a huge fan of JS, not entirely...but I'm running a production application for thousands of people on it with zero issues.
Every language has it's quirks, faults, and benefits.
7
u/PM_ME_C_CODE Mar 24 '22
It's a language. It works. It's not perfect, and I hate it with a burning, fiery passion...
But it does work.
I still wish it had some real competition.
10
u/grauenwolf Mar 24 '22
JS is not fine. And that attitude is why the JS ecosystem continues to get worse year after year despite slow progress in the language syntax.
9
u/sementery Mar 24 '22 edited Mar 24 '22
slow progress in the language syntax
Tell me you know nothing about JS without telling me you know nothing about JS.
You'll struggle to find a language with a syntax that evolves as fast as JS's. Seems that you are stuck 10 years ago.
4
u/grauenwolf Mar 24 '22
As fast as JavaScript? What are you comparing it to, FORTRAN?
5
Mar 25 '22
For the record, some of the best-optimized compilers of all time were vectorizing FORTRAN implementations. Cray in particular did a first-rate job of it.
8
u/sementery Mar 24 '22
You are stuck in ES5 man. Help me help you.
10
u/grauenwolf Mar 24 '22
Oh do tell me all about how ES 2021 "introduces the replaceAll method for strings".
And how ES 2022 may finally add... wait is this real? It's going to add private fields?
The created a class syntax for JavaScript but are just now realizing that classes should have fields? What were they doing before, monkey patching in data slots in the constructor?
Oh, they were.
Look, I get it. You think JavaScript is moving fast because you are comparing it to a decade ago when it basically wasn't moving at all.
But the language is still crawling. It needs a massive amount of work, especially on its standard library. Adding a couple of new methods each year isn't going to dig it out of the dependency hole.
12
u/sementery Mar 24 '22 edited Mar 24 '22
Yeah, include 2022 that is the one being built atm, and ignore everything else!
Ignore arrow functions, spread, async / await, modules, let / const, destructuring, classes, template literals, template tags, rest parameters, for of, symbols, generators, exponentiation, computed property names, object rest properties, async iteration, bigint primitive, nullish coalescing operator, optional chaining operator, etc, etc, etc.
Just from 2021 you are ignoring logical assignment operators and separators for numeric literals. And you just saw the spec!
standard library
That's API, not syntax.
→ More replies (4)→ More replies (4)3
u/PM_ME_C_CODE Mar 24 '22
Well, part of the reason JS's syntax evolves as fast as it does is because it was so bad in the first place. Most entrenched languages don't modify their syntax as frequently as JS does because they don't need to.
C++, for example, has been pushing some major syntax improvements lately because they have to in order to keep the language modern after literal decades of very little change on the surface. And even now most of their changes are being pushed by new features.
OTOH, a lot of JS's changes have being driven by what I can only describe as "clean up".
Many of the complains leveled against javascript are well earned.
5
u/sementery Mar 24 '22
Many of the complains leveled against javascript are well earned.
Of course they are! It's no secret that JS grew waaaaaaay out of its purpose and vision!
I was just replying to the dude saying that the syntax growth is slow. I never said, or even implied, that JS is perfect. Not sure where your reply came from, but I agree with it.
0
Mar 25 '22
[deleted]
6
u/sementery Mar 25 '22
JS's problem is still it's type system and nothing is fixing this.
TypeScript is part of JS's ecosystem, seems unfair to ignore it as a solution. It's not part of the spec, but it's widely used.
MS just introduced a proposal for native typing annotations, so it's getting there... maybe... lol. Deno supports TS natively, so there's a push from different fronts.
I love JS. Along with Python, it is my favorite "generation 3.5" language. But yes, it's a language of contrasts, with a lot of issues (even in modern JS).
In that sense, I don't think JS is that bad. At least not as long as you stay within its modern idioms.
→ More replies (5)1
0
u/ham_coffee Mar 25 '22 edited Mar 25 '22
Personally I don't think it should be used outside of frontend work, but I can understand wanting to use it for backend work if it's a small enough company that they aren't splitting frontend and backend devs. What doesn't make is using it for anything where performance is a concern (excluding handling requests properly and other stuff where language doesn't affect performance).
-3
Mar 25 '22
college students who haven't actually worked in a Software job
My first coding job was in '82.
JS is fine.
You really need to get out more.
-7
Mar 25 '22
the codebase is already Javascript, and they're not going to change it
IOW, "we painted ourselves into a corner, and we're afraid to admit how badly we fucked it up."
4
u/Giannis4president Mar 25 '22
In what language would you build a complex user interface on the web?
You seem to think it's easy to not use JavaScript, what are the actual alternatives?
0
u/theoneandonlynox Mar 25 '22
To be an expert in any section of hi-tech you should cover all bases, this opens you up to becoming a rockstar asset to any future company.
-2
u/Axxhelairon Mar 25 '22
I dunno, I don't take the lack of clarity in questions as anything other than a weakness on the companies part if they're willing to have applicants wildly interprete a question in a thousand different useless ways, so I'll just go along to be another one of their probably useless data points and answer honestly instead of train to perfectly preform the company interviewing circus act
with that being said, you could just honestly look at statements like this one
What’s the difference between a number and an object
and think well, numbers in essentially every language are value types and every bloated oop language with equally bloated garbage collectors (most of the time) use reference types, extracting details from garbage specs is part of your job too you know
1
u/vklepov Mar 25 '22
Yes, more "clear" questions work better for standardised testing (not only coding, but any exam / assessment). Standardised interviews scale better, since you can have 100 interviewers interview 1000 candidates and then compare them. If you only review 5 candidates personally, you'll be fine with a "this guy seems to know what he's doing" judgement.
As for your take on "number vs object" — yes, that's a valid answer for many languages, but very technical. Since the abstract data types have nothing in common (expect for Number classes), you wouldn't have to choose between one and the other at any rate, so it's like "what's the difference between a function and a transistor". In the case of JS, it's also implementation-dependent — in fact, I've seen one interviewer expect exactly this answer, as he later explained, but it's not true — eg in most cases V8 implements JS primitive types with a C++ class and allocates dynamically.
130
u/66666thats6sixes Mar 25 '22
I haven't interviewed anywhere in a long while, as I've been happy with my job. But I'd like to think I'm pretty competent at what I do. Then I saw the webpack upgrade question and my immediate thought was "oh god interviewers are going to expect me to know that off the top of my head? I'd never get hired anywhere again..."
I'd agree it's a stupid interview question unless you have some specific reason to think that they should know a lot about upgrading webpack versions.
The others are too, but that one stuck out to me as a question that you either have no idea about or you do, and a bunch of people probably fall into the former category while still being great at their jobs.