7 ms·

As a recruiter, what shortcuts can I use to tell if a person can do the job?

15 points by niccl 6y ago

We're a tiny development group providing analysis tools and reports to support a consulting group. There are just three full time developers. I've recently been made tech lead. Prior to starting here 3 years ago I'd been contracting/self-employed for 20+ years, so I've got very little experience of the recruiting process. I've been largely responsible for hiring developers (usually on contract) for a couple of years here, and to be honest my hit rate is not good. We've had a couple of outstanding people, some ok, and some ... less so. I've read many articles here about how hiring is broken, long interview sequences don't test what matters, etc., and I don't have the time, skills, resources or experience to come up with a massive interview protocol anyway. We seem to do stuff that's out of the normal experience (Python to create thousands of individual reports on thousands of rows of postgres data per report) so the pool of candidates here is limited. I think I know what I want: A maintainer who can find their way through an ugly codebase and quickly fix bugs that are identified by people who know the business domain thoroughly but are sometimes not good at translating the problems they see into words that make sense to a developer who doesn't have that underlying understanding of the business domain. And who understands about Chesterton's Fence Are there effective techniques that can help me sort the good from the less good, and if so what are they?

cpach 6y ago
You might want to say what country and region you’re in. Are you trying to hire devs in Silicon Valley? Madrid? Flensburg? Etc. The way to go about it and your expectations might vary a lot depending on the locale. Devs in SV can demand very high salaries and can afford to be very picky. Not so for every other region in the world. So how experienced devs you can hire for a certain salary will very much depend on where the company is located. And the advice that holds true for Silicon Valley might not be the same for other places.
- muzani 6y ago
  I've always felt that it was the opposite. I'm nowhere near as good as your average junior Stanford-graduated SV engineer, but I usually just highball a salary and people pay it anyway. Whereas SV engineers complain a lot on the interview gauntlet.
ChrisMarshallNY 6y ago
You probably don't want me. Not because I'm no good; but because I'm the wrong stack. However, I do have something that will tell you an unbelievable amount about me; the StackOverflow Story[0]. I have a gigantic portfolio, with dozens of repos, hundreds of thousands of lines of code, a decade of commit history, dozens of published articles, going into tremendous detail about the way I think, work, architect and code. I also have a bunch of apps on the App Store, with full source[1]. TL;DR: There should be no question as to my abilities, or even "soft" factors, like personality and team dynamics. Maybe you don't want a "shortcut." I was a development manager for a quarter of a century. It was a small, high-functioning team. Every person we hired became part of the "family," and was a commitment. When they finally rolled up our team, the person with the least seniority had a decade. There was no way that I would “shortcut” that hiring process. Each engineer was a major deal. I would have killed for the type of information that even a quick glance at a GitHub ID will give, let alone an SO Story. It has been my experience that the "shortcut" everyone wants, is a 50-line binary tree leetcode test; which I am pretty terrible at, as are many experienced engineers. For some reason, that tells more about me than the portfolio; which recruiters have always immediately ignored. It was insulting. It was meant to be. After a few of those, I just gave up looking for work long ago. I now just do my own thing. I don’t have a thing to prove to anyone. I am not alone. I routinely visit GitHub pages jammed with detail about how people work. I often see solid green activity logs (like mine[2]). You should look for a portfolio, and ask why not, if they don’t have it. Also, don’t wait for them to come to you. Seek them out. Use your network. It’s a big deal. It’s worth the time and effort. [0] https://stackoverflow.com/cv/chrismarshall https://stackoverflow.com/cv/chrismarshall [1] https://littlegreenviper.com/AppDocs/ https://littlegreenviper.com/AppDocs/ [2] https://github.com/ChrisMarshallNY https://github.com/ChrisMarshallNY
- mraza007 6y ago
  Just curious so you do contracting now or build projects for the clients
  - ChrisMarshallNY 6y ago
    I am open to it. I enjoy doing stuff for others. It has always given me great personal satisfaction to deliver software to spec. I have spent my entire life, doing exactly that. But I have the luxury of choosing what I want to work on.
