Need Regex for phone number

[Marc Girod]

0

Doesn't this sound paradoxical ?
I can see a circle in that 0...

Marc

 

[RedGrittyBrick]

Doesn't this sound paradoxical ?
I can see a circle in that 0...

In multi-layered pleasure per byte, it probably exceeds anything I've
written since first I applied crayon to wallpaper.

 

[Peter J. Holzer]

The only way to really be sure is to call up the number.

That still doesn't give you the area code. Although if somebody answers
the phone you could ask ...

hp

 

[Peter J. Holzer]

MG> This kind of interview strategy does select some people and
MG> reject others.

That's exactly the point.

MG> Whether the people selected are more suitable to the job than
MG> the people rejected is questionable. It is only obvious to
MG> certain kinds of people. It is not to others.

If you don't have basic Perl knowledge -- and a level of regular
expressions knowledge sufficient to make at least a reasonable attempt
at solving that problem

I think I have both. But if you asked me that question you wouldn't get
a Perl answer. Instead I would ask you why you needed that information,
I would tell you about various conventions for writing telephone
numbers, maybe suggest a few heuristics, ask what should happen if those
heuristics fail, how they should be maintained, etc. Only if all of that
is clear (and that would take a lot more that the 5 minutes you
mentioned earlier) would I start to attempt and implementation, and I'm
not at all sure whether it would involve regexps.

hp

 

[Peter J. Holzer]

CW> You'd think that - but in practice, there are a lot of people who
CW> present themselves as Perl experts convincingly enough to get past HR
CW> people and generalist recruiters. [...]
"Do you play golf?"

Heh, I already "failed" that question once by answering "no, only
minigolf, and that rarely".
To my defense I can say that I was asked that question at a pub after a
few beers and without Perl context.

hp

 

[Charlton Wilbur]

MG> But that's not what you measure, or determine, or show. I
MG> repeat myself: I tend to get rejected in such tests. It doesn't
MG> seem to depend on the area of expertise.

MG> Do you mean that I am worth *nothing*? Yes. I can see you do.

No. I mean that if you can't come up with a rough solution -- not a
perfect solution, not the solution we're looking for, but a rough
solution -- to that problem in five to ten minutes, there's a good
chance you're lacking in the sort of skills that this group uses every
day.

Charlton

 

[Charlton Wilbur]

PJH> I think I have both. But if you asked me that question you
PJH> wouldn't get a Perl answer. Instead I would ask you why you
PJH> needed that information, I would tell you about various
PJH> conventions for writing telephone numbers, maybe suggest a few
PJH> heuristics, ask what should happen if those heuristics fail,
PJH> how they should be maintained, etc. Only if all of that is
PJH> clear (and that would take a lot more that the 5 minutes you
PJH> mentioned earlier) would I start to attempt and implementation,
PJH> and I'm not at all sure whether it would involve regexps.

The answers: We need to make sure we have a reasonable phone number in
order to contact customers. Marketing wants area code information
because it's the key into their demographics information system. We're
only dealing with North American phone numbers here, and we're using
freeform form field entry, so we're dealing with whatever people give
us. If validation fails, we just respond with a "Your phone number was
not understood" message, and ask the user to re-enter it.

And at some point in there I'd congratulate you on your thoroughness and
remind you that my role in the interview process is largely to assess
your experience and skill with Perl, not your adherence to good software
engineering practices or your arcane knowledge of telephone number formats.

Seriously: the point of the question is not to determine who has worth
as a human being or to solve the problem once and for all time. The
point of the question is to ask a question that's reasonably well-scoped
but with a lot of fuzzy areas and possibilities for human error, to see
how the candidate approaches the problem. You're not supposed to get
the right answer, because there is no right answer.

Charlton

 

[Charlton Wilbur]

BL> The only way to really be sure is to call up the number.

BL> Yes, it is indeed similar to the problem of checking if an email
BL> address is valid.

So substitute "well-formed" for "valid" in the spec. Sheesh.

Charlton

 

[Ralph Malph]

No you don't, a simple equality test will suffice for that:

$phone_number eq '3108222400';


The quality of the answers you receive here is in direct
proportion to the quality of the questions you post here...

Have you seen the Posting Guidelines that are posted here frequently?

ha ha ha ha, of course he has *seen* them.
Since it is a lengthy piece of unreadable excrement *seeing* them
doesn't seem to much matter, now does it?
Told you so.

 

[sln]

MG> But that's not what you measure, or determine, or show. I
MG> repeat myself: I tend to get rejected in such tests. It doesn't
MG> seem to depend on the area of expertise.

