4 ms·

Smith's Nineteenth Rule is probably spot on based on most resumes I see. The ones that list every insignificant detail are sometimes good at getting interviews

by fecak 13y ago

Smith's Nineteenth Rule is probably spot on based on most resumes I see. The ones that list every insignificant detail are sometimes good at getting interviews (particularly in companies that use ATS or train recruiters/HR to scan for single words), but not always successful. Again, as someone who specialized in Java for many years, this was something I'd see on a daily basis. I see it much less now in the camps I deal with regularly (Python, Ruby, FP, mobile) but that probably has something to do with the technologies themselves and naming protocols.

michaelochurch 13y ago
The Java programmers tend to be enterprise types (not to knock that; a few of those are really good) who aren't especially selective in the technologies they work with. Until about 5 years ago, using Python meant you deliberately went out there to find non-standard technologies-- you were passionate about more than just getting a job. Short technology lists show selectivity. For example, I've dealt with XML but I'm not going to put that on my resume. I don't even know what it means to "know XML".
- fecak 13y ago
  Java programmers tend to have longer lists for a few other reasons. For one, the number of available frameworks, IDE's, and other tools is much more significant than other language ecosystems. There really isn't another dev group that has as many tools available between the vendor and open source options. There is also the tendency to name every single Java API - you can't just say you know Java EE (formerly J2EE), but you have to list EJB, JSP, JMS, etc specifically to get picked up by searchers. There are many Java devs who worked with JSP and servlets that didn't use EJB, but when EJB was in high demand everyone listed it anyway.
- jerf 13y ago
  'I don't even know what it means to "know XML".' There's definitely such a thing: Do you understand entities and how they work? (There's more to it than just & and <. Without looking it up, do you know what a Billion Laughs is, and why it's related to entities?) What's in a DTD? Do you understand XML namespaces properly? (e.g., in the tag <x:test xmlns:x="http://blah.com/ns1" http://blah.com/ns1" att="1"/>, what namespace is "att" in? What, exactly, does the http://blah.com/ns1 http://blah.com/ns1 mean? How does it relate to blah.com or the content at http://blah.com/ns1? http://blah.com/ns1?) Do you have an understanding of the various schema languages? Do you understand how encodings interact with XML? Are you familiar with the terminology (e.g., can you precisely answer "What is CDATA?", with some idea of where in the XML grammar it appears and what characters are and are not allowed)? Do you know what a processing instruction is? What is the correct way to embed binary data in XML? BTW, the answer is generally no. "Everybody" understands a subset of XML with balanced tags and simple attributes, but I'd guess single-digit percentages of the people who have "XML" on their resume really know XML, rather than the simple subset. Fortunately, as an interchange format, since nobody understands XML, nobody uses it to its full capacity, those few who try use it incorrectly, and it turns out there isn't a heck of a lot of reason to actually know the full scope of XML, since in general you're unlikely to encounter correct advanced XML anyhow. You can easily go an entire career without ever seeing the advanced features used correctly. Actually knowing XML can be almost end up being an impediment, you're almost better off having a fuzzy understanding so that when you encounter some developer's weird half-assed dialect, you're less shocked and just get on with it. (I am aware that some of my example questions there are themselves based on false premises. Consider them trick questions.)

by fecak 13y ago

michaelochurch 13y ago

The Java programmers tend to be enterprise types (not to knock that; a few of those are really good) who aren't especially selective in the technologies they work with. Until about 5 years ago, using Python meant you deliberately went out there to find non-standard technologies-- you were passionate about more than just getting a job. Short technology lists show selectivity. For example, I've dealt with XML but I'm not going to put that on my resume. I don't even know what it means to "know XML".

fecak 13y ago
Java programmers tend to have longer lists for a few other reasons. For one, the number of available frameworks, IDE's, and other tools is much more significant than other language ecosystems. There really isn't another dev group that has as many tools available between the vendor and open source options. There is also the tendency to name every single Java API - you can't just say you know Java EE (formerly J2EE), but you have to list EJB, JSP, JMS, etc specifically to get picked up by searchers. There are many Java devs who worked with JSP and servlets that didn't use EJB, but when EJB was in high demand everyone listed it anyway.
jerf 13y ago
'I don't even know what it means to "know XML".' There's definitely such a thing: Do you understand entities and how they work? (There's more to it than just & and <. Without looking it up, do you know what a Billion Laughs is, and why it's related to entities?) What's in a DTD? Do you understand XML namespaces properly? (e.g., in the tag <x:test xmlns:x="http://blah.com/ns1" http://blah.com/ns1" att="1"/>, what namespace is "att" in? What, exactly, does the http://blah.com/ns1 http://blah.com/ns1 mean? How does it relate to blah.com or the content at http://blah.com/ns1? http://blah.com/ns1?) Do you have an understanding of the various schema languages? Do you understand how encodings interact with XML? Are you familiar with the terminology (e.g., can you precisely answer "What is CDATA?", with some idea of where in the XML grammar it appears and what characters are and are not allowed)? Do you know what a processing instruction is? What is the correct way to embed binary data in XML? BTW, the answer is generally no. "Everybody" understands a subset of XML with balanced tags and simple attributes, but I'd guess single-digit percentages of the people who have "XML" on their resume really know XML, rather than the simple subset. Fortunately, as an interchange format, since nobody understands XML, nobody uses it to its full capacity, those few who try use it incorrectly, and it turns out there isn't a heck of a lot of reason to actually know the full scope of XML, since in general you're unlikely to encounter correct advanced XML anyhow. You can easily go an entire career without ever seeing the advanced features used correctly. Actually knowing XML can be almost end up being an impediment, you're almost better off having a fuzzy understanding so that when you encounter some developer's weird half-assed dialect, you're less shocked and just get on with it. (I am aware that some of my example questions there are themselves based on false premises. Consider them trick questions.)