Don't use bcrypt - <AUTHOR> http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html <comment><USER2> This article doesn't feel very well done to me. He writes: "The first cipher I'd suggest you consider besides bcrypt is PBKDF2."

PBKDF2 is not a cipher. It's a KDF, and it's almost always used with an HMAC or a cryptographic hash rather than a cipher. The thesis of this article seems to be "PBKDF2 is well understood, where bcrypt is not." In fact, the opposite is probably true.

bcrypt uses a block cipher (blowfish) to create its underlying compression function. Block ciphers are extremely well understood, have been studied to death for years, and are modeled on extremely well understood constructs. They can be used to create cryptographic hash functions, but usually aren't, because they're slow (which we don't care about in this case).

Cryptographic hash functions, by contrast, are not well understood at all. They are "magic" in many ways, and aren't modeled after anything. Many more "bad things" happen in this space than in the block cipher space. The only reason people mess with them at all is because they're faster than block ciphers, which again, we don't care about in this case.

The other appeal to PBKDF2 is because it "comes from RSA." This doesn't feel like an extremely compelling argument, but if we were going to believe it, then why not use the PKCS#12 KDF? PBKDF2 was proposed in PKCS#5, and "12" is a larger number than "5", so if we're going to do what RSA tells us we should do, they're essentially saying we shouldn't actually use PBKDF2.

<comment><USER3> _Cryptographic hash functions, by contrast, are not well understood at all. They are "magic" in many ways, and aren't modeled after anything. Many more "bad things" happen in this space than in the block cipher space._

Is this a common opinion amongst practitioners? The opposite philosophy (e.g., that a random oracle is a "weaker object" than an ideal cipher) underlies some lines of work in the theoretical cryptography literature.

<comment><USER4> The two models are equivalent, in fact: <http://eprint.iacr.org/2008/246>

This of course says nothing about how to go about building an actual cipher/hash that withstands all kinds of cryptanalysis.

Edit: apparently not so clear, I'm told: <http://arxiv.org/abs/1011.1264>

<comment><USER5> A better interpretation of that paper is that it is giving an upper [edit: upper bound] on how inequivalent the models are.

Also, that paper was subsequently shown to be fatally flawed. <http://arxiv.org/abs/1011.1264>

Anyway, yeah, a theoretical diversion.

</comment></comment></comment></comment><comment><USER6> _> I write this post because I've noticed a sort of "JUST USE BCRYPT" cargo cult... This is absolutely the wrong attitude to have about cryptography._

No. This is incorrect. This is exactly the _right_ attitude for most developers to have about cryptography, because on a subject as complex as cryptography most developers (including me!) are _nowhere near smart enough_ to understand the ins and outs.

Encouraging people to make their own decisions on subjects they aren't equipped to understand fully is dangerous advice. It leads to all sorts of bad outcomes. People who have to choose between options they don't really understand end up choosing things at random, or on the basis of incomplete or misleading information, or getting seized up by the need to make a choice and choosing nothing at all.

This makes cryptography one of the _very few_ cases where a cargo-cult approach is better than the alternatives. A simple message that "this is the approach people smarter than you agree is correct, use it," repeated consistently, will help more people more completely than dumping them into the deep end of the crypto pool ever will.

<comment><AUTHOR> You're defending cargo cult cryptography? If you try to use crypto without understanding it, you're at great risk of using it wrong.

<comment><USER7> The opposite turns out to be true in practice. People have the choice of using a simple crypto library interface (like BouncyCastle PGP) or "really getting to understand" AES, and so end up fielding software with vulnerabilities PGP addressed in the '90s.

A pithier way to say the same thing is, "you're right, except for the words 'without understanding it'".

</comment></comment></comment><comment><USER7> PBKDF2 is worse than bcrypt.

scrypt is better than bcrypt.

bcrypt has the advantage of being both very good, and also broadly available on web platforms. scrypt does not yet have that advantage; when it does, I will start saying "just use scrypt".

But the simple fact is: _all three of these functions are fine_. ANY of them is a huge step forward from what people do without them.

"Just use bcrypt" is 1000x more effective as a meme than "just use adaptive hashing" (which is what all these constructions are).

So, while I have few specific technical qualms with this article (e.g. why do I care whether something is a PKCS standard or not?), the overall message is a bit hyperbolic.

<comment><USER8> _PBKDF2 is worse than bcrypt._

By roughly a factor of 5.

 _scrypt is better than bcrypt._

By roughly a factor of 4000.

 _why do I care whether something is a PKCS standard or not?_

You don't care, and I don't care, but I'm sure you know lots of companies which do care (especially since PBKDF2 is a NIST standard too).

<comment><USER9> When we were looking at password hashing, and the choice came down to bcrypt or scrypt (about a year ago, so recently enough), I said we should go for bcrypt because scrypt was comparatively new; inasmuch as it makes a difference, it's just had less time to be attacked.

Was I wrong?

<comment><USER10> its a sane decision. just make sure you implement properly. like everything crypto, it will be broken, eventually. but its a safer choice than a new algoritm.

it reminds me of the vulnerability issues. when apps have no known vulnerabilities, all is fine. when a new "instant root compromise of any system" comes out, its omgomgomg. Then its fixed, and all is fine again.

Except that vulnerability was always there. And other ones that are yet to be public are there too. And many of them are "omgomgomg" material.

Well crypto is the same. We don't have public data on which algorithm are broken. We just know they will be eventually, by logic or by brute force.

So, take the wise decisions, and don't forget you might eventually need to update it.

<comment><USER11> This is a naive attitude. Mathematically-secure cryptography with an implementation that avoids all side-channel attacks is _unbreakable_ , as in, would take more time than the projected heat death of the universe to brute force.

That's not to say that all implementations are secure, or that there are not undiscovered mathematical flaws in common algorithms, but the idea that all encryption is brute-forcable given enough AWS instances is just plain incorrect.

<comment><USER12> How do you know that mathematically-secure cryptography can actually exist?

<comment><USER13> This is not related to password hashing algorithms being discussed here, but:

mathematically-secure cryptography was invented in 1882/1917: <http://en.wikipedia.org/wiki/One-time_pad>

Fun further reading: <http://en.wikipedia.org/wiki/Venona_project>

Also, fun reading: The Code Book by Simon Singh, and Spycatcher by Peter Wright

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I'm a web developer, so while security is obviously a huge concern, it's not my main area of expertise. I don't have the knowledge to evaluate the pros and cons of each cipher, and the situations in which it's appropriate to use each one.

It would be wonderful if someone with more knowledge of the subject could throw up a 1-page site with an appropriate security choice (or a few choices with situations in which each would be more acceptable) for a given range of situations, to establish a 'sane default', taking into account their availability on a number of platforms and programming languages.

For example:

      Need to sign a message? Use HMAC-SHA1
      Need to checksum a file? Use SHA-1
      Need to hash a password? Use bcrypt
      Need to transmit data over a network? Use SSH2
      Need to secure HTTP? Use SSL 1.2 with (these ciphers in order of preference)
      Need to secure home WiFi? Use WPA2-PSK
      Need to encrypt files? Use GnuPG
      Need to do (this type) of encryption? Use CBC. For (this type), use ECB
      Need to create a TrueCrypt volume? Use (this cipher) with (this many) bits.

<comment><USER15> I guess the question is - who do you trust to make these calls?

In this case, the answer probably is OWASP which is a great and often overlooked resource, contributed to by a lot of experts in the area. They have a lot of pages in their wiki that address crypto concerns...

<https://www.owasp.org/index.php/Guide_to_Cryptography>

[https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_...](https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet)

<https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet>

<comment><USER7> OWASP is a great resource with a terrible track record for application cryptography.

<comment><USER15> Whoops, I will stand corrected.

Casting my eye over the recommendations in the pages I linked - yes some of it seems to be a little behind the times (for instance, adaptive hashing isn't mentioned once in terms of securing passwords), but none of it seems outright terrible.

Is this something that the crypto community/experts can come together and improve the same way as the vuln/exploit security community have made OWASP what it is?

Or is the real truth that executing proper crypto techniques are simply to difficult to boil down into a pile of cheatsheets?

</comment></comment></comment></comment><comment><USER8> > _While scrypt's cryptographic soundness, like bcrypt's, is poorly > researched_

I think we may have different notions of what "poorly researched" means.

<comment><USER16> I think he meant it hasn't undergone the same level of public scrutiny. You've certainly spent ample time researching it, and it's obviously been tested, but possibly not as much something like AES.

<comment><USER7> bcrypt is better tested than PBKDF2: far more publicly "testable" systems use it (bcrypt was the password file format for OpenBSD).

<comment><USER17> was?

<comment><USER7> In the sense of "that's where it came from".

</comment></comment></comment></comment></comment><comment><USER18> I like this article. But this sentence is odd.

> […] _with an academic pedigree from RSA Labs, you know, the guys who > invented much of the cryptographic ecosystem we use today._

Appeal to authority fails a little bit when RSA opens random Excel attachments from unknown untrusted sources - attached to an email that have to be retrieved from the junk mail folder.

(<http://blogs.rsa.com/rivner/anatomy-of-an-attack/>)

EDIT: As other commentators point out, I am wrong to suggest that anything coming from RSA Labs is somehow "weak" because someone at RSA fell for a phishing attack. I do find it odd that a security article suggests "These people are good; they did 'this thing' which everyone uses". That's not a great way to approach choosing crypto components. Even experts make mistakes.

<comment><USER19> As does ad hominem...

Edit: realized I should probably explain. What an administrative assistant does in a social engineering attach has nothing to do with the quality of cryptographic research at RSA. Humans are ALWAYS the weak point in cryptography.

<comment><USER20> No, ad hominem is "You're wrong 'cause you're a jerk." DanBC pointed out that their opinion might not be as above reproach as is often assumed because of past lapses in good judgment.

<comment><USER19> _Ad hominem is an attempt to negate the truth of a claim by pointing out a negative characteristic or belief of the person supporting it._ [1]

That sounds pretty much like what happened above. The truth item is whether RSA's cipher chops can be respected. The negative characteristic is an HR person succumbing to a social engineering attack. Ad hominem isn't just calling names.

Let me put it differently: in what way does the HR rep's mistake reduce the quality of ciphers that have come from RSA?

1\. <http://en.wikipedia.org/wiki/Ad_hominem>

<comment><USER21> Ad hominem is an attack on the person whose argument you're trying to disprove. Here, that person is the one who wrote the article, not RSA.

The argument "X is safe because its creator, Y, has a good reputation" can certainly be refuted by attacking the claim that Y has a good reputation. It's not an ad hominem.

The fact that the error by the HR person doesn't actually invalidate RSA's reputation as cryptographers is more a Non sequitur.

</comment></comment></comment></comment></comment><comment><USER22> I guess it's hip to have an opinion, but JUST USE BCRYPT. It's secure and available. Don't spend time thinking about it, just use bcrypt, it does everything you want, move on to something more worth your time.

Unless you're some blogger who needs to generate some page views, then pick some obscure topic like how to store password hashes and rake muck.

<comment><USER23> > JUST USE BCRYPT

multiple things come to mind:

\- Millions Of Flies Can't Be Wrong

\- Citation Needed

\- JUST USE SCRYPT

etc.

</comment></comment><comment><USER24> I wouldn't exactly call "just use bcrypt" a cargo cult. It has had real benefits to the web dev community because it factors down to "don't store it in plain text or use MD5 or something".

Several people working on small projects have already come to me and asked me "what's this bcrypt thing? should I use it here?" I guarantee these folks would have just stored it plaintext otherwise. So I've directly observed the mantra making stuff safer. Win.

<comment><USER7> I strongly agree that when asked by friends what to use, you should think about _which library is going to be easier for them to use_ , and not try to think through which construction is "better". That this blog post gets the real ordering of betterness wrong is tangential to the real problem, which is that it gets the value proposition of bcrypt wrong.

</comment></comment><comment><USER25> Microsoft uses PBKDF2 for newer domain cached credentials (DCC2). These password hashes are stored in the registry of Windows clients (laptops and desktops) and allow users to logon when the domain is unavailable. They use 10240 iterations. It's very compute intensive to crack... roughly 330 guesses per second. Great article BTW!

Edit: I only post this to add to the examples of who uses PBKDF2 in addition to what the article lists.

</comment><comment><USER26> Oddly enough, this article prompted me to setup bcrypt hashing for our unreleased app. I tend to not follow the tide when it comes to people screaming on the internet about something. People get highly emotional about the "next big thing" and defend with every ounce of willpower the decisions they've made. While I understand this mentality, it can make it hard to be objective.

Seeing an article where someone disagrees with the buzzing hive mind is always refreshing for me and made me actually consider, for the first time, that an algorithm aside from sha1(app_salt + user_salt + password) would be a good idea.

I did some research and decided that for PHP, bcrypt is the absolute easiest option to implement. scrypt is too new, PBKDF2 while administratively accepted has much less info on using it in PHP than bcrypt does.

So while I ultimately ended up disagreeing with the author, the article was invaluable in the end.

</comment><comment><USER27> _However, if you're looking for a key derivation function for a new project, bcrypt is probably not the best one you can pick._

I'm confused. Why would I pick bcrypt as a key derivation function when there are nice key derivation functions out there that are widely documented?

<comment><USER28> As stated in the article, a popular stance on Hacker News and Stack Overflow is "USE BCRYPT". It's chanted to crypto-noobs and webdevs as a simple-to-use library for password storage that is more secure than MD5/SHA/Whatever hashing, and with built-in salts.

The whole point of this article is to say that, in fact, there are other options.

<comment><USER7> Bullshit. There is one very-well-written article at Coda Hale's site that says "just use bcrypt", but in discussions of adaptive hashing on HN, people who know what they're talking about are continuously at pains to vouch for PBKDF2 and scrypt (it helps that one of the people who knows what they're talking about on this subject is (a) vocal on HN and (b) designed scrypt).

It irritates me that despite going through the effort of vouching for PBKDF2 and scrypt every time this f'ing topic comes up on HN, people still manage to reduce this issue to another tribal conflict.

And who are these "crypto noobs" you speak of?

<comment><USER29> _Raises hand_

It's important to know what you don't know. And I know enough about crypto to know that I don't know anything and should listen to people who do.

</comment></comment></comment></comment><comment><USER30> I wasn't aware that anyone suggested using bcrypt for key derivation. The idea, as I understood it, was to avoid writing your own password hashing implementation. Bcrypt is a complete password-hashing implementation, so use it, rather than cobbling something together yourself. This is the standard advice for cryptographic software.

PBKDF2 isn't a password hash: the specification doesn't define a storage format for iterated, salted password hashes. It's not that hard to invent one if you already specialize in writing cryptographic software, but most programmers still shouldn't be doing that. It's just too easy to make mistakes that go unnoticed until it's too late.

If you insist on using PBKDF2, then I suggest using my PBKDF2.crypt() implementation at <https://github.com/dlitz/python-pbkdf2>. I'm not a cryptologist, but I'm the maintainer of PyCrypto, so presumably I can be trusted to do a better-than-average job of this sort of thing. If people want, I'll write a proper spec and add SHA256 support with a different algorithm identifier (the current implementation still uses SHA1).

But really, if you need a password hash, just use bcrypt and get back to writing the code that actually provides value to your user base and differentiates you from your competitors. Bcrypt is good enough for now. _This advice might change in the future,_ so do pay attention, but for now, just use bcrypt.

</comment><comment><USER31> So the author says to use PBKDF2 because it's researched and tested better than bcrypt, and then suggests scrypt as another alternative despite having, from what I can tell, _less_ research done on it than bcrypt.

The crypto space can be intimidating to your average dev, but almost every app needs some sort of protection (at least for user information). I think the author is fair in wanting to push for the "default" to be PBKDF2 instead of bcrypt, but should he really be advocating a less-tested function in the same article?

<comment><USER7> Is there a reason other than branding that you think it's fair to push for PBKDF2 to be the "default" instead of bcrypt?

<comment><USER4> To be honest, I don't see why anyone would use bcrypt over PBKDF2, if the security of the primitives is of any serious concern. I am new here on HN, so I'm not aware of your arguments on why bcrypt is better than PBKDF2.

As for the "branding" question, would you recommend XTEA or MARS or Threefish over AES for someone in need of a block cipher? Of course not. Standards are not always perfect (and many a flaw has been found in standards), but they are generally beneficial.

PBKDF2 also has the advantage of being modular. It takes in an arbitrary PRF (although HMAC-SHA1 is the usual); maybe HMAC-SHA1 turns out to be poor for the job, just plugin a better PRF (hell, you can plugin a provable PRF that reduces to integer factorization or the elliptic curve discrete log). bcrypt is just bcrypt --- a seemingly not too peer-reviewed modification of an ancient cipher, that is not even recommended anymore.

scrypt is better than both, of course. Provable time-memory hardness is great, and should be made standard.

<comment><USER7> It takes an arbitrary PRF that is in practice virtually always SHA2, and practically always a well-known cryptographic hash function. If you're going to bank on a cryptographic primitive and you have a choice between "cipher" and "hash function", you pick "cipher".

Also, for lay developers, choosing a crypto construct for its modularity is like choosing a smoke detector because it allows you to use different radiological bits in it. _You're not supposed to be messing with those bits_. The whole point of the package is not to have random developers changing them.

Also, I want you to note something:

You pick AES not because it's a _standard_ but because it's the product of a contest in which many of the world's best cryptographers competed to design the replacement to DES. _That's not what PKCS standards are_. A PKCS standard is simply something that survived a standards group discussion.

<comment><USER4> I see you've adopted Moxie's argument, block ciphers against hashes. Very well. The hard part of designing a good hash function is achieving collision- resistance; one-wayness is easy. In this context, we don't really care about collision-resistance, since HMAC can be a PRF without collision resistance of the underlying hash (there was a recent proof by Mihir Bellare) --- this is why it's still "OK" to use HMAC-MD5, despite MD5 being completely broken otherwise. The adage that we know much more about ciphers than hashes, although still mostly true, is an exaggeration at this point in time, where we have the HAIFA mode, good block ciphers, and soon SHA-3.

I didn't mean to say that Joe the webdev would be choosing the PRF, that's insane. But whoever providing the (library) implementation would have their life facilitated by having modular primitives, instead of having to code another construct from the ground up.

Edit: True, the AES competition was a much higher-profile event. There is an important difference (this is not a rebuttal, but a remark): AES is a cipher, PBKDF is a construction. AES has no proof of security, nor hope of one: it's a purely heuristic security argument. Through models like the random oracle, however, we could show that the PBKDF construction is secure, if H is secure. In such a case, there is not as much need for a competition, unless you're competing for performance or the like. That said, I would _love_ proofs of security (or show the lack thereof) for PBKDF2.

<comment><USER7> It's not "Moxie's argument". It's also Schneier and Ferguson's argument from Cryptography Engineering:

 _Event hough hash functions are used in almost every system, we know far less about hash functions than we do about block ciphers. This is one of the failures of the cryptographic community. Compared to block ciphers, very little research has been done on hash functions, and there are not many practical proposals to choose from._ †

It is also the reason why we are sponsoring contests to replace SHA2, because the research horizon for the current generation of cryptographic hash functions is... ominous.

You're making a noncontroversial statement (ciphers are better studied than hashes) sound like a controversy. It's not really a controversy. And please note: I didn't bring "conservatism" into this discussion; the blog post we're responding to. If you put it to me directly, I'll say bcrypt is more conservative than PBKDF2/SHA2 (which is what every current PBKDF2 system is going to end up using). But I didn't write a blog post that says "don't use PBKDF2".

† _I say this only to make the point that it's not an argument pulled from thin air or from Moxie comments; something that Schneier commits to writing is, I mean to say, very likely to represent conventional wisdom._

<comment><USER4> You're right, I do recall that passage. Apologies if I sounded patronizing.

I tried to be careful with the wording, precisely to avoid making a common- sense statement into a controversy. Yes, block ciphers are more well-studied (2012-70s > 2012-80s). My point was that the gap is much smaller now than (say) when AES was standardized (I wonder, was that passage also in the "Practical Cryptography" 2003 book?).

As a personal note, I doubt 5-10 years from now SHA-2 will have been compromised for password hashing (or HMAC), though. It has been remarked several times during the process that SHA-2 would have made a great SHA-3 candidate, its only major flaw being length extension attacks. The main fear was that SHA-2 would succumb to the same techniques as SHA-1 and MD5; so far, that has not been the case (perhaps because everyone is fighting it off with the SHA-3 candidates).

Of course, I didn't write a blog post either with anything. I don't blog. Given the choice, I'd give priority to PBKDF2; that's about it. Of course, I'm not a customer-facing developer, so my worries are different.

<comment><USER7> No problem. I think you probably know this stuff better than I do. In practice, I think PBKDF2 really means "PBKDF2/SHA2", and that in 5 years attacker tools will be most efficient for PBKDF2/SHA2, less efficient for bcrypt, least efficient for scrypt, and won't address PBKDF2/AES-256-CBCMAC at all because nobody will know how to code it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> While we agree on the fact that using either of the three can't be a bad thing, I'd like to give my opinion on why I favor PBKDF2 over bcrypt, and probably even over scrypt, although I admit the "memory-hardness" of the latter makes it superior in principle. But still, my reasons for going with PBKDF2:

It's not just that it's endorsed by RSA, no it's actually the NIST recommendation for password hashing and I find it rather unfair that people on this thread turn that against it!

It's the same argument why we generally recommend AES over let's say Twofish or Serpent. We all agreed here that in crypto it's a good thing to be mainstream. And being recommended by NIST makes you Justin Bieber, or not? Standard algorithms may be poor, true, but being a standard has one important advantage: most of the public scrutiny goes into the standard. Much more money and fame there. So it's much more likely that the public will get to know about a flaw in the standard faster than it will get to know about flaws in non-standard algorithms. And that's why I follow standards - even if it's a crappy algorithm, I will know immediately when it's broken and I can react by replacing it right away. The time between an algorithm gets broken and the fact becoming public knowledge is potentially higher the less common an algorithm is. And the time in between being broken and being public knowledge is the most dangerous in my opinion.

I'd like to point out that bcrypt is not equal to Blowfish. It piggybacks on Blowfish's key setup. But note that it just piggybacks, on top of that it further extends the original key setup. Blowfish's key setup was probably never invented to do what bcrypt does now, and the last 30min of googling have not brought up any papers about bcrypt cryptanalysis. Compare that to HMAC. Compare that to using PBKDF2 with HMAC SHA-3 when it's out. I'm not saying that Blowfish or any of its parts are bad, but if not PBKDF2 itself, but then most certainly its building blocks have received a lot more analysis than bcrypt or scrypt. With SHA-3 on the horizon the research community knows a lot more about hash algorithms and there is a lot of research going into these topics. That's why I personally feel safer with a construction that maybe in itself has not received more research than the other two alternatives, but where its building blocks almost certainly have, unless somebody proves me wrong. And when that happens, I'll stand happily corrected and will use the next standard.

</comment><comment><USER33> "that won't help you if an attack is discovered which mitigates bcrypt's computational complexity."

AND you lose control of your database. Even if I had a magic instant bcrypt reverser, it does me no good if I don't have the hashes. You cannot be compromised by a bcrypt mistake, it would only make your already existing compromise slightly worse.

<comment><USER7> And of course that's a nonsensical argument in favor of bcrypt, as it applies identically to PBKDF2 and scrypt.

You could use a similar argument to recommend Elliptic Curve over RSA, or RSA over Elliptic Curve.

<comment><USER33> It's not an argument in favor of bcrypt. It's a rebuttal to an argument against bcrypt.

I have seen several people, whenever this comes up, make the mistake of thinking that your whole app could somehow be compromised by the wrong choice of password hash.

<comment><USER7> I agree that this is a second-tier security issue, as well.

I only got religion about it after reading 100 threads from people bragging about how they'd designed their custom password hashes with Whirlpool _and_ AES-256; in other words, as a nerd tic.

</comment></comment></comment></comment><comment><USER34> To be honest, if anybody breaks into your web application it is very unlikely to be because they broke any encryption. SQL injection or man in the middle type attacks are far far more likely.

What you need out of an encryption package is in the event of being tested for PCI compliance or any legal liability investigation into a breach. You need to be able to say "all of our encryption is done with bcrypt , it's the industry standard an complies with X Y and Z".

<comment><USER35> The debate around secure password storage is sort of orthogonal to initial compromise of a web application.

The reason that it's important (although as others here have noted, less important than primary application security concerns) is what areas of attack are opened up by using insecure password storage "after" an initial compromise.

This could be something as simple as being a nuisance to users of the system (having to send out those "our password database was compromised, and we didn't do a good job of storing them securely, so you should probably change all of your associated passwords), to something much more serious (using said insecurely stored passwords to attack your other systems for example).

PCI doesn't really care how you're encrypting your data at rest. I cracked the password storage from an application once which was literally just a simple substitution cipher (which was positionally dependent...it was for all intents and purposes as secure as a newspaper cryptogram puzzle). That application was PCI compliant.

While "what you need out of an encryption package" might just be the bare minimum of "cover your ass", that's no reason to settle for insecure password storage.

</comment></comment><comment><USER36> Suppose hypothetically you knew everyone using your service used a strong password. Say they all have good password managers that generate 40 character random passwords for them.

Is there then any need to do more than a simple salted hash? (Remember, the hypothesis is that all your users are using strong passwords).

<comment><USER7> The difference in that (obviously unrealistic) case is (I think?) between a cost per password of hundreds of thousands of dollars versus high tens of millions of dollars.

</comment></comment><comment><USER37> TLDR: Use PBKDF2 or scrypt instead.

PBKDF2 has had longer public exposure, and also features an adjustable CPU work factor (though with a lower theoretical safety-to-compute-time than bcrypt).

scrypt is newer, but features both a CPU and memory work factor (memory-hard algorithm), and is algorithmically superior to both.

<comment><USER38> > PBKDF2 has had longer public exposure

I don't know whether or not it's had _more_ public exposure, but I don't think it's had _longer_ public exposure. Afaik, bcrypt's canonical reference document is the June 1999 Usenix paper ([http://static.usenix.org/event/usenix99/provos/provos_html/i...](http://static.usenix.org/event/usenix99/provos/provos_html/index.html)), while PBKDF2's is the September 2000 RFC (<http://www.ietf.org/rfc/rfc2898.txt>).

<comment><USER37> Thanks for the reference, didn't realize that, though I think that's what the article was implying.

</comment></comment></comment><comment><USER19> As long as we've got some smart people hanging around: where does HKDF[1] fit into this? More specifically, when would you use HKDF over scrypt?

1\. <http://eprint.iacr.org/2010/264.pdf>

<comment><USER7> _This makes PBKDFs very di fferent than the general-purpose KDFs studied here. In particular, while passwords can be modeled as a source of keying material, this source has too little entropy to meaningfully apply our extractor approach except when modeling the hash function as a random oracle. Also the slowing-down approach of PBKDFs is undesirable for non-password settings_

<comment><USER19> But, as mentioned by @cperciva elsewhere in this thread, generating a key and creating a password hash are nearly synonymous. Using HKDF for passwords would be silly, but the more interesting question is: when would you use scrypt for key derivation in a system?

More to the point: what are the tradeoffs you'd consider in choosing one over the other?

(Addressed more to @cperciva...) I'm assuming tarsnap uses scrypt as its actual key derivation function for file encryption and authentication. Why scrypt instead of something else (and I have faith that it's not "not invented here" syndrome)?

<comment><USER7> I'm quoting the actual paper.

<comment><USER19> I am aware. I did read it before I posted it.

<comment><USER7> So you think maybe Hugo Krawczyk is mistaken? :)

Short answer: I think scrypt is an advancement over the class of constructions HKDF belongs to. If you're picking nits about which function to use, use scrypt.

</comment></comment></comment></comment></comment></comment><comment><USER39> Note that scrypt uses PBKDF2 before and after the memory-hard function.

<comment><USER8> Only as a cryptographic mixing/expansion function. There is no reason to think that scrypt's security would be any less if the PBKDF2 calls were replaced with xor.

<comment><USER39> Doesn't it provide more protection against possible flaws in Salsa?

Also, somewhat related question -- what if Salsa core in scrypt is replaced with BLAKE core (with fewer rounds than in hash), and SHA-2 in PBKDF2 with BLAKE, thus making it possibly smaller (hardware and lines of code). Will this work well?

<comment><USER8> _Doesn't it provide more protection against possible flaws in Salsa?_

In a very theoretical sense, yes. But Salsa would need to be very very broken in order for that to matter (hence the "no reason to think" comment).

 _what if Salsa core in scrypt is replaced with BLAKE core (with fewer rounds than in hash), and SHA-2 in PBKDF2 with BLAKE, thus making it possibly smaller (hardware and lines of code). Will this work well?_

Probably. I proved the security under the random oracle model, but the property I actually need is approximately "can't be iterated fast", which is a _far_ weaker requirement.

<comment><USER39> Thank you for your answers.

</comment></comment></comment></comment></comment><comment><USER40> Yes, Use Bcrypt. And Scrypt: <http://news.ycombinator.com/item?id=3725284>

</comment><comment><USER41> I know this may be dumb, but why don't we chain all the algorithms, then if one is broken the passwords are still secure.

</comment><comment><USER28> tl;dr

PBKDF2 and scrypt each have supposed upsides to bcrypt and all the benefits.

PBKDF2: RSA tested and widely used. scrypt: memory hard as well.

<comment><USER7> "Memory hard" is a serious benefit that scrypt actually has.

"RSA tested and widely used" is subjective, not particularly meaningful, and in some senses erroneous, and so makes a poor case for PBKDF2.

If people want to seriously push for scrypt as a replacement for bcrypt as the "default" function, I'll design and print flags and pennants for the movement. But when people say "use PBKDF2 instead of bcrypt", I think the net effect is to scare people back to salted hashes, and my general response is going to be to poke holes in their arguments.

<comment><USER42> Question: what does "memory hard" mean? Uses lots of RAM to preclude simultaneous connections running attempts in parallel?

<comment><USER35> Correct.

I just spent the past two days sitting in a workshop on "Special-Purpose Hardware for Attacking Cryptographic Systems" and the most repeating thread from all of the talks was how to deal with the unique memory limitations of GPU's and FPGA's when using them to attack crypto. Bandwidth is the largest one, and specifically the tiny amount of shared memory available to the GPU.

Basically, if you're forced to use "local memory" (which has a huge cost in transaction time), the amount of operations per cycle you can perform goes way down, which in some cases can be the difference between an attack taking "2 years" and "until the heat death of the universe".

<comment><USER43> Just to add to that a little: when comparing these functions it's not so relevant the _absolute_ time consumed; all of them can be tuned to take whatever amount of time is acceptable on the defender's general purpose hardware.

The key factor is minimizing the _relative_ advantage that an attacker with focused resources (such as dedicated hardware) is able to gain over the defender.

</comment></comment></comment></comment></comment><comment><USER44> Long story short, if a bcrypt exploit is found, _you'll be sorry_. So use <http://en.wikipedia.org/wiki/PBKDF2> or <http://www.tarsnap.com/scrypt.html> instead. They're apparently better tested.

I'm no expert opinion, but seems a bit unnecessary and that bcrypt is still a perfectly good choice for most password stores.

</comment><comment><USER45> How is being from RSA labs an advantage? I'd estimate that it's more likely that there are government backdoors in RSA crypto than in other variants.

<comment><USER43> For one, it's something the government uses for its own crypto.

Unlike some crypto standards, PBKDF2 is just something too simple and too user-configurable to be able to hide a meaningful hole in. Given that PBKDF1 was found to be less-than-ideal and depracated in favor of the better PBKDF2, it would be a very risky proposition to attempt to weaken it in a way that gave a meaningful advantage to one party over the other.</comment></comment>


Ask HN: Should we change the way we do software interviews? What's stopping us? - <AUTHOR> https://hxngsun.wordpress.com/2018/03/25/ask-hn-do-you-like-your-companys-interview-process-if-not-what-are-the-reasons-you-cant-or-wont-change-it/ <comment><USER2> It's entirely bullshit, and I regret being on both sides. I used to do coding screens, but I feel like some moderate knowledge of syntax and a decent education is enough to skip the rest. The whole cargo cult of coding screens came up during the 00's when Google made it look important, and you're correct that it's largely an exercise to convince the team that they're special.

Software engineering is the science of avoiding coding! And the code that these elite teams produce is often pure shit anyways.

<comment><USER3> At my work we give coding exercises to interviewees with screen-sharing and give candidates lots of time and as much interaction as they want. The questions we pose are simple and do not require years of algorithmic experience and generally don't involve coding that couldn't be done by somebody with a couple of introductory software courses. Candidates choose their own programming language and environment.

The problems can be solved naively with a straightforward solution, or much more optimally after some further considerations.

The approach is absolutely not b.s., and we observe:

* some candidates completely misunderstand the very straightforward problems posed and their solution has no hope of addressing the issue

* some candidates have a rough idea but can't write the two nested for-loops required, for example, for the naive solution to one particular problem

* some candidates don't ask for clarification or confirmation that they understand the problem correctly even when they'd benefit -- others do and make better progress

* some candidates don't consider the full range of allowed possible inputs for the problem statement and assume the happy path always ... this is plenty forgivable, but when this is suggested or pointed out, some candidates find an easy way to resolve, others jump through interminable hoops to address, and others have deficit in communication that doesn't let them discuss the issue

* when discussing perceived flaws in implementations, some understand the language used to discuss software, others have a hard time communicating or answering questions about their implementations -- e.g., when one candidate wrote a recursive function all of whose branches ended up calling the same function recursively and we asked "when will your recursive function ever stop?" in many forms, they could not see or understand the intent of our question

* some candidates misunderstand writing a solution addressing a particular test case vs a general solution

* a few candidates are able to see the more optimal solution and write a good second algorithm based on that approach

* very few candidates resort to stepping through code in their IDE, unfortunately, to see or demonstrate what happens

We've eliminated many candidates we feel would have been a poor match based on inability to understand requirements, consider all possible input situations, inability to write naive algorithms, inability to communicate effectively about interview problems. ( Note that we also let candidates continue addressing the problem as "take-home" after the interview if they show promise. )

One junior candidate we just recently hired in a South Asia office did quite well on the algorithms portion, but unfortunately did not know Linux/UNIX/macOS command-line ... and assumed she was going to fail that portion of the interview -- she'd worked only in Windows contexts before. We had pointed her to a Linux-in-the-browser site and we just asked her to Google/search for the solutions to the various fairly basic operations we asked her to perform on the command-line -- she was surprised we'd let her do that. She struggled through and found solutions, and that's exactly what we wanted to see. There's nothing that exposes a candidate's suitability more than an open environment with a problem to solve and opportunity to discuss.

<comment><USER4> You have described a process that helps your company eliminate candidates efficiently.

Your company has become very good at finding what people are not good at.

Your company is not alone in that approach and this is exactly where the tech industry interview process fails.

It looks for the wrong thing.

</comment></comment></comment><comment><USER5> I would fail utterly at a real coding interview. I've been out of school too long for that crap. And also, my tolerance for it has dropped as well.

But, I'm now a dev manager so I get to sit on the other side. I've been doing interviews in the last week for a dev position and I don't subject candidates to coding. I talk with them about what they work on, one of my senior devs sits in and goes even deeper -- learning what they know without even really asking formal questions, for the most part. Past that I care more about them being smart enough and willing to learn new things, and easygoing enough to get along with the rest of the team. Hell, that's at least half of what I care about to be honest.

<comment><USER6> I encounter people who can make pleasant conversation about programming all day... but literally can't seem to actually program in practice. Do you see that? How does your interview check for that?

<comment><USER7> My experience has been that devs who struggle, will struggle with a simple for loop. This seems consistent with what I've heard from an Amazon bar raiser and the existence of fizz buzz. I'd be reluctant to give up this one sanity check of asking in real time a for loop question for whiteboard, or paper, psuedo code prefferably.

<comment><USER2> At one point for phone screens, I just asked people to code up strcmp. I got some amazingly bad answers.

Some of this code-screen mistrust seems to come from the flood of poorly- qualified candidates; maybe there's a more diverse pool than before, but it comes at the cost of lots of wannabes.

</comment></comment></comment></comment><comment><USER8> We absolutely should. Here's what I'm doing to help change it:

I'm launching a new venture that will try to help connect great engineers with great companies. Companies with great teams, competitive benefits, and the belief that engineers shouldn't have to go through bullshit interview practices and shouldn't have to study 150 hours for a round of interviews.

The flow is pretty simple: a quick Skype/Hang out call to learn about you, what've you done, what you want, and what you like/don't like.

Next, you'll get access to a git repo. In that git repo is a project with real code and a few features/bug fixes for you to implement. You commit against that repo just like you would at work. After a certain amount of time, you'll lose access to that repo.

One or more engineers will review the repo with no knowledge of your age, gender, work history, etc. Based on that engineer's feedback, we match you with companies that we think there will be a good fit. If there is mutual interest, you meet the companies in person for a final round where you can't get rail-roaded with bullshit questions.

Email me @ email@example.com if any of these are you:

1\. You're in the Bay Area or NYC and interested in fair interviews with great companies

2\. You're in the Bay Area or NYC and work for a company that wants to offer fair interviews to get great engineers

3\. You're a great engineer who would like to get paid to help create interview projects or perform reviews of candidates code - we're paying up to $100/hr. Great side hustle opportunity.

I wasn't planning on announcing anything about this yet but this post got me so fired up.

<comment><USER9> It's really easy to say "interviewing is broken" and get a bunch of people excited and agreeing. It's almost like saying "politics is broken," everybody agrees but doesn't agree how to fix it.

<comment><USER8> I can tell you we've gotten rave reviews from the companies we've partnered with, and almost all of the candidates we've tested with this love our process better than the alternative. I can't fix interviewing for everybody, but I think we're on a pretty good track for at least some of the world. I'll take that, for now.

</comment></comment></comment><comment><USER10> I personally like the way we currently do software interviews. I got a nearly perfect SAT/GMAT through rote preparation (despite not doing so well in school generally), and brought this skill to bear on software engineering interviews. As such, I've had job offers at some of the best companies in the world, something my pedigree otherwise wouldn't have allowed. I'm not able to get a job at McKinsey or BCG, no matter how well I do in case interviews, because they weight academics and prestige of school highly.

I get that many people, especially seniors, are annoyed by the general software engineering process because they feel entitled to certain positions. But for the most part it seems to make things as meritocratic as possible (aside from holding back certain populations because of bias, something people seem to be working on fixing).

So yeah I agree several day-long interviews for a company is draining and a huge time suck, but aside from that relatively minor inconvenience it puts everyone on a level playing field, and those who are "too good" for the game are free to opt out.

<comment><USER11> > I get that many people, especially seniors, are annoyed by the general > software engineering process because they feel entitled to certain positions

I'm annoyed by the process - as both interviewer and interviewee - because I don't think that it has much to do with the actual work.

</comment></comment><comment><USER12> Absolutely. I've seen companies send an intern to do a technical interview for someone with over 10 years of experience. The intern's feedback was that the guy had a lot of experience, but made some syntactic error on a whiteboard exercise so it was a pass. I don't know who gets to dictate shit like that, but it's absolutely broken. For reference two days later I overheard the same intern saying that JavaScript was fully synchronous.

As a fun aside, I've seen people send out HackerRank evaluations for entry level positions and I think that's ludicrous.

The best interview I have had was me Skyping with one of the devs and he gave me a link where we were able to share a browser session (for the life of me I can't remember the name of the site), but he described the problem and as I typed he could see what I typed. There was no emphasis on result that I can remember, just the process of writing code, talking it out loud and seeing code evolve and asking whether certain edge cases should be considered.

What's most broken, I think, is the fact that interviewing is an uneven, broken experience that's different everywhere you go because no one really knows how to interview. I haven't seen any company take metrics on whether their process is good or helpful or filters out too many people or not enough.

<comment><USER13> Agreed. The best two interviews I've had was one that was similar to your experience. The other was being invited to pair with a team member for an afternoon.

Interviews where people just wait for you to make a mistake should be not a thing anymore.

(Looking at you, Google)

</comment></comment><comment><USER14> Personally I'm very defensive against more academic interview processes (like Google's) because I'm a college drop-out and feel some amount of insecurity being ranked among peers with better academic backgrounds who might excel at such tests. In truth it is a personal failure of mine, and something i'll eventually get over through study/training the next time I'm looking for a job (hopefully years from now).

Sure it would be great if we found some super-magical process that didn't irritate or inconvenience incumbent and new developers alike. But you probably can't please everyone, and in the meantime we need to do the best we can because hiring still has to happen. Companies with slightly better processes will be rewarded (hopefully) and companies with more painful processes will face some penalty from losing candidates that would move their company forward. Hopefully this is enough of an incentive to keep companies continually working towards better hiring practices. But I kind of doubt it.

<comment><USER15> I can tell you from experience ppl with college degrees go through the exact preparation process, aren't well off because they took an algorithm course 2 decades ago.

<comment><USER14> I agree. But I think there is a skillset to taking tests that can become highly developed in a college environment (where 3/4 finals exams are taken quarterly). You're more likely to get a fully grounded education, such as database and operating systems semantics (compared to the self-taught web developer who began and exists at a much higher abstraction level). It's my understanding sometimes these questions are sometimes thrown in and could be crucial to a candidates success.

Of course this applies more to fresh grads.

</comment></comment></comment><comment><USER16> Most thinking people hate them. Everyone at my job believes they wouldn't would be able to pass the interview again for a job they've held for years.

</comment><comment><USER17> I actually really like the way that my company does software interviews. We do an initial resume check and screener phone call. After that, we send prospectives a take-home code sample that they can work on. The problems are very small and well-scoped and they can take as long as they want to work on it.

We do an initial code review. If we have notes for improvement, we give the candidate feedback and ask if they'd like to do one more pass at it. If they don't want to, but we think that the general thinking and instincts behind the logic is sound, we bring them in for an in-person where we ask them to go over their code review on where the pitfalls are and where they think they could potentially improve.

That gives us the most realistic sense of how well a candidate is going to do at the company, since this is essentially our process.

<comment><USER12> I like that it's transparent, and I've gone through a similar enough process several times, but as much as it gives your company a realistic sense of future performance, I think it's unfair to candidates. One job made me do this with two onsite interviews and then I waited three weeks to hear back. They were comparison shopping during that time, but as a candidate it was stressful.

</comment></comment><comment><USER18> My impression of the big 4 interview process I went trough for my current position wasn't at all that it was all about having done a lot of preparation in the form of hackerrank problems etc. On the one question that most closely looked like something from my preparations, I did worse than the others. This was because I didn't actually think the solution trough properly and mostly repeated what I "knew" was the answer.

My conclusion was that it's mostly about being able to solve novel (which means preparation matters less) problems in code and explain the reasoning behind the solution. It is of course possible that I was just lucky in having good interviewers, in which case I guess that would answer the question, more of that and less of syntax checks or finding the one true answer-type of questions.

</comment><comment><USER9> Most people hate them when they get rejected, consider them fair when they pass. Like anything, they are mostly subjective and very gameable (compare it to getting accepted at a college)

It's not remotely scientifically-objective, but most things in life aren't. I'd liken it more to dating. Both parties are evaluating each other on innumerable criteria through their own subjective lenses, and trying to reduce it a scientifically-quantifiable measure is dubious.

<comment><USER19> There are real results based on how successful someone is on a job. Being dismissive that there is a problem because you think people only complain when they don't get a job is simplistic and incredibly naive.

If an interview process is completely detached from what it takes to succeed at a job, what good is it?

<comment><USER20> What makes you say it's completely detached from what it takes to do the job? The only evidence that I see cited often is some study by Google that says success in the interviews didn't predict performance, but Google continues to use the same model for interviewing. I would think an organization that big would have people devoted to improving their interviews and would change it if they thought it had bad outcomes.

</comment></comment></comment><comment><USER21> I especially love being asked questions from university CS courses that I completely forgot in the 20 years since I graduated - because they were completely irrelevant in the real world. It's like reliving the exam nightmare throughout your entire life.

</comment><comment><USER22> I'm getting a bit frustrated with the talk about interviews, as we repeat the basic message every now and then, but nothing changes. I feel we all agree that the current status quo is not good, but so far there has not been any good alternative:

\- Whiteboards are unnatural. Besides, you don't want to check their knowledge of university-grade algorithms or data structures.

\- Problems to take home are an artificial setting - you can't be absolutely sure that they did the work themselves, and you have no idea how the mesh with other people. And you probably get some false negatives because they're stuck and can't ask their colleague.

\- On the other hand, if you're using real code from your project, you're just asking for unpaid work. And paying every candidate is a significant expense.

\- Using a proxy measure like HackerRank or a Github portfolio excludes people from minorities or who only want a job and not a mission.

\- Not doing any coding opens you up for people who can talk, but not code.

Have I missed anything? Is there a good alternative to find the right people? I'd love to improve my company's interviewing process, but sooner or later we always hit one of the mentioned problems.

<comment><AUTHOR> > \- Not doing any coding opens you up for people who can talk, but not code.

I think candidates should definitely code at least fizz buzz or something as a sanity check. It probably shouldn't take more than 10 minutes.

> \- Problems to take home are an artificial setting

How do you feel about potential solutions I have mentioned in the post, e.g. exposing the candidate to a project during the on-site for 3 or 4 hours?

I'm also not a huge fan of take home projects unless they can for sure be time-boxed to be less than 4 hours, and it would be ideal if you actually got paid for the 4 hours of time.

> \- On the other hand, if you're using real code from your project, you're > just asking for unpaid work. And paying every candidate is a significant > expense.

Paying every candidate is an expense, but is it less expensive than hiring the wrong candidate and then needing to fire them? It seems like other comments here have already pointed out that they pay something like 160k annualized salary hourly rate, which seems pretty reasonable.

<comment><USER22> > How do you feel about potential solutions I have mentioned in the post, e.g. > exposing the candidate to a project during the on-site for 3 or 4 hours?

It's certainly another interesting idea, but from the top of my head, I find several drawbacks: The first is NDAs, as not all code may be exposed to non- employees. Secondly, it will disrupt your team for a bit, because at least one developer should be available at all times and can't really join discussions or go into deep focus time. Finally, and most importantly, I think it's impossible for such an interview to have internal consistency: Every candidate will probably solve a different problem (or do you keep a bug open just for interviews?) in a very different social situation. If you're more the nervous type, you suddenly have a whole room full of full-blown developers see you sweat. Internal consistency, however, is one of the most important themes in interviews for me. Everyone deservers teh same chance.

> Paying every candidate is an expense, but is it less expensive than hiring > the wrong candidate and then needing to fire them? It seems like other > comments here have already pointed out that they pay something like 160k > annualized salary hourly rate, which seems pretty reasonable.

But is it less expensive than other methods of interviewing? If a classic whiteboard has a slightly worse chance of hiring the wrong person, but has no additional cost, it might still be better, all in all. Additionally, the expense depends on how many you interview for a given position (is there a filter interview beforehand or do you invite every reasonable resume?). A better idea that we sometimes use it to hire uncertain, but hopeful candidates for a paid internship. If they're good, the get a full contract; if not, we haven't lost much. Also, it's an easier decision after several weeks than after four hours. However, we can't do this for everyone.

<comment><AUTHOR> > But is it less expensive than other methods of interviewing?

I'm going to assume you are including the costs of firing people as part of "interviewing" after they have been hired and found to be a bad fit.

I'll take a stab at this. 160k annualized per hour is about 77 dollars an hour, if we're assuming 260 work days a year and 8 hours of work a day.

$77 * 4 hours of a day = $308 additional cost per interview. I'm going to assume you're already doing some panel interviews with at least 2 people, so I won't include their cost in there. And there's potential savings if we only have 3 people interviewing for the 4 hours instead of 4 or more.

Let's say I am trying to hire for 20 positions, and I am willing to interview n=15 times per position.

20 hires * (15 interviews * $308 per interview) = $92400 additional cost, whether I get 0 or 16 successful hires out of this process.

If we think about the cost of onboarding someone with 3 other employees who are getting paid about the same over a period of 3 months:

308 * 3 employees helping with onboarding * 65 work days * 8 hours * 10% of time spent onboarding = $48048 cost of onboarding 1 employee

Let's define a bad hire as someone who contributed no value and we'll treat the salary we paid them up until the point we fired them as a sunk cost. It takes maybe 4 months (260 * 4/12 = ~87 work days) to figure out that someone should be fired if it's not super obvious?

Let's say we would have normally only hired half of our target candidates (10 out 20). I'll also be conservative and say the new process reduces the number of bad hires by 10%. So assuming 1/10 of our actual hires was bad:

~87 work days * $308 per day + $48048 cost of onboarding 1 employee + ~$5000 for health benefits = $79844 cost of firing 1 person, not including the cost of other employee benefits, the effect on morale, etc.

So here you're adding a cost of about $12556 dollars. I think the cost of firing someone is actually a lot higher than what I have calculated here, though I don't know what the actual figures are for that.

But I feel that if candidates at least enjoy the process more (which based on this thread, it seems like a lot of people here would), then isn't that a drop in the bucket in the company's bottom line for something pretty valuable?

There's obviously a lot of other intangibles at play here and we can model this all sorts of ways. Let me know if I've made some egregious error.

</comment></comment></comment></comment><comment><USER23> My opinion is we need to have more variety of interview options. Everyone has their strengths and weaknesses and any given Dev has to have some kind of idea of what they excel at. Some people are really good at tough algorithms.

I recently went through a job search and I ended some coding tests because they took too much time and the questions I was asked seemed more like a random candidate filter rather than a test of developer knowledge.

My personal opinion is to make an easy coding exam similar to triplebyte or other apply once talk to many companies and randomly accept a portion of candidates.

That way people will know it's not their skill and can optimize for market exposure rather than arbitrary coding problems.

Then have an in person where you see if communication can happen. Ask them to walk you through the code used on the entrance test.

Can the industry move towards something like match day for doctors, but more ongoing?

</comment><comment><USER24> Whiteboarding is a waste of time in my opinion. The problems are recycled anyway (reverse singly linked list, needle in haystack search, etc). It doesn't give you a useful signal about the person's coding ability when they can just do rote memorization on a toy problem.

<comment><USER25> I try to ask a simple question that pretty much any half decent developer should be able to solve quickly. Then we have a conversation about it and discuss why they did it, possible problems, how they'd handle new requirements, etc. It's more important to me that they can speak intelligently and collaboratively than memorize a bunch of puzzles. It is tough to determine if a candidate will be a good fit in the hour they give us.

</comment></comment><comment><USER26> These two below resonate after hiring dozens of engineers:

> – What kind of quality work does this person produce in a normal work > environment where someone isn't breathing down their neck?

> – Can I work with this person on projects that span weeks, months, or years?

No matter how well they anwser questions, how they whiteboard, how high is their IQ, or how well they do homework - none of it would tell you anything about their work quality or actual on the job performance.

Just ask them a for loop question and give them a contract to work on something. If it works, maybe hire them.

<comment><AUTHOR> Interesting, have you had success with this approach? I might imagine there could be some stigma associated with this since why waste time if there's no guarantee of full time employment?

In California, it is at will employment anyway but I get the feeling that contractors are easier to fire than employees. Correct me if I am wrong.

On the other hand, candidates who are actually good will do very well and get through without any problems. I feel like it would take at least 2 to 3 weeks to find red flags, then at least 3 months to determine if someone is a superstar, and at least 6 months for everyone else to shine through.

</comment></comment><comment><USER27> I've thought a lot about this (and I'm sure others have to); I think candidates generally fall in two buckets:

1\. Can code:

        a. Gifted:

These have a natural talent for coding and can crank out code at the drop of a hat

        b. Persistent:

Have moderate-good talent for coding, they make up the gap with gifted coders with sheer persistence and relentless pursuit for making themselves better

2\. Cannot code/haven't coded in a long time

How can you test for coding? In my view it's certainly not some academic question or the in-vogue programming interviews book. This is clearly proven to be red herring. Also at least in the bay area, there are set questions that FANG and other companies have which are shared all over the internet and amongst friends who work there. So an interview becomes a casting process for a role, where the script is the questions you have "rehearsed". This is an absolute facade and needs to stop!

I ask simple programming questions and look for "naturalness" in the way they answer and talk through the solutions. No complicated brain teasers or the smug "look at me, I know this obscure/complicated algorithm invented before I was born" questions.

Coding is one facet, the other one is design. No matter how good a coder you are if you have bad design skills it doesn't matter. How do you test for design?

1\. Resume experience: Talk through technical issues/challenges, pros/cons etc. of projects they've done before

2\. A simple-moderate design question: If someone lists distributed systems as one of their skills, ask them a question on it. A decent amount of determination can be made about a candidate they way he/she answers.

I'm refining my process after each interview I take and would love feedback.

<comment><USER28> I create a sample project based on real world coding problems we face everyday. The actual class is a skeleton with non working methods and comments describing what the methods should do.

I then have another test class with simple failing unit tests. They have to write the code to make the tests pass.

Then I give them more complicated failing unit tests that they also have to make pass without causing the first set of test fail.

We do pair coding and they can ask me any business question they have if they don't understand a requirement.

They can use Google if they need to during coding.

<comment><USER27> Thanks, that sounds like a good way to screen someone.

</comment></comment></comment><comment><USER29> I've been through and used several different styles of interview and the one that stands out as being "the best" at predicting whether a person will fit on the team is just to bring them in and work with them for a day on _your actual product_

1) You don't do problems you've already solved that they have to come up with same answer to.

2) You don't do algorithm / problem testing that they're never going to use on the job.

3) You don't do whiteboarding except as you would in real life.