MG> Do you mean that I am worth *nothing*? Yes. I can see you do.

No. I mean that if you can't come up with a rough solution -- not a
perfect solution, not the solution we're looking for, but a rough
solution -- to that problem in five to ten minutes, there's a good
chance you're lacking in the sort of skills that this group uses every
day.

A phone number rough solution is like it has 4 wheels when
designing a mazarati.

One solution/one type, group of edit boxes, pre-defined,
restricted to digit chars, validated with onselchange or
lose focus notify.

Parsing a single text entry for all the possible forms of a
phone number is quite another thing. This is usually what is
seen in on-line user entry forms. This way usually requires user
validation, or a forced re-entry, to conform to specific
pre-determined forms, or both. Then there are credit card numbers ..

-sln

 

[ccc31807]

          We have a text-input field that we ask the user to type a
          telephone number into.  As part of data validation,we need to
          know if it's a valid phone number and to identify thearea
          code.  Please write some code to do that.

A North American telephone number consists of a three digit area code
(NPA), a three digit exchange (NXX), and a four digit number,
optionally preceded or followed by other digits. As long as you get
ten digits, you don't need a regex to separate the NPA, NXX, and
number -- substr will do just as well.

I just came through a major project like this, and the core of the
solution was to use a NPA/NXX database for a lookup. My project
required mapping numbers to geographical areas (using zipcodes) and
proceeded from the fallacious assumption that the zip code assigned to
the telephone billing center indicates the area of the subscriber's
residence (it doesn't).

My data doesn't come through user input, but from a call center which
records the number of the incoming call. The application processes
several thousand calls a day, and we have a significant number of
'numbers' that can't be mapped. Those numbers are (mostly) formatted
properly, but are not valid North American numbers.

Assuming that you collect your data via an HTML form, the JavaScript
form validation routines do a fairly good job of validating format,
depending on the specification for the input of data, e.g., requiring
input like '999-999-9999'. Assuming that you can retrieve the first
ten digits, optionally preceded by a '1', it's trivial to validate the
input as a 'telephone number.' However, to map the input to an area
code and exchange, your program should test the input against the
database.

The two biggest challenges are (1) dealing with the execution speed of
the script because of the amount of the data, and (2) fighting the
assumption that the data is valid. I solved the first challenge by
collecting all the numbers and running the script at 3:00 a.m. daily.
I haven't solved the second problem, and have concluded that it's
insoluble.

CC.

 

[lotug]

Thanks, that seems to work.

Quoth lotug <[email protected]>:

Sorry, I guess I assumed to much.
Yes, I was looking for regex that would identify the phone number in a
txt string regardless of how it was formatted. Different people input
phone numbers in different ways. Also, I have regex that identifies a
phone number in a string, but I'm looking for perl regex that will
identify this particular number within a text string.

3108222400
(310) 822-2400
1(310) 822-2400
1-310-822-2400

For those forms, something like

    /1? [-(]? 310 [-)]? \s* 822 -? 2400/x

may be sufficient, though it will catch strings like '-310)8222400'
that you don't want.

Etc., etc.

You will need to make a complete list of all the forms you want to
catch, and create a regex that matches them. Probably the best way is a
simple alternation, which you can build like

    my @cases = (
        "3108222400",
        "(310) 82202400",
        "1(310) 822-2400",
        "1-310-822-2400",
    );
    my ($pattern) = map qr/$_/, join "|", map "\Q$_", @cases;

Ben

 

[Uri Guttman]

JS> Do I have that about right?

no. i know charlton (i placed him there) and his type of question is
extremely valuable in screening candidates. it isn't about knowing phone
numbers or styles, it is a basic simple parsing question that any decent
perl hacker should be able to do. and if they have questions, that shows
an inquiring mind which is good too. if you spend more than 10 minutes
on that (hell, 30 seconds!) it is a bad sign if you expect to be
hired. i don't use such questions but i always review candidate code and
i ask questions about how and why they coded something. i learn more
about candidates from their code than any other aspect of interviewing
them. and yes, i interview plenty of candidates as part of my business.

uri

 

[Charlton Wilbur]

JS> Ten seconds. /([2-9]\d\d)/. But that requires an "esoteric
JS> knowledge" of the NANP, that area codes don't start with 0 or 1,
JS> and that they changed to allow 2-9 as a middle digit. Do I win?

Nope. You missed the "validate it" part completely.

And you seem to have willfully missed the point elsewhere, too. Hint:
this is not a major programming challenge for the company at large.
It's a fairly simple problem that weeds out the people with no Perl
knowledge or experience to speak of.

Further, if the interviewer tells you that it's a toy problem to
evaluate the way you approach problems, haranguing him about how asking
that toy problem is going to hamper the country's entry into
international markets is one of the few wrong approaches you can take.

Charlton

 

[Charlton Wilbur]

UG> it isn't about knowing phone numbers or styles, it is a basic
UG> simple parsing question that any decent perl hacker should be
UG> able to do.

Precisely. It's a toy problem that any competent Perl programmer should
be able to come up with a reasonable solution to within 10 minutes.

Its principal goal - which it performs admirably - is to eliminate
candidates who are good enough at putting keywords on their resumes and
speaking bafflegab to HR people to get to the interview, but who do not
have any actual hands-on Perl skills.

Charlton

 

[Uri Guttman]

JS> From this exchange, I learn that my prospective employer is
JS> inconsistent in producing specifications for the software he wants me
JS> to write. He changes his mind on a daily basis, forgets he changed his
JS> mind, and uses incorrect and misleading definitions for those specs he
JS> does write. It would be a very poor programming environment and I'd be
JS> better off looking elsewhere, because even if I nailed the specs on
JS> something, I'd have "completely missed" something I was specifically
JS> told was NOT a requirement yesterday.

you just blew the interview. NEXT!!

JS> By all means, keep presenting toy problems as if they are real, change
JS> the spec at whim, and fail to define the standards you want followed.

you haven't done much screening of perl candidates it seems. or talked
to many who do.

uri

 

[Ted Zlatanov]

CW> Precisely. It's a toy problem that any competent Perl programmer should
CW> be able to come up with a reasonable solution to within 10 minutes.

CW> Its principal goal - which it performs admirably - is to eliminate
CW> candidates who are good enough at putting keywords on their resumes and
CW> speaking bafflegab to HR people to get to the interview, but who do not
CW> have any actual hands-on Perl skills.

The Brainbench Perl tests are also good at filtering out the rabble.
It's a commercial service so YMMV but for me it's been helpful.

Ted

 

[Uri Guttman]

CW> Precisely. It's a toy problem that any competent Perl programmer should
CW> be able to come up with a reasonable solution to within 10 minutes.

CW> Its principal goal - which it performs admirably - is to eliminate
CW> candidates who are good enough at putting keywords on their resumes and
CW> speaking bafflegab to HR people to get to the interview, but who do not
CW> have any actual hands-on Perl skills.

TZ> The Brainbench Perl tests are also good at filtering out the rabble.
TZ> It's a commercial service so YMMV but for me it's been helpful.

i dislike them in particular and pretty much any multiple choice
automated test. they don't show how someone thinks or codes. code
review and coding assignments of simple problems are much better
indicators. i actually would downgrade anyone who promoted their
brainbench score. it's as useful as msce's! and i know people who will
NOT hire someone dumb enough to get an msce!

uri

 

[Peter J. Holzer]

UG> it isn't about knowing phone numbers or styles, it is a basic
UG> simple parsing question that any decent perl hacker should be
UG> able to do.

Precisely. It's a toy problem that any competent Perl programmer should
be able to come up with a reasonable solution to within 10 minutes.

The problem is that there are way too many programmers which then take
their solution to your "toy problem" and apply it to the real world.
There are a lot of registration forms which require a phone number as a
mandatory field but don't accept my phone number because it it has too
few or too many digits or I have formatted it differently than the
programmer expected (and of course he doesn't tell me what he expects -
he just tells me "please enter a valid phone number" and deletes the
other 20 fields I have already entered. There are also forms which don't
accept email addresses with a "+" in the local part, or punctuation in a
house number. And so on.

hp

 

[Ralph Malph]

CW> Precisely. It's a toy problem that any competent Perl programmer should
CW> be able to come up with a reasonable solution to within 10 minutes.

CW> Its principal goal - which it performs admirably - is to eliminate
CW> candidates who are good enough at putting keywords on their resumes and
CW> speaking bafflegab to HR people to get to the interview, but who do not
CW> have any actual hands-on Perl skills.

TZ> The Brainbench Perl tests are also good at filtering out the rabble.
TZ> It's a commercial service so YMMV but for me it's been helpful.

i dislike them in particular and pretty much any multiple choice
automated test. they don't show how someone thinks or codes. code
review and coding assignments of simple problems are much better
indicators. i actually would downgrade anyone who promoted their
brainbench score. it's as useful as msce's! and i know people who will
NOT hire someone dumb enough to get an msce!

What about the many people who have these as they were required
by a former employer? Do they also get to miss out on the
experience of working next to a morbidly obese mouthbreather
that smells of faeces?