4 ms·

So, assuming this is all essentially right from the employers point of view, what can senior developers do to make the selection / hiring process more efficient

by jnxx 5y ago

So, assuming this is all essentially right from the employers point of view, what can senior developers do to make the selection / hiring process more efficient for themselves? The thing is that there are a lot of spammy recruiters as well. And dealing with them costs a lot of time. At least if one does not want to do a shotgun approach to applications, one has to be really selective on where to apply, with very little solid information beforehand. What I can think of: * be selective where to apply * prefer job advertisements on companies web pages, as they give often much more information on the role, than a typical recruiter will give out * do not apply to job descriptions which are not at least a n 80% match with the own qualifications and interests * a job offer is not entirely different from a requirements specification, so a good engineering company should be able to write something quite specific * if one stated requirement is not matched in the application, explain and point to an equivalent qualification (say, no years of experience in Go, but 10+ years experience with each of Java, Python, and Ruby). * as a reasonable coding task should not require preparation by experienced people, do not prepare for them * Interviewers have a reasonable interest to learn about the candidate's skills in programming. But it is hard to measure that with coding interviews, especially since since like architecture and design decisions become much more important for actual senior work. It might be more efficient for the developer to put some personal programming projects on github, and put the URL in the resume - qualified interviewers can then ask about the code and gain insight from the reasoning behind it. And, another question, how should one handle recruiters and interviewers which apparently have not read the resume? Or the ones which ask one to apply even if the specified required qualifications do not really match? (e.g., have never worked extensively on Windows, a lot of experience with embedded C++, but recruiter asks to apply for a C# job?). For HR people it would certainly help them if there were more information about the company, tools, actual tasks, and some words on what the core of business is - and how software relates to that.

josephg 5y ago
I don't think spending so long on the other side of the fence has given me much special wisdom, but the first thing to mention is that, if you don't have a warm lead, you will need to take the time to prove to the company you're applying to that you have actual programming skills. Nobody wants to waste time doing this; but companies have very few reliable signals outside of an interview to differentiate you from someone who's vaguely terrible at programming. And programming job ads get flooded with low value candidates. They can't tell you apart from your resume (people lie) or your github profile (Its easy to clone semi-popular projects to pad out github repos). > be selective where to apply 100%. And talk to your friends and get warm leads when you can. You can learn much more about what its like to work at a company by talking to people who already work there. Go in for lunch. Get a sense of the company culture. If you have skill, everyone is hiring. Ignore the recruiters and choose where you want to work. > do not apply to job descriptions which are not at least a n 80% match with the own qualifications and interests I disagree with this actually. Again, if you're a senior developer with skills, figure out what the company is doing and decide for yourself if you want to be part of that. Technology match matters here; but job ads are pretty uniformly terrible. Nobody knows how to write them well. I certainly don't. > architecture and design decisions become much more important for actual senior work Yes; from the people I interviewed, I found senior developers were competent but still a bit slower than mids at raw programming tasks. (This makes sense, because they often don't do it as much). In comparison, senior devs were much better at debugging problems and at architecture whiteboarding style questions. > And, another question, how should one handle recruiters and interviewers which apparently have not read the resume? The first thing to know about recruiters is they don't work for you, because you don't pay them. The way recruiting should work is like acting - you get a manager (recruiter) who knows your skillset well. They talk to lots of companies and find you a stream of good gigs you like. You pay them $10k for that service, or 2% of your salary or something. But programmers hate paying for this, so instead all the recruiters work for the companies. They get the same cut, but our experience of working with them is awful. I'd avoid most recruiters whenever you can. Use HN's job board and things like that, and skip to talking to the actual team managers and engineers as quickly as possible. Recruiters hunting C++ devs for C# roles is just lazy people being lazy. And who cares if your interviewer has read your resume? Its disrespectful, but it doesn't matter. Roll with it.

by jnxx 5y ago

josephg 5y ago

I don't think spending so long on the other side of the fence has given me much special wisdom, but the first thing to mention is that, if you don't have a warm lead, you will need to take the time to prove to the company you're applying to that you have actual programming skills. Nobody wants to waste time doing this; but companies have very few reliable signals outside of an interview to differentiate you from someone who's vaguely terrible at programming. And programming job ads get flooded with low value candidates. They can't tell you apart from your resume (people lie) or your github profile (Its easy to clone semi-popular projects to pad out github repos). > be selective where to apply 100%. And talk to your friends and get warm leads when you can. You can learn much more about what its like to work at a company by talking to people who already work there. Go in for lunch. Get a sense of the company culture. If you have skill, everyone is hiring. Ignore the recruiters and choose where you want to work. > do not apply to job descriptions which are not at least a n 80% match with the own qualifications and interests I disagree with this actually. Again, if you're a senior developer with skills, figure out what the company is doing and decide for yourself if you want to be part of that. Technology match matters here; but job ads are pretty uniformly terrible. Nobody knows how to write them well. I certainly don't. > architecture and design decisions become much more important for actual senior work Yes; from the people I interviewed, I found senior developers were competent but still a bit slower than mids at raw programming tasks. (This makes sense, because they often don't do it as much). In comparison, senior devs were much better at debugging problems and at architecture whiteboarding style questions. > And, another question, how should one handle recruiters and interviewers which apparently have not read the resume? The first thing to know about recruiters is they don't work for you, because you don't pay them. The way recruiting should work is like acting - you get a manager (recruiter) who knows your skillset well. They talk to lots of companies and find you a stream of good gigs you like. You pay them $10k for that service, or 2% of your salary or something. But programmers hate paying for this, so instead all the recruiters work for the companies. They get the same cut, but our experience of working with them is awful. I'd avoid most recruiters whenever you can. Use HN's job board and things like that, and skip to talking to the actual team managers and engineers as quickly as possible. Recruiters hunting C++ devs for C# roles is just lazy people being lazy. And who cares if your interviewer has read your resume? Its disrespectful, but it doesn't matter. Roll with it.