Would you hire a developer who doesn't know how to use regular expressions?
That's about it, please state your reasons for or against, and feel free to give different answers for different situations. Just try to break up your answers if you can.
Would you hire a developer who doesn't know how to use regular expressions?
That's about it, please state your reasons for or against, and feel free to give different answers for different situations. Just try to break up your answers if you can.
Well, does he at least know what they are? If not, no. If so, then probably because no one can be an expert in everything, but if he has at least an understanding of the purpose, then he can look up syntax.
Yes, although regular expressions are a powerful tool knowing them does not make or break a good developer.
There are many other important aspects of computer science developers must know to be a good hire.
If you develop BIOSes, I doubt there's much need for regexes. The same obviously goes for most, if not all, embedded situations.
Just teach him or her how to use them. They are not that hard. But which developer does not know regular expressions? If he/she likes to know how they work, he/she just uses that Holy Google.
It would depend on the situation. Many languages do not support regular expressions (for example MS SQL or MASM) so there would be no point in asking about regular expressions in an interview for an embeded ASM programmer.
Sure, why not? Regular expressions is something that people who had experience with sysadmin and/or Unix often have contact with. But a developer used to Windows, for example, might rarely come into contact with it.
Of course! I've hired a few kids out of college who had just never been exposed to that world. I've also worked with excellent developers who have just never had a need.
Now, if we were talking about server admins, or maybe web programmers who claimed Perl experience, I would think twice. It depends a lot on the job.
Basically, it depends.
If they are straight out of school, then I would - I don't think all (or really, that many) schools get into regular expressions, so you might be missing some decent junior candidates that way.
If they have been working for a while, then no.
I did an IT diploma and did not know what a regular expression was when I got hired for my first job. I quess it would depend on the level of the position you are looking to hire for. I would be very hesitant to hire a senior developer who did not know what a regular expression was. Not so much a junior developer. Most of these things are learned through hands on experience.
Does the job require knowledge of regular expressions? Would you eat at a steakhouse where the cook didn't know how to bake cakes?
Yes, if they were a solid programmer otherwise.
Regular expressions are a very simple thing to teach provided you have a person of sufficient skill. It's much easier to teach a good programmer regular expressions than it is to teach programming to someone who understands regular expressions. Hire the programmer.
Yes, if he has other things to contribute to the team.
If for example you are using a specific protocol for communicating with external hardware and he is knowledgeable about this protocol, hire him.
If your area of work does not require string manipulation, I would at least consider to hire him. It's not as if regex is the single most important thing every programmer needs to know. They are a tool, very useful if you are doing string manipulation. Nothing more.
Of course, not knowing at least some very basic regex is a bad sign. He may have other knowlegde gaps, in more important areas. That is something you have to decide on a case by case base.
Agree with Daniel and Chris, if the developer has perl or other scripting experience then regexp is something that (s)he should know, but for someone fresh out of school they might not have been exposed to regexp. Moreover, it could be that they have may used regular expression without knowing what they are.
No, I would not.
Nor would I hire someone who doesn't know SQL, JavaScript, XML, CSS, or basic string manipulation using Excel formulas.
Developers who don't know these either don't have the experience I'm looking for, or they've been relying on GUI designers (e.g., VS) or leaky abstractions (e.g., LINQ) rather than actually learning the languages required by the platforms they are developing for.
Edit: Wow, such negativity! Sheesh. FWIW, I was talking specifically about hiring developers for the technologies our business (a consulting firm) deals with. I don't need "integration developers" and I sure as hell don't need a C++ person who can't write decent cross-browser HTML/CSS. And like it or not, in the real world outside the ivory dungeon of Big-Corporate-IT, basic ability to do data manipulation using RegEx and even (gasp!) Excel is part of the job. Data management falls on developers because the line staff don't have the skills and we have a crapload of incoming data to deal with. We don't get to write kernel mods all day, nor can we wrap ourselves in comfy 10-layer-deep enterprise abstractions. This isn't a Mort talking, either--our shop is run by operations, not IT, and we need people who can hit the ground running with the technologies we use every day.
It might depend on the job, but someone who didn't know REs would indicate to me someone without much curiosity or interest in learning new and different skill, and I absolutely would try not to hire such a person.
As long as they know how to ask for a regex on StackOverflow, yes.
There should be a regex.stackexchange.com for asking and answering regex questions.
There are dozens, maybe hundreds or thousands of niches. You could ask the same about assembly language.
If the programmer is a 3D engine builder who never uses strings, probably be better to know assembly, matrices, and shader programming than regex.
I would not take that into account, even if he is expected to use regular expressions in the work that I am hiring him for. I would however be interested in knowing his capabilities of learning quickly, not only regular expressions, but anything that can be related to the work he is expected to do. That is what really matters.
Well, first things first.
Hire a developer for what? What's the job description - what project types, what language(s), what other skills required?
Even if you mean someone who just codes, then you first have to answer - WHY do they need to know regexp for the job?
If the job does not need regexp experience, then it's not an issue. Same as if they don't know SQL (and won't be needing it for the job), or Perl, or Ruby, or COBOL or FORTRAN or any of a thousand other things that some jobs require but others simply don't.
Regexp by and of itself usually only really means that they were "doing stuff" in the unix world with Perl or scripts or similar stuff. While that can be incredibly useful in context, out of context it's no more valuable than anything else if you don't actually need it for the job description.
Cheers,
-R
It's not something that would be a disqualification, no. However, I have trouble imagining a competent experienced developer of the kind we would hire not knowing regular expressions. Consider it a big red flag.
Not unless it was for a very junior trainee position (in which case I'd be looking for aptitude to learn, rather than any specific knowledge).
Even if he was going to be writing embedded assembly, regex is a tool any good programmer will use almost daily. It's not just about writing regexes for the code he's being paid to write, it's a skill that demonstrates he finds effective ways to do his job.
Regex is confusing and 90% of the time i hack a regex expression from something I've found online. I also find that the JavaScript regex is different from the C# regex so there are portability issues. I suppose the candidate should prolly have heard of them if the position requires it, but it's just one technology in the toolbox.
aside: I once interviewed for a position where they wanted me to whiteboard out some code to parse XML. So I started scribbling DOM class code and XPATH queries and they stopped me saying 'what if i didn't have those classes'. so I started scribbling .indexof() code and they stopped me again and wanted me to do it with pointers to a char array. So I stopped them back and asked if they were really parsing XML is this cryptic way. they said no, but it's just an interview question they use. I recommended they review their interview questions.
To program in Perl? Definitely not.
To program in Excel? Regexes are not a factor.
So, it depends on what the person is doing.
And keep in mind that many talented programmers do not start with a computer science degree, earned by taking third year computability and complexity courses.
Are they a developer that doesn't know how to write regular expressions, or a developer that doesn't know how to use regular expressions?
A developer that isn't adept at writing regular expressions but is adept at using existing regular expressions is probably still pretty efficient, since there are tons of preexisting regular expressions out that that cover an awful lot of common scenarios, particularly validation.
I'd be quite wary of a developer that was writing his/her own long and bug-prone routines for things that could easily be handled by regex.
But then again, as another commenter mentioned, regex isn't taught at a lot of schools. A bright but inexperienced developer (first few years in the biz?) simply might not quite get what they are or why they're tremendously useful.
(Personally, I fall into the category of an experienced developer who's not that great at writing regex but recognizes when they're the right tool for the job and will then borrow an existing one or cobble together his own after when the situation demands it.)
IMO, anytime you establish an opinion of someone (such as whether to hire them) based on a single criteria (such as knowing regular expressions), you're making a huge mistake. In fact, the only time I would recommend you not hire someone strictly based on their lack of regular expression knowledge would be if the job's primary function included managing regular expressions. Otherwise, if they qualify for the position in other ways, encourage them to learn it on the job and give them a shot.
Simply saying (or thinking) "Ha! You don't know regular expressions? Get outta here..." or any variant of it is not professionalism, it's elitism, and has no place in the business world.
It depends ... if they responded with "No, but I know finite state automata which are equivalent" then I would probably hire them :)
In most cases, I wouldn't expect deep knowledge of Regexes, but I would expect, when confronted with a problem best solved with a regex, the candidate would minimally answer, "um... maybe a regex?" or "um... grep?"
Anything more than that is a bonus, with an otherwise decent candidate.
I've been a professional developer for almost 20 years and I can count how many times I've used regex on one hand and have 3 fingers left. To use that as a barometer for programming skill is nonsense unless the job specifically calls for it.
I have built many enterprise-level critical systems for industries such as financial, pharma, insurance and many other. Regex has not been an issue.
I think whether a candidate knows regex or not is irrelevant for a programming position, it is useful skill to know but if the developer knows the more important skills like software design patterns, oop, platform knowledge etc then I am confident he can learn regular expressions as well. OTOH if he has never heard of regular expressions then this IMO, shows a certain mindset that may disqualify him in my eyes.
Absolutely NOT because he or she would most definitely NOT be a Vim user!
Just be sure, ask them to solve the Monty Hall Problem.
Absolutely, if s/he can show good programming aptitude. After all, ain't that what you are looking for? How long it takes to learn the regex? A programmer may know nothing about regex, yet could be brilliant programmers, and not necessarily otherwise. And people who rely on regex to filter out candidates are somehow unbelievably foolish in my opinion. Sorry.
I think many answers are missing the point. It's not that RegEx is necessary for the immediate job. It's that it demonstrates well-rounded knowledge and curiosity of a powerful and broadly useful tool.
Hi
I do know regular expressions to certain extent but by no means an expert. Knowing or not knowing regular expressions shouldnt be the absolute yardstick for your hiring decision.Thirst for knowledge should be
Once on a mailing list a user responded to a question of extracting element from a xml file using regular expressions . I looked at it and imediately asked why not use some of the xml xpath constructs available in that langauge to parse the xml. All the experts agreed
You should look for wholistic qualities when hiring someone.
regards Edwards
I think RegEx is good indicator of how much someone cares about programming. I have co-workers that dont know it, but they also dont know how to write clean code or how the programming language we are using really works(sometimes Im shocked by the stuff they dont know). RegEx is never used as keyword on job adds, so RDD programmers wont learn it. I think every programmer that cares about getting better will at least try RegEx.
I might if it was a junior-level position, but probably not otherwise. I consider regular expressions to be more than just a useful tool - they also play a key role in formal languages and the theory of computation. A good engineer should know about both perspectives, practical and theoretical.
(An interviewer once asked me "What is a regular expression?" I replied "A finite state automata". He said "What's that?". I didn't get the job --- probably just as well, too.)
it depends
if you have to equally matched programmers in all areas, but one understands how regular expressions work - sure, take him
but keep in mind that programming isnt just about mathematics - its about problem solving and 'chunking' a big task into smaller pieces
-- LM
In the past ... no I wouldn't, because how would they be able to use ed efficiently? :)