Had the almost exact same experience, but with Java. I'm a C# developer and although I have some experience with Java, I don't have enough to list it as a skill on my CV.
Anyways, in this interview I was being asked about Java and I answered every question by saying I don't really know Java. The interviewers were obviously getting annoyed. So I asked "Sorry, I thought this was a C# job?". No, it was a Java job and magically my CV had modified itself to say I had 7 years of Java experience.
I told them I did not put that on my CV, I actually had my own copy with me and showed them that. We all realised the recruiter changed my CV. They apologised and wished me luck.
Thirty minutes after leaving the recruiter is on the phone to me, screaming at me and berating me for not going along with the ruse. He said "Sure aren't Java and C# are pretty much the same thing?"
Now that is why if I ever have to send my CV to someone it will only be a PDF version.
> Now that is why if I ever have to send my CV to someone it will only be a PDF version.
This doesn't always help either though. I have only ever sent PDFs to recruiters for this reason. Yet I have still had a recruiter completely rewrite my resume and add false information.
I generally keep a resume on me when I go to an interview just in case an interviewer had not seen it. I'm glad I do that.
I've had them re-type the resume and add typos and errors. I don't need a recruiter for that. I can put typos and errors on my resume by myself just fine.
I was doing some interviews and the resumes we were getting were like 5+ pages long. Maybe it was some cultural difference or something but I'd always been told to keep my resume to 1 page front & back at the absolute longest.
Turns out it was a different resume that the recruiters would send us. They were garbage in quality and I hate them.
It's not cultural. I think the agencies are trying to put in every single keyword and "skill" to get past algorithmic filters and also make sure non-technical managers see the words they are looking for.
At a past role we were looking for a contract Tableau person and one of the agencies that was approved by HR sent me 20+ resumes. All of them were 5+ pages, with things like "Made a Bar Chart in Tableau," "Made a Pie Chart Tableau", etc.
After looking at 10 of these, I told our HR exec these resumes all looked the same and I thought they were fake. I had a meeting with the agency rep and they said they smiled when I said these resumes were BS. Their response was "Usually we send resumes to a manager and they have a 30 minute phone conversation with some of them. After that they sign a contract with one of them."
The point is, a lot of hiring managers want a person to do X on a contract basis, but they don't understand X or have anybody in their group that does X. For all they know, connecting to a SQL database and making a bar chart is rocket science. These agencies target these managers.
I did end up interviewing 2 people from that agency, both of which were actually quite good with Tableau. Of course, those people were curated by the agency after I made my comment.
I'm not sure entirely that it's not cultural, though I'd love for someone to confirm. I interviewed with a recruiter for jobs in Australia, and they asked that I make my resume into a novel.
I wasn't trying to imply that all countries have similar expectations of resume format and length. I was just saying that if all the resumes from recruiting firms are atypically long, it's probably the recruiting firm that is responsible. It's not because they employ people on visa or anything like that.
I'm an immigrant to the US, and in my home country resumes are all really long. Even people who have never had a job and just finished their bachelors somehow find a way to have 5 page resumes. I think immigrants to the US in IT/Tech roles figure out fairly quickly that they need to drastically reduce the lengths of the resumes.
Huh. How long ago was this? Genuinely curious (pessimism and cynicism in cheek, if you will) if this is a good idea for me to do if I'm applying somewhere not deeply technical (eg, FAANG).
I'm actually in Australia myself. Guess my choice of reference for "nearby offices of competent tech companies" had unintended geographic connotations, woops
Some companies want resumes submitted as text or .DOC, for easier keyword searching perhaps. Or to avoid viruses? So the recruiter may OCR the PDF, then "improve" on it.
It's really not made to be and with the exception of an embedded file that's actually editable (eg: LibreOffice optionally keeping an ODT version inside the PDF), "editing" a PDF tends to be a disaster of trying to match the layout with whatever text you are attempting to edit.
Certain tools, such as Word and LibreOffice, make it a bit easier as most of the source text is in the document, others like LaTeX end up looking like garbage through machine processing.
> Thirty minutes after leaving the recruiter is on the phone to me, screaming at me
I once refused to let a recruiter send my resume to this company because I thought the company was slimey (it looked like they used SEO to trick people who were actually looking for a free government service to use their paid service instead... but it was purposely ambigious they were not affiliated with the government)
The recuriter started getting angry at me, so I made it clear I would not work with someone who didn't respect me, and hung up. A recruiter who views you as simply a product to sell is not worth keeping. There's a million recruiters.
A recruiter called me out of the blue years ago when I was looking for a job, probably from LinkedIn. I didn't know much about contracting so I was just curious as to what he could do for me.
He called me once screaming at me because he thought I was not being exclusive to him with regards to a particular job. I told him quickly where to go, it was him who called me, grow up and stop wasting my time. To this day I have no idea what he was smoking that day cause I'm as bewildered now as I was then about what he was on about.
> it looked like they used SEO to trick people who were actually looking for a free government service to use their paid service instead... but it was purposely ambigious they were not affiliated with the government
> Had the almost exact same experience, but with Java. I'm a C# developer and although I have some experience with Java
>Sure aren't Java and C# are pretty much the same thing?
Yea, hear that from the other side:
I went for interview at Amazon (~2017?) for Java backend engineer. During the interview they were asking me only JavaScript questions from what looked like a standardized form to filter out phonies. I obviously failed the interview. Was told if this isn't the job I wanted I should apply for a different job and come back when I get some more experience in... Java. The recruiter had absolutely no idea that Java isn't JS and was interrupting me when I tried to explain the situation. I really should have applied for a job I wanted. One of the worst interviews I event went to.
Java devs with wide recruiters network got such emails weekly, calls monthly, until TypeScript came to rescue.
That's something I've noticed over the last 10 years or so as job descriptions get longer.
All those new terms like React, Vue, SaaS, Azure, AWS etc. They don't really know what they mean.
I was asked if I could code in Azure. This led to a weird conversation where I was trying to explain what Azure was, whilst he wouldn't listen to me and was adamant that it was a programming language.
"But can you code in API? I don't want your life story, just answer me! Do you know API?!"
I'm so lucky, I think I found the best recruiter in all Vancouver. He helped me get my ideal role and was generally kind and competent. Just to offset the horror stories.
How did you find your recruiter? Do you mind sharing the rough process that unfolded? Not asking for you to share them, just wondering if there are any takeaways you would have for others on the process.
No prob. He actually had a position advertised on roberthalf.ca.
The position seemed right up my alley. The directions part explained he was the recruiter for this position, and to reach out on LinkedIn first. So, I did that. I guess it was a pre-screen to see if I read directions.
He accepted the request but didn't respond to my message for a few days. I'm really not good at self promotion, but I also really wanted to get his attention. I saw that he posted regularly to LinkedIn and also engaged with a lot of posts. So I posted a cool side project[0] to LinkedIn that I had recently done. I was feeling pretty exasperated, I think I wrote something like "if i will do this just for fun, imagine what I will do if you hire me." I don't necessarily recommend that exact approach, but he did notice it and that is what got the ball rolling. Thankfully he thought it was cool, because it is a little bit edgy. I was looking for a smaller company that valued a hacker mindset, so it was a bit of a filter as well I suppose.
We immediately hit it off. He seemed to understand what I was all about, which is cool. I'm an aspie and a lot of ppl just don't get me. He has over 20 years experience so he really knows his stuff and he was just nice and down to earth.
I got extra lucky because he was friends with the hiring manager for 20 years, they worked in the game industry together in the 90s.
I'm not capable of generating any takeaways currently, as I am real tired, so I will leave that as an exercise for the reader. Hopefully my response was vaguely coherent and at least tangentially related to your question. Sleep time!
Seems like a wonderful red-flag system to me. I'd rather live in a world where bad recruiters make their values apparent than in one where they are well hidden.
TBF the recruiter likely was parroting what a previous candidate they were repping told them. I frequently find I have to re-educate recruiters who were previously informed incorrectly.
Absolutely, but that was kind of my point. A lot of recruiters I've encountered are like talking to a markov chain trained from some job ads. It sounds right if you don't actually know what the words mean.
..."maybe they are"...
did you check for a pulse?
I suppose there's nothing preventing walking Markov chains from having pulses...
But your comment is the pithiest most succinct one here.
Throw away the OP's tweet and all these comments, especially mine, and just put your comment on a blank page and let's call it's the succintestist summary possible.
I had one where "OWL is just like MFC, right?". At least she did listen while explained the differences. Sadly, I took a report writing gig to get out of one place. That was a hell of a bad call.
C# and Java the language are similar enough; the ecosystems are very different. A C# developer would mostly be expecting to develop Windows programs or possibly Windows server / IIS applications. A Java developer could be working on all kinds of different things.
I do most of my development in a what looks like a watered down version of JAVA. Last year I had to dive into C# and asp.bet for a bit. I felt like at home. The language makes sense,there are hardly any surprises and most of its features are excellent. You are right, however, that the ecosystem itself is different and it will take some time to get used to it. However, unless a company hires a contractor on a short term basis,the expectations are that he'd be there for at least a year or two. That's plenty of time to get going and adjust to the ecosystem,which,I think any competent developer would do in a month or two.
There are also arguments when it comes to some very niche types of jobs,e.g. deep optimization all the way to the compiler,some esoteric use cases,etc. Yes,in those cases it's better to hire language native,but for most jobs that won't be the case.
Keyword-happy business HR: "Sorry, we're looking for Java. Case-insensitivity? No, we have to be sensitive to everyone. Being insensitive is not what HR does."
Even one month - two months is a long time for any non-esoteric language except maybe C++ (even that one I doubt) for any developer with experience picking up multiple languages. Most teams are actively working on making their ecosystems easy to pick up for beginners.
That is, unless the company in question has made a complete mess of their pipeline and aren't aware or unwilling to admit it.
The trick isn't memorizing them. The trick is discovering them. I've been emitting various versions of Wingardium Leviosa at Spring Boot for days now, with no effect. Once I've learned the incantation I'll have it and can repeat it in ten seconds, but until I have it I'm producing no actual work.
Arguably, I'm more valuable because I have the capacity to eventually figure this out, rather than having already memorized it. But if this were a crisis rather than a minor bug, it would be much, much better to have somebody who'd already spent that decade learning all of the many, many, many incantations that Spring Boot requires.
(I'd also argue that Spring Boot in particular is much, much, much too dependent on incantations, and the main lessons I've learned could be put on my resume as "Expert in Spring, and you can be too in one lesson: Don't.")
That really applies to all ecosystems. Hiring somebody smart is better. But there really is something to be said for having somebody with X years experience, who can therefore do some things in 10 minutes because they've already done the painful part on somebody else's dime.
I was once backed into a corner to write a web app in some form of Java. So I chose Spring and Angular. After months of frustration, trying to find examples, and put something together, I had gotten just one "show" page and an "edit" form worked out (but not the "update" function side). I put it all aside one day, and wrote what I was working on in Rails. It took me 1 afternoon, including authentication with SAML.
That's when I realized 1) how much Spring and Angular were NOT doing for me (compared to Rails), and 2) how much knowledge lies buried in BOTH stacks. I feel that Rails is by far the better tool for creating CRUD simple web apps, but the ability to be quick with it comes from years and years of living with it, and understanding how 3 or 4 lines of configuration work together to produce the effect of several hundred lines of explicit Java and JS in Spring and Angular.
Disclaimers: YMMV. TACMA. Past performance is not indicative of future results. Et cetera. Et alia. Ad nauseam. E Pluribus Unum. QED.
From my perspective, a great advantage of Java over non-statically-typed languages is that when I make a stupid error, most likely the IDE will notice it and underline it immediately. Thus I don't waste my time hunting for stupid errors.
That is, unless I use Spring. The stupid Spring-related errors only appear at runtime.
Ok, honestly, after a year, using Spring is more convenient than not using it. (Basically, there are two or three types of stupid errors I usually do, and I learned how to decipher the intimidating error messages.) But the first experience is quite a shock. You write something with algorithmic complexity of Hello World, then you run the program, it throws a screenful of error messages, and you want to scream.
It reminds me of my childhood experience with Turbo Pascal, where you had to wait until the compiler told you that you missed a semicolon... and then it pointed at the wrong place -- not the place where the semicolon should have been, but usually the beginning of the next line. After some time, it becomes obvious, but the first time it's definitely not.
Oh, if only you get error messages. My most common mode of failure in Spring is "nothing happened". Which there's no way to debug, or Google. At least error messages show up in Stack Overflow. You missed an annotation, or provided the wrong kind of annotation, and Spring just said, "Well, apparently that code doesn't matter."
Inversion of control means you have no control.
At least Spring has switched mostly to annotations, which are sorta like Java. The IDE can spot some errors.
Until now, I felt bad that I haven't learned Spring earlier. Now I feel happy that I only met Spring after the annotations were added. I can't even imagine the horror...
> It reminds me of my childhood experience with Turbo Pascal, where you had to wait until the compiler told you that you missed a semicolon... and then it pointed at the wrong place -- not the place where the semicolon should have been, but usually the beginning of the next line. After some time, it becomes obvious, but the first time it's definitely not.
C++ template expansion and linker errors come to mind. First time you encounter those it's typically either very short and cryptic or at least 500 errors and the compiler hitting an internal limit of how many of them to display.
I reach for Spring Boot as my tool of choice for most APIs, but I feel your pain. There’s always a particular corner, the dreaded “configuration” folder, filled with a collection of random annotations, single-purpose beans, filter chain setup, etc.
I find that most of my business logic ends up being really compact and powerful, but the tradeoff is that one chunk of the project is really dense.
The problem isn't can I learn, the problem is do you want to wait. You need a few great developers who have a lot of experience to ensure that a mess that is hard to clean up isn't main. If you have a 10 great developers who know how to do whatever right, then 100 other great developers who no nothing about the whatever can learn. However without those 10 experts in the domain to start with nobody knows what the right decisions are in the first place - in 3 years they will realize their mistakes but by then it is too hard to fix them.
To qualify the anecdote below, let me be clear that I’m an outlier: I have shipped‡ software on _lots_ of different stacks and 35+ different languages°.
I know exactly the difference between having to deal with the Java ecosystem for SOAP and the Microsoft ecosystem for SOAP—I had to deal with both at the same time at one job a decade ago. At that job, I worked with a lot of really smart people, but it was a Windows shop. Most of the people I worked with _could NOT_ work with the non-Windows platforms we had to deal with (HP-UX, AIX, Solaris, Linux, VMware, and HP-UX). They would _constantly_ break code that was written to be cross-platform safe because it wasn’t what they were used to. On the other hand, at least I didn’t have to become familiar with how Exchange worked in order to integrate with _that_.
The number of people who can make the level of context switch you’re referring to, or working with multiple contexts like this, is vanishingly small in our industry. It can be done, but I think that you deeply underestimate the surface area of those ecosystems and the _willingness_ of people to put themselves in uncomfortable positions. The OP who talked about knowing C# but being interviewed for a Java position would have been _deeply_ uncomfortable writing Java because the tools they were used to weren’t available.
I would not make the same judgement you’ve made here. That said, if someone _wants_ to learn a new ecosystem, I’m happy to have them explore that (I prefer ability to learn over proven experience when I’m in a hiring position).
‡ Shipped: made it so that others could use, not just myself. This would include a project that I ported from Ruby to IO so that I could learn IO and a project that I ported to Elm in order to learn Elm. It does not necessarily indicate pickup. If we restricted this to stuff that I know that other people used, I might lose a couple more than the two I just mentioned.
° Languages: I include variants of languages that are _sufficiently different_ from their predecessors so as to require translation. This mostly affects the shell scripting variants (Posix sh, ksh, bash, and zsh are all _similar_ but sufficiently different that I count them; I have shipped substantial scripts in each). I don’t count gawk vs awk. Regardless, I vary between 3–4 languages and ecosystems weekly at my current job.
Yup. Very similar language, but good luck going from ASP.NET MVC to Spring Boot without missing a beat. Or from WinForms and WPF to Swing and whatever else is new and hot in Java-land. Not to mention NuGet vs Maven, EntityFramework vs Hibernate, etc.
I think this hides/hints at a greater point, though. C# or Java is a technology choice (among many, such as which ORM to use or even whether to use an ORM at all). All technology choices have an impact, and, in my experience working with both of these and other languages, it's just as likely for two shops that chose the same programming language to have made enough other different technology choices to make the transition challenging.
No one said there wouldn't be some ramp up time. Especially if there is another senior Java dev on the team that can "show the ropes", I don't think its that bad.
If we're talking about a lead or solo dev position, it would cause issues though.
This. I can do programming problems in Java, but I definitely can't lead a team doing a Java project. I don't what Gradle/Maven/etc really are. I don't have years of experience with how libraries, the API request pipeline, middleware, etc work. I don't know little tricks / nuanaces, like the fact that Visual Studio has to be restarted for local code to pick up new environment variables, why String and string are the same thing, etc, etc, etc.
I actually find the things _around_ the languages like build tools and ansible and such by far the more confusing parts of dev work just because I never know which of them I should spend time trying to understand and if I just want a runthrough for someone who can already program I never know where to look.
Lots of new languages that arose in reflex to the "stack complexity" of Java ... eventually achieved the same stack complexity with a totally different set of framework/tool names.
Ruby/Rails in particular became this. Javascript rocketed to this complexity level, with the added chaos of seemingly reinventing the entire toolchains every 2 years.
yeah, i never understood that part. People wanting to use javascript on the backend, but not having any of those tools. They exist for a reason, and it's not to make things more complicated.
When I started developing I felt the same way. One day I finally decided that maven was going to be around long enough (and I was going to be a java dev long enough) to spend some time learning. It didn't take long, couple days at most, man has it saved me a lot of grief over the years. CSS was the same, although it took longer than a couple of days, it has been more than worth it.
Honestly unless a candidate would have to learn to code in a significantly different paradigm (eg has only OOP experience and the work is in Erlang), I can’t think of a reason why prior experience with the language would be an issue.
Ironically, going the other way seems to be more difficult. C# has more features to learn, but simply not using them until you learn them won't really hurt you. Going from C# to Java, on the other hand, has some traps. You can get yourself into hot water if you don't know, for example, that the boxed and unboxed numeric types have different equality semantics.
I think the biggest hurdle going from Java to C# is how you think about asynchronous code, more so for desktop software. My last role was C# with me coming from Java and I got a few rude awakenings.
I think it also depends on the role. If the role expects a deep dive into the language and its ecosystem (more of a senior role), then the ramp up time is longer. But if it is a more junior role where you are just implementing stuff using core components of the language, then it should be easy enough to make the switch.
> "Sure aren't Java and C# are pretty much the same thing?"
While it was extremely unethical for him to change your CV, Java and C# are indeed very similar, to the point that most organizations use devs with that background interchangeably.
If that company really ruled you out because you had 7 years of C# experience, and not 7 years of Java experience, you likely dodged a bullet.
> If that company really ruled you out because you had 7 years of C# experience, and not 7 years of Java experience, you likely dodged a bullet.
Respectfully, I disagree. Things that you should learn over 7 years of experience go far beyond learning the language itself or the fundamentals of its standard library. We're talking about two very different ecosystems.
Yeah, there's some truth to both your points. If you need to backfill someone for an existing production project that doesn't have the bandwidth to train them effectively you are setting that person up to fail. This is why tech interviewing is such a pain in the ass though as there are a lot of competent programmers who can pick up new languages quickly. When we decide on who to hire while at megacorp it is always - generalist or specialist. When we decided on who to hire while at a start up it was always - growth minded and quick learner.
> We're talking about two very different ecosystems.
Are we talking about the vast differences between Akka and Akka.NET? ;-)
Honestly, to the extent the ecosystems are different, it is probably more valuable to add someone to a team with experience with a different ecosystem unless there is literally no one on the team with experience with the current one (and in that case, you might question your commitment). Yes, it takes a while to learn a given ecosystem thoroughly, but that's not really what is going to drive the productivity of your team.
Meh, sure a C# dev can do Java and get up to speed with it pretty quickly, but certainly a proper Java dev will be more productive immediately. Knowledge of frameworks is a real skill for example.
The frameworks are typically very analogous between the two as well, it takes a while to learn them but in the meantime it's googling "how to do concept x in framework y". Apart from the initial project setup you're also generally spending a lot less time dealing with the framework and instead looking at other code.
I fired a recruiter looking for jobs for me once when he created a .doc version of my resume (unmodified from what had been in the PDF, but it looked like _crap_). I told him that was completely unprofessional and I couldn’t trust him to find jobs that suited my targets or skillsets.
Now, I tell people to look at my LinkedIn profile as that is the only resume that I keep. I’ll download the PDF of it if they want, but I haven’t maintained an actual resume in at least ten years.
It's common practice for recruiters to replace your personal contact info with their agency's header/contact info.
I don't mind that. It makes sense.
I generate my resume as a PDF from HTML/CSS. It's fun to see how recruiters handle that. I think most use image manipulation to insert their header. One recruiter sent me some image assets and let me add the header/footer myself.
I'm sure some recruiters go too far with the .doc, but there are legitimate reasons too.
Last time I applied for job through a headhunter (2010), they ran my LaTeX resume through an automated .doc converter that destroyed all the formatting and then didn't even attempt to fix any of it. Somehow I still managed to get some interviews, and when I saw the printout on the interviewer's desk I shrieked in horror and handed him one the original paper copies that I'd luckily had the foresight to bring with me.
What are these recruiters you all talk about? Are these some middlemen you contract to get you a job? Like an athlete's/actor's agent?
I only had experience with recruiters who work for the organisation I'm interviewing for. None of this contact info / skills tampering makes sense in that context.
Post your resume on one of the really big job boards like Dice or Indeed and you'll see what we're talking about. Last time I did that I was getting 4 or 5 calls a day. Most of those recruiters were from the same three companies and you could safely rule them out because they would ask for your SSN. But anyone who calls you and tries to establish a personal relationship might be worth working with.
Rather than wait for applications, some companies will hire third party recruiters to find candidates to apply. Some will have in-house recruiters doing the same. If they find a successful candidate, they're paid with commission. Sometimes, being contacted by one is the only way to apply.
I've worked with several recruiters who are trying to shop around as an outsourced recruiter. Basically, they take your resume and slap their name on it in an effort to show companies "You should use me because I provide well-qualified talent."
If you're not going through internal recruitment then this is a great way to go about it. The recruiter isn't just trying to get their 20%, so they spend a lot more time getting to know you and also getting to know where you're going.
The biggest down side is that you'll never hear a negative word about anything, so you gotta be good at asking some pointed questions.
Never send doc. Always pdf. Next time I'm lookin I'm gonna send a jpeg for shits n giggles.
Same goes for references, always, "available on request for the employer who can reach out if they like, no you can't have them. Go find your own clients".
This may be a benefit in this case, as sneaky edits to a JPEG full of text will show up as a difference in patterns of artifacts - original text will be compressed twice, while the edits just once (or once and zero if they save the edited image to PNG). Takes a bit of time and skill to make this unnoticeable.
Ages ago, I was looking for a job. I made my CV using LaTeX, and provided it as a PDF to the recruiters. They straight turned around and asked for a Word format version instead. So I converted each page into an image, and pasted each one into a page each in a Word document, then sent that to them. They complained that there was something wrong with the document, and they were having trouble editing it.
I later had a job interview, and saw what the potential employer had been sent. They had re-typed it, and it looked awful.
> Anyways, in this interview I was being asked about Java and I answered every question by saying I don't really know Java. The interviewers were obviously getting annoyed. So I asked "Sorry, I thought this was a C# job?".
Are those types of exchanges still take place at the interviews? I was lucky enough to avoid them, having worked at companies that are able to afford to spend extra time training people. Those types of discussions often remind me of the Linus' quote: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
Pretty much every interview I've had has been like that. Asking lots of exam style question about the language/platform.
In my experience most employers say they want good programmers, but in reality they want quick programmers. People who can get the product out the door ASAP. And that's why I wouldn't take a Java job without learning the ecosystem first. Even if they promise training, there's a high chance of them reneging. So I would end up in a stressful situation trying to learn as I go.
I'd rather stick with what I know and what I'm good at.
Had this happen to me as well, only my background is JavaScript. I've had more than one conversation with a recruiter where they didn't understand the difference between Java and JavaScript, so I'm unsure whether this was done due to malice or incompetence.
+1 to the PDF resume, if for no other reason than you don't have to deal with format issues on windows/mac.
That usually results in a drop in quality if they burn the pdf, and at least so far I haven't had that trick used on me. I suppose you could add some watermarks to discourage it.
> Now that is why if I ever have to send my CV to someone it will only be a PDF version.
Although it depends how you generate it how easy it will be, Word has built in support for editing PDFs. So does LibreOffice (in Draw I believe). It's pretty accessible to non-technical people without expensive software to edit PDFs nowadays.
Weird. The recruiter did not show you the job description? Whenever there is a job sent by recruiter, I also ask for JD and the range of annual compensation. For the JD part, it is quite often that it is just a copy-paste from some employment website.
If I felt like I wouldn't get blank stares a lot of the time, I would absolutely love to use this. I'm at a completely different level of the industry than most of HN, so I don't get the benefit of (sometimes) interviewing with someone who is technically inclined rather than just a manager.
Anyways, in this interview I was being asked about Java and I answered every question by saying I don't really know Java. The interviewers were obviously getting annoyed. So I asked "Sorry, I thought this was a C# job?". No, it was a Java job and magically my CV had modified itself to say I had 7 years of Java experience.
I told them I did not put that on my CV, I actually had my own copy with me and showed them that. We all realised the recruiter changed my CV. They apologised and wished me luck.
Thirty minutes after leaving the recruiter is on the phone to me, screaming at me and berating me for not going along with the ruse. He said "Sure aren't Java and C# are pretty much the same thing?"
Now that is why if I ever have to send my CV to someone it will only be a PDF version.