Engineering teams are people working collaboratively to solve complicated problems where nobody knows the "right" answer. Any interview that's going to tell you something is going to measure along those metrics, and not "can you invert this b-tree on a whiteboard."

<comment><USER30> I'm assuming you pay a fair rate for that day of work?

<comment><USER29> Of course.

</comment></comment></comment><comment><USER15> There are tons of threads on HackerNews on this and they all usually follow the same exact pattern of discussion.

Everyone hates interviews and how they are useless but in the the end we settle for the status quo.

</comment><comment><USER31> There is no right answer to this. Every company is different, so there is no right way to do software interviews.

Enterprise SaaS, Consumer Social and ML API companies will all have different working environments. Add on to that options of remote vs on-prem, CI/CD vs TDD, customer integration requirements, staff numbers, perks etc... and you have completely different needs for workers and teams.

A team earns their hires, and people will naturally gravitate to environments that suit their work styles.

<comment><USER30> > there is no right way to do software interviews.

In the context you presented this in, I agree with you. However, interviewing is a skill that must be learned or you are going to make loads of beginner mistakes. In that sense there are many right things you should be doing in an interview and whatever your company _style_ is, you're going to want to use at least some of those best practices in your interviews if you want to find the best candidates in the shortest time.

<comment><USER31> Isn't this true for anything though? More experience = better (on average).