andy800 6y ago
>> I'd been contracting/self-employed for 20+ years, How did you convince companies & clients to hire you? What are the questions you were repeatedly asked? I'd think you actually have plenty of experience in the recruiting process, just from a different angle. (and congrats by the way, it's always interesting how contractors line up work and keep a client pipeline going -- something at which I've only had sporadic success)
- niccl 6y ago
  I was outstandingly lucky! Most of my work came by word of mouth. I live in a comparatively small town in a small country, I used to work in a small but tight-knit industry, and I have an unusual name. I tried to make sure to have coffee with someone every week and the work just came in. It didn't seem to matter who the coffee was with, as long as I did it to keep my name current. Hence the lack of recruiting experience.
randombytes6869 6y ago
> . We seem to do stuff that's out of the normal experience (Python to create thousands of individual reports on thousands of rows of postgres data per report) Sounds like you need somebody that knows Python and SQL, should be easy to find. Everybody thats been in the business for a while has done reports. However everybody also hates doing reports, so you might have to pay more than you want to, or hire interns to do it. > A maintainer who can find their way through an ugly codebase and quickly fix bugs that are identified by people who know the business domain thoroughly I would just look for somebody experienced then, maybe 3 years +. Its going to cost more though, especially if the codebase is ugly and most of the work is reports. > I've been largely responsible for hiring developers (usually on contract) Hiring on contract is unlikely to get you desirable hires. Good devs have a lot of options. My somewhat generic advice is to have a coding assignment. Some people won't do them but its the best way I've found to screen candidate quality. Equally important is to have a good developer look at the submissions. The quality of code as rated by good devs has always correlated strongly with the quality produced once hired, at least from what I've seen. Advice for your situation specifically is to offer a lot of money and don't do contract-to-hire. Reports suck, your codebase sucks. Good developers can find another job within weeks and won't stick around unless you make it worthwhile. Most desirable hires will outright refuse contract-to-hire so you're restricting yourself to a low quality talent pool already. You can nab good people for a lucklustere job without paying a premium if you're willing to give rare concessions. Fully remote work, flexible hours, part time, 4 day schedule, relative autonomy, etc. If you can't do that or pay well turnover will remain high. You're not in a good spot right now. If you're open and honest about the job "writing reports in a crappy codebase" you won't get many interested hires and those you find will ask for more money. If you lie/deflect you will hire more but turnover will be insane. Your best option may be to hire interns. They will expect the job/code to suck and ask for little money. Turnover will remain high and quality will be all over the place, but at least it will be cheap.
- perl4ever 6y ago
  >Most desirable hires will outright refuse contract-to-hire so you're restricting yourself to a low quality talent pool already That seems like an odd thing to say. Where do you jump from "undesirable" to "low quality"? Isn't it exactly the undesirable but fair quality people who are stuck doing contract to hire? That is, those who are undervalued in the marketplace? It seems like a doubtful plan to insist on only chasing people who don't need the position you want to fill and probably don't want to do it.
