Hacker News Reader

Comment by biztos | Hacker News Reader

This is a great run-down of the trouble with e-mail addresses.

I worked in e-mail security for quite a while. "Write an e-mail address parser" was my go-to technical interview question.

It was pretty easy to see if the candidate had ever given any real thought to e-mail (most had not); and you could also pick up a lot of signals about engineering style, for instance if they started with a regex (fewer did than I expected). And it was trivial to adjust the difficulty: if someone thought the question was easy and had a fast solution, you could just throw them a test-case like the ones in this article.

(Note: the actual title is "Your E-Mail Validation Logic is Wrong" -- and it's only about addresses, the author isn't implying that e-mail systems can't validate messages nor for that matter addresses.)

View on HN

What if the answer they gave was "This is a very hard problem that honestly isn't worth solving, just check against a .@. regex and call it a day?"

So only a@b?

I think you’re missing some stuff in your regex.

Eh, that's why you use a validation email. Only bother with 'validation' at all to catch something obviously wrong.

HN markup strikes again (OP wrote .X@.X, where X is an actual asterisk, which HN renders as .<i>@.</i>)!

"Can you write me a parser that has a <1% false negative and <1% false positive rate on real email addresses?"

A similar enough issue happens in coding interviews anyway. Sometimes the interviewee is aware of a library that essentially solves the problem for you. In those cases I give them some credit for knowing of it and then ask them to implement it anyway, as if the library didn't exist (because there are a large number of problems out there for which a solution doesn't yet exist, and when hiring a SWE you need to find someone who can write new solutions from scratch for those situations; whether a given toy interview problem is such a situation doesn't matter for the purpose of evaluating said skills).

I would usually structure the question a bit, give a couple test cases with different formats and ask something like "write a class..." if in Python, etc. I wasn't trying to trap anyone who might actually think /\w+@\w+/ covers the range of all possible addresses.

Digression: I do miss the days when you could assume a candidate for a position at Aquatic Widgets Incorporated would know something about water, or about widgets, or at least would have looked up what an aquatic widget is before bothering to come in for an interview, but those days have long since departed the realm of Software Engineering as far as I can tell. Which may be a good thing from the engineers' point of view, I'm not sure.

That would demonstrate an understanding of email -- it is a very hard problem -- but probably also an unpleasant attitude you might not want in a co-worker. Whether the problem is worth solving is very often not your call as an engineer.

> Whether the problem is worth solving is very often not your call as an engineer.

IMO well functioning teams do consider the thoughts of their technical members when deciding which problems to solve.

The person "making the call" on whether having perfect email validation is worth solving may not have an appreciation of how difficult it actually is, so having a discussion with engineers on how much work/time it would take should play a big part in prioitising it.

Additionally, things like validating email on signup are mostly solved (albeit imperfectly) so one can and should use existing implementations and focus on building their product.

Yes, and it's a technical question. You wouldn't let business people decide which database to use, how to store data in a database, how to send data from backend to frontend, etc... those questions should be up to the technical team to decide.

Password strength requirements and email validation are just like the database examples, and if a company doesn't let these technical questions be answered by the technical people, that's a bad sign.

No offense but if an organization does not listen to engineering in determining how to deal with a technical problem, that is an enormous red flag.

While maybe the engineer won't actually make the call, the engineer should inform management's understanding of the costs of the approach and the efficacy of alternatives, and management should go along with that recommendation unless they have a good reason not to. Of course tone is important, someone saying "fuck no, I ain't doing that" likely indeed would be unpleasant to work with, but a respectful "I would recommend against doing that" is the sign of a confident and intelligent professional.

>Whether the problem is worth solving is very often not your call as an engineer.

True, but as an engineer you do need to provide accurate feedback regarding "Hey, this is gonna work much of the time but email is hard, this is a complex problem. If we do this from scratch we're going to miss a lot of things potentially".

I'd sort of raise the issue that "Writing an email parser from scratch is a bad idea due to the sheer complexity involved. If you're looking for serious email address validation there may be better options out there that have dealt with this complexity rather than start from the ground up."

Not to say I wouldn't try just for the sake of working through it as an example / 'where would you start' discussion.

But if we're pretending this is a real world task I'd probably discuss how this is an endless / possibly ultimately futile time sink and there might be better options than starting at point A ;)

Reply on news.ycombinator.com