3 ms·
I've also been accused of faking things that I definitely did do myself, sometimes I find myself unconsciously playing down accomplishments so as to not to be a
by mantap 6y ago
I've also been accused of faking things that I definitely did do myself, sometimes I find myself unconsciously playing down accomplishments so as to not to be accused of fakery.
What you can keep in mind is that there are very large amounts of money at stake for software engineering jobs. So it is magnet for every kind of faker you can imagine. So don't take it personally, just be thankful that you are qualified for a job that many people wish they could do.
And yes the whole thing is a game. The people who are good at the game are most likely to win. So just learn to be good at the game.
- comprev 6y agoI hadn't thought of tech jobs being a target for fraud but it makes sense. Candidates will always test the market for how much they can inflate their experience.
- halbritt 6y agoI’ve been a hiring manager for a few roles. Every one that was posted publicly received approximately 20 applicants that were obviously not suited to the role for every one that was. This is exclusive of any level of seniority, which I like to be flexible on where I can. While I wouldn’t say this is fraud per se, the candidates were obviously using a shotgun approach to apply to any job in the industry.
- heavyset_go 6y agoI'm curious as to whether other roles and industries see a similar signal to noise ratio. I wouldn't be surprised if a lot of people are just applying to every job that's listed in their current location or where they want to live.
- ChrisMarshallNY 6y agoRecruiters and LinkedIn make it worse. LI has some very spammy features they sell to recruiters, based on keywords and tags. I'm a native Swift developer, with over 30 years' experience programming Apple devices, but I have also written a lot of PHP (backend) stuff, and Web sites. A few years ago, I spent a few months, learning Android, and decided I didn't like it, but I do have Java and Android Studio in the mix. I often get recruiters, trying to match me with Web design or C# (nowhere in my stack) jobs.
- halbritt 6y agoI spent the first part of my career as a network engineer, moved into management, started doing "cloud" stuff for whatever that means, and have very obviously not been an IC for a long while. Been in the bay area tech scene for over 20 years. I'll still get pinged by recruiters for a senior network engineering job in Idaho or some such.
- ChrisMarshallNY 6y agoI was a hiring manager for 25 years. I never gave one single test, and I could usually weed out the spammers from a quick glance at their résumé. I often hired folks that didn't "hit all the sweet spots" on their CV, because I found them to be eager, energetic and curious. Had a couple of bad decisions, but very few.
- jefftk 6y agoFor the opposite perspective, I work at one of the FAANGs and I've given about 200 interviews. A mix of initial screening interviews and full evaluative interviews. At the screening stage I've interviewed several people who looked great on their resume and were really good about talking about programming and what they liked, but couldn't code even my warm-up problem on the whiteboard. These weren't people who were too anxious to code well in this setting, [1] these were experts in BS. Because the company is very careful/ slow to with firing people, which I generally think has really positive effects on employee well-being, hiring someone like this would be really bad. Much less extreme, but I've also seen many people who looked very similar in their resumes but were worlds apart in how the coding interview went. Some of them could quickly flush out specifications, asking good questions, talk about why they want to solve the problem the way they did, and fluently write code, while many others struggled in different areas or sometimes all of the areas. This is also really important for figuring out which of them we want to hire, and how badly we want to hire them. How the interview is run matters a lot, and also what sorts of problems you choose. I think it's really important to choose problems that aren't essentially spending 45 minutes on one narrow knowledge test (especially of the "have you already seen this before" variety), but instead test as many aspects of the person's skills as possible. I want to see how they handle incomplete requirements, simple design, thinking about how to create an output format that is maximally useful to a consumer on another team, naming things, thinking about the runtime of different approaches, thinking about big-O space usage, thinking about back of the envelope space usage in bytes, coding, thinking about edge cases, etc. If I had more time I would want to check code reading, testing, and debugging as well, since these are so important to being an effective programmer, but they're unfortunately much slower to evaluate. [1] I've interviewed people like that as well, and within the confines of the interview I've been asked to run the best I can do is note that I don't think we're able to evaluate them well this way.