muzani 6y ago
The most common complaint with interviewing is that it's too slow, too exhausting, and doesn't test relevant skills. So interview faster and interview easier. First off, offer above average market rate. It doesn't have to be high, but it keeps everyone's minds off money and their main focus is to work rather than using you as a stepping stone. Make this rate clear. Make the interview process clear. People dread being dragged through 5 interviews only to get lowballed. First level: filter. Ideally do it in the application form. Pick something that correlates to skill level. Lots of small questions is better than one big question because it reduces the randomness. Like I've seen things like "explain grep", "use functional programming to solve this problem", or "how do you keep up with the latest tech trends?" It should filter about 3/4 of your applicants. Your personality/attitude interviews should go here too. I'd recommend finding one good question that takes a few hours. It can be take home or on site or whiteboard. Since you only have one, make it good. It should test that they can read instructions, ask if instructions are unclear, and code. If your goal is to fix bugs, take an old, bugged snippet of your code and watch them figure it out. Try to do that process as fast as possible, ideally within a week or two. The more skilled someone is, the faster they'll get jobs. If you want an even lazier system, just pay for Codility for a bit and make them do some tests. It tests quickly enough, has a broad range of questions, catches cheating, tests that they can read instructions, and there are even some bug fixing challenges.
thorin 6y ago
I'm not a great fan of technical interviews with specific technical questions or coding exercises, probably because I feel like I probably wouldn't do well in them so interview style may be self-selecting in that sense. What I'd normally do is ask someone to describe what they've done as if they can't describe it well then they're unlikely to understand it properly and I value verbal or written communication highly. I'd also ask them the technical and business reasons for that implementation and what could be improved. I'd start with something as simple as possible and hopefully build up. I'd perhaps ask them to describe a solution to a difficult but not impossible problem relating to their area of expertise. For instance in SQL I'd ask how to describe how one might write a report that looks like a calendar by selecting all dates for a year and grouping by month, day, week etc. This is something that might take a few hours if you haven't done it before, but you could probably describe the process. If I can't explain a problem like that in 10mins to them we're probably going to struggle to work together. I'd also ask them about any personal areas of interest. A lot of people in IT in the UK don't have any interest in it outside of work, which is kind of understandable. I wouldn't expect massive github repos or personal projects, but I would expect them to have technical "interests".
tucaz 6y ago
My shortcut is to look for people who get stuff done. During interviews I don’t ask technical questions or test the candidate but talk about accomplishments. How many projects have they deployed to production and what problems does it solve? A lot of developers work just during the development phase of a project and then jump to the next one. As a consequence they have no experience deliverying real life products and support systems in production. I always look for people who finished things. Anyone can start or work on an ongoing project but just a few go through the whole process and have to maintain their stuff running. I also talk about what the project does, in details, for the business. A good developer has to understand they are building something that is not just a piece of software but a tool to solve problems. If they have these 2 things, I think we can work on the rest if needed.
- dyingkneepad 6y ago
  Don't you end up hiring a lot of people who are very good at bullshitting? Because that's what happened before we started introducing fizzbuzz-like problems.
  - tucaz 6y ago
    I should have been more complete I’m my response. What I described is the first step to narrow down candidates that I choose for in-person interview. After that step, if I think they are worth “investing” I’ll give them some assignments and drill down on the tech questions. But yes, this process still fails. It just fails less, I think.
dyeje 6y ago
IMHO, the easiest way to evaluate if a candidate can do a job is to give them tasks that they would do on the job. In your case, it looks like you should have them generate a report and try to find a bug in some business logic starting with an ambiguous problem statement.
tychonoff 6y ago
Interview programmers like you would a carpenter: 1) Describe some projects you've worked on, and your role in them 2) Describe some of your favourite projects, or accomplishments 3) What are your favourite tools? 4) How do you think you can help? 3) Provide resume, references and a cover letter As someone mentioned already, look for people who get stuff done.
- sloaken 6y ago
  Oh I like your answer so much better than mine
