"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.
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.
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.
>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".
