How to write a developer resume that will get you hired
slideshare.net
slideshare.net
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'.
- 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...
You'd have to ask them why.
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)?
(this was not my case because my first ever internship was through word of mouth)
- Basic info (of course)
- Courses/Certificates
- Voluntary experience
- Personal projects
- Conferences/seminars attended
- Skills (programming languages, etc)
Don't worry if it's half a page, but you may want to increase spacing/font size
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.
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.
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.
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.
This actually happened to me a couple of weeks ago, and I do have JavaScript listed in my languages section...
The HR people literally just do a "Find" for words without reading the rest, and that gets you a phone interview.
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.
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.
This is my CV, I try to be straight to the point and keep it under 2 pages on the word version.
https://www.linkedin.com/in/allandegnan
To be fair the advice is largely still apt.
#1 First step is generally clueless recruiters who'll want you to have 9 years experience with Java 12.
#2 Convince them, your CV goes over. If it has any meat or interesting projects, you'll get called in.
#3 Smile, be likable and be able to talk about $foo at a resonable level and you've got the contract.
If you had a business, would you want to hire someone who is probably going to jump to another job in a few months?
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.)
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.
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.
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.
In case a frequent switching happened, what would you like to see in a resume?
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.
> In case a frequent switching happened, what would you
> like to see in a resume?
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.
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.
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.
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.
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.
Decent challenges, and decent colleagues are included in my definition of market price.
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.
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.
> I think the slides could use some dressing up
> What's the Perl scene like in the UK?
[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.
> "Candidate driven", which means: there's a lot more demand than supply.
Really? Good to know :) I'm a Perl guy, but I'm looking for consultant / freelancing gigs. Do you think it's worth looking to the UK?
I'm a Norwegian citizen, which is basically EU when it comes to working permits etc..
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.)
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.
Am I being a little stuck-up?
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.
I have about 5 years experience now.
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?"
Edit: Grammatical fumbling.
The only place where an educational degree will help in development jobs is probably getting work visas.
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.
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.
They just go top to bottom looking for keywords.
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.
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.
'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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'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'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.
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.
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.
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.
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.
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.
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.
However, it’s unlikely that the best fit is going to have your ideal background and be willing to spend much time jumping through your hoops.
You think that's jumping through hoops?
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.
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".
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."
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.
I wasn't offered either of the positions. No idea if the way I dressed had any bearing on it.
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.
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.
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.
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.
It's come up a few times on HN that some companies do do this. They are widely regarded as completely nuts.
> 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.
http://web.archive.org/web/20140618142018/http://blog.42floo...
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).
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.
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?
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.
I don't know if the smiley is supposed to indicate this comment is a joke, but you must be aware that this comment is a joke, right?
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.
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.
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.
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.
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.
As general advice, this is wrong. There are a lot of positions where wearing a suit to the interview would automatically mean you won't get hired.
Of course, it depends on the locale, the position, &c, but the idea that a suit is always safe is somewhat outdated.
And a sense of fashion is relevant to the job...how, exactly?
Are you sure you don't want to take a bit of time and rethink that?
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.
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.
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).
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.
Shows you actually care about programming
... easier said than done
(mostly in Canada)
// Set a fake timeout to get the highest timeout id
var highestTimeoutId = setTimeout(";");
for (var i = 0 ; i < highestTimeoutId ; i++) {
clearTimeout(i);
}
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.
With AdBlock it's working perfectly.
I also saw requests to LinkedIn going from SlideShare, I wonder why.. https://twitter.com/NicolaeNMV/status/527092523987402752
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.
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.
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.
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
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.
Good luck.
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.
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.
> Am I fucked?
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.
1. Is "too lazy" to deal with visa stuff.
2. Where the recruiter doesn't hire you because you have jQuery and Angular, but no Javascript experience.
3. Doesn't hire people because they didn't wear a suit.
4. Interviewing developers did not prepare for the interview.
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.
There is already JSON Resume [0] initiative but YAML feels much more natural when writing semi-structured text.
Here's the source if anyone's interested: https://github.com/hanula/resume
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.
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.
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?
Looks like if you're in the US, though, you're going to have to be careful to find out first what the code is.
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.
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.
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.
So? Just because the author has a business reason to present this great free content, doesn't make it any less great and free.