sloaken 6y ago
List needs and wants, separately. Too many job ads list requirements which they will never find in a combination. As such they attract liars or exaggerators. Your posting should list no more than 5 REAL must haves, preferably only 3. Wants and nice to haves can be long, I would put them in priority order. Describe what the real job is. If you are looking for a maintainer, say so. But I think you might want to also bring in a consulate to clean up your 'ugly codebase'. With that 'ugly codebase' you are almost begging a person to come in and replace the fence. Need to pay that tech debt. Otherwise anyone you hire will either hate the job, or want to throw the fence away. When I interview people I have a set list of questions. Then I have like 5 questions tailored to their resume. 'So tell me when you were involved in the design of space-x what did you do?' Then is often followed by deeper probing questions on their exact role. When looking over a persons resumes I watch out for items that are just bragging. Typically this is a list of too many accomplishments in too short of a time. I look for 3 month jobs where they list items that would be appropriate for a 3 year job. Given your situation I would specifically ask: 'Scenario: you are given a 4000 line program to fix, you look at it, and the code looks like it was written by a child. Just a load of crap. How do you address fixing the code?' You would expect the first question back is: 'What is the criticality of the fix? Does it need fixing now? Do I have time to clean it up?' I worked at one place where this one guy hated when people would rewrite code, but he was the worst, as in he always rewrote others code. Personally I find people who do not see the value in code reviews, are not worth the trouble. They tend to leave 'ugly codebase'.
mrfusion 6y ago
Make a small db with a subset of your data and give them a simplified report to make. Have them do it as homework. If they do a great job, hire them. Don’t bring them in for a day long interview and try to prove they can’t code. (True story)
he11ow 6y ago
You may want to consider the possibility that the poor hit rate could be a cause not of your inferior hiring skills, but due to the fact that you are looking for a rare combination of skills, for a job that doesn't sound very appealing: You want someone who's technically solid, while also good at understanding problems as described by laypeople, and doing all that without understanding the business domain. Way before Chesterton's Fence, you're looking for someone who is very good at communicating human-to-human, human-to-abstract and abstract-to-software. Tons of people can do one of the three. Lots of people can do two out of three. Three out of three is rare. That is not a "maintainer". So a different way to approach your hiring would be to revisit the process. If you were able to direct the conversations with the business side to a person who's good at linking between them and what needs to be solved, your maintainer could be just that - a maintainer who goes through a bunch of fixes in that ugly code base.

mraza007 6y ago
Oh wow that’s pretty cool. I must say that’s really good not a lot of people can enjoy that freedom. Just curious if you don’t mind sharing how did you achieve that freedom like what did you do to get clients or contracting gigs
- ChrisMarshallNY 6y ago
  You probably won’t like the answer. I’ve spent my life living frugally, and investing cautiously, but aggressively. I am not wealthy, but have enough to maintain my (fairly humble) lifestyle, while I spend -literally- 7 days a week, learning tech, which I love doing. When I left my last company, after nearly 27 years, I did look at working elsewhere (I was a manager), but the way I was treated in that search was so abominable, that I decided it was not healthy for me to continue the efforts. Being older in tech really stinks. This goes double, when we switch from management, back to tech, so my network is useless. It was much better for me to give up on playing other people’s games, and do what I need. It literally would have killed me, otherwise. My health has improved dramatically, after making the decision to do my own thing. It’s working out. I discovered that I never lost a thing, tech-wise, but I did need to spend the last three years “retooling” myself. I am not actively seeking gigs. It’s been my experience, that as soon as people find out about my age, the relationship immediately dies. This is particularly obvious with recruiters. I’ve started to make my age clear, right off the start, to avoid that. I’m an extremely good engineer, with “bleeding edge” skills, coupled with a lifetime of shipping software. I’m damn good, up to date, and used to Getting Things Done. I can prove it, too, with an enormous portfolio of code, apps, Web articles and participation in many fora. I’m an “open book,” with nothing to hide, and nothing to be ashamed of. I have a very high level of personal integrity, self-discipline, and empathy. I have a fairly deep and wide skillset that is quite rare in today’s tech world, coupled with enormous experience and a great deal of energy. I’m gregarious, optimistic, compassionate, and a marvelous team member. I treat others with respect and kindness. I’ve architected infrastructure that has become a world standard, and written humble little “toy” apps. I also have some specialization in areas with a substantial future (iOT, Apple tech, and Surveillance tech). My current project is a low-level abstraction of Core Bluetooth for Apple operating systems[0]. It’s not complete, because I still need to write three more test harnesses and supporting documentation. Despite that, it’s already in a shipping app[1]. I’ve been looking at applying my skills to help NPOs and whatnot to thrive in today’s world. There’s a dearth of up-to-date talent interested in doing that, as there’s not a lot of money, and the NPO scene is pretty crazy, in its own right. Because of my investments and humble lifestyle, I would have been happy to work for far less than many, as long as the work was interesting, and I was not asked to compromise my principles. I wouldn’t have minded taking risks with startups, to which I could have brought a really unique level of experience and expertise. I would think that someone that is used to shipping would be useful to a startup. Also, I've got lots of experience evangelizing projects to cynical, empirical, intelligent managers at all levels of a corporation. I’ve also started to look at training. That’s something I can do quite well. But I’m pretty bad at leetcode, and I’m...well...not young. I won’t enter a relationship that requires I be humiliated and treated like garbage. You -literally- can’t pay me enough for that. I never did that with any of my employees, and it’s rather shocking to encounter that in today’s tech scene. It’s not surprising that the average stay at a company for an engineer is around 18 months. I kept senior-level employees for decades. It’s amazing what simple compassion and respect will buy you. None of us was paid particularly outrageously, but we were a very tight team. It really is interesting that requesting (not demanding) to be treated with a little bit of respect is considered “arrogance.” [0] https://github.com/RiftValleySoftware/RVS_BlueThoth https://github.com/RiftValleySoftware/RVS_BlueThoth [1] https://apps.apple.com/us/app/blue-van-clef/id1511428132 https://apps.apple.com/us/app/blue-van-clef/id1511428132
  - perl4ever 6y ago
    I suspect that you're on a completely different wavelength from the potential candidates for this job. Remember, "Python to create thousands of individual reports on thousands of rows of postgres data per report" I think paying over, say, $75K is going to fail because anyone who can easily make more than that is going to consider themselves too good to do this stuff. There's plenty of stuff that you can pay peanuts for, that you can't get a FAANG-level SWE to do for any price, so the answer to finding the right person is not always "pay more" or do any of the other things that people making $600K instead of $60K expect.