In theory there is an optima between a new hires ideal workplace and the hiring company's style of work. As with most things it's about knowing yourself and identifying in others if there is a match.

<comment><USER30> Sure it's true for anything. Which is why it's surprising when 95% of the engineering interviews you go on the interviewer doesn't have even a remote clue about interviewing best practices. Which is also why you get so many whiteboard coding interviews. "That's what happened to me once in an interview, so I'll just do the same thing".

It's the very reason I mentioned it. Too many people haven't figured out the very obvious fix: get some training in how to interview!

</comment></comment></comment></comment><comment><USER32> I always ask them to read code and tell me what it does. 100% better than whiteboard coding because you can hear them working through it.

</comment><comment><USER33> I conduct this style of interviews. It's easy to complain, but much hard to propose better options. Most alternative hiring proposals do not meet the fundamental criteria of Big 4 hiring: they must reject approximately 99% of applicants while consuming an average of two hours of engineer-time per candidate.

<comment><USER5> In a sense maybe this is how it should be. The interview should reflect the company's culture. The candidate is trying to make a decision just as much as the company is.

</comment></comment><comment><USER34> I enjoy the coding interviews. I would interview just to do them.

</comment><comment><USER30> I would like to offer a partial list of practical ways to make software engineering interviews better.

1\. As a candidate, if you are in a strong enough position to refuse the job, then refuse to do white board exercises with no resources. No one codes like this in real life so refuse to do it in an interview. Be willing to walk out. I just say "I'm a good programmer and your interview process is broken. If you want to hire good programmers it's your interview that needs to change. We can start that right now and talk shop as programmer to programmer about coding, or I can leave. I'm happy with either option but I'm not going to waste your time or my time with whiteboard exercises that don't find the best programmers. How often do you use composition over inheritance here? I've been learning a lot about that and it's really helping me write better code. Can I show you some of my recent code where I've been doing that and get your opinion on where it could be improved?" Remember that your job on the interview is not to follow their script. It's to prove to them that you are the best candidate for the job. Go off script and take control if they are bad at interviewing. If good programmers are regularly walking away from these types of interviews, the interview process _will_ change.

