Hacker News new | past | comments | ask | show | jobs | submit login

Broken record: startups are also probably rejecting a lot of engineering candidates that would perform as well or better than anyone on their existing team, because tech industry hiring processes are folkloric and irrational.

I co-manage a consultancy. We operate in the valley. We're in a very specialized niche that is especially demanding of software development skills. Our skills needs also track the market, because we have to play on our clients turf. Consultancies running in steady state have an especially direct relationship between recruiting and revenue.

A few years ago, we found ourselves crunched. We turned a lot of different knobs to try to solve the problem. For a while, Hacker News was our #1 recruiting vehicle. We ran ads. We went to events at schools. We shook down our networks and those of our team (by offering larger and larger recruiting bonuses, among other things).

We have since resolved this problem. My current perspective is that we have little trouble filling slots as we add them, in any market --- we operate in Chicago (where it is trivially easy to recruit), SFBA (harder), and NYC (hardest). We've been in a comfortable place with recruiting for almost a year now (ie, about half the lifetime of a typical startup).

I attribute our success to just a few things:

* We created long-running outreach events (the Watsi-pledging crypto challenges, the joint Square MSP CTF) that are graded so that large numbers of people can engage and get value from them, but people who are especially interested in them can self-select their way to talking to us about a job. Worth mentioning: the crypto challenges, which are currently by far our most successful recruiting vehicle (followed by Stripe's CTF #2) are just a series of emails we send; they're essentially a blog post that we weaponized instead of wasting on a blog.

* We totally overhauled our interview process, with three main goals: (1) we over-communicate and sell our roles before we ever get selective with candidates, (2) we use quantifiable work-sample tests as the most important weighted component in selecting candidates, and (3) we standardize interviews so we can track what is and isn't predictive of success.

Both of these approaches have paid off, but improving interviews has been the more important of the two. Compare the first 2/3rds of Matasano's lifetime to the last 1/3rd. The typical candidate we've hired lately would never have gotten hired at early Matasano, because (a) they wouldn't have had the resume for it, and (b) we over-weighted intangibles like how convincing candidates were in face-to-face interviews. But the candidates we've hired lately compare extremely well to our earlier teams! It's actually kind of magical: we interview people whose only prior work experience is "Line of Business .NET Developer", and they end up showing us how to write exploits for elliptic curve partial nonce bias attacks that involve Fourier transforms and BKZ lattice reduction steps that take 6 hours to run.

How? By running an outreach program that attracts people who are interested in crypto, and building an interview process that doesn't care what your resume says or how slick you are in an interview.

Call it the "Moneyball" strategy.

Later: if I've hijacked the thread here, let me know; I've said all this before and am happy to delete the comment.

> we use quantifiable work-sample tests as the most important weighted component in selecting candidates

Can you speak to that a little? I'm reading it as either programming challenges in a real environment, or analysis of previous code snippets submitted. In either case, I'm happy to see more companies doing this.

I'm always looking for ways to improve my interview skills, but I want to do it honestly. Studying to the test isn't fun for me, I would rather hack on something.

Most programming puzzles aren't real work-sample tests. A work-sample test has to be representative of the actual stuff you'd do on the job.

The trick is, to work in a recruiting context, you also want those tests to be standardized and repeatable. A lot of companies fall down on this. They have candidates do "real work", often in a pair-programming context. There a bunch of problems with this:

(1) "Real work" usually isn't standardizable, so you can't compare candidates

(2) Signal quality from the test is intensely dependent on who is doing the work with the candidate

(3) Two different candidates might end up getting "tests" that are wildly different in terms of predictive power

I have a bunch of ideas for pure software development work-sample tests, but I'm not ready to share them. The idea is simple, though:

* It's a realistic exercise that approximates actual day-to-day work as much as possible

* Every candidate gets the same exercises

* The exercises have objective (preferably gradable) outcomes

So accurate. I'm a grad student who studied security deeply during my time in school.

I want to keep my hands on a keyboard and I don't like airplanes (which rules out consulting) so I've applied at a lot of companies to be a ``security engineer''.

I can't tell you how many well-respected companies ask me to write min-heaps, depth-first searches, etc. I don't understand what they are asking me this for...It isn't even close to a realistic representation of what my day-to-day responsibilities would be. It is also an immediate turn-off....

I don't understand how there can be a good hacker that does not, at least on some intuitive level, get such basic data structures or algorithms. I don't mind if someone doesn't know what depth-first search is, but I should be able to explain it quickly and they should be able to come up with at least pseudo code. The relevance of this to software engineering roles just seems too great.

Cramming these questions online does not work. I don't know what Facebook/Google et al are doing but I can spot a candidate who studied interview questions from a mile away. They may bang out a DFS by rote but that's just warmup; they should be able to talk about details, deal with changing requirements, discuss the algorithm/efficiency/design of their solution, be able to talk about underlying data structure primitives, etc.

To be fair the grandparent was talking about a specialized position in security engineering for which the generic coding interviews could be a bad match.

>I don't understand how there can be a good hacker that does not, at least on some intuitive level, get such basic data structures or algorithms.

And I don't understand why someone who spends his time up to the eyes in crypto proofs, exploit code, and research articles should have to cram for an Algorithms 1 exam for each interview.

I've seen these questions used well (had a neat discussion with a start-up CEO in Boston once about reimplementing a toy Twitter in Scala), and really brilliantly (another start-up in Boston once asked me to describe my favorite algorithm and got a short, ad-hoc tutorial in lottery scheduling), and really, really badly (BigCos asking stuff you'd see on an undergrad-level exam from years and years ago).

