Salaries

CodeWhisperer

@Oscar L said:

Next in the sample questions, you posed the phone number formatting question. I would have chosen regex's because I just recently figured out I could replace a recursive descent parser"

Yup, nothing wrong with the regex solution. This is a way of doing it without a regex:

        static string StripPhoneNumber(string str)
        {
            string ignoreList = " ()[]{}+-";
            StringBuilder sb = new StringBuilder();  
        // iterate through each char, keep numbers, ignore stuff on the
        // ignore list; return null if a bad char crops up
        foreach (char c in str)
        {
            if (char.IsDigit(c))  
                sb.Append(c);
            else if (ignoreList.IndexOf(c) == -1)  
                return null;   
        }

        // collect the results and check against the length
        // throw out any leading '1'

        string result = sb.ToString();

        if (result.Length &lt; 10) // not enough numbers
            return null;
        if ((result.Length == 10) &amp;&amp; (result[0] != '1'))
            return result;
        else if ((result.Length == 11) &amp;&amp; (result[0] == '1'))
            return result.Substring(1);
        else
            return null;  // too many numbers
    }

<FONT face="Times New Roman" color=#000000>And you can see in the results that you get the desired results...plus some unexpected ones thrown in.  Oh well, I never said it had to match ONLY those formats :)</FONT> 
<FONT face="Courier New"><FONT color=#0000ff size=2>425 555 1212 -> 4255551212 = PASSED

425-555-1212 -> 4255551212 = PASSED

(425) 555-1212 -> 4255551212 = PASSED

+1 425 555-1212 -> 4255551212 = PASSED

+1+4+2+5+5+5+5+1+2+1+2 -> 4255551212 = PASSED