2\. Unless you've been trained to interview people, you are probably really bad at it. Think about how bad someone is at _coding_ who never did it before and has no training. Interviewing people is no different: it is a skill that takes time and effort to learn. Get trained up, and practice with role playing with colleagues. As much training as you have time for. Educate yourself in your free time on a regular basis with articles about best practice. Adding more words won't make this sink in more, but I will end by saying I can't stress this point enough. You are bad at interviewing. You need to fix that before anything else if you want to hire good devs.

3\. How are you measuring success as an interviewer? This is a really difficult thing to measure because how can you find out that your interview process is rejecting candidates who would make great employees? I'm not going to try to answer this here, but it's an excellent question to think about. One thing that might help is the next point.

4\. Whatever your first impression is of the candidate, spend a good part of the interview trying to prove yourself wrong. Candidate seems like a perfect fit for the team and a great coder? Instead of relaxing because you're sure you already found the right person, see if you can figure out why they might be a bad fit or if their coding skills aren't as good as first impressions. Same for someone who seems weak at coding. Maybe they are just nervous. Can you make them relaxed enough so their awesome skills can come through? Maybe in both cases your first impressions will be proven correct. But if not you might have just found a diamond in the rough that other companies are skipping over.

I hope this very incomplete list is enough to get folks interested in following up on point 2.

