This person sounded really experienced, so I looked them up on LinkedIn. 7 months at their first company. 9 months at their current company. That's it, aside from non-programming jobs before their bootcamp.
The whole thing reads like inventing scenarios that didn't happen or embellishing them.
> A bad interview is when you ask them the definition of some specific thing in some specific framework like “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
Not that believable, but okay.
> I once had an interviewer ask me if I was a wizard with GO, C++, Rust, and C over the phone. Then when I said I had some experience with rust, he immediately cursed at me and hung up.
Didn't happen.
> Nobody in their right mind is going to move to San Francisco, California to be a “Lead developer” for only 70k with zero equity.
Are any companies actually trying to recruit like this? And is it successful beyond just throwing up a hiring post and not getting anything? I put in a limit buy of $3000 for 1 BRK/A on a whim once.
Somewhat relevantly, a closure isn't a "specific thing in a specific framework." Its a concept that exists in many languages, and has no real relation to frameworks.
I would never treat someone like they're stupid in an interview, but being completely unfamiliar with common programming concepts and treating them as irrelevant or trivial things is definitely a red flag.
I know approximately what a closure is, and I am sure I have used such constructs instinctively in my work many times. I don't have a formal Cs education, but have never failed to not be able to finish my coding work because I didn't know stuff.
Once a guy asked me to write out merge sort on a whiteboard and I couldn't. I didn't get the job. Surprisingly I'm doing just fine in my current position and am very productive (as much as I may say so myself) and have never heard complaints from anyone that I don't know what I'm doing.
So if you don't see a CS degree in the resume then don't ask what a closure is or to implement a merge sort in the interview. Ask them to solve a real problem. The top computer scientists didn't discover the merge sort for years or decades and you want me to figure it out on the spot? Or you just expect me to memorize useless shit like this? Give a problem a programmer would encounter on a day to day basis that wouldn't need a lot of googling. Let them figure out how to solve it and see if it works for you.
You probably won't need merge sort in your day to day programming, but closures (sometimes called lambdas), definitely. Every time you create a function that captures some variables outside its scope, congratulations, you've just used a closure.
Yeah, without knowing the term closure or lambda(which are not necessarily closures but could be as an implementation detail) I'm not sure how one would effectively communicate with others about code in a high-functioning environment using high-level languages. They are very widely used.
i now know of closures, and have actually used them intentionally, and rarely, and def not enthusiastically.
i lived mostly in the java world, and discovered closures when i was getting wacky results while playing around with a Clojure looping example.
then ran into similar situations about once a year when doing something in javascript -- usually passing some function for a callback, and needing access to 'this' in the original/calling scope - which only confused things when i needed access to 'this' in the (local?) function scope, too.
guess i'm not against closures -- they just seem mysterious to me.
ditto lambdas. they seem like a good way to write esoteric code, and write more error-prone/less-defensive code -- that, for instance, might be more likely to produce NPEs, and generally be less maintainable b/c of the focus on brevity instead of clarity, and be geared more towards expert users/coders instead of the generalists (like me) who are often brought in to maintain older code.
That's true. The problem in this case is that they are weeding out applicants based on their knowledge of terminology. Talking about a concrete code sample may not fall into that trap.
> "I don't have a formal Cs education, but have never failed to not be able to finish my coding work because I didn't know stuff."
...that statement looks kinda sus. In a code review I'd maybe get you to simplify it or break it up to confirm the negatives end up meaning what you wanted them to mean.
If you claim to be very experienced in JavaScript but then say that you are ignorant of closures, then that's definitely a red flag. That language relies heavily on closures, more than others, and almost every programming pattern in the browser involves capturing some sort of state about enclosing scopes etc. given the asynchronous nature of things.
The inordinate amount of space the article devotes to complaining about 'credentialism' just reinforces the impression that the writer hasn't taken the time to know his tools/languages/frameworks at a deeper level, and is dismayed to have been found out in interviews.
The person may know what is and how to use it without knowing its formal definition in programming language theory. I personally find interview questions that ask you to regurgitate definitions like an exam to be poor indicators of real world skills. It would better if the interviewer first established terminology to avoid confusion and then ask how they would use such language constructs
I don't think it's unreasonable to expect someone applying for an engineering role to know the technical terminology of their field. Especially if they've been "programming for many years" as this person has.
Adding to this, I think even a little bit of genuine esoterica is okay in an interview process so long as:
1) You're looking for someone with deep knowledge of that subject
2) You don't treat it as an automatic fail when they get it wrong
If I'm interviewing for a senior role, and I ask them a few super obscure questions about the language/framework/platform I need them to be an expert on, that serves as a litmus test for their overall depth of knowledge. Those facts individually may not be required for the job, but they give a read on how deep the person's knowledge goes in general.
But, as you pointed out, I wouldn't really even put closures in that category. For JS it would be something more like, "What does '{} + 12' evaluate to?"
Again, it's just a signifier. If you know the answer (or can explain a good guess!), you probably also know a bunch of actually-useful dark corners of the language. If you don't know the answer, you may still know all those other things. It's just one data point among many.
You're right! Though the original question - '{} + 12' - is extra tricky and actually evaluates to 12 ;) I'll leave figuring out why as an exercise for the reader
at this point, i'd love to know when the answer is just '12'.
i remember going at it with some dude back in the day who was 100% certain, and got visibly upset, when i stood my ground that java only used pass by value. i allowed that even object references were being passed, but that they were passed by value.
>at this point, i'd love to know when the answer is just '12'.
Ctrl+Shift+k in a browser (firefox) opens a console. Just write {}+12 there and hit enter.
My guess is that {} is (in some circumstances) evaluated as a block of code (instead of an empty object). Since the block is empty it evaluates to undefined. The +12 is considered another block of code ( the + operation takes here only one parameter - so it is not a sum ). Consecutive blocks of code are evaluated to the value of the last block of code, which is +12.
{}/12 for example doesn't work at all - which is a hint that the + is not a summation operation.
Edit: I'm wondering why we use 12 and not 42
Edit2: Technically you are correct about java being pass by value. But at this point I'm questioning the sanity of the distinction. It feels more and more like a philosophical discussion.
> > ask (...) “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
> Not that believable, but okay.
To me, it sounds very believable. I have been asked about defining what closures are multiple times.
I switched a couple of times between backend, frontend and mobile, and I had to learn bunch of interview questions that never came up in real life.
In different communities, there are different concepts that they love to ask, even if in the end at your day job, you rarely use them.
The JavaScript interviews are always about quirks very specific to JavaScript that the interviewer learned last week. They then act like without that knowledge you can't possibly contribute to their Angular dashboard.
JavaScript people always go through some examples of the "you don't know js" book, and they ask about the quirks of the language. My opinion is that the code they ask about would be rejected at most companies PR review process, because they are tricky, unclear, surprising. The "You Don't Know JS" book is a great book, and you shouldn't use 95% of the code in there if you want to scale your team without very-hard-to-find bugs.
Java and Android people love their design patterns and clean architecture questions, and they would be floored if you told them that you don't need 13 layers of classes just to call your backend and build a plain old Java object from a JSON.
People also love asking questions they themselves could barely answer. Yesterday, the team lead of my team had to accidentally clarify the event loop in a technical meeting, he was squirming, his clarification was terrible, yet we expect juniors to nail the question, and if they don't explain it exactly like we would, we act like the candidate is a "script kiddie".
If you're looking to get hired as a front-end dev at any level above entry-level, you definitely need to know what a closure is - not just for its utility, but because it can cause nasty bugs when you implement it unknowingly.
If I were hiring a mid-level or senior-level front-end engineer and they do not know what a closure is, that'd be a red flag for unfamiliarity with a core language feature. It's on par with not knowing what a decorator is in Python, or reflection in Java.
Yeah, I think this post is much too generalized compared to what the author has really experienced. It is pretty clear reading between the lines that they're finding getting an entry level job frustrating.
> Are any companies actually trying to recruit like this? And is it successful beyond just throwing up a hiring post and not getting anything?
During an active season (spring, fall, usually) I get one of these a day, or every other day at least. Other times it slows to a trickle--1 a week or so. Usually it's some "I have an urgent requirement for a 6 months contract position for $45/hr. with (litany of skills/responsibilities that screams shitty Dilbert-esque cesspool). This is for in person only at (place on the east coast which would require me to uproot my family and move across country)" style content. Some of the more amusing ones are for contract positions in the Bay Area--those usually have people who, bless their hearts, think they're making an effort with $75-$80/hr rates.
Is this one of those "We couldn't hire locally so we have to get someone in on visa" type situations? I know that happens here (Australia), at least pre-covid
I've seen some "top performing" code, that I had to just trash... because making any changes to the hack job of top performing "just ship it" people is a nightmare.
I'll give the benefit of the doubt to someone with 25 years experience that they know the difference between a true 10Xer and one who 10Xes by leaving 20X of tech debt in their wake.
Bootcamp grads haven't been in the workforce long enough, so whether they can weather the fickle winds of the technology landscape is an open question. That's where the CS degree shows its worth: technologies change but fundamentals change less. Comparison-based sorting is still O(nlogn). You still have to partition and break down large data sets in order to work on them. Time and space tradeoffs will always exist and will need more than a bootcamp education to be able to evaluate properly.
meh - I had basically 2 data structure courses, which is not a "year of classes" since the class met for 1 hour, twice a week for about 20 weeks, and times 2 for that second semester. So I have 20 * 2 * 2 or 80 hours of O notation and heap sorting.
The rest of my CS degree consisted of a lot of stuff I used in class (assembly programming) and maybe I got something out of that. I also took a functional languages course which was taught with Scheme (a lisp dialect) which is a little iffy on practical skills. A formal database class (which was an elective)
So I know boyce codd normal form and o-notation, is that really much of an edge over the bootcampers after a few years?
And to be honest because everyone brings up O notation every time we have this talk I'm pretty sure most bootcampers learn that by looking it up and probably binary trees. Yeah. so I'm really not very convinced from a practical level how much more they're pulling.
It seems to me I was in the wrong classes altogether - the real money at this point is in ML and there's not much a CS degree helps with in that area really - so yea, the fundamentals did kinda change, right?
No. Look around you in any tech organisation and see how much value is generated by the people who code vs. data scientists, and how many software people there are vs data scientists. ML is very popular and the startup ecosystem has latched on to it for funding but the fundamentals of CS have not changed. Sure, there's real money in ML but there's plenty of lucrative opportunities in software development.
Your post somewhat proves my point: you are here (and presumably thriving) in software dev despite taking many courses that you deem only tangentially related, years ago. Whether the same can be said of bootcampers remains an open question, because they haven't been in the industry long enough. Anecdotal evidence from software dev managers I know who have tried hiring bootcampers has been overwhelmingly negative (but they are often comparing BS/MS/PhDs who have spent 4-10 years immersed in various aspects of CS to bootcampers, which isn't fair).
I own an agency. Yes there are shitty agencies, but there are also _plenty_ of shitty companies hiring directly. We have shared our developers' bafflement at how poorly they get treated by Internal Recruiters at the hiring company several times (and generally never worked with the hiring company again).
I had a few like this particularly when I was first entering the field professionally, but not so much anymore. I had one that wanted me to move out to some random town outside myrtle beach for around $17/h iirc.
If he had only that much experience and he applied for some senior position that required years of knowledge, I'm not sure I would curse at him, but I would definitely be really angry at him and whoever let his resume turn into an interview.
we hired a confident 2 year out bootcamp grad that was able to pass our interview process and he nearly destroyed our company, twice. There is a reason the interview is difficult to pass, being a dev is a job with an insane amount of responsibility, you do not want bad people in there.
It sounds more like your company has failed to implement robust processes to catch mistakes before they're big problems to me. No individual should have the power to destroy the company except maybe a CTO or a lead sysadmin. For everything else important there should be layers of security and QA checks, with automated sanity checks on config and data for really important stuff. If a new hire can deploy stuff without multiple people seeing it before it gets to production then everyone in the company is responsible for accepting a process that can lead to serious issues.
This is what I call the "Perfect World Fallacy". Yes, in a perfect world, you'd be absolutely right. But that's not the reality we're living in – in particular, that's not the reality small and young companies are living in.
When you're scaling up, or when you're short on staff, and there are fires to be put out everywhere, you just don't have the capacity to design and test those perfect processes. Where are they supposed to come from?
> layers of security and QA checks, with automated sanity checks on config and data
Ha! I've never, ever seen any company which comes even close to that platonic ideal.
Yes, in a perfect world, you'd be absolutely right.
A lot of companies choose not to do process oriented work, and just wing it instead because they believe they can go faster. That's fine. It's a choice driven by resources.
What's not fine is complaining that someone you hire is "bad" because they get stuff wrong when you're forcing them to work without a process-based safety net. People will always make mistakes. If your belief is that everyone should be perfect because you've chosen the no-safety route then you don't get to complain when someone nearly sinks the company. Expecting people never to get things wrong is unreasonable, and it's the exact reason why we have processes to catch problems.
> If your belief is that everyone should be perfect [...]
Well, you seem to believe there's such a thing as a perfect process. How is a non-perfect employee (or a group of non-perfect employees) supposed to come up with a perfect process?
> [...] because you've chosen the no-safety route [...]
Who said anything about no safety net? Maybe there was a process, or a safety net, but it wasn't perfect and didn't catch those mistakes?
I didn’t fire him because he made 2 mistakes. I fired him because I was giving him 10-15 hrs/week of coaching and mentorship and he wasn’t improving at all. The process that was bad was our interview process and our process change was changing our interview process.
Pretty strong disagree on this. I prefer working on teams that optimize for execution speed and just hire people who won’t go up in flames in that environment.
Focusing on process and making the safest process will kill your team. Your best team members don't want to be hampered by a process that slows them down to protect them from their worst team members. The advantage you have as a startup is speed, don't throw it away so easily.
You recognise this and you didn't implement processes to catch problems after the first mistake (obviously, because there was a second mistake). If there's a third mistake I think you're going to have to accept it was partly your fault.
I don't think that. I think that when someone fucks up so badly it almost ends the company you review all your processes and work to limit the possible damage any one person can do. That would be a matter of putting in lots of additional checks for things to start with, and then removing them as you figure out what things don't need multiple people's oversight.
That sort of bureaucratic process is horrible and annoying, but it's less horrible and annoying than everyone losing their jobs when the company fails.
We're very fortunate in tech that we can automate 99% of this stuff. Stopping someone pushing bad code that fails tests or hasn't been peer reviewed is a straightforward case of adding some deploy rules to a repo. It's much harder to fix processes where things are manual checklists people need to follow.
In a company there are seldom human failures, those are process failures. If deploying means sshing into prod server and messing around, anybody is going to eff that up sometime. That person is then not a failure, having to do those error prone tasks is the failure.
The whole thing reads like inventing scenarios that didn't happen or embellishing them.
> A bad interview is when you ask them the definition of some specific thing in some specific framework like “Tell me what a closure in javascript is.” then treat them like they’re stupid if they don’t know.
Not that believable, but okay.
> I once had an interviewer ask me if I was a wizard with GO, C++, Rust, and C over the phone. Then when I said I had some experience with rust, he immediately cursed at me and hung up.
Didn't happen.
> Nobody in their right mind is going to move to San Francisco, California to be a “Lead developer” for only 70k with zero equity.
Are any companies actually trying to recruit like this? And is it successful beyond just throwing up a hiring post and not getting anything? I put in a limit buy of $3000 for 1 BRK/A on a whim once.