quickthrower2 6y ago

I don’t have one and mainly the reason is I don’t need one to get a job. The other reason is I’m not selling myself as someone who has a lot of open source code, and any code I write on the weekends is going to be dogshit from a clean code perspective. Because I am learning and prototyping. That said the main thing the company hiring needs to know is does SO story predict success in the job? Probably a little bit - it at least highlights commitment and you could scrape HN to find good stories then reach out. But if you ask “do you have a story/why not” to people coming in from regular channels even SO applicants I think it’ll waste a lot of people’s time in both sides.

ChrisMarshallNY 6y ago
That depends. My “nights and weekends” code is not “dogshit”[0]. I spent a lot of time as a manager, and it was how I “kept my chops up.” One of my side projects[1] has turned into a worldwide standard; used daily by tens of thousands of people. I fail to see how, if we are talking “clean code,” a short leetcode test will say anything more than a portfolio; even one with “quick and dirty” code (which is all you’ll get in the test, anyway). Also, if companies start using portfolios as material for hiring, then folks are a lot more likely to take care, in their extracurricular work. That won’t hurt. I think there’s a real crisis of quality, in today’s software. I see a lot of pretty impressive stuff, daily on GitHub; even “experimental” projects. There’s a great deal of code and history out there. The fact that someone is working on side projects; especially if they are doing so as part of a team, can speak volumes on their behalf. The SO Story is less common. I wouldn’t expect that from everyone, but it can be quite helpful. It organizes this stuff. Have you ever seen a graphic designer apply for a job? When they arrive for their interview, they come in, holding a large, flat, black case. It’s called a “portfolio,” and contains samples of their work. They often also contain interim work, showing the person’s process. Even students, fresh out of school, are expected to have one. It’s so standardized, that companies don’t even mention the need to bring one with you. Today, it’s probably quite common for the portfolio to be digital. No design company on earth would ignore that, flip a matchbook into the interview table, and ask the designer to “draw Spunky,” but that is exactly what most tech companies are doing, these days. Basically, what I am saying, is that many folks have a lot of pretty good stuff available as some kind of portfolio, and it’s, quite frankly, ridiculous to think a whiteboard test will tell us more about someone than that. Even if the work is not suitable for our use, it can be the structure for a conversation. One of my favorite things to do, in an interview, was to find a “story” the applicant wanted to tell, so a lot of my questions were designed to find the “hook,” where they suddenly smiled, and started to tell me about problems they solved, or teams they worked with. Those conversations are gold. They are what we look for. All the rest is BS, and many developers aren’t “people persons.” Getting them to “open up” like that is really the job of any interviewer. It has been my experience that hiring managers and recruiters completely ignore portfolios. Even companies that ask for GH or HN handles seem to ignore the contents. I think they just want to find out if people have them, as some kind of “cultural flag” (I have also seen a lot of GH handles that tell me the developer is not so good, but I’d not know that, unless I looked; and what people write here...well, not so sure that’s helpful to convince managers that we’d be good team members). [0] Don’t take my word for it; look for yourself: https://github.com/ChrisMarshallNY https://github.com/ChrisMarshallNY [1] This shows the reach of the project. It’s a “live” dashboard: https://tally.bmlt.app/ https://tally.bmlt.app/
- quickthrower2 6y ago
  Graphic design is a bit different in that it take a lot less time to evaluate than code, and you can probably use IP protected work in your portfolio, since it is protected as a trademark not as a trade secret. Yes you have, prima facie, written good code. I don't have 2 hours now to fully critique it though. If I were interviewing you and using this code to see whether to hire you, I need to do a lot of work to see if (a) you really wrote it and (b) it is well engineered given the problem space. I'd mark you up for the great documentation though - I can see at a glance that there are lots of code comments, and a good README.md - so that is positive. But it's not a deciding factor, I still need to see if you can code. If I am looking at Githubs, well I have 20 candidates. 20 different code bases, trying to achieve 20 different things. That's a lot of work to weed out. I don't mind that at a late stage, but not an early one. Some companies say - 2 hour coding test or BYO open source project - BUT that should be a small volume and you need screening rounds before that. However if I were interviewing you and gave you a leetcode or similar test, I know the answer, and I can probably run some auto tests on it. Much easier and practical for early rounds. Also switching it around a lot of good devs don't do side projects at all. Doctors who do doctors without borders are probably better on average (?) but would it be a hiring criteria? Or builders who help their local church rebuild a wall. Builders can have portfolios. Luckily that can be based on the work they were paid for, due to IP not being an issue. When a new architectural techniques comes out, say a new kind of render, they can add this to their portfolio. If a new tech comes out, say "Rust", I need to make a mirror project for my portfolio as the work project is IP protected. I need to build that church wall to get a job if a FOSS project is expected.
  - ChrisMarshallNY 6y ago
    That (a) is amusing. I’ve encountered it before. If someone is able to hack GitHub to fake tens of thousands of lines of high-quality code, ten years of commit history, dozens of Medium articles and blog entires, multiple Web sites, and documentation up the wazoo, then you should hire them on the spot; even if they are fronting for a Hyderabad shop. Like I originally said, and this goes double for small teams and startups, every employee is a huge commitment. I would gently suggest that “shortcutting” the process is kind of reckless. It’s pretty easy to figure out if someone wrote something, by simply saying “This project you did is pretty cool. Tell me a bit about it.” Bang. You just struck gold. A portfolio would be a perfect opening for these types of questions. I would struggle to find those "hooks," with some applicants. In my stint as a manager, I had to fight like hell for every headcount, and I kept employees for decades. There was no way that I’d “shortcut” that process. YMMV I think that we’ll be seeing a lot more open source for proprietary work, in the future. Decompilers are so good, that it’s damn near impossible to truly hide how we do stuff. Another thing that needs to DIAF, is the "shower clause." This is the clause in the employment contract that says "Every idea you come up with in the shower at home belongs to us." I didn't have it with my job, so I was able to design a lifesaving infrastructure that is being used by thousands of people around the world, and has now been passed on to another generation of engineers. It's going to become a ubiquitous infrastructure, and will directly impact many, many lives. That would not exist, if I had had a "shower clause." If someone has a great idea in an extracurricular venue, then don't try to bully them into handing it to you for free. Figure out another (more equitable) way to get it. The whole deal with employees, is that we're not "Programming Modules." We're humans, and we need to be treated as humans, from the job ad, to retirement.