<comment><AUTHOR> Really good points here, especially #3. In the past, we've looked at all the candidates we hired who turned out to be high performers (gets stuff done in a timely manner, writes tests, pushes back against unreasonable deadlines, doesn't require too much hand-holding) and looked at how they scored on the rubrics / and who was interviewing them. We have even been able to tell whose hires have been relatively not so great, but this takes earliest 4 months and usually up to 6 or 8 months to figure out.

</comment></comment><comment><USER35> Isn't this obvious blog traffic generation against HN guidelines? I'm flagging it.

<comment><USER6> Just because it's a link to a blog? That's the whole point of HN to like to blogs and other content. Which guideline is it breaking?

<comment><USER35> That was never "the whole point" of Ask HN posts. The standard is, and had been for years, to just post your question in the submission. That being said - I don't see anything in the guidelines addressing that.

<comment><AUTHOR> I tried to paste all the content in but it exceeds 2000 characters, I thought providing my experience might help generate more discussion.

Does it make more sense to paste the link into the body of the text and just ask the question?</comment></comment></comment></comment>


A developer's guide to health and fitness - <AUTHOR> https://www.zeroequalsfalse.press/2017/06/26/fitness/ <comment><USER2> Related podcast out today; interview with Chris Kesser MD - on functional medicine > [http://www.stitcher.com/podcast/the-tony-robbins- podcast/e/](http://www.stitcher.com/podcast/the-tony-robbins-podcast/e/)