Strangely enough, I'm praising the two startups that didn't offer me a job (though I'd really like to reapply to that second one), and condemning the BigCos (you know who I mean) that did offer me a job.

You're right it isn't well suited for security people.... But is it well suited for software engineering types? Most code people write is not a search sort insert etc. Most of the details of using these data structures are invisible in oop and the difference is only what class was instantiated.

I'm not saying it isn't important to know, but I think there are better indicators for someone who will perform well on the job

Sure, but these tests are necessary without being sufficient. I'd expect that performance in these tests is predictive up to a certain level but that being really good at them versus just performing decently is not nearly as predictive for actual job performance.

Similar story here. Now not only these "big" companies as Facebook, Google, Microsoft focus mainly on algorithms and data structure during interview, to my surprise some of the early startups ask heavily for whiteboard coding...

It's no surprise these companies rejects many really good hackers (at least from people I know... yes, I admit the small sample size) and accepts these just optimize for algorithm preparations by doing a set of online coding problems.

The startup industry saw the same kind of interviewing voodoo in the 90s, copycatting how Microsoft conducted them.

They're asking you that because there are lots and lots of candidates who look great on paper but don't actually know anything. I have personally met several.

I wouldn't ask a candidate to implement a min-heap (mostly because it's kind of obscure and I'd have to think about it) but a depth (or breadth) first search is something I'd expect any competent candidate to rattle off in a heartbeat, just because it's such a fundamental cs principle that gets used in lots of places and, unlike things like sorts, doesn't really have a good library to fall back on in practice.

Believe me, I can and do implement them, but I always do so backhandedly. ``I am a security engineer, what does this have to do with security''.

In reality, I have not accepted an offer from any companies who ask me these questions because most of the positions are not exactly what I am looking for.

Also, I tend to disagree. Some of the best security guys out there never went to college. It's hard to expect these guys to know algorithms and datastructures even if they are really gifted exploit developers, or the like.

edit: To clarify. What this really shows is that I am not being interviewed by a security person...ie there is no special interview process for my position compared to a regular software engineer.

I really doubt that it's possible to be a top exploit developer and yet be unable to implement BFS/DFS in under fifteen minutes. Some things really are just the absolute basics. If it never goes further, then that's a problem, but there are enough people out there who can't write ten lines of code that you have to weed them out.

My cousin's employer has started using Javascript Under Pressure [1] as the first round of technical interviews - it lightens the mood, and fully half of the people applying for a front-end development position at his company can't finish the first one, which is literally to write a function that returns the argument multiplied by two.


Relaxing with a few beers at home, this was fun. "12 minutes, 19 seconds for all 5 levels. Well done!" Don't care that I'll be blasted for being a slow old man. Come on, you know you want to! Stallman, babbage, lovelace and torvalds await.

That was great fun for non webdev Javascript coder, and I was about 3 mins in and finishing 4th problem.

However, getting one of the tests wrong in 4th problem because of two chinese UTF-8 symbol having more length than "tiny" kind of irked me and reminded me why I do not do webdev.

I suppose this is actually a good kind of test, because real webdevs would actually have learned not to use s.length but use something else.

What is it though? This seems like a Javascript fail more than anything else.

I just did that and I'm pretty sure I used "s.length()" and I didn't even notice any Chinese characters.

I had to check typeof (apparently those two chinese characters are not a string) to fix this, again this is actually useful, but was not expected given the ease of first 3 problems.

Please put a warning if you link to a site that auto-plays audio.

Gah, that made me jump.

Ok, that JavaScript under Pressure is a lot of fun and it would make a great ice-breaker.

I doubt "the best security guys" end up with the same interview experience. If you are widely known in the industry as an expert or the best at something I think the process to obtaining a job is significantly different from someone applying for jobs.

Not here. I am way more scared of the "best" candidates than I am of the normal ones.

I would imagine with someone like Bruce Schneier, you'd be paying them for the name and not their output. Google did it with a bunch of legendary computer scientists. Their role is mainly to get top notch junior people to come work there.

Really, that's surprising to me. Would people of Bruce Schneier/Fyodor/et al stature go through the same interview process that everyone else goes through? I'm pretty sure they wouldn't at a big company but you guys do things differently (for the better it seems) so maybe?

Yes, they would. I am 100% sure of it.

For all I know Fyodor is a collective of cheap developers and designers from far-far-away coordinated through an outsourcing agency with a single front figure reading from a teleprompter.

That would still be a notable effort, but I'd like to know who I'm hiring and for which qualifications (cat herding or design and implementation).

Do you also feel that Bruce Schneier could be a collective of cheap developers? That seems like a pretty odd position to take give Fydor's identity is widely known. (http://insecure.org/fyodor/)

"For all I know Fyodor is a collective of cheap developers and designers from far-far-away coordinated through an outsourcing agency with a single front figure reading from a teleprompter."

And would that matter?

In general? No.

When the teleprompter reading person applies for a security job they're supposed to do alone? yes.

What kinds of questions would you expect to be asked for an interviewer to distinguish you from someone who looks good "on paper" but is a big phoney?

We apply a "peer" interview model, where candidates before being offered a job have to sit down with two of their future peers. This takes care of the phoneys as their (already successful) peers see through the posing.

Interview Process is: HR filter -> Manager interview -> Grandfather (Manager's Mgr) interview -> Peer meeting

The peer meeting isn't conducted in an interview setting. It's more informal, adapted to the needs of the applicant. It could be a lunch or a dinner and once it was even participating together at a hackathon.

We carefully select peers against "buddy bias" and encourage diversity in the workplace.

Our company is over a period of several years very successful in recruiting and have very little turnover. The biggest drawback could be that we are "too picky" and thus (at times) have problems growing fast enough.

Exactly. A false positive in the interviewing process (hiring a dud) is much more likely than a false negative (turning off a great candidate).

The secondary reason to ask these easy basic dev questions is an attitude check. Someone who gets personally offended at being asked to do something that is easy for them has a risk factor for being a poor teammate.

> A false positive in the interviewing process (hiring a dud) is much more likely than a false negative (turning off a great candidate).

I see statements like this thrown around a lot. Do you have precision/recall/F-measure numbers to back this up?

The most famous example I know of is the guy who implemented a FizzBuzz test and thereby eliminated the vast majority of programmers who otherwise appeared qualified on paper and in person. I don't have the link handy but I think it was covered in codinghorror.com.

I have been very interested in running a similar experiment myself, but alas I am not a hiring manager. As I recall from that example, there were no details of what counted as "qualified" on paper and in person.

> [...] unlike things like sorts, doesn't really have a good library to fall back on in practice.

Depends on your language. Some are better able to abstract and express this `pattern' as a library.

We actually took a few things that we wrote in the infancy of the company and turned them into work-sample tests. We use the same test for everyone so that we can grade effectively while still ensuring that it's a good sample of what they'd be working on (because it's something we actually did!).

We have a front-end and back-end test. I'm sure that at some point we'll grow large enough that solutions to our test will be posted online but I'm not going to worry about it right now.

They won't be posted online because my team will have put you out of business by then.

This approach will be difficult for firms that use contingent recruiters, because the recruiters will be incentivised to coach candidates.

Does anyone have any luck with outsourced recruiters? From where I stand, they seem like a bane of the industry.

Was going to answer this but then saw the child comment say this:

"but only because a) he was really hungry at the time b) he really went out of his way to build up a lot of contacts with a lot of top-notch talent."

And that was really the essence of what I was going to say. I think after a while anyone who is busy and being paid in the manner that a recruiter (or real estate salesman) is is going to go for the easy route and the low hanging fruit. Especially as they get busier. Because back and forth is time consuming.

It's kind of like a satisficing model. You need to keep the client happy enough to keep sending you projects and no more than that. [1]

Consequently in theory a new and hungry recruiter is really the one that will give you the best results but that assumes they have a file full of candidates and that kind of contradicts being new.

[1] There is truth to that book that stated that real estate salespeople get more when they sell their own house than your house. 3% of $10,000 is not $10,000 and it pays to move on to the next deal in your book.

I've never understood paying 3 recent to sell a house, especially in these times(Internet), and some markets sell themselfs(Bay Area). Plus, the full commissions usually go to the best salesperson, or Cheerleader. It's eight courses! Two years for a broker--who most likely got their brokers license with any four year college degree. (Yea--most of these guys partied through a bachler's degree before this year and got their broker's license. They lobbied Gov. Moonbeam to make it harder for anyone else to do what they did--The Terminator saw right through the ploy, and vetoed the bill--ironic?) Success is moving Realestate. The average homeowner only realizes they could have got more after they do their homework, but that never really happens--they go into denial after the sale. It's done.

I've never seen a industry that needs a fresh, iron clad Application, but it has to be top notch. A hungry, smart developer could revolutionize the Realeste market with the right code, and eliminate Realtors to a history wiki. Plus--I would never need to look at their stupid smiling faces everywhere. And yes, I know a house is the biggest thing you will ever own--you need hand holding? That's all your full commission will get. Smart Realtors always cover their asses legally if you buy a Lemmon. This is just my rant on Realtor's--especially full commission brokers. The above post reminded me of how arcane buying a house is.

We've had some good luck with a single one, but only because a) he was really hungry at the time b) he really went out of his way to build up a lot of contacts with a lot of top-notch talent. In a lot of ways, he was a lot more like an executive placement consultant, only placing software developers.

The large bodyshops, OTOH, seem like a colossal waste of time to me. I don't trust them, and the candidates they offer have been almost uniformly disappointing.

I've hired a number of engineers through agencies. It's a PITA because our incentives aren't aligned but I've found a few things to help. One is to be firm with recruiters and not to care about your relationship with them. In a place like NYC where there are hundreds of firms constantly trying to work with me I make it very clear what I expect of the recruiters. If they don't give it to me I move on.

Perhaps coincidentally, companies say there is an engineer shortage while at least 80% of the Rails jobs on LinkedIn & Craigslist are posted by recruiters. Recruiters may simply be ruining the employment market, probably as a gold rush.

I have exactly one that I think is good in 21 years in the field. He actually understands his candidates at a moderately deep level and I can get on the phone with him, describe what I'm looking for, answer his questions, and a week later get a handful of resumes with his notes attached after speaking with the candidates.

His "secret" is that process, which also allows him higher than average access to passive job seekers. Let's face it, many (not all, but many) of the "best" candidates already have a sweet gig and aren't pounding the pavement looking and mindlessly applying to every job posting. This recruiter calls them and they take the call, because he's not just matching asses and seats like it was a musical chairs problem.

Candidates like him (he placed me once 17 years ago) because he's not perceived to be a time-waster, and hiring managers like him because I get better candidates through him (albeit at a lower volume and I "can't afford" him for every role).

That's responsive to your first sentence; to your second sentence, I generally agree. I have the luxury of having a strong in-house recruiting team, who are willing to selectively and smartly use outside agencies when it makes sense. As a result, I get to direct the flow of nonsense from outside agencies at my in-house team. ;)

Anecdotally, I know of an experienced and competent engineer who actively sought out a recruiter, hoping to find a job in Silicon Valley (which he did). Some people just can't be bothered with the interview grind, and if you know you're good, why not have a recruiter do a bit of the grunt work for you? But I suppose this could be an edge case, where a legitimately good candidate actually works with a recruiter.

I tried that route to no success. My problem, back when I actually wanted to work in SV, was I found it to be an impenetrable bubble. There seems to be a serious delusion that any engineer worth a damn will move to SV of their own volition, so the only reason to look outside is to try to snatch the top talent from the top schools elsewhere.

I have had good enough luck that I won't dismiss a recruiter outright.

I treat recruiters like widening the funnel, and haven't found any correlation that suggests they produce better results.

I have found the best results is hitting people up through linkedin.

We've had success with this approach with outside recruiters. Generally the recruiters aren't skilled enough to coach a candidate on the tasks. But in the case that they are, one of the components of the onsite interview is a code review of the code the candidate wrote. This usually includes me challenging design decisions and then changing up requirements and asking how the code would change. So even if a candidate WERE to be coached by an recruiter, the candidate would have to really understand the code they wrote and why they wrote it.

If the recruiter can coach the candidate, you should hire the recruiter to program for you.

They don't need to be skilled. They just need to debrief the people they send you post-interview.

Who asks programming puzzles anymore?

When was the last time you applied for a software developer job?

Before Matasano, if you don't count clients interviewing us.

Who asks programming puzzles? Read interview postmortems. The answer appears to be "everyone". We are probably just talking past each other: asking someone how to sanitize an input or parse an HTML document during a face-to-face interview is a "programming puzzle".

It's hard to imagine that Facebook, Twitter, Dropbox, Google, Amazon, Apple, and all the rest of the companies that hire software developers, who have more or less the same type of interview, have gotten things wrong, yet have been so successful in hiring good people and building good products.

Perhaps the real problem is that those companies have taken all the people who perform well at whiteboard interviews, and what's left are people who struggle.

Still, I wouldn't say the system is flawed because it selects a certain type of people. Clearly those people do well.

It's not at all hard to imagine that the best known company in the industry, the one that spends the most on direct outreach to clients, whose compensation system more or less sets the standard for the industry, a company that is essentially rolling in money, is able to make a conventional recruiting process viable for itself.

Having said that, if you talk to Google people who are close to hiring, especially about the process that connects "interviewers" to "recruiters", I don't think you're going to hear consistently good things about how the system works in practice.

Googled used to do the puzzle thing and gather copious metrics on how it worked out- it turned out that it didn't.


Note the word programming. If a brainteaser puzzle has nothing to do with the job you'll be performing then of course it won't indicate real-world performance as well as one that's related to the opening at hand.

Yet, these large companies are always desperate to aqcuire, or 'acq-hire' smaller companies.

It's easy to imagine that smart people's thought processes are imprisoned by their own egos. It is an easy trap for a smart person to fall into.

Algorithmic testing has real practical implication if the role requires it, which a subset of the engineers at the aforementioned companies will use.

The other practical implication is standardization of the interview process, rooted around an academic background in computer science. It's easy to test whether someone knows a "fundamental" (whether it's actually fundamental to the job is another question) cs data structure or algorithm.

The idea is, interview for square pegs, since it is easier to measure the quality of that particular shape at scale. If there is a high-quality peg that happens not to be a square, it is a loss that the system is willing to accept, provided that a large enough % of the good candidates are squares.

Great points.

Though I believe algorithmic knowledge is a lot more practical than people give it credit for. I'm not talking about crazy graph searches, or implementing A* in ASM.

Are you going to be efficiently searching strings, or reordering arrays, full time? Probably not, but you will likely come across a time where you will need to think about the consequences of your design, even in a simple crud web-app. And that stuff is important.

> It's hard to imagine that Facebook, Twitter, Dropbox, Google, Amazon, Apple, and all the rest of the companies that hire software developers, who have more or less the same type of interview, have gotten things wrong, yet have been so successful in hiring good people and building good products.

It could be also cargo cult.

If you are a startup, how you will add a technical founder or a first technical hire? Just by his/her ability to write O(log n) searchs in a whiteboard or you will dig deeper and make sure is the perfect match?

Hopefully the startup will dig deeper.

Early in the life of your company you're hiring for very long term, and you need generalists.

Unless your company is building a product around whiteboard coding or something.

The point you are grazing is that this approach results in many false negatives, and few false positives. This is workable for companies that are consistently able to attract large numbers of candidates, such as the ones you listed. (And yes, there are false positives. I personally witnessed someone at a large company who was very adept at whiteboard coding, and a very lazy employee.)

You've said it more eloquently than I can, but I want to bring up that:

"results in many false negatives..." is not some universal truth.

Is there evidence that shows current software interviews turn down way too many great candidates?

There should exist a large enough group of developers who have been rejected a number of times[0], who have gone on to be very successful[1] in their careers. Does this data exist?

I agree that the current process isn't perfect, and it does produce some false negatives and some false positives. The amount which, has yet to deter me from beliving that the system works, as intended. Certainly there are some fringe candidates, who are turned away, but I don't think it's as onerous as people are making it out to be.

Also, most companies didn't start out with unlimited piles of cash, nor could they have their pick of employees. They had to work at it, and I don't believe the culture of their hiring has changed significantly.

For the record, I struggle with traditional coding puzzle interviews. But I also know coding on the whiteboard is a skill, which can be practiced, and with time, improved upon, such that if you are a really good developer, but struggle with passing interviews, you can deal with that problem by becoming better at interviewing.

Or you know, create something awesome, and never have to worry about interviewing again.

[0] Failing one or two interviews isn't really indicative of anything. So this group would require consistently failing multiple standard coding interviews.

[1] How to measure success? I say gone to be a major contributor to the success of a company, or built their own company that is considered "successful."

We turn down candidates all the time. No doubt that many of those go on to find success elsewhere, especially the ones that we turn down for fit (cultural or candidate expectations).

It's an open question whether a negative for fit is a false negative or not. If someone wants to be a foo and the need that I have is for a bar, it's a true negative for us, but when that persons goes and finds success as a foo somewhere else, I'm not sure where to put them your data set.

Even for the false negative, how would I possibly know what career path they took after that? I certainly hope it turned out well for all of them, but I have no practical way, not to mention no incentive, to find out.

To flip things around: would you hire someone who was a really good fit, but was weak technically?

I'd add to this that either way, whether interviews work or not, the problem is more complex than that: is the potential hire at the right point in his or her life to work for you? Are current open positions a good fit? Will the team get along? This may speak more about less mature candidates, or for smaller companies with more specific skill requirements, but my ultimate point is that rejection shouldn't be forever but few companies take that route...

Your post seems to employ circular logic. You're asking for evidence of one of your assumptions:

> Failing one or two interviews isn't really indicative of anything.

Apologies for the logic fail.

I'm asking for evidence that shows candidates who have routinely fail traditional software interviews, have gone on to be above_average -> exceptional in their careers.

My hypothesis is that if traditional software interviews have systemic and endemic flaws--that is interviews produce there are a lot of false negatives, there would exist a large group of people who have failed continuously, but have yet gone on to be good-to-great elsewhere.

Getting a no hire from one or two companies, would not classify a person as a "false negative", it could be (as others have mentioned) an issue with fit.

Well add 1 to the "rejected but went on to be awesome" Brian Acton.

I've had to do a bit of sanitizing input and parsing HTML documents "for real" at my job. It's not a primary duty, of course, but it comes up now and then. It seems like a reasonable test for "can they actually write some code to a well-defined spec," although probably not a great test for "are they good at working on a team and architecting bigger projects."

This is also a practice that is extremely easy to teach and fix.

But can be very costly to your business.

SQL Injection--not html parsing ;)

I was about to simply repost this sentence as its the HEAVY substantial bit of the post.

What does it mean? Throw engineering problems your CURRENT team has solved in the past at new candidates. I have seen only ONE startup ( even among the nastiest of hard problem seekers ) GET how substantial this is. So many of these companies are too busy to think about smart sourcing, at their own peril.

Test new engineers off past solved problems. End of story.

I like this guy's stuff: http://codingforinterviews.com/

I wonder if some companies are accidentally scaring away potential candidates even earlier in the process. I've personally shied away from many job postings that are asking for "rockstars" or "only the best", since they don't generally seem to be interested in "intelligent problem-solvers who don't know every intimate detail of the latest JavaScript framework or nosql database, but could learn quickly if needed".

  we interview people whose only prior work experience is
  "Line of Business .NET Developer", and they end up
  showing us how to write exploits
I am surprised you sound surprised. Do you label people by the kind of technologies or jobs they held? I mean, you argue against it, which I think is a positive argument, but somehow it seems that the labels people place on technologies and business domains are somehow rubbing off on the people who were using them. Feels myopic to me.

Zero prior cryptography experience. Zero work history in software security. Hired through a resume-blind work-sample process. Goes on to successfully implement a crypto attack that fewer than 10 people in the world have probably ever implemented before, one that requires debugging a lattice reduction step that takes 6 hours to run before you get to the part where you use a Fourier transform to postprocess the result.

Or: Zero prior software security experience. Zero prior Rails experience. Zero prior Ruby experience. Hired through a resume-blind work-sample process. Looks at Rails for the first time, 30 minutes later reports a vulnerability that results in a CVE and a Rails patch. Repeats. Now runs Rails internal review board.

I have other examples. Worth knowing: we aren't Rails neophytes (for instance, we're one of the firms that reported the YAML code execution bug) or for that matter crypto neophytes.

It's not about what technologies you use; I don't so much care whether someone writes .NET code. It's the "absolutely no prior work experience doing this and no flashy resume to get them in the door" that stick out to me.

Some of the best software engineers are .NET and Java software developers. These are the guys running massive systems, but no one ever hears about because its boring government/corporate work. But that work is infact the most challenging. Imagine the amount of transactions a bank has to handle every day, without fail!

It's just that Hacker News biased to a certain section of society.

And they tend to be complex systems with a lot of edge cases and you start getting a feel where all the edge cases actually lurk.

Did this guy have a math background? Was he coming up with the solution to the problems on his own from scratch?

Amen on the Moneyball approach.

At my last company, we did a traditional interview plus a pair programming interview. Eventually, we moved the pairing interview up in sequence, because it gave us far more information than the traditional stuff. It let us see what they could really do, and told us a lot about how they worked as part of a team. Mere questions don't get at that.

We also paired most of the time in the course of our work, which gave us a lot more room to take hiring risks. If somebody was bad, the amount of damage they could do was limited. If somebody was just uneven in skill profile, pairing let us take advantage of their strong points while mentoring them in their weak points.

I'd love to hear what else people using a Moneyball approach are doing to reduce risk and increase yield after hiring.

> startups are also probably rejecting a lot of engineering candidates that would perform as well or better than anyone on their existing team, because tech industry hiring processes are folkloric and irrational.

That sounds right to me, but I'm wondering if there's any evidence to support the claim.

To me, the smoking gun is the fact that there is near-universal agreement that we're in a talent crunch, but at the same time successful startups are demanding that candidates accept temp contracting roles to mitigate the risks of bad decisions.

Couldn't that be because startups have to "lower their standard" for engineering interviews, since there's a shortage of people who will perform up to their standard in an interview? In other words, if there is a shortage of experienced candidates who can nail the interview, startups might be willing to go for people with less experience who they believe will be able to learn quickly and end up being valuable team members.

Of course, this assumes that a trial (say, 30 days) can give a lot more information about the long-term potential of the candidate than a day-long interview, which feels like a reasonable assumption to me.

For some companies the standards are not entirely meaningful. Must have 3.9 GPA from an Ivy League school, know [obscure library] in detail, have experience in Scala and Lua and OCaml and Julia, as well as a deep passion for cricket. Then, once this person is found, they put them to work building a Rails CRUD app... There is some hyperbole here, but not too much.

I think I lost one job because I used emacs and they used vi.

I'm not wholly disappointed, because 1) I finally got around to using vi, spending a solid week using it and only it, as my homework[1] for the company, and 2) you don't want to work someone that only hires clones of themselves.

[1] They didn't assign it to me, but I'm always looking for something interesting to do, and since I was serious about wanting to work for them I did it to ease my eventual on-boarding.

A company-specified text editor is a indicator of an unbearable degree of micromanagement.

Be happy you don't work there.

They did a lot of pair-coding, so I'd see a common development environment as acceptable.

Sounds like one of those 'boutique' consulting agencies that likes to build 100% mandatory pairing into their costs when billing clients for their sake.

Are you sure you didn't get the job because you used emacs? I can't see why that's a reason for not hiring you. As markrages says, if this is true, it's some inconceivable degree of micromanagement.

This comment is the vulgar truth.

The industry wants hordes of people who color by number with the newest frameworks, not hackers.

The question as I read it is, is there evidence that conventional hiring practices are ineffective?

I didn't provide evidence, but did point out what I see as a smoking gun, which is the trend of temp-to-perm hiring.

Temp-to-perm is not conventional hiring; if you do it, you are not hiring the way AmaGooBookSoft hires. That you would do it at all suggests that the conventional hiring process isn't effective.

At the same time, temp-to-perm makes it harder to find people; it (almost) has to, since asking a candidate to accept a monthlong (or even weeklong) contract is onerous. People forget that candidates often interview at multiple companies; a week off work seems reasonable when you don't consider that it's a process that might repeat 2, 3, or 4 times for a given candidate.

> The question as I read it is, is there evidence that conventional hiring practices are ineffective?

There is clearly evidence that the entire hiring process leaves much to be desired. Temp-to-perm is obviously not ideal. I'm just wondering whether the problem is that companies are relying on the temp-to-perm pattern in lieu of better available alternatives, or if the temp-to-perm pattern is simply the best option because there is genuinely a short supply of experienced, easily recognizable talent.

In the last 10 years, I've never interviewed anywhere on the east coast that wasn't 3-month contract-to-hire. Then again, that was all through recruiters. I don't work as an employee anymore, and I don't deal with recruiters, so I'm not sure what it's like now. However, there doesn't seem to have been any sea-changes in the market around here, so I suspect everyone is still doing it.

Really? I'm in the Boston market, and we don't use contract to hire as a strategy, and to my knowledge, none of our primary direct competitors for engineering talent do either.

(We will occasionally hire an ex-contractor, but that's the exception and they were genuinely a contactor first. No one comes through the front do applying for a full-time position and gets offered a contract-to-hire.)

Well, to be fair, I hadn't ever applied for anything in Boston. Also, I acknowledge that not all places may do this, just that I've never encountered one that didn't. Which could say more about the quality of the recruiters I was using than anything else.

Basically, in a 300 mile radius around Washington D.C. there is apparently a shit ton of little, bullshit consulting agencies. There are at least two in even the small towns. Bullshit consulting agencies are the type I'd expect to do contract-for-hire.

It's also, for no reason I understand, the only types of places that would ever look at my resume. Perhaps that is because the alternatives to the consultoware places are health insurance companies (which I patently refused to apply to) and financial services companies (also not terribly appealing). Those sorts of places always looked like they were exactly the same sort of poorly managed shit-show as the consultoware places, just that the client was in-house. Not much consumer-facing software being made out here, I guess.

Mitigating risk by contract-to-hire might be reasonable in some European countries where firing is rather complicated. But, what's the problem in US? I thought it was extremely easy to fire people there.

Most European countries allow a probation period, in which you can terminate the employment contract very easily. It's not even reasonable in Europe.

You are qualifying this with the word "successful", but is it really the case that high-quality candidates are putting up with temp contracting roles in lieu of an immediate "permanent" position? That seems like prima facie evidence that there is not, in fact, a shortage of high-quality candidates.

The later says nothing about the former, IMHO. Even if there's a crunch, a bad hire is a bad hire.

The point isn't that bad hires have become less tolerable; it's that conventional interview practices are so unreliable that startups have taken to doing things that actually make it harder to attract candidates in order to mitigate their risks.

Good point.

"if I've hijacked the thread here, let me know"

Excellent information. You gave some thought to the process and stopped going for the legacy solution to the problem.

Would like to point out to anyone that you can actually do a version of this even when the company isn't doing the last 1/3 and being the one that is creative. That is you find a way to separate yourself from the crowd in a way that removes the resume, interview and credentials from the evaluation process.

My example of this is to go for the job that isn't being advertised or that the company isn't even hiring for so you aren't competing with the other person with a better resume.

I did this when after I sold my first company I landed a sales job at a tech company never having sold that type of product and really having very little experience (in that) at all. They weren't hiring so I wasn't being compared to anyone else just to whether I could do what I proposed to them. For that matter anytime I sold a product (for something for two different new companies I founded) at the start by cold calling I was doing a version of the same thing. They just evaluated whether they needed the product/service not whether I had something better than the other people who visited.

I guess the bottom line is whether you are looking or "looking for" you need to do outreach which is really just selling in a creative fashion.

From my brush with Matasano recruiting, I have one main thought.

When I got the first phone screen, I mentioned that your hiring page said to expect about a month-long hiring process. The response was that that was for someone with experience in the field. OK.

Since I had no relevant knowledge/experience, you (I'll use "you" to refer to Matasano) sent me WAHH, and said to read it, and contact you when I thought I was ready. I wrote back, asking how I'd know when I was ready (remember: no knowledge or experience). No response, ever.

I hope the prerequisite to interviewing at "entry level" in Matasano isn't full mastery of everything covered in WAHH. The last of my textbooks that I've looked at and thought "I know everything in here" was my middle-school algebra text (this one: http://www.amazon.com/Algebra-Structure-Method-Book-1/dp/039... ). And there could easily be something mentioned in there that I don't know; I made the determination by looking through the table of contents. Every one of my later textbooks mentions something I don't know in the table of contents.

I don't think I've just failed to accomplish anything at all since taking middle school algebra, and even restricting discussion to school math classes I have some accomplishments beyond that point. So the impression I got was of a ridiculously unachievable standard for interviewing, that maybe I'd be ready to interview after several years of work in the field. Or maybe not.

1. you didn't tell them you were ready. instead, you asked irrelevant questions. how are they supposed to tell you when to feel ready?

2. you sat around and waited for them to contact you. they have other, better shit to be doing, i assure you of this.

3. being aggressive and having initiative and believing in yourself is a big part of getting hired. if you don't have those things, you probably won't get hired in a competitive environment.

>> Tell us when you're ready.

> What does "ready" mean?

That's hardly an irrelevant question; it's impossible to know that you're ready without knowing what being ready entails. Are you trying to select for people who are confident they can already do anything no matter what it is?

"ready" means "ready to move forward in the interview process". What else could it possibly mean in this context?

Well, the definition of "ready" you offer seems to be something like "desirous of concluding the interview process quickly". I want to know about the useful sense of "ready", "likely to conclude the interview process successfully". Quickly getting a rejection is of very little benefit. Obviously, when I first contacted them I wasn't hoping to prolong the interviews as long as possible; they told me that I wasn't ready to continue at that time. But they also told me that I should be the judge, based on no criteria, of when I was "ready" to continue.

I'm not sure why you think what I said means "desirous of concluding the interview process quickly", because I didn't use most of those words and you appear to have pulled them from thin air; frankly, that's weird.

They gave you plenty of criteria; they gave you a book, and the understanding that they wanted you to be able to talk intelligently about the material that the book covers. If you're so incapable of self-introspection that you can't accurately judge how well you understand material without external validation, then you should probably work on developing some self-awareness before getting upset that a company doesn't respond to arbitrary requests for meaningless information.

> I'm not sure why you think what I said means "desirous of concluding the interview process quickly", because I didn't use most of those words and you appear to have pulled them from thin air; frankly, that's weird.

I rephrased you because, if I just quote you, there's no indication that I understand what you mean by the words. You seem to indicate that I in fact didn't. I'm going to call that a success for rephrasing. If I get you wrong, I hope that you'll tell me what you actually meant, which you didn't do here.

Let me try saying things another way. If I ask, "what does 'ready' mean?" and you reply "it means 'ready to move forward in the process'" (my emphasis), you've defined "ready" by reference to itself, which is obviously incapable of being helpful. So I did my best to determine what you might have meant. The entirety of my complaint is that, lacking domain knowledge, and faced with a job ad saying "no knowledge is necessary to apply", I was told "you're not ready to apply, come back when that's no longer the case" and then, upon asking, was not given any guidance as to how to determine whether I was or wasn't ready. So, in answering the question "am I ready to move forward in the process?", all I can do is devolve it into the question "do I want this process to go forward regardless of the outcome (which I can't predict), or would I rather remain paused?". That's purely a question of, in the words I used before, how quickly I want to conclude the process. I can't refer to any other variables or goals, because I can't evaluate those.

> If you're so incapable of self-introspection that you can't accurately judge how well you understand material without external validation [...]

Nobody can do that. Try evaluating yourself without external validation sometime. If you score e.g. a "good", ask yourself "good in terms of what?" External validation is the only thing giving any meaning at all to evaluations.

I didn't define "ready" in terms of itself (unless you're unclear on the literal definition of the word "ready", in which case you'd be better served looking in a dictionary than applying for jobs); I gave an expanded context for the term.

This is not a hard concept here; I would rate it as slightly more complicated than walking and talking at the same time, and slightly less complicated than walking and texting at the same time. So, uh, you probably shouldn't walk and text because you'll hit a tree or fall into a pit. Just some free advice there.

If you're capable of forming memories, you're capable of self-evaluation without external validation, you goofball. "Good in terms of what"? Most people choose "how good [I was] before [I] started studying" and it seems to work pretty okay for them.

he's trolling you.

The tendency of people to troll by acting like a complete moron baffles me. I can't help but think "Congratulations, you've successfully managed to be a moron".

It's kind of like the Turing Test -- relatively easy for a simple program to simulate insane or stupid humans.

"the crypto challenges, which are currently by far our most successful recruiting vehicle (followed by Stripe's CTF #2) are just a series of emails we send; they're essentially a blog post that we weaponized instead of wasting on a blog."

I kind of hoped you are at least looking on our answers or something :)

What surprises me is that plenty of engineers have remarked how a basic knowledge of algorithms and data structures has been the key to getting hired, rather than the ability to write good code or solve problems that are similar to the ones a candidate would actually have to solve. Those are not tested in interviews.

Given that background, given that people are trying to improve the recruiting of engineers, given the penalty applied to people who recruit for the standard package, given the rewards for those who recruit accurately to their needs, .... why does the "irrationality" persist?

I don't know if Matasano is a nice place to work at (well, friends there have been happy, so I guess I do have some information), but it sounds like a wonderful place to interview for. Enjoyable instead of actively painful and stress-inducing.

If someone doesn't make the cut, what does Matasano say? Do you say what didn't work out, or is it the industry standard and horribly antiseptic "we have decided not to move forward at this time"? I'd understand the latter, but if there's a place breaking that mold, I think it might be you guys.

That sounds fantastic. The few times I didn't get an offer from an interview (early in my career), the "we can't tell you more in case you sue us" answers to why I didn't get the job were as crushing as the actual rejection. I always felt terrible having to give that answer when I worked for a big company, particularly for the marginal candidates. The terrible candidates aren't going to be able to improve enough to game the system, so there's no real risk to giving them the information as well.

we interview people whose only prior work experience is "Line of Business .NET Developer"

I'm assuming you are not interviewing every or even most.NET developers and trying your luck to find the one who can write that great exploit. So, from all the candidates with resumes that would be considered subpar before the process overhaul, how do you determine which ones have potential to write that great exploit?

That's what a work-sample test is. Candidates here do a series of challenges that are quantifiable (scored), and calibrated to match the day-to-day of working here. We don't ever wonder whether a .NET developer is capable of reverse-engineering a protocol and finding security bugs in it, because we invented a series of protocols and a series of security bugs, and we make candidates try to do that.

Ah, I thought the test was given during the in-person interview.

We recently started putting sales candidates on the phone to cold call. The most critical thing we measure is how many minutes they spend on the phone. It's been a pretty strong signal of how they would perform if we were to hire them.

Sales is a different beast.

If you need 2 sales guys, hire 3, give them a month and fire the worst one.

That is horrifying to me as a developer, but apparently this is fairly standard for sales.

First place gets a Cadillac, second place gets steak knives, the rest get fired? (a quote from Glengarry Glen Ross)

That's a BIT of an overstatement depending upon the particulars. Outside sales for complex products can require a quarter or two ramp-up so you want to be somewhat selective. If you're hiring someone for that sort of position though they probably have some sort of track record.

For an inside sales position, you're not all that far off though.

As I've seen it put in another discussion, "sales managers don't have any trouble firing people."

That is a classic work-sample test.

This might be obvious to those with more sales experience, but can you explain what exactly you're looking for in regards to "how many minutes they spend on the phone"?

In other words, is the success of the sales people about spending more time on the phone in total? Or is it about spending more or less time per call?

Thanks in advance!

This might be obvious to those with more sales experience, but can you explain what exactly you're looking for in regards to "how many minutes they spend on the phone"?

Our sales process is based on our reps cold calling businesses. We learned after a couple of mishirings that the most difficult part of the job is being able to manage emotion and taking rejection. For example, as a rep it is completely normal to be rejected in some manner 50 times a day. So if you get discouraged or upset after your third rejection, it is unlikely that you would have the motivation or drive to make more calls and therefore, you're likely not the right fit. All of this is usually summed up in the metric time spent talking across all calls.

While ultimately the time on the phone translates into revenue, we like to emphasize factors that is in our control. We can't control whether someone ultimately signs up or not but we do control how much break we take in between calls.

If applying for Matasano is as fun as microcorruption I might as well apply there. Do you consider H1B candidates?

Through the Matasano challenges, for one.

Our public challenges are part of outreach, not qualification. We are very worried about drawing conclusions from them in our hiring process, because those challenges are public and people often work together on them.

Don't stop, thanks to the two public programs you've run so far I've:

* Got into Ruby and Go (trying to get a feel for what language felt most comfortable for bit manip.)

* Got into assembly (for fun so far)

* Got a good appreciation for bit-level operations

* A bazillion more little facts and insights that help in daily work life

I bet if you polled how it's helped other people there'd be all kinds of great examples. For work, I'd say the best impact has been a personal drive to pentest our own product, resulting in a lot of bugs found and fixed. That included managing to root our servers via a product flaw, which was scary and amazingly fun.

So yeah, thumbs up, don't stop now (please).

As for the above catering to newcomers, sure but it ramps up incredibly and pushes some boundaries if you've never touched that stuff before.

The public challenges seem to embrace newcomers. Assuming someone does well on their own - should that person expect to do well in the hiring process? Or is there a significant difference in skill set / level between the public an private tests?

I am in Greater Chicago, I have seen your outreach before..glad to know its working...

> we over-communicate and sell our roles before we ever get selective with candidates

Sorry, I'm a bit confused about this sentence. The roles your selling are the roles you're hiring for? I guess even if that's true I don't understand what you mean by selling roles before getting selective. Would love some clarification!

The typical candidate at Matasano spends ~45 minutes talking to me or Jeremiah (the two of us are very senior and currently co-manage recruiting) before they ever get teched out. In that phone call, we try to answer every question the candidate might have about the role, and do our best on the phone 1:1 to sell our firm to the candidate.

What kind of experience does the average applicant have? As a 27 year old dev the process you've described sounds as terrifying as it does exciting.

For instance on the challenges I liked that you put (largely paraphrased here) 'If you breeze through these we might want to talk to you.'. Having ploughed/struggledto set 5 now it's almost daunting to think people DO breeze through that. Granted, the stats you've published so far indicate those people are far and few between. It kind of puts you in your place, but the exciting part comes from knowing there's so damn much to learn still.

What is the very specialized niche that is especially demanding of software development skills?

Software security. We take products that 4-8 person dev teams spend 9-18 months building, and, in 2-3 weeks with 2-3 people, essentially compete with those teams to find clever vulnerabilities they left in their code. Particularly on non-web projects, this often involves reverse-engineering from binary and quickly tooling up for bizarro undocumented proprietary protocols and APIs. If you're a startup, you hire for Rails, or low-level C database stuff, or iOS, or distributed systems. For us, switch those or's to and's.

Security audits and the like. tptacek is the founder of http://www.matasano.com/

I know the company and I know about tptacek from HN, even a friend worked there a few years ago. I just wanted to understand if they were in some new specialized niche.

Sure. I'm just explaining how someone could conclude that hiring for a software security team is actually harder than hiring for a typical startup; the skills requirements are close to a superset.

Could it be that the specialization you are working with ends up actually be a benefit with regards to finding new hires?

From my perspective, I'm probably not going to go out of my way to apply to a typical startup unless there is some reason to believe the renumeration is remarkable. However, I might be interested in applying to a company like yours as a challenge to myself.

That happens. For example, to be a low level 3d engine programmer is a quite specific skill, yet because of the nature of the games industry, such people don't get paid as much as your average full stack web developer.

Yes, I used to work in the security field and almost every project was an adventure, a challenge where you also need to learn at the speed of light.

Regarding work sample test, what about candidates who don't have several hours to waste doing homework for each interview?

They should apply elsewhere. Seriously.

If a candidate doesn't have "several hours" to engage in a process intended to lead to both sides investing thousands of hours over the coming several years, they're welcome to apply elsewhere.

For every time I've interviewed, I've done several hours of homework on the company, understanding their competitive position, reading their financials (if a public company), founder bios (if a startup), bios of the people I'll be meeting with, etc.

I'm not doing this out of desperation; I'm doing it because I'm picking the company just as much as the company is picking me. Conversely, I'm willing to "jump through hoops" provided I believe that the company believes that hoop is helpful in selecting strong employees, because ultimately, I want to work at a company with strong colleagues and the hoop is a signal that the company wants the same thing.

Fair disclaimer: I haven't applied anywhere in the last <long time> and in my 20s, I enjoyed the take-home programming challenges. To this day, I recall enjoying Acclaim (game company)'s take home test that was rudimentary AI for a turn-based very simple game. I crushed it, flew out to interview, and got an absolutely laughably low offer (par for the industry), but I still think fondly of "doing that homework".

I've also been asked head-scratchers before. I had a recruiter ask my GPA and SAT scores for a role in my late 20s. Wait, WTF did you just ask me?! I answered, and that firm (D. E. Shaw & Co.) was the most-talent dense firm over 5 employees that I've ever experienced. If I'd have indignantly replied that my SAT scores were irrelevant to the position and none of their damn business (both are arguably true), I'd have missed out on one of the best work experiences of my life (and two handfuls of those colleagues are still working with me today, 3 firms and 17 years later).

Anyway, sorry for the long response.

Shorter version: You're picking the company. Do your homework.

They're picking you. Do their (reasonable) homework if you believe they're assigning it for the purpose of giving you great future colleagues.

All reasonable points that I agree with. It presumes, though, that the companies you are interested in turn out to be as respectful of candidates as you are of selecting them and complying with their hoops. This thread is full of anecdotes about (predominantly SV) companies who disrespect candidates by misrepresenting their hiring process, setting up meaningless hoops, rejecting candidates after hours or days of work for nebulous "culture fit" reasons, or simply going silent in the middle of the process. If you are a candidate who has invested multiple hours multiple times for disrespectful companies like these, you would probably develop the attitude fsk posted about. Its a bad place to get into, and unfair to both the candidate and the companies who do respect their candidates. Unfortunately, aside from the rumor mill I don't know how to tell which companies are respectful and which aren't until after investing multiple hours into the process.

Ah yes. All fair points as well. This is probably another reason why network hiring is so effective. I'd never pull someone from my network into a crappy experience.

Unfortunately, I don't have any useful contacts, so I'm blindly sending out resumes. There's no point carefully researching the company first, because 90% of them never respond, and many companies don't mention their name in the ad. (Some are posted by headhunters, some anonymously by a company.) Even when I research companies and apply directly on their website, it goes nowhere. Even if I did research them, it's hard to evaluate someone until you meet them in person or talk with them over the phone.

I'm currently employed, so I'm only spending 1-3 hours per week on my search.

I have enough experience, education, and honors in school that you shouldn't waste my time with pointless homework. I've never seen a job programming test that was a more accurate measure of ability than the homework and tests I took in school.

Look at it from the candidate's view. I send out a bunch of resumes. About 5-8 of them want me to take a technical test before they call me or before I meet them. 1-2 of them are willing to proceed directly to an interview without insulting me and wasting my time first. So, I focus my energy on the people who take me seriously and treat me like a professional.

It's physically impossible for me to do a technical test for everyone who demands it. I don't have the time.

If Google or Yahoo asked me for a several hour pre-interview screening test, I'd probably do it. If your no-name startup is wasting my time before an interview, I'll just look elsewhere.

Also, in my experience, a pre-interview screening test is anti-correlated with good work environments. Of course, they'll say I'm "not a team player" for refusing the test.

After I did a bunch of pre-interview screening tests, and only rarely progressed to the interview stage after doing the test, now I don't bother. I know my solution is correct, but still not even an interview after I do the test. For the handful that did interview me, I wasn't impressed by them. Why am I wasting my time with people who don't respect me? Why should I waste a couple of hours for the privilege of maybe getting a chance to talk with the hiring manager, who's already pre-qualified himself as a twit by making me take his stupid test?

I'm even reluctant for post-interview programming tests. Once, someone asked me to do an assignment after the interview, and implied I'd get an offer if I passed. I did it, I know it was a good solution, but no offer. There's even people who try to put free consulting in the test, like the guy who asked me to write a program that connected to Interactive Brokers and executed VWAP trades.

I'm even reluctant for on-site tests now. Just a couple weeks ago, someone asked me to do a test, said I could use whatever language I wanted, I picked C/C++, and then they laughed at me for using pointers. Why bother?

If you know your stuff, you should be able to evaluate someone by talking with them for 15-30 minutes. If you aren't willing to spend 15-30 minutes evaluating me, based on my experience and education, then I'm not wasting a couple hours on your stupid pre-interview test.

Yes, I may be missing out on good jobs, but they are missing out on a good candidate.

> I had a recruiter ask my GPA and SAT scores for a role in my late 20s.

I think the question is: could they be used against you?

I don't see how they couldn't, and you wouldn't know.

If they're asking for your GPA and SAT, then presumably they're rejecting you if the number is lower than a certain cutoff.

> if I've hijacked the thread here, let me know; I've said all this before and am happy to delete the comment.

You were voted up because it's a detailed and insightful comment. Thanks for sharing.

Skip the present business model, make a product out of your hiring model. To reach that predictability is worth a lot to most any company.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact