At our university, University of Manchester, we had a careers service drone telling us to list your experience working as a waiter and highlight skills you learned there ('communicating in stressful environment' and what not).
Dear young readers. Seriously, don't do that. Waste of space at best. Looks just stupid at worst. It doesn't tell me anything about your ability as a programmer at all. Description about a weekend project is much more useful. And no, clarifying whether someone wants latte with regular or soy milk is not a 'communication skill'.
Do you (or anyone else reading this thread) have advice for current college students looking for internships or their first full time job?
Unfortunately, I don't have the breadth of experience detailed in the slideshow to even justify a multi-page CV. In my environment, we work with a 1 page resume and <2 minutes of interaction with a recruiter at a career fair (~30% chance they're technical).
I have a variety of side projects I've hacked on, but it's very hit and miss -- some recruiters care a lot, others care more about my GPA and what classes I have taken.
What can students like myself do to best position ourselves in these situations, especially when we can't have multiple resumes for every company there is (and are forced to generalize)?
I graduated during the peak of the recent recession. I ran into this a lot. What worked best for me was to stop fine tuning my resume and do my best to skip HR. I got a few interviews by calling friends already in the field (some of those parents of friends) and asking to be put it contact directly with a technical hiring manager.
Of course, none of those panned out either. A few took hires with more experience and one offered me a job at an embarrassingly low salary (i.e., less than I made as a summer lifeguard).
Ultimately, what worked for me was getting in with a good company doing low level tech work (help desk) which got my recommendations for an internal position. This was my first lesson in corporate hiring: the most effective way to find a job is knowing someone.
I can't speak for everyone, but we get it (that you don't have experience to show). You are a student at the beginning of your career. Just be honest and enthusiastic. As the parent says, blathering about your experience selling coffee is pretty pointless. Hey, if you started a coffee cart, that could be interesting to tout.
If you don't have anything for your resume, all you can be is smart and engaging.
If you still have time in school, picking up an interesting project is very worthwhile. We could do side projects for credit. I don't really care if you wrote it in Javascript, if it is web enabled, or you did math with matlab; just give me something to talk to you about, and I can figure out if the several fairly well defined projects I have in mind could be tackled by you.
In other words, I don't look for a college grad with no work experience to be able to lead a team, design a product, and so on. I have a bunch of 'turn the crank' work, and a few challenges to throw out as well. I don't want to babysit you, but I also want you to ask questions and learn. Part of interning is giving back to the community, but part of it is I have work I need done. So, when I read your CV and/or talk to you, I just want to figure out if you can perform at that capacity.
If there is nothing left to talk about I resort to asking about your coursework. 'What courses are you taking'. 'Blah, and foodle, and a compiler course.' Okay, can you tell me what a recursive descent parser is? uhh...I've never heard of that" That is an actual conversation I had with somebody recently. I blame the school more than the person, but no offer was made. I wasn't going to have the candidate code a parser for me, either for the interview or the job, but I just wanted to have a conversation about anything where I could probe knowledge (less important) and ability (more important). Find an area that know something about, find the limit, inject a new piece of information, and see if they can assimilate it. If they can, that's an offer. If not, probably not.
To be fair, you'll probably get a lot of "code 'delete_node' for a binary tree type questions, so like it or not brush up on that crap.
Beyond that, for me at least, the CV isn't very important. If everything you list is about networking and databases, and I am looking for graphics programming, I scratch my head as to why you are applying and probably move to the next resume. A fit in interests is important, after all.
>> Do you (or anyone else reading this thread) have advice for current college students looking for internships or their first full time job?
Do something and write it down. Most coursework is not relevant here, but classes that involve a large project - put down the what you did for it. Did you design something? Build something? Discover something? Win something? Lead something? I'm not talking about regular lab projects here, I mean big things that take at least half a semester.
This has been my approach, YMMV. People can appreciate if you demonstrate an ability to DO stuff.
can't have multiple resumes for every company there is
But you can target 3-5 companies which you reckon you stand the best chance of getting in.
Research up the wazoo on your selected handful. The best is if you can network into present employees and probe into what's actually going on in there. What technologies do they really use, what's griefing them, and most important of all, why's this req open.
By working backward from why THEY need that extra pair of hands, YOU stand out as the best person for the job.
You're being harsh - graduate CVs are tough because almost no-one has done anything useful. Yes it all looks rubbish but I'd rather someone who had made an effort to sell themselves and had shown they had the ability to pitch up to a job on a regular basis.
But in our industry, it's easy to stand out. Spend a weekend or two, make some web app, Android app, or whatever. Maybe make a commit to some open source project, if you are struggling with ideas (in that case, you are capable to work with code written by other people, amazing!). And you are ahead of majority because you demonstrated that you can make something practical, real world.
Absolutely do this. Having interviewed 50+ candidates for various positions myself, it's amazing how much you can stand out just by upping your online profile a little bit. Some examples:
- one guy I interviewed for a junior position had put his CV and projects online on his own website. It wasn't loads but he was the only one out of that bunch of grad inverviewees to do it. I had a look through it before his interview, and when he came in I said, "that HTML looks remarkably clean! Did you tidy all that up just before you posted for the job?" We both laughed because it was obvious he had. Rest of the interview was nice and easy after establishing the "we are developer friends" bit.
- one guy had no degree, no A levels to speak of, but his contribution to open source was immense. We got him in for interview and he could speak clearly and with authority on each of the huge projects he was involved in. We offered him the job but he refused us to go somewhere bigger.
So go get yourself a GitHub account, buy a domain name for very little/year, point it at a GitHub Page and put anything you can think of on there. Congrats, you are now better than 90% of candidates out there.
In my experience, development experience is relatively easy for students to obtain while in school. Internships are abundant (obviously not everyone is going to come out of school having worked for Google or Microsoft but most people who want to get development experience during college can find it). Personal projects are another way of doing something "useful" that have effectively zero barrier to entry.
It isn't too hard to do something "useful" as developer in college, if one has the motivation...
I beg to differ. For a graduate position, any professional experience is a big plus. I am prepared to teach people programming. I dread to teach people professionalism.
A large company might have an HR department that is insulated from any of the 'technical' branches that company might have. Imagine if they had to have all sorts of knowledge about what every individual branch of the company does? It's their job to be gatekeepers that make sure the people coming in for interviews are not raising any red flags, further along in the hiring process skill will be determined.
recognizing the "JS" in AngularJS or the name of a library which has all but become synonymous with JavaScript does not require intricate knowledge of the technical branches of a company. Furthermore, if a recruiter is filtering candidates based on a technical skill, they need to know more than just that single keyword. This is not necessarily a failure on the recruiters part; it could be a failure of the hiring branch to adequately prepare the recruiter. However you look at it, it is a failure.
Actually I'm thinking of testing future candidates with a "dumb" response like this, just to see if the candidate clarifies the situation and is helpful, or if we are dealing with someone who is just rolling their eyes all day, because of all the dumb colleagues. Someone who feels the need to be condescending when someone lacks some knowledge.
I've been applying at our state government and keep hitting this. The standard joke is you could list your only experience as "Pizza Hut Delivery Driver", as long as you put the words "Linux, Javascript & Apache" in the description.
The HR people literally just do a "Find" for words without reading the rest, and that gets you a phone interview.
Great slides - thanks. One surprise "leave off education". Would like to hear some more thoughts about that - haven't seen that before. 18 yrs experience so I'm sure its not too important (I did nothing spectacular in college, but did graduate) - still leave it off completely?
I started putting an abbreviated education section at the very bottom (instead of a full section at the top, as is common) and it significantly improved response rates. I especially recommend this strategy if your field of study isn't traditional.
I made the change to education at the bottom after watching a recruiter read my resume in person--I could actually see the moment she got to the education section and tuned out completely. It turns out people in tech tend to be turned off by my chemistry degrees. (Aside: It would be cool to have some sort of service that allowed you to A/B test resumes against a certain hiring demographic.)
That's what I'm also curious about. I never finished my degree and understand I have to leverage work experience and a killer portfolio to get my next development job, but have yet to figure out how to structure my resume around this niggling detail.
Leaving off the education section is interesting... I'm assuming this strategy is to give you an opportunity to create interest as a candidate before the (inevitable?) question comes up, "I see you didn't mention education on your resume... Could you tell me more about that?"
Well, to be honest, I have had a masters degree and absolutely nobody has asked me about it EXCEPT for Google. I'm sure there are other places that focus a lot of Algorithmic stuff that would prefer if you had some academic backing, but by and large I don't think it matters at all. Especially in this job market.
The only place where an educational degree will help in development jobs is probably getting work visas.
Google is also totally possible to get hired at with professional experience alone — you're likely to get quizzed even more on CS than other applicants (which is a lot to start with!), but it's far from impossible.
If you graduated college, it might be worth 1 line - a few decision makers will filter you out if you don't explicitly say it.
Or, it's worth 0 lines if you think that's not the kind of company you want to work for.
I once had a hiring manager ask why my K-12 education was not on my resume... he said he had wanted to filter out my CV on that basis; then I filtered his company partly on that basis.
I have a bachelor of Software Engineering (certified Engineer) with First Class Honors, and I know I'm usually competing against people with a Comp Sci. degree, or even just a diploma. I think it's important to highlight my education, as it puts me a cut above.
I for one would never consider a Software Engineer better than a Computer Science degree. I check to see if you have a degree in software and assume whatever label you use is just due to the random selection by your college.
Having no experience and no experience is killer, but once you have some experience lack of a degree isn't a big deal.
My degree was an extra year on top of Comp. Sci. and included fields like compiler theory and design, real time programming, digital electric design and engineering math 1-4 which comp. sci. didn't.
I'm also a certified Engineer (in Australia, anyway), which I always thought counted for something.
After about 5 yrs experience most people don't really care about where you went to school (except places like Google or Facebook). Some might care whether you completed a degree but are probably more interested in what you did the last 5 years (ie if the most exciting/interesting you can talk about after that many years of working is your school experience then you have bigger problems than your CV).
From my experience the kind of degree someone has is virtually meaningless. The only time I even take it into account is when I'm choosing interns and the difference between Software Engineering and Comp Sci is still meaningless.
It depends. If you have a lot of experience in the field, then that's going to be more important then the degree you obtained 10-15 years ago. If you don't have that wealth of experience, then it makes sense to include your education.
Thanks. That's probably why I still like to include it, I've taken many years off for traveling, snowboard instructing, etc. so my experience section is a lot thinner than it should be for my age (32).
Thanks for this, currently a PHP contractor looking for work in the UK and this certainly opens my eyes up to the issues with my CV. Probably explains why I haven't been getting many interviews!
What would you suggest for a contractors CV which is primarily filled with 1-2 month contracts?
I usually try get the last years work on the CV, but as you can imagine that starts to take up quite a bit of room when you have many short term contracts.
I would portray as one role, and a few really important projects.
For example:
Senior Consultant
For the past 24 months, I've worked with a large number of varied clients to realise true business value for them.
This has included Real Example A and Specific Detail B, but beyond the pure technical skills, it has highlighted the value of softer skills.
Most notably, I recently worked with the estate of Douglas Adams in an ecommerce towel distribution hub.
Don't panic, I'm the right chap for the job.
I put seperate contracts on as seperate jobs and find getting PHP jobs hilariously easy. People do ask why I change jobs so often, but the standard "I'm a contractor and finance dept don't wanna pay our rates" goes down well enough.
This is my CV, I try to be straight to the point and keep it under 2 pages on the word version.
Why are you perpetuating the myth that frequent switching of jobs is somehow detrimental to your career? Maybe that's true for corporate megacorp, but in the startup world I feel it's par for the course. At least all the best engineers I've worked with never stuck around long.
If I take you on I want some indication that you're going to stay around long enough for the investment we're going to make in you to be worthwhile. We'll normally pay a recruitment fee and then we'll pay you while you're learning about our product, our industry, our processes and the specific technologies you haven't worked with that we use, and we'll be paying our existing staff to take time out from coding to do those things. That's not inconsiderable.
Obviously your experience may render some of that irrelevant. If that's the case then if you're massively better than the other candidates I may take the risk but if you're not, then I can take you or I can take the person who is as good but will stick around longer. That's not a tough decision.
I'm not looking for gold watch territory or even an indication that you might be around for 5 years, and I'm not looking for a guarantee, but if your CV shows a pattern of you moving every 15 months I need to work out why I think I won't be your next 15 month stint and if I think I think I am whether it'll be worth my while.
Most people jump when the company is not paying market price so they switch.
I move very fast from companies that don't keep up with pay.
I stay at companies with regular pay rises. I've had both. So in my mind it means that companies concerned with job hopping, are really hoping to keep your pay down. It's an early warning .
I accept people leave when their salary diverges more than a certain amount from the market rate but that would normally - even in a good market - take time.
Personally I wouldn't expect a major pay rise within the first 12 months of a job (if you do then you've probably not negotiated your starting salary properly). Add to that a couple of months after that to find another job and a month notice and the shortest stint relating to poor pay I'd expect is about 15 months. If you're staying 15 months or so in places which are bad payers and a few years in places which are good then your average is probably going to be 2-3 years. To me at least that's not a problematic amount of time (particularly not if you've shown you can stick at least place for 3 years or so because that says to me you're not inherently disloyal).
So short stints don't say anything, at least not much, about money when I read a CV.
It's simple logic, people move because they can better deal somewhere else otherwise there would be no point. So if people move, the benefits aren't keeping up with other jobs they can get.
Most employees are not loyal, because they know companies are not. If they think companies are loyal, they are probably new to the job market. Once a project ends, and there's nothing else to work on they will get rid of you. There's no reason why employees should not think the same way.
Obviously there is no one rule for everyone but personally in 20 years working in IT I've never left a job because of money (and I've left a few). I've left because of uncertainty, because the work was bad, because there were too many arseholes where I was, because my skills were rusting but never for money.
In the past five years a fair number of people have left the company I work for and I'd estimate about 25% were money related.
As I say there's no one rule but I've seen developers put up dreadful money for a job they liked and take a pay cut to get out of somewhere they hated and if I had to generalise I'd go with that over them following the pay cheque.
"Most people jump when the company is not paying market price so they switch."
I've seen no data that suggests this is true, and from my own anecdotes I've found it to be untrue as well. The people I see that switch a lot seem to be simply unable to deal with colleagues or challenges that aren't going their way. Lots and lots of prima donna's in this industry that do not have the skill set to change things that are problems.
Even the money concern is a bit of a red herring. Being unable to justify pay increases at your current employer may be a sign of a bad employer, but it's just as likely the sign of someone who either cannot present their value proposition properly or someone who overestimates their value. Both are bad signs for the candidate.
"Any smart person can justify just about anything"
This turns out to not be true of lots of people. Being able to understand your value to your employer and to outline it in a compelling way is a skill that is very under developed in software tech candidates. It's also a skill that I've found correlates well with good hires.
As someone who has done a ton of hiring, switching jobs a lot is definitely a red flag. Not an automatic reject, but I frequently have to make choices like "It will take this person N months to become useful here, they switch jobs on average every M months. M-N seems like a pretty short time..."
The things that would really make up for the switching would be either A) experience which is very close to what I am currently hiring for B) a reason for the frequent switching.
At least for me, the CV is the least important part of the hiring pipeline. I have found them to have virtually zero correlation with good hires. So if I get a CV with frequent switching on it, and the candidate is great in all the other pipeline, it probably won't matter at all. If on the other hand, there are other questions about the candidate, a frequent switcher will get some questions about what they want in a job and a little bit of skepticism if we think there will be a big ramp up cost.
For permanent employees, I would definitely agree - anyone who is unable or unwilling to stay in a permanent position for more than a year, say, probably isn't going to be a good bet in the long-run.
For contractors, it's obviously somewhat different - but speaking from experience, many short contracts tend to get extended, so someone who has a raft of 1-2 month contracts and very few longer ones might be a bit of a risk. (Obviously some contracts are intentionally short - but I would definitely describe a very short contract on my CV as being more of a "project" than an actual contract.)
If you hire me "at will" then I won't ever stop sending out resumes.
I have had my job eliminated, regardless of my personal job performance, a grand total of four times. I have been forced out via office politics once, and voluntarily left a job once.
If you had a family, would you want to work for someone who is probably going to sell or eliminate your job well before retirement?
The loyalty from employers is gone. If you don't want me to leave in a few months, offer me an actual contract, and one that binds you to the relationship as firmly as it binds me.
Rule of thumb is two years. You're allowed to have one or two where you've left after three months - not every role works out.
But more than anything: get comfortable talking about WHY it didn't work out, in a way that doesn't bad-mouth the company and still makes you look like a professional.
An advantage of applying through a recruiter is that they can have this chat with you first, and then make your case to the employer (who they will have a relationship with). As a Hiring Manager, I've said no to candidates, only to have a recruiter persuade me (rightly) that actually I should talk to them, even though there were things that spooked me about their CV.
It is not a myth. It WILL raise eyebrows, with HR mostly. A corollary of that is, if you don't actually have a HR department, there won't be any eyebrows to be raised.
However, even if HR doesn't like it, if you do get an interview, then you can tell them a happy story to explain what happened. It helps if you can convince them that this time you'll stick around, provided the necessary conditions are met. Then ask several questions to clarify the points that are important to you.
Depends what you mean by "long". I think people should move every two to three years. But you say "myth", and I can tell you categorically that CVs with lots of 6 to 18 month non-contract roles on them get rejected on that basis alone.
What's the Perl scene like in the UK? As a former Perl professional, I'm continually not impressed by the caliber of some of my colleagues. I've actually left for greener pastures.
"Candidate driven", which means: there's a lot more demand than supply. Mostly London centric. Good roles tend to be in mid-sized companies with large existing Perl codebases rather than startups (who often choose something a little trendier) or huge corporates who rewrote everything in Java 5 years ago[1].
[1] Or, tried to, but there are still pockets of Perl everywhere that no-one ever got around to rewriting. See: Amazon, the BBC, etc.
One thing I have been noticing lately with HR drones, is that unless you have stated specifically that you worked in technology X on a project at work, it doesn't matter how many off work projects you might have done in the said technology.
Even if there are other people using the said projects.
Speaking as a hiring manager this feels perfectly reasonable so I'd be interested to know why people might think it isn't.
I write a job spec which lists what we're looking for which is advertised and passed to recruiters - if you're interested in the job you've almost certainly seen that.
Assuming you do have the experience, using the spec you should be able to tweak your CV in about 5 minutes to highlight the key things we're looking for. If you do that, you've cleared this (very low) bar with a very small time investment and it's not a problem. If your CV makes it past the recruiter (or HR department or other non-technical screener) I then know that the CV I'm looking at is worth my time and the following interview is more focused as I know a bit more about what you've done where.
Yes you are having to spend time but, as I say, this should be a very short tweak to your existing CV so it doesn't feel like a big ask given that I'm going to spend longer than that reading it (and hopefully interviewing you about it).
Obviously if there is no job spec then this doesn't work so well but there's usually something, even if it's just stuff you've gleaned from the advert or conversations with the person you learned about the role from.
As an aside, please don't ever try to get round the keyword thing by listing everything you've done or used. I had a CV the other week which listed 43 skills, tools and technologies for one nine month role. From that I have no way of knowing what you used in passing and what you really know - you've provided so much information it just became noise. My rule when I'm working out what to put - if you put it on your CV you'd better feel happy answering (proper) questions about it and I don't believe that you passed that threshold with 43 things in a nine month period.
There's one very simple reason that this strategy fails: good developers can and do learn new technologies quickly. It's far more important to find someone willing and able to learn than someone who can copy and paste a few keywords.
But it doesn't fail. I've been recruiting solid teams who deliver software for a decade now.
The right current skills and the ability to learn future skills aren't incompatible. After all, how do you think those people got those current skills? I don't have to choose one or the other and I've rarely met anyone in IT who isn't willing to learn new skills.
Generally I have two or three core skills I'm looking for for a role for and the rest are nice to have. To me it's a given you'll basically be smart and that you'll need to learn stuff but I also know from experience I can get smart people who have a core set of knowledge which will make them productive early on.
I certainly have no interest in someone who can copy and paste keywords and if that's all you'd done you won't get past first interview. All I'm asking is that you present your experience in a way which is most relevant to me to help me understand.
I imagine Kernighan, Ritchie, or Dijkstra talking to an HR drone. They say, "I see from your resume you have a lot of experience with C and C++, but we're really looking for someone with more recent $MAGIC_KEYWORD experience."
The legend laughs, says "thank you," and then hangs up the phone. Meanwhile, everyone behind the HR firewall that has actually earned a CS degree is blissfully unaware of the sheer magnitude of idiocy that one sentence represents.
The image is hyperbole, but that is a fraction of what you might be doing when you focus on specific experience rather than aptitude and adaptability. What you are looking for is someone who can solve complex problems by reducing them to smaller sub-problems that can be automated. Anyone with a knowledge of how computers operate can use any higher-level language to perform the actual automation. Focusing on candidates who already advertise specific skill keywords will save you, at most, a few days, as the new hire acclimates to new syntax and keywords.
If your business involves spatial positioning, for instance, it is far more useful to learn whether the candidate knows the difference between 4x4 matrices and quaternions, or between geodesic and geodetic coordinates, than it is to know whether they can describe the math in Lisp or C# or Javascript or reverse polish notation.
Your initial bozo filter should undoubtedly be a simple trapdoor function that takes candidates several minutes to solve, but takes you (or a less qualified underling) only seconds to verify. Then, if they pass it, make a more concerted effort to determine whether the developer is a match for your team's development style, without resorting to keyword-based prejudices, or relying upon people with little or no technical capacity to filter your candidates.
Unfortunately, it's not. I recently heard about a conversation DHH had with a recruiter, who asked him how many years of experience he had with RoR. His answer: "all of it."
Yes, my last job search consisted of posting my resume on one and only one job board. I then received a deluge of phone calls and multiple job offers soon after that.
In the end if you’re depending on people reading a job posting you’re already missing out on a lot of highly qualified applicants. If you then want tailored resumes your mostly excluding the type of people you actually want working for you.
PS: And no I will not show up to an interview if you don't list a salary range.
CVs posted to job boards (in the UK at least) aren't looked at by companies but by agencies. Those agencies call you and do all the pre-screening (and CV tweaking) before they send the CVs to people like me.
When I've looked for a job I'll always say to the agent I'll tweak my CV myself because I'd rather I did it than them (I've seen some horribly butchered ones come through - in those cases I can normally tell it was the agency and don't hold it against the candidate but sometimes that may not be the case).
Essentially I suspect everything I asked for happened with you, it just may not have been done by you.
Salary I totally agree on - I post a salary range for the role (usually a range but also dependent on experience) and want to know candidate salary expectations before hand. If we're not happy with what the candidate is looking for based on what their rough level of experience I wouldn't interview.
I'd love to have my resume show that I have successfully automated work for other software developers, small business owners, photojournalists, hospital physicians and nurses, corporate attorneys, military pilots, and rocket scientists, and that all of it was done in a manner that is largely invisible to the beneficiaries. Throwing a bunch of keywords tailored to a specific job ad is completely pointless, from my perspective. I have successfully learned the work of several different skilled professionals and reduced large portions of that work to computer programs.
What you ask, and is mirrored at hundreds of other companies, is roughly analogous to someone in the construction trade building residential homes, commercial office space, retail buildings, and municipal buildings over the course of their career, and then having someone suggest that they ought to list "hammer" and "screwdriver" on their resume. Never mind if the person actually uses pneumatic nail guns and power drills for the nails and screws, the magic keywords are "hammer" and "screwdriver". Never mind if the person is actually smart enough to be a general contractor and halfway to being a civil engineer. If that resume doesn't say "hammer" on it, he doesn't get called back.
What you are asking is irrelevant, gratuitous, and counterproductive--thus, hoops to jump through. My skills are not Java and C#. My skill is making other skilled workers more productive, by any means necessary--though usually with the help of a computer. Part of that is recognizing that when thousands of people are each wasting their time on unnecessary steps every time they perform a task that may be repeated several times every day, the situation may be improved dramatically by eliminating that waste.
There are several potential solutions. One is to tell you, and everyone else in a similar position, that your expectations are ignorant and counterproductive, and show a cavalier lack of respect toward potential hires. You are asking that they invest five minutes of time specifically into your company, rather than into their own general job search, just so that you will not arbitrarily toss their application into the trash. This is in addition to the 20-60 minutes the typical HR gatekeeper already requires to re-type every single datum from that resume into a non-portable custom form in their candidate tracking system.
If I'm going to spend even more time on your company, I'd like the potential return to be worth the effort. Until you actually talk to me, I won't know that. And as long as we're talking, we can just skip the resume and spend that extra five minutes on the way to "yes", instead of just evading "no".
Speaking as a developer, why do you feel it's reasonable to disregard side projects? If, say, I claim LLVM knowledge based on a publicly available language developed on my spare time, why shouldn't be taken into account in the recruiting process?
I don't disregard them completely and I think CVs can be written in such a way that recruiters (who actually get very excited about such stuff these days) and HR people will be fine with this sort of thing.
What I would say is that there is a difference between hobby code where you get to do what you want and code where you didn't control requirements and had to deliver to unreasonable people in unreasonable timeframes (aka commercial software development). Obviously it would depend on the projects but generally someone who has commercial experience would probably be viewed more favourably as it's more directly comparable to what I need you to do.
All that said, I deal in corporate style CRUD apps (there is a bit more to it that that but that's the core). That's an area where OSS - the best sort of out of work project as it's team based, real world and so on - isn't that active so it's not a consideration I have to make too often.
>What I would say is that there is a difference between hobby code where you get to do what you want and code where you didn't control requirements and had to deliver to unreasonable people in unreasonable timeframes (aka commercial software development). Obviously it would depend on the projects but generally someone who has commercial experience would probably be viewed more favourably as it's more directly comparable to what I need you to do.
Yeah, the difference is that hobby code means that you can take the time to do it right and "commercial contexts" (aka coding in a rush) means that you can't so you never learn how to do it properly.
I do agree with you RE: hobby code. I did a jQuery Facebook app for fun, but the one-off weather app I built for a major utility company was and should have been way more impressive even though I did the hobby project after the weather app with all the lessons I'd learned about Javascript from the one I got paid for.
Ultimately this is why I don't take any of my side projects seriously anymore, and if there's something I want to learn, I'll find a way to get paid for it. That way I can figure out where it fits in the ecosystem of working with other professionals to deliver production code that fits specs and actual business needs. I still have side projects, I just use them to scratch an itch rather than to try to conjure something truly useful to someone out of thin air.
That doesn't work in the real world for most people. At my Day Job, I use Language X with version Y for everything. I use Library Z and T only. Oh, and I can use ancient language B as well but I cannot use any 3rd party code with B. You will use version control method G.
Any attempt to deviate from that is not permitted because it leads to compatibility issues with the rest of the codebase & it reduces the ability of other programmers to work efficiently on it.
I suspect many programmers operate under similar restrictions.
I mean, if your job comprises only tasks and no responsibility, then your job then is to either demonstrate enough value so as to convincingly ask for responsibilities or hop around until you find someone that will give you the latitude you need.
I've worked three jobs in the last year where I had a lot of flexibility in this regard. And I enjoyed it when I was freelancing too. The world's a lot bigger than the little bit of it you're seeing now. Get out there and see some of it.
> I mean, if your job comprises only tasks and no responsibility, then your job then is to either demonstrate enough value so as to convincingly ask for responsibilities or hop around until you find someone that will give you the latitude you need.
> I've worked three jobs in the last year where I had a lot of flexibility in this regard. And I enjoyed it when I was freelancing too. The world's a lot bigger than the little bit of it you're seeing now. Get out there and see some of it.
Ah, the patronizing tone of someone without a clue. Some of us enjoy working on large, important things that need standards. I'm responsible for millions of dollars of revenue and financial transactions. That means I'm going to be conservative 'cause, y'know, money.
Many, many people work in situations like that.
The majority of programmers aren't web developers with one-off projects they mostly do by themselves.
Did I say a career goal? No? Maybe y'know, you shouldn't put words in people's mouths and actually read what was written.
I'm telling you the way you value/put things is specific to you and a smaller percentage of the programmer population than you imply. It works for web developers working on small projects. It doesn't work in larger team environments where having 90% of the developers needing to learn X to maintain the project is a noticeable impact.
> Ultimately this is why I don't take any of my side projects seriously anymore, and if there's something I want to learn, I'll find a way to get paid for it.
Side projects should be taken seriously because people aren't going to rearrange their careers to scratch itches like "I want to see if I like Django better than RoR".
If that falls under the category of "career goal" for you, we honestly should stop talking to each other because we operate on two very different levels. We are never going to agree.
The problem becomes when you [like the OP] try to apply your limited world view as a universal truth.
One of my side projects that I run for fun and setup in a couple weekends generates thousands of dollars a year which I then reinvest into my side projects to amuse myself. It is a hobby that pays for all of my computer-related hobbies. So when people like you and the OP dismiss them, I'm amused because I realize I can't take either of you seriously. You don't consider the possibility that you are wrong when told you are mistaken but instead resort to claiming I don't know what I'm talking about.
I know another developer whose side project generates non-negligible revenues and consulting gigs.
So when you said can't take your side projects seriously to reinforce the OP's point, you reinforce this idea that side projects should not be taken seriously.
> Side projects should be taken seriously because people aren't going to rearrange their careers to scratch itches like "I want to see if I like Django better than RoR".
If that falls under the category of "career goal" for you, we honestly should stop talking to each other because we operate on two very different levels. We are never going to agree.
I guess you're right, we're never going to agree. The choice of platform to specialize in is in my opinion a very very important career decision you have to make, because the switching costs are greater than we're going to see. Platform familiarity has bought me 90% of the flexibility I have at my job. I got to be that familiar because I happen to really like Rails. I got to learn Rails because I got someone to pay me to learn it.
At one point, a career goal of mine was to "get paid full time to work with Rails." Now that I've achieved that goal, I have bigger and better ones. I don't know what level you are operating at, but my new goals involve putting together a cohesive team that can knock out projects really fast, followed by starting a company with the experience gained from accomplishing the former.
> One of my side projects that I run for fun and setup in a couple weekends generates thousands of dollars a year...
Thousands a year? I just don't get spending that kind of time for that little of a return. I'd rather roll that effort into being a better coder and the best way I've seen to do that is to work on projects bigger than yourself, that bring lots of people with different talents in to build something that much more interesting and viable. If I just wanted a few thousand more, I'd ask for a raise. Just because it's non-negligible doesn't mean it's worth my time.
So you make over $200k a year AND have fun doing it?
I'm just asking because that is the only way your comment makes sense. If not, I suggest you re-read.
> At one point, a career goal of mine was to "get paid full time to work with Rails." Now that I've achieved that goal, I have bigger and better ones. I don't know what level you are operating at, but my new goals involve putting together a cohesive team that can knock out projects really fast, followed by starting a company with the experience gained from accomplishing the former.
I wish you the best of luck with your goals, for whatever that is worth. I don't mean any of this personally...I just think the view you and the OP take is far too narrow.
The reason I said "different level" is our goals are so completely different as to be incomparable from an objective viewpoint.
Say it's something like Angular, I'll just use it on my next front-end project. When I wanted a better provisioning scheme, I built it for my employer. I sold my boss on the benefits of automated provisioning, and created a system for doing it. When I started reading object-oriented design literature, I immediately started implementing it in my next project. I didn't even need buy-in because they don't and can't see anything but the fact that everything is more flexible and modular.
When I wanted to learn how to do TDD, I first sold it to my boss, and when he saw how powerful an idea it is, said to go all in with it. I got him to buy a book and the Destroy All Software screencasts.
Basically, whatever the business you work for needs, find a way to deliver it in a way that scratches your learning itch.
Side projects for me have been relegated to just exploring new domains, with technologies I already know well. When I'm having fun on the weekend, I don't want to get hung up on high-friction, high-buy-in paradigm shifting. I just want to have fun and focus on gathering insight.
What I get out of that first statement is that you do tend to disregard unless the candidate knows exactly how to describe the related subjects on their CV in a way that makes you happy. And you don't see the problem that developers might have with that? Especially when they don't know the secret method of describing things to make recruiters happy?
As for the rest, I think it's reasonable to assume that a candidate with commercial experience will favor over hobby experience. I'm sure there are plenty of examples of where that doesn't hold true, but I suppose it's a decent rule.
The GP is giving helpful advice here. It takes stages to get to the people who will have some idea if your side project is really something or a bit of fluff.
Recruiters don't have the experience to know, so it is your job to help them out with your CV. They are looking at many applicants and can't research them in depth and get through the stack at the same time.
I believe this is essentially true for hiring managers as well, although they will probably be able to tell fluff from something interesting, they won't have the time to do it. And it will reflect poorly on you if you aren't willing to work your CV for relevance to the job.
When you get through those gates to a peer interview, you can talk up your side projects all you want, and these are the people who might look at it and incorporate it in their decision making.
It is helpful advice, to get a job from that recruiter. But what I'm saying is that this is an example of the games that job seekers have to play with different recruiters that have their own methods and agendas. It's also possibly a difference between Europe and United States hiring methods, which could be a misunderstanding on my part.
But you've mentioned part of the problem, "Recruiters don't have the experience to know", therefore there is an issue with some recruiters being the gatekeepers. Especially when they state things that imply if you didn't explain things in the magic way that they want to read it then they'll pass on your resume. That's my issue. It's one thing to say "please phrase your experience in simple terms for a non-technical person might be able to understand and can easily use as a basis for research" as opposed to "write it the way I like it or I may disregard". It's not as bad as the guy who throws out resumes stating he doesn't hire unlucky people, but it is a problem.
After all, if someone writes that they have AngularJS experience and the recruiter can't be bothered to think "I don't know what that is, maybe I should look on Google" then there's a problem. I'm not saying that the recruiter in this thread is that person, but does seem to have something close to that mindset.
Which, I feel the need to point out, I've personally never had a bad experience with a recruiter nor hiring manager. I'm not sure if that means that this problem that crops up quite frequently in the community is not that big a deal as it seems or I'm just lucky. I've also been on the hiring side of the table. It's just my personal experience and it may or may not mean anything to the discussion.
There is nothing magic about it. It's common sense. You first make it through a basic keyword search, then someone sifts through those results for basic relevancy, then you get an interview.
You are the one seeking something here, lost in a pile of other seekers. Why wouldn't you do everything you could to make it easy for the person looking at your CV to pass it on to the next stage of vetting.
Why would someone bother googling some obscure reference on your resume when they have dozens or hundreds of others that fit the bill? The key is learning what it takes, in general, to get to the next stage. While there are always horror stories about oddball reasons for not getting selected, they aren't the norm.
Understand the job you are going for, understand the expertise and expectations at the different stages, and you'll do fine. It is basically a numbers game at that point.
Basing selection heavily on keywords when the gatekeeper doesn't understand the keywords is a problem. That is the problem I'm referring to. I don't know how else to explain this.
I don't disagree with you that using proper keywords is common sense. I'm not complaining about that in any way. But, as it has been pointed out in many places, stuffing your resume with keywords is a bad idea. So, I simply cannot list off every single little thing I know, I have to cull it down somehow. If I didn't find the magic pattern required for the gatekeeper when choosing my keywords then my resume gets passed over. For example, if a developer specializes in AngularJS, among many other things, then they are likely to list that and leaving off Javascript. It's only common sense because AngularJS IS Javascript. Remember, too many keywords is bad. What if that developer happens to specialize in multiple Javascript frameworks? Remember, too many keywords is bad. If the gatekeeper doesn't understand that AngularJS is Javascript, but fails to see the Javascript keyword then they may disregard. That's a simple example but could easily be understood to be possible.
Another example, how many times has a recruiter mistaken Java and Javascript as the same thing? To me, that's a problem that potentially keeps good candidates from being matched to jobs they are good matches for. Good candidates that the hiring manager never even knows about.
I think it's OTT describing it as a secret. If a job spec lists a skill, highlight where you've used it so I can see your experience. That's not difficult or counter intuitive or unreasonable.
Realistically I can't interview everyone and it wouldn't be in anyone's interest to do so. The current stats I have say I will first interview one in four screened CVs. Out of those about one in three will get a second interview and half of those an offer. So I interview maybe half a dozen people per appointment from about 25 CVs).
That means right now if you give up an hour of your time for a first interview (plus travel and so on), you've got a one in six chance of getting a job. If I interviewed more people, your chances go down. I may end up with a better recruit but I'm actually externalising a lot of the costs to the other candidates who don't get the role.
As for interviewing people after the first selection round based off of resumes; that's a totally different situation and I can't say I disagree with your viewpoint.
> What I would say is that there is a difference between hobby code where you get to do what you want and code where you didn't control requirements and had to deliver to unreasonable people in unreasonable timeframes (aka commercial software development). Obviously it would depend on the projects but generally someone who has commercial experience would probably be viewed more favourably as it's more directly comparable to what I need you to do.
1) If I can write a backend integration for some well known property (say, Amazon) as a hobby in Language X.
2) If I can show I can write backend integrations for some well known standard (say, EDI) in Language Y at my Day Job.
The idea I could write a backend integration for some API in Language X at a new job in situations where I don't control the requirements, etc. is quite reasonable.
"Commercial experience" is really managing expectations and timelines to make it clear what you can/cannot do. It doesn't magically make the choice of X vs. Y a significant difference if you are experienced enough in both to produce functional projects. Tbh, I'd be more worried about domain knowledge (How well does the programmer understand accounting?) than I would be about whether the programming language is X or Y is the one they use at their day job.
The quality of code isn't going to massively change because a different language is used. You aren't going to know the quality of code from their Day Job anyway, for all you know its unsustainable crap and they are trying to bail before their boss realizes it. At least with a hobby project you can check the basic boxes like "Does this person like OOP vs. functional programming?".
The most that would change is how often the Dev would need to refer to the documentation and honestly, for anything that matters, that is going to happen alot anyway since no one wants to write something moving 5-6 figures a day worth of product without double checking everything first.
If you aren't building something that handles that kind of value, the bar makes even less sense since you aren't worried about them screwing up language specific edge cases that might cost you more than their paycheck if it goes unnoticed for an hour.
If anything, it seems to me this is testing for the absolute opposite of what you'd want to test for. Sure, it'll work if the other measures are good...but communication ability + domain knowledge + ability to write code in Language X is what is required. Caring about whether or not Language X is or is not a hobby language...isn't testing for anything relevant to the job if they've had programming jobs before.
spoiler: he advises to just put the keywords, to please every layer in the hiring process.
This is a quite conservative document: your CV is a little piece of shit in the stack, people have better stuff to do than read your freaking CV, you stupid millennial, they hate recruiting and they are absolutely not willing to spend any time on it, and there are millions other people waiting for your job, so you'd better get in the freaking line before they retract the privilege they gave you by accepting your CV in their stack. And the lowest salary in the team does the actual interviews, because I told you I have better things to do.
I'd be terrified of anywhere that didn't put their best people forward for interviews. Two reasons:
1) Hiring someone is a big deal. You want the people best placed to judge whether they're right involved.
2) You're selling the company to someone who may/will have other choices. Put the people forward who are going to do the best job of that.
Point 2 is important. I have no interest in candidates who do the whole "you'll make all the effort and bend over backwards because I'm in demand". Similarly I have no time for companies who demand days of preparation before interview as if I have no other options and they're the only game in town. In almost all cases the person isn't good enough to put up with that attitude and the company isn't the only place the person might consider working.
Jobs are a coming together of two interested parties and both sides need to show respect and be fair and reasonable. As a result if I'm recruiting then beyond a slightly tailored CV and some basic research into what we do (and maybe the technologies we use if you don't know them) I don't expect preparation. In exchange I'm going to spend time telling you about the role, the company and the project, I'm going to answer questions and I'm going to be as honest as I can be to make sure you can make a good decision.
Wait, the developers are the most important? Then why is the initial filtering done by someone else? Why does the hiring manager have no time to waste on hiring? When it's time to do some real work that take time and discernent, it's the developers who do it.
'sounds familiar?
Showing respect is not having someone who have no clue in JS libraries filtering CVs for JS positions, certainly not. They'll settle for famous education places. The candidate write without too many typos and show proper development skills and the hiring chain show proper hiring skills and get the hiring process as least stupid as possible. That's what I would call respect from both parties.
Having a clueless HR person initially filtering the CVs for keywords in 15s is not showing respect. They'll have their role later, in managing the vacations, doing the pay stubs, calling some previous places for feedback, bugging the newly hired with red tape and managing the retirement plan, places where they make a difference.
1) Like all things it's a balance. Developers are valuable resources and I'm not going to dump 100 CVs on them when I can reduce that number. Aside from anything else they'd hate me if I did but also I can reduce that number without significantly reducing the quality.
2) In many cases these aren't HR generalists, they're recruitment professionals. They know about whether people are eligible to work, they know about qualifications, they can spot odd patterns and gaps in CVs and they can spot a well written CV.
You mock spotting typos but how interested should I be in someone who sent out a professional document to someone they were trying to impress and didn't proof read it? How serious are they about the job? Are they going to send the same sort of thing out to my customers? Maybe it's just me but while it wouldn't exclude them outright for this, it raises alarm bells.
3) You can define basic rules which allow someone relatively non-technical to filter out complete time wasters. If a candidate hasn't listed JavaScript in any of their roles and I've asked for commercial JavaScript experience then I can reasonably conclude (1) they don't have it, (2) they do but not enough to warrant listing it (which is effectively 1) or (3) either they are an idiot or their communication skills suck because despite knowing it was relevant they didn't mention JavaScript when applying for the job. Whichever it is of those I don't think I need to waste a developer's time having them look at the CV - maybe they do have those skills and a developer could work that out but I could probably find someone who knew JavaScript who didn't also have the questionable decision making skills that led them not to mentioned it.
Let's be clear, this isn't a stage where people making difficult, detailed decisions requiring specialist skills. This clearing what should be a relatively low bar to create a long list where those with real skills will get involved.
I guess it might depend on the industry, but at most interviews I have done, the expectation has been to just wear jeans and whatever. I usually go with jeans and a polo shirt for safety.
It really depends on the place. If there's a recruiter involved, ask them. Otherwise, (the following is based on my experience in the US, YMMV, etc), if they're not a software company, or are a defense contractor or similar, probably safest to go with a suit. If they are a software company, business casual is probably fine. If they're a startup, jeans and a t-shirt is probably fine. If you're uncertain, consider dressing up slightly; i.e., you think jeans and a t-shirt is fine but aren't sure; go with khakis and a polo. You think business casual is okay but aren't sure, go with a dress shirt and slacks.
In general the commentary along the lines of "would you want to work there if they judged you on your clothes?" is probably true, however it misses a major point. In many roles, roles you may even enjoy, you will interact with executives or with customers, at some level. Even if that doesn't entail dressing up (and oftentimes it won't), being able to show that you can exude professionalism during the interview shows that you can do it in such a situation, and it's generally easier to do that when dressed nicely (though balance it against the discomfort of wearing something you're unaccustomed to).
I don't have all these different kinds of clothing. (And no I don't want to own them either).
Am I the only one who thinks this game should be played the other way around?
If a company needs my services, they should impress me. I am not a model and I am sure as hell not a wage slave. I don't do CVs, and I sure as hell don't talk to HR. I am performing a necessary duty, if I can fill my role then my other traits will be catered for.
From my experience some basic self respect ensures you only end up with good jobs. The positions you have to bend for are not worth bending for imho.
That attitude is a bit arrogant, and will only serve you well as long as potential employers have little alternative but to put up with it.
But it is still less arrogant by far than the attitude of most employers with open positions that I have encountered.
The "game" should be played with equal respect offered by both sides. Both parties are vetting the other before entering into a potentially long-term relationship. It is not the time to play stupid dominance games. I expect that equal effort should be expended on trying to convince me to work there as is spent trying to ascertain whether I am qualified to do so. If I spend a full day of my time jumping through hoops, I expect to see the company sacrificing a significant effort in exchange, trying to convince me to work there.
If you hear even an inkling of a suggestion that the company is trying to "avoid wasting interviewers' time," just say, "thank you for this, but I wouldn't want any more of anyone's time to be wasted," exit as gracefully as possible, and cross that company off your list. Then do the rest of us a favor, and post a negative review of the interview. Time spent on recruiting is an investment that might not pay off, never a waste. And nobody involved should be disrespectful of the other's time or preferences.
I thought interviewing was a negotiation, you trying to get the best deal, them trying to convince you to work for peanuts. You meet in the middle, or you both walk away.
All the talk of respect and time wasting and efficiency is missing the point. Arrogance is a tactic and if it works for you at your level, then more power to you.
When I'm on either side of the desk, I don't assume that it is the employers job to get a candidate to work for peanuts. The marginal cost difference between what a good candidate is worth to me, and what I can effectively negotiate is tiny in comparison to getting the candidates I want.
That is, it is much more expensive for me to get the wrong candidate, than to pay a little too much for a good one.
But do you offer what they're worth? Or do you have some plausible equation of position and experience. Then you tell the candidate about pay ranges and bonuses etc. Then you pretend to haggle over a 1% bump and some one-time perks.
If we're being honest, early Engineers on a project can create millions in wealth for the investors. That they're paid a few percent of that is where the 'peanuts' come in. It all seems reasonable the way its laid out.
As a consultant, I charged many times what I'd earn as an employee. And they paid - because they were in a tight spot, and the only way to get the job done was to pay what it was worth. And that's arguably what their own Engineers are worth too, but have been negotiated down from.
That really depends on the hiring environment you are working in. Right now, in most of the tech centers around, it is an employees market. This is not always true and it can be different for different tech centers, technologies, and employees.
So sure, while this is working for you right now, keep it in mind in the future when this bubble bursts.
I do find it interesting that an adult with professional career in the western world doesn't own at least 1 set of "professional" clothes. What do you wear to weddings and funerals?
I didn't say I don't own professional clothes. For me its a shirt--the ones you iron--a suit jacket and jeans, no tie.
It's just that I am not willing to compromise on my interpretation of "business attire". I consider it quite offensive to openly criticize based on looks. If anybody would consider my jeans unfitting then that's their problem as I have a very good reason to wear jeans (exclusively). I wear clothes because I like them and I consider them fitting.
On weddings and funerals: Depends on the wedding or funeral, chances are I wont be going to "suit-weddings" and on funerals I reckon the dead person respected me well enough to trust my choice of attire.
> So sure, while this is working for you right now, keep it in mind in the future when this bubble bursts.
I am not in a bubble. :) I have chosen a profession which is unlikely to die off very soon, I invested a lot into being good in my profession and when my industry is no longer my market then I am in the wrong industry.
Edit: For context, I am not an employee, I am a consultant. I don't have a boss, I only have customers. I was an employee before and I didn't like it.
This is just my opinion, but I think every guy should own a suit. Sometimes you want to class it up for various reasons, whether to show respect, or indicate status. When I'm giving a presentation at work, I class up my look a little bit, and I think it helps people take me more seriously.
Especially when you look like you're not even old enough to buy a beer. The apparent age difference of me wearing an untucked polo with jeans and me wearing a decent suit replete with nice dress shirt and classy belt is quite interesting.
I work at a very casual office, when I've interviewed I've seen just about everything from jeans/t-shirt to a suit. My take away is "look nice" regardless of what level of dress you have chosen. I've been impressed by candidates that wore suits. It shows they understand their appearance is important, however, it is not a deciding factor in the job, just a nice to have. Also had people show up in a suit that is 10 years out of style or with hideous tie,etc. They would have been far better off to come in khakis and a polo.
Here are my basic rules on Interview dressing:
1 When in doubt, wear a suit. For all lifes clothing decisions, better to be over, than under dressed
2 Ask a recruiter whats appropriate, if you are dealing with one.
3 Whatever you wear, make sure it looks nice (no stains, ironed, fits well,etc)
How someone is dressed is a very small part of hiring (in the tech world, less so for other professions), but it does speak to attention to detail, and how they see themselves. Given two equally skilled candidates the one who presents themselves best (attire wise) is going to get the nod.
Actually, I don't care...but for me what it speaks to is self-awareness. Many developers get caught up in their own little world. If they can't be bothered to think about how others perceive them it also points to all kinds of other things they neglect to consider.
This is RTFM for life type stuff. Seriously its two seconds to google for "rules of the interview" or some other such thing. Do you know any Good devs who wouldn't reference the docs for an api they are working on? Same type of thing, read the docs goes along way with a lot of things.
Its not a deal breaker, but when you have limited time in which to evaluate someone you learn to have lots of little things add up to a picture of someone. That's what I mean by that.
It's likely that at some point in your career you will have to interact with clients or present in front of an outside audience. What you wear and how you present yourself reflects on your company.
So, let me make sure I'm understanding what you're saying, here. You would reject a candidate for a software developer position (or any other mostly "back end" role) because that person may or may not some day end up making a presentation to people outside of the company?
Are you sure you don't want to take a bit of time and rethink that?
I will slightly adjust that to - it depends on the company (do your research). Clearly if you are applying for a startup of early 20 somethings a suit makes zero sense (but then there is less doubt, no?)
I really don't think so. If you went to a first interview in a suit and everyone were dressed extremely casually (flip-flop casually) and then you dressed the same for a second interview, definitely questions might be asked. But on the whole in the UK I would say it's pretty common to dress smartly for a first interview unless you have specific information (eg. from a recruiter or hiring manager) that you should not do that.
If I were interviewing in finance, I would definitely wear a suit. If I were interviewing at a startup or a digital agency, or equivalent, I would wear smart trousers (maybe smart jeans) and a shirt. That's playing it safe. Sometimes I interview people who are wearing jeans and a t-shirt and generally look pretty scruffy - I know that they know that that is probably the attire most of their potential future colleagues will be wearing, but it certainly doesn't impress me much. But maybe I'm just old-fashioned.
I thought there was a lot of good advice in those slides, incidentally.
Absolutely right. If I turned up to a job interview in a suit and everyone else was in beach attire, I'd absolutely ask about the dress code and make a joke about my own attire.
I always wear shirt and tie to the interview then ask about dress code as if they expect me to sit there developing suited and booted I'm not the guy for the job!
Yes, they do, and I've seen it once or twice on here from blog posts from company leads/founders talking about their applicants. I don't have it handy, because I don't bookmark that sort of thing, but they believed that you could overdress.
They're simply looking for someone who doesn't dress up because they believe that will indicate someone that they'd want to hire. You, as the applicant, may not be aware of this because there's often incomplete information on both sides of the table (that's what the interview is for). You can always ask indirectly, stop by their place and peek through the windows, or research this information yourself, like looking at company photos. Or you can just do what I do and dress up anyway because someone who believes that dressing up is a negative mark is probably not compatible with me.
> Another quick story before I really dive into this blog post. We had a gentleman over to interview for one of our account executive positions at 42Floors. He had strong experience leasing SF office space: great resume, great cover letter, did well in our initial phone screen.
> When he walked in the door, we could hear the clacking of his shoes on our hardwood floor. He was dressed impeccably in a suit that probably cost more than my first car and was carrying one of those leathery-thingys that seemed to exist only for the purpose of being carried during interviews.
> I stole a glance to a few of the people from my team who had looked up when he walked in. I could sense the disappointment.
> We’re all happily wearing blue jeans and sneakers. It’s not that we’re so petty or strict about the dress code that we are going to disqualify him for not following an unwritten rule, but we know empirically that people who come in dressed in suits rarely work out well for our team.
> He was failing the go-out-for-a-beer test and he didn’t even know it.
No, but if one wears an ill-fitting suit, and or is visibly uncomfortable because of their clothing; that could negatively affect an interviewer's perception of a candidate.
If you didn't tell the applicant ahead of time not to wear a suit, it was your fault he wore one. Being dressed in a suit is the standard in the professional world. Just because you (and I) work in an environment that doesn't conform to that, doesn't make the applicants judgement suspect, it makes our worldview skewed and we should be prepared for that. Further, it is common courtesy to tell an applicant not to bother with a suit, just in case it is in the back of their closet gathering dust...
In the UK, I went for a Perl programmer job interview a few years ago in a suit and was told I was overdressed. I then went back to the same company for another interview a couple of years later, in jeans and a polo-shirt and nobody said anything, but I was looked up and down and it was pretty clear to me I was underdressed that time.
I wasn't offered either of the positions. No idea if the way I dressed had any bearing on it.
Example: UK and Nordic business dress codes are miles apart. In the UK every traveling sales person wears a suit. It's especially obvious when we have internal meetings where they dress up for work and can't wait to switch to casual before we go to a restaurant. Meanwhile the swedes all wear jeans to the meeting and dress as smart as possiblr for the restaurant.
For interviews I'd always just dress smart but not wear a suit unless I believe there will be at least one more person in the office wearing a suit. Dress for confidence. Being overdressed and uncomfortable (if you aren't used to wearing suits) isn't a confidence booster. Just be clean and at least as smart looking as the person interviewing.
I think it's more of an industry thing, I've worked in the UK in the games industry and dressing up was definitely not needed.
I actually dressed up once for an interview with Peter Molyneux and the first thing he said before even shaking hands was "oh, you dressed up" with a very confused face.
"Your CV should be about three pages" - I had always been told, keep your CV to two pages, so you can print it on one sheet of paper (both sides).
I like it as it ties back into the main message of these slides: "reading CVs is a chore" so keeping it condensed helps me to focus with showing only the most valuable information.
It's not necessarily bad advice. Brevity is appreciated in all things -- especially by an HR worker or hiring manager, who has to sift through a stack of 300 resumes in a week or so. But it's not a hard-and-fast rule. Also, the one-page advice originated on the non-technical side of the job market. Technical resumes are usually longer than non-technical resumes.
Three pages is pushing it, though, unless you've been around for more than 10 years, or if you have something unique about your history that doesn't quite fit into your Experience section. If you've been granted 20 patents, or if you've been published 20 times in the Harvard Business Review, then by all means, include a section on these things. (But only if you feel they're relevant).
Probably outdated - for my first job search, a recruiter shopped around a beefed up version of my resume that spanned two pages instead of the one I had it. I was surprised that the old adage was not used in practice.
It really depends where you live. In the US it seems you list every significant position you ever held. In Western Europe I have always been told the CV should never takes more than one side. I don't know about other continents or culture.
I've always tried to keep mine to one page. But I've been doing some interviewing at my current company recently and all the ones I see are 2-4 pages, so maybe I'm the only one doing that.
That seems the ideal length - first page is a bit more career context, second page is pretty much keyword pounding - a lot of recruiters and corporate HRs use automated keyword analysis (and are skimming over you anyway), I have bullets listing: languages, technologies, specific software packages and skillsets (no matter how "soft"), so once my experience section has hopefully piqued their interest, they can box tick after that.
I have yet to meet an employer that is actually looking for this. Caring about programming only gets in the way of the atrocities my employer needs me to commit to make things work. Now. One of the differences between academia & real life, I guess.
I am a hiring manager. I do want my people to "care" about programming, more specifically I want them to care about the quality of their work. Not all managers in all companies realize the costs incurred by doing garbage work and the follow on consequences. For those that do, it makes sense to have employees that care to do that level of work. If you are constantly committing atrocities, it may be time to seek out employment where you don't have to do that (I admit, that is far easier said than done)
Agreed, to clarify my comment. One will not find that company working at the sucky company they are at. Might as well quietly network/research those companies in an effort to make the jump.
I'm a hiring manager and it's a surprisingly rare but strong signal that someone has a record of contributions or portfolio, especially given how low the barrier to entry is. It's practically an automatic interview given the CVs I've seen and hire if you can talk intelligently and engagingly about what you've worked on.
Then why would you waste space (and interviewer time) by putting it on your CV. The CV is basically your first impression with a company (assuming you aren't coming in through backchannels). Basically everything you put into it should have a purpose.
Well, I put it because I thought it would be relevant, but apparently it wasn't. How could I know beforehand what will not be relevant or interesting to whoever will read my cv?
When I said "nothing interesting", it means that I don't have an open source project people are using, and I am not a massive contributor. However, I have some ELisp code to help me write Python a bit faster, a contribution in the Rust language - I dabbed with Rust once, stumbled into a problem, asked on IRC and they told me "oh, it's a bug, add this one line here and push it" - and couple of other stuff, so while it doesn't make me a top coder, I hope it proves I am someone curious and it would give the interviewer extra stuff to ask ("I see you that played with Rust, what do you think of it?"), just as the presentation said, but sadly that didn't happen.
Am I doing something wrong or is this website horribly non-functional, after 20ish seconds it just goes blank and tries to start loading a new page, if you try and download the slides it just pops up a blank modal.
I encountered the same thing and pasted in the following in the console to disable all timers(1):
// Set a fake timeout to get the highest timeout id
var highestTimeoutId = setTimeout(";");
for (var i = 0 ; i < highestTimeoutId ; i++) {
clearTimeout(i);
}
Ha! I'd never looked at at the value returned from setTimeout to see what it was. Obviously it was going to be some sort of ID but it never occurred to me that it was a simple counter. Neat trick.
I just hit ESC a bunch of times as the page was loading and it seemed to stop the offending code from getting a chance to execute.
Great tip: HR is just matching technical words they don't understand as a filter. They also do this for titles. So they might be looking for a "Project Director" but think you are a poor fit because your last title was "Founder". And for past employers. You may have done marketing at Intel. They will see Intel and think you were an engineer. Etc.
Also, peer interviews are very important and often the least thought through. Try to connect to your potential co-workers. That is where qualified candidate usually stall.
As a former non-IT systems engineer[1] I have this problem frequently. I get pings once a month or so for DevOps and SRE type positions from in-house recruiters or various companies, but never anything for embedded development (which I was actually doing at the time I was called a "systems engineer").
Now that I have more than a couple years if NLP experience the contacts are getting more relevant, though less frequent. Unfortunately, I don't want to make a career out of NLP.
Also, never ever apply through one of the career portals companies setup (taleo and the like).
Having applied for tens of perfectly matching jobs at MS, Google and others through their portals, all I can say is they never call you if you apply through their online resume management system. Taleo etc are a resume blackhole, and once they have your resume in their DB, the third party consultants cannot help you either since your phone number check turns up a duplicate on taleo.
If Satya Nadella were to apply via taleo, he wouldn't even be called.
I can only speak for Google, but I did get an interview for a SEng internship with them after applying online. However, for big companies it's virtually impossible to not find a friend of a friend who works there in order to get a direct introduction.
Recently coming out of a Job search, sending out even the perfect resume won't get the attention of recruiters as much as you physically talking to them or someone from the company. They are much more likely to remember a good person than an excellent resume.
Of course you should make your resume as nice as possible, all I'm advising to job-seekers is that it isn't enough, and it would probably be worth your time socializing rather than making your resume absolutely perfect
I don't know how effective it is to go via a recruiter. But it is indeed effective to talk to a technical person directly and establish a rapport.
For example, if you wanted a job with Amazon and are qualified, I would say send me a mail. Or go to an Amazon show like RE:Invent and show off your programming skills in a boot camp. You will meet Amazon engineers there. Get their cards and send them a resume. There are github repositories where teams from companies like Amazon (AND twitter/fb/google/ms) actively contribute. Go see how you can improve them and submit a pull request. We not only have systems work happening in AWS - there is work in every aspect from web programming to documentation to distribute systems. IMO, it all comes down to initiative.
I have switched about 4 teams now between MS and Amazon and not one of them were via a recruiter. There were extremely talented recruiters who handled the interview logistics, but the jobs themselves happened because people on the ground knew me.
I spent 2.5 years at my first job (effectively moved from junior dev to senior). I then took a job at a traveling consulting company (where I was officially promoted, and ran a huge project), but left after 1 year because I couldn't stand traveling that extensively. Then I moved to my current company, where I've been for 9-10 months, but will likely be fired by the new management team that came in, because I'm part of an overbudget project.
Am I fucked? My current plan is to just wait and see if I am let go or not (probably will be), and then go travel for a few months (I'm burned out). But the very first page of this slideshow is that hiring managers look for red flags about multiple short time roles and employment gaps, and I'll have a 1 year, and a < 1 year on my resume.
No. Write the reason you left the travelling job - that's legit. It's also not your fault if a company makes you redundant.
People want to hire people who will stick around. Leaving a job because you were made redundant, or because of exceptional circumstances (large amounts of travel) don't make you a flight risk - but again, mention the reason right there on the CV so it's obvious.
Probably not. Be honest (to yourself and who you are trying to get hired by) about your skill set and explain why you left those companies. Do NOT bad mouth previous employers.
Thanks for sharing! Lots of great information in here. I've been a hiring manager for a role more than once and I can attest that it's all true. It would be nice if more people made CVs as easy to read as the tips here would produce. I even picked up one or two new ones for my own CV :-).
I'm still debating whether working for a company where the HR people does the initial filtering is worth working for. It's certainly something I was not doing when I was hiring, I was getting my resumes directly.
What's your view on listing multiple positions in the same company?
I've joined a company as a "Software Developer" during my final year in university. When I graduated I got promoted to "Senior Software Developer" but I left a month later to move halfway across the world (my employer knew I'll be leaving soon but chose to promote me anyway). How should I present this on my CV?
I feel like categorising the whole year as "Senior Developer" is bending the truth but splitting it into two takes too much space. Plus my responsibilities didn't really change, only my title did.
As I am currently looking for work, I had to update my resume, but then I decided simple text processor would be just boring and I created themed HTML/PDF resume generator in Python that takes simple YAML data file. It worked pretty good.
There is already JSON Resume [0] initiative but YAML feels much more natural when writing semi-structured text.
I remember an awful confrontation with a first stage HR employee that was particularly nitpicking with my resume while not knowing the difference between Java and javascript. Ha.. keywords.
An awful confrontation is definitely not a way to go. May want to try coaching approach, politely explaining the difference. For all you know, it may have been an intentional filter.
Bottom line though is that it helps you to use the same keywords they are looking for, to the extent you have the relevant experience.
Intentional meaning her toying with me to test my stability ? Any way I failed hard, I was in a bad place and immature. Of course I would do everything differently. Acceptance of the game instead of anger.
Yeah, it's possible - HR should screen for cultural fit and sometimes they may pull a trick or two like that.
I've never toyed with applicants per se, but would occasionally ask them to explain me something that is either very simple or that they know very well, to test for condescension and arrogance. Bottom line is that if someone shows arrogance in an interview, they will likely suck to work with and unlikely to be good mentors to juniors.
It's funny, because I'm rarely arrogant in the workplace, I love sharing, but when I'm denied very simple job offers by someone who doesn't seem to understand what we're talking about it rapidly grind my gears to that sad point.
> If you can't be bothered to dress up a little bit for your interview, the hiring manager knows that you're going to be a pain in the ass to manage.
I wonder how common this sentiment is in the UK. I know that most developers I've met/interviewed/been interviewed by in NYC don't care (at least outside of finance). Can anyone on the other side of the pond give me their thoughts or experiences?
It's true everywhere. Always, ALWAYS wear a suit to your interview, even if the hiring manager says he doesn't care. It presents a crisp, professional appearance and shows the hiring manager that you care.
No. This is horrible advice for software professionals in the US. In a lot of places, it will show the hiring manager that you are an alien to their culture. You should simply wear what you would ordinarily wear to work when clients are expected that day in the office.
If the software professionals there actually wear suits, you can also wear one to interview, but be mindful that you probably won't enjoy working there much.
If on the job you are expected to wear casual or business casual clothing, by all means do so. But only once you have the job. During the application and interview process, making a good impression is paramount. A suit is clothing literally tailor made to make a good impression. I have yet to meet the hiring manager who would dock a candidate for overdressing to the interview, even if overdressing on the job would raise a few eyebrows.
Don't discount his advice about culture, finding people who culturally fit is important and if they are using dress as an indicator you don't want to fail it.
The advice I have heard is to ask the hiring manager. If they say they don't care feel free to wear a suit, however if they say something like "nothing too formal" listen to them.
I agree with this statement, and I'm in the US. My manager wears cargo shorts to the office, but I'd still raise an eyebrow if you wore them to an interview.
The key is to dress up "a little bit".
Wear what would you wear for a "big day" - presenting at a conference, demoing for a customer, or a one-on-one with your boss's boss. Some places, that's a clean t-shirt and your best pair of jeans. If you're fixing healthcare.gov, that might be a suit and tie.
As others have said — a suit is almost never a negative here (provided it's well fitted, clean, etc.). Nobody would be surprised at someone turning up for a interview for even a retail job in a suit. Is it nowadays often unnecessary? Yes. But it's a safe choice, because nobody will claim you're overdressed, and you're not going to be underdressed.
I agree pretty much with these ideas and I actually follow them, still from my dozen or so jobs in the past only one or two came from a "send us your resume" process; the best resume is no resume.
Sorry It was nice and made nice points but it seems like you just want to advertise your own business by offering to rewrite CV's and a link to your site.
Dear young readers. Seriously, don't do that. Waste of space at best. Looks just stupid at worst. It doesn't tell me anything about your ability as a programmer at all. Description about a weekend project is much more useful. And no, clarifying whether someone wants latte with regular or soy milk is not a 'communication skill'.