</comment><comment><USER3> Develop health and fitness apps that work together. Adding HealthKit into your iOS and watch OS apps creates a more integrated user experience.</comment>


Why 'Ditch the algorithm' is the future of political protest - <AUTHOR> https://www.theguardian.com/commentisfree/2020/aug/19/ditch-the-algorithm-generation-students-a-levels-politics <comment><USER2> "Power, Process, and Automated Decision-Making" by Ari Ezra Waldman is a good discussion on how biases manifest in algorithmic decision-making. I agree that an algorithm would be agnostic to the data, but that biases inherent in the data would be cemented, not overcome, by agnostic algorithms.</comment>


Implementing a programming language in D: Lexical Analysis - <AUTHOR> http://blog.felixangell.com/implementing-a-programming-language-in-d-part-1 <comment><USER2> Wow, perfect timing! I'm currently writing my first lexer/parser in D as well ([http://github.com/landaire/hsc](http://github.com/landaire/hsc)) for a Scheme-like language used in Halo 3. I found Rob Pike's talk on lexical scanning to be pretty useful ([https://www.youtube.com/watch?v=HxaD_trXwRE](https://www.youtube.com/watch?v=HxaD_trXwRE)) and I've modeled mine pretty heavily after the text/template lexer: [https://golang.org/src/text/template/parse/lex.go](https://golang.org/src/text/template/parse/lex.go).

</comment><comment><USER3> I've never seen the D language before and I have to admit, it looks very elegant and has piqued my interest. Thanks for your post.

I'm wondering why you used D rather than Rust? Was it just that you were curious about the D language or is there something about Rust that you don't like?

<comment><USER4> One advantage I could see of Rust over D for language stuff is sum types (enums in Rust). So for example you can write:

        enum MyLanguage {
          Var(String),
          Int(i32),
          Sum(Box<MyLang>, Box<MyLang>),
          Let(String, Box<MyLang>, Box<MyLang>)
        }

(Apologies if I got a few things wrong; I just mean the general idea)

Seems like without a construct like this, you'd have to use subclasses or something similar, which (to me) isn't quite as nice.

<comment><USER5> Like others said, this can be done as a library type in D: [http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with- mat...](http://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching)

edit: not that it proves anything, just that "it can eventually be done".

<comment><USER6> Can you name the variants to distinguish two variants which "carry" the same types? It wouldn't be as useful if you can't express something like:

        enum ConnState {
            Disconnected,
            Connecting,
            Connected(net::TcpSocket),
            Transferring(net::TcpSocket),
         }

<comment><USER7> I would probably do it like this in D (disclaimer: I haven't tested this code!)

      import std.typecons;
      import std.socket;
      import std.variant;

      struct Disconnected {}
      struct Connecting {}

      alias Connected = Typedef!(TcpSocket, null, "connected");
      alias Transferring = Typedef!(TcpSocket, null, "transferring");

      alias ConnState = Algebraic!(Disconnected, Connecting, Connected, Transferring);

You could use plain structs instead of the typedef template for the same result.

</comment></comment></comment></comment></comment><comment><USER8> Another option is to use a lexer/state machine generator. Ragel support D and Rust (as of the not-quite-released v7) as target languages.

</comment><comment><USER9> Nice read! I'd really like to know when we can expect the next post to be published.

<comment><AUTHOR> Thanks :) Second post is in the works, will probably be out next week when I have time around college :)</comment></comment>