6 ms·

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 fr

• opportune 5y ago
  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.
• ZephyrBlu 5y ago
  Knowing this, his perspective may be based off agencies rather than tech companies which would explain a lot of the things he's ranting about.
  • peteretep 5y ago
    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).
• rhacker 5y ago
  I have 25 years experience and a CS degree. I even taught Java and C++ for 4 years at a college. Our top performing developer has this background: No software eng. experience 2015. 2016 Bootcamp 2017 Salesforce 2018 - today - our company: TS, React, Vue, NodeJS, Python, Main devops developer that brought up our docker infra. > Didn't happen. Yikes...
  • JAlexoid 5y ago
    What do you mean "top performing"? 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.
    • mLuby 5y ago
      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.
      • JAlexoid 5y ago
        Unless a person becomes omniscient after 25years of experience - you can easily miss horrible work.
  • rmk 5y ago
    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.
    • rhacker 5y ago
      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?
• MattGaiser 5y ago
  > Are any companies actually trying to recruit like this? I get some very crappy spam offers like that every few weeks. 35K to be a Java dev in Atlanta kind of thing. They do happen.
  • the_only_law 5y ago
    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.
    • MattGaiser 5y ago
      I have two years experience, so I am newish.
• bostonsre 5y ago
  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.
• sidlls 5y ago
  > 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.
  • anitil 5y ago
    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
• jmknoll 5y ago
  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.
  • trinovantes 5y ago
    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
    • machello13 5y ago
      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.
  • ramraj07 5y ago
    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.
• serial_dev 5y ago
  > > 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".
  • mLuby 5y ago
    > People also love asking questions they themselves could barely answer. Somewhat similar to hazing (itself an extended "interview" process). "I had to get through it, so you have to too."
  • sangnoir 5y ago
    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.
• 0xB31B1B 5y ago
  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.
  • onion2k 5y ago
    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.
    • 0xB31B1B 5y ago
      Yes, we have a bad process, show me a company with < 8 devs and traction that has a good process lol.
      • onion2k 5y ago
        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.
        • adwn 5y ago
          > after the first mistake (obviously, because there was a second mistake) What makes you think those two fuck ups by the same person where the same kind of mistake, or even related?
          • 5y ago