[[[]]][][]][[][4[25---555-[1[2][1][2] -> 4255551212 = PASSED

425bbb1212 -> (null) = FAILED

4425 555 1212 -> (null) = FAILED

25 555 1212 -> (null) = FAILED</FONT>

<FONT size=2></FONT>
</FONT>

ammoQ

I think I would have done it similar to CW, even if it's "lowtech" compared to regexes. It's simpler, probably faster and easier to check for correctness.
Anyway, I wonder what you guys do with international customers which have a much longer phone number. ;-)

apapadimoulis

I avoid regexes as much as possible in long-term solutions. Although I can build and understand them fairly well (6 or 7 out of 10 maybe), I've found that most developers are frightened of them and have a very difficult time maintaining them.

ammoQ

@Alex Papadimoulis said:

I avoid regexes as much as possible in long-term solutions. Although I can build and understand them fairly well (6 or 7 out of 10 maybe), I've found that most developers are frightened of them and have a very difficult time maintaining them.

Is there any way to put comments in regexes? For example, a function checking the syntax of an email adress might contain comments like
/* check the name part /
/ check the existence of exactly one @ /
/ check the domain /
/ check the TLD /

The corresponding regex might look like that:
"^[a-zA-Z][\w.-][a-zA-Z0-9]@[a-zA-Z0-9][\w.-][a-zA-Z0-9].[a-zA-Z][a-zA-Z.][a-zA-Z]$"

(just googled for it, no idea if it works or not; I've seen even longer regexes for that job)

Would you want a junior programmer to implement the rule "domain cannot be all digits" into that regex?

@ammoQ said:

@Alex Papadimoulis said:
I avoid regexes as much as possible in long-term solutions. Although I can build and understand them fairly well (6 or 7 out of 10 maybe), I've found that most developers are frightened of them and have a very difficult time maintaining them.

Is there any way to put comments in regexes? For example, a function checking the syntax of an email adress might contain comments like
/* check the name part /
/ check the existence of exactly one @ /
/ check the domain /
/ check the TLD /

The corresponding regex might look like that:
"^[a-zA-Z][\w.-][a-zA-Z0-9]@[a-zA-Z0-9][\w.-][a-zA-Z0-9].[a-zA-Z][a-zA-Z.][a-zA-Z]$"

(just googled for it, no idea if it works or not; I've seen even longer regexes for that job)

Would you want a junior programmer to implement the rule "domain cannot be all digits" into that regex?

In perl and some perl-style regexes, yes. You add the /x [extended] regex qualifier, and the regex engine no longer considers whitespace significant, and anything after a bare # is considered a comment. In most PCREs, you can use (?#comment) or the option PCRE_EXTENDED. Yes, I comment my regexes, one grouping per line.

My earlier solution is actually assuming that I'm going to accept a lot of things that aren't really formatted phone numbers, like 1-(601]-555-5555. For example, I'm not attempting to match that the parens/blocks match, which is a very difficult job for most regexes. Your above solution is similar to mine, except that I'm using an even more permissive approach. Whether or not that's acceptable is dependant on the application: if you're writing a batch-loader, it might be, but if you're writing a UI, you'd probably want more checking to avoid bad entries in the first place.

Checking an email by the RFC by regex is actually very, very difficult. Dealing with nestable comments, embedded whitespace and embedded newlines, without losing any data... is difficult. I wrote a pretty good one, once, but it relied on multiple variable-length backreferences, so it doesn't really work all that well in some implementations.

I don't think that adding the 'domain cannot be all digits' rule into that would be exactly trivial, but it could be done. I'd agree that it'd be best, both maintainer-wise and performance-wise, to either split the regex pieces, or to write a real parser for that, as it became more complex.

tufty

@ammoQ said:

I think I would have done it similar to CW, even if it's "lowtech" compared to regexes. It's simpler, probably faster and easier to check for correctness.
Anyway, I wonder what you guys do with international customers which have a much longer phone number. ;-)

Not necessarily a longer phone number, but different rules apply. Once you start getting into National Numbering Plans, it all gets very scary very fast. Regexes still work, but you have to have (potentially a bunch of) regexes per country. Or some sort of generalised scanning engine at which point you're effectively reinventing regexes anyway...

Yeah, I deal with this sort of stuff on a day-to-day basis. Not only do I have to deal with phone numbers from most of the countries in the world, I also have to know if they are mobiles, premium rate, etc. The US in particular is a pain for this (read: it's not possible to derive all that from the US NNP, although that's what NNPs are supposed to tell you).

Simon

CodeWhisperer

Just as an update, I had an interview candidate in just a few hours ago. Relatively young, maybe 5 years of 'professional' experience, he answered the StringBuilder question just fine; jumped right to the linked list solution and then even wrote his own little linked list (rather than just using List<>) on the board. Took him maybe 10 minutes to work through the problem and then we were on to talking about web stuff.

I didn't ask him about polymorphism.

We're making him an offer today.

-cw

Oscar_L

@CodeWhisperer said:

the linked list solution and then even wrote his own little linked list (rather than just using List<>) on

How would it have affected your assessment(or did it not matter) if he used List<>?

CodeWhisperer

@Oscar L said:

How would it have affected your assessment(or did it not matter) if he used List<>?

Only marginally. It was nice to see that he knew how to do it and understood some of the issues with working with them, but before he wrote any code he had said enough that I could tell that. If he had used List<>, I'd have known that he understood what was going on underneath.

But, really, the tipper came later when I was asking him some ASP.NET stuff: the difference between Server.Transfer and Response.Redirect. Generally that's just a toss-out to see if the person has even seen the functions; in this case he had and had used them, but didn't really know the difference. He did know that Server.Transfer screwed up the browser's URL sometimes...but didn't know why, I asked him to think about that for a second. Then a little light came on over his head and he said "Oh, Server.Transfer never talks to the browser!". Ta da.

Seems like a little thing, but a) he had some experience, b) he detected a pattern in it, c) he put it all together in a fairly stressful situation; and, d) he left the interview knowing something he didn't before.

As far as I'm concerned, that's a really good sign in a relatively junior engineer. I can't expect him to know everything, but I do expect him to be able to figure it out. :)

-cw

CPound

@CodeWhisperer said:

We're making him an offer today.

Should he choose to accept your offer, I wish him all the best.

ammoQ

I found this today in Austria's newspaper "Kurier", it's a statistic about income in IT jobs:

Software
Junior Developer: 23830 EUR
Application Developer: 40600 EUR
Senior Application Architect: 55420 EUR
Project Manager: 72840 EUR
Manager Application Development: 104310 EUR

Hardware (sic!)
Server Administrator: 29400 EUR
System Engineer: 44800 EUR
Data Base(sic!) Engineer: 56970 EUR
IT Controlling: 64410 EUR
Manager Data Center/Infrastructure: 107207 EUR

CPound

@CodeWhisperer said:

We're making him an offer today.

Don't keep us in suspense. Did he accept the offer?

He didn't...I bet you he didn't.

LOL

CodeWhisperer

Honestly not sure; two different guys started last week, another two start on Tuesday. Even if that specific fellow didn't, I apparently don't scare too many of them off.

-cw

CPound

@CodeWhisperer said:

two different guys started last week, another two start on Tuesday.

For a "$100M/year company" you guys sure hire a lot. How can the company afford that? Or is there high employee turnover perhaps?

CodeWhisperer

You're awfully eager for something to be wrong.

I don't think we're hiring all that much compared to the area, nor is the turnover much different. There are thousands of devs/engineers in the area, and there are still more jobs than devs to fill them -- and now Microsoft has said that they intend to hire something like 5,000 people in the next couple years. And when MS grows, everyone around them tends to grow as well, so it's just going to get worse/better. All those people come from/go to somewhere else all the time, and for different reasons. I think you'd find the dynamic quite a bit different than what you're used to.

In our case, we're ramping up so can run two pretty big new development efforts and put more people on a couple specific problem areas. So, yeah we do hire a lot, some are permanent employees, but a fair number are contractors -- mostly because we can't get enough good guys to hire full-time.

Ironically, the permanent employees cost less than the contractors. We pay $100/hour for most of the contractors. All day, every day. That's, what, $16K/month x 12 months = $192K/year. Contracting company gets a big percentage of that, but yeah, it costs a bundle.

-cw

jsmith

I feel like jumping in here with another perspective because right now it looks like CodeWhisperer beating up on CPound...

CPound,
It looks like you are using the wrong yardstick to evaluate good code. You seem to think that if it functions then it is as good as it could get. That's like a custom car painter being happy if the paint sticks to the car.

The absolute lowest level of acceptability of code is that it performs its intended function. Next, it must be maintainable and then extensible. Good programmers write maintainable code without even thinking about it. They wouldn't dream of copy and pasting the same chunk of code 9 times -- not because they were taught that loops/functions/classes/whatever were "good" in school, but because they know that some day the requirements will change or a bug will be discovered and they'll never find the other eight.

Good programmers also write methods that are "reusability friendly". Meaning that they can be used in many situations without doing a whole lot of research as to whether the method will cause unexpected issues. We do have fancy words for this stuff, like idempotent. But, we don't use the words to scare away 23 year olds that didn't get a CS degree. We name things that are important, these things aren't important to the rest of the world, so the names seem odd to most and it looks like we are trying to build some type of clique. This is not ivory tower stuff, but real issues that are important even in 1000 line apps. All of us have libraries of code that we use in many projects and we know from experience that methods with side effects cause us to have to work late at the least convenient times.

We also know the common pitfalls of modern languages and the available solutions. The interview question about String building was designed to see if the candidate was familiar with the perils of String concatenation and the available solutions and their tradeoffs. That is very important stuff for writing reusable code. You might write a library in a small app today and reuse it in a large app tomorrow. If the library builds strings (maybe javascript generator), it should be second nature to choose the correct String building technique. Making the wrong choice will lead to horribly slow code very quickly. Sometimes questions like this could be considered "trick questions", for example; the .Net GetPixel() method of the BitMap class is horribly slow. However, expecting that someone knows this at an interview would be a trivia question. Expecting that they know that String concatenation is slow is not trivia. It is far more common and is a result of the way that most modern languages handle Strings.

As an example, I recently picked up some C# code that was written to wrap some common TWAIN API calls. Well, the code did perform its intended function, but it was still amateur code. Whenever the API returned an error code, the library hosed up the message pump of the form, locking it up (BTW, the asynchronous parts of TWAIN use the message pump to signal state changes -- yipee!!!). This was very annoying and not all that fun to debug. A few hours of coding later and it still worked just like it did before from a functional perspective. However, now I could drop it into an app without expecting clients calling me back saying "there was no error message, it just locked up".

Also, if you've never heard of polymorphism, then it means that you haven't spent a whole lot of time thinking about how interfaces could help to build extensible apps. I've seen code written by guys like you. After five or six years of maintenance, there are 100 if tests that check for a configuration option and implement a different chunk of code. A good programmer would immediately see the advantage of interfaces and probably run-time loadable implementations (or plugins as people like to call them). Not knowing the word doesn't mean that a person doesn't know about these things, but it would be very hard to read and talk about interfaces and plugins without bumping into the word polymorphism a few hundred times. Someone who knows the word polymorphism is more likely to do extensibility right than someone who doesn't. Also, at an interview, the interviewer would go a step further and not just find out if the candidate knew the word polymorphism, but also if he knew how to use it and where it is applicable. I want to tell my higher end programmers "change that config switch to a plugin" and have them know what I'm talking about and go do it.

Finally, I don't have a degree in CS. I still managed to learn all the big words and find value in them. A read a lot, not just API references, but about design patterns and architecture. I try new stuff, and sometimes make a bigger mess than I started with. I also make the type of salary mentioned earlier in the thread in a small US market as a full-time employee with benefits. I feel that I'm far cheaper than two programmers at half my salary.

Value	Fixed Point encoding
1.0	`<FONT style="BACKGROUND-COLOR: #eeeeee">0x00008000</FONT>`
-1.0	`<FONT style="BACKGROUND-COLOR: #eeeeee">0x80008000</FONT>`
2.0	`<FONT style="BACKGROUND-COLOR: #eeeeee">0x00010000</FONT>`
-2.5	`<FONT style="BACKGROUND-COLOR: #eeeeee">0x80014000</FONT>`