3 ms·
You are thinking like a founder, you need smart people to solve problems, not a react engineer, or a vue engineer etc. Most job postings are usually created by
by davismwfl 7y ago
You are thinking like a founder, you need smart people to solve problems, not a react engineer, or a vue engineer etc.
Most job postings are usually created by recruiters that get details from the teams on what skills are needed. So the ads read like an ingredient list of sorts.
And like you said, the job ad needs to state what the responsibilities are and should detail the current stack so people know what they are applying for, but that shouldn't be used to exclude quality candidates. I have hired people with no experience in a specific language but by talking to them they were highly competent engineers and I wasn't worried about them picking up a new language.
One of my major disagreements with the current hiring methodologies is that it rewards people who study for a test of sorts but may not really have experience solving real world problems. Or other "tests" that focus on whether someone can write some useless piece of code just to satisfy the interviewer that the person is competent. But the reality is it never accomplishes what hiring engineers think, because they didn't really talk to the person to figure out what they know, what their experience is and whether they understand architecture or coding choices really. I've been interviewing engineers (as well as everyday business team members) for somewhere around 25 years now. I went through the dotcom boom/bust where we did some weird interviewing methods many that seem to have made a sad come back again. And the key thing hiring always comes down to is understanding peoples decision making process more than their ability to write code for this contrived problem in the next 2 hours.
I do not use coding exercises at all with candidates, and I do not give them take home tests or anything of the sort. I have found it commonly eliminates the very people I need to attract. I want the guy who is smart and thinks through problems and who has experience and values his time. I want the guy who when he sticks his resume out he has 20 people wanting to interview him and he doesn't have the time to do everyones 4-6 hour "test" plus another 4-6 hours of interviews, because if he did that for everyone he'd drop the ball at his current position. I want to talk to these people, I want to walk through problems with them (sometimes walk through code I provide so they can comment on it and I can ask them questions), I want to talk about what they have solved and how, and I need to see that they can communicate with me & the team as well as fit in. Of course I ask them specific language questions if I am hiring for a specific need, but I don't care about seeing them write some piece of code in the next 2 hours, I just want to know how smart they are and where they have weaknesses (since we all do). And I need to hire people that complement my teams weaknesses not multiply them.
*edit to add this -- Also the reason I can hire really good candidates before others most of the time is my rule is from initial contact to decision is 5 days or less. That means while other companies are screwing around we already made a decision and gave them an offer or passed on them. Most startup hiring processes take weeks to get through and suck up a huge amount of time from company engineers, founders etc taking away from dev/product time.
- FpUser 7y agoAgree with everything except the tests. Ususlly do not need those but id did happen couple of times when I wanted to be absolutely sure that the person can work in particular domain. Basically take it home and come back in a week or whenever you feel like. The test was the actual problem but greatly simplified and should not take more then a day to solve so the person gets paid for a day.
- davismwfl 7y agoI don't disagree with you when a candidate has already been through a thorough interview process but the company has some concerns around a special and unique area of concern. It is very fair IMO to ask someone to do a little test around that special area or go through a more detailed interview there, I've done this for specific candidates myself too. But that area needs to be something so considerably unique to your business that the person can't have conceivably done it 20 times before. What is ridiculous is asking them to solve a puzzle unrelated to the job, or write loops or look up data from a database when all those things are something they have done likely 100's of times and you can easily ask questions around. In this specific case, I don't think a small test is out of line at all, as long as it is paid and short and the person knows they are the short list ready for an offer, or an offer has been made contingent on the test. What I object to is all these companies that do a 10 minute call (or not even) and then ask a candidate to spend many unpaid hours doing a test before they even bother seeing if the candidate is a fit for the position. And frankly, even paying for it doesn't make it fair for most experienced engineers. For example, I have seen most companies that do offer to pay, offer typically around $50 for 4 hours or $20-40/hr and they want an NDA that contains non-compete clauses many times. I have seen 5 startups doing this in the last few months, one was a company I had been mentoring off and on, the others were mainly companies friends had applied at and were dumbfounded. But if you take my scenario where the test is legit, you are testing something that is specialized knowledge and isn't useless to the company so you need to pay a fair consulting wage for the time, not a discount amount. Hopefully that makes sense, it does in my head but I am not sure I articulated it well. The overall goal is move through interviews fast, find smart candidates that will solve problems and don't put so much emphasis on meaningless details. I have seen a few companies doing a solid technical interview and they do ask quite a few algorithm based questions. I normally would disagree with algorithm questions when they are done just as a CS question. But when they are being asked because the candidate will literally need to be implementing them or understanding them at a deep level because the product and position being interviewed for is handling millions of distributed transactions a second or something similar, then they are legit and very necessary questions. But they are more or less useless (with a few exceptions) when you are a startup and you don't even have a working product or customers, in that case, the company just needs people with experience to get the product out the door and stop worrying about crazy algorithm questions or useless tests.