Or simplified:

Gullanian's is elegant. Grue's I'm pretty sure is less efficient than a for loop?

How important is that though? I'm trying to put myself in the problem domain of developing software for the web stack. Are you working on software that deals with the nitty gritty of individual characters in strings a lot? I guess the rationale is that if a candidate can't do really simple stuff like that they can't handle more complex stuff.

A possibly analogous situation is that say I am interviewing for C++ programming job and the interviewer asks me to write a program to reverse a linked list. It is pretty easy, basically trivial, to just use the c++ standard library. Also say that basically I have used the standard library extensively in my job experiences. I solve the problem using the trivial solution and the interviewr says no that isn't what I want. I want you to do it using nodes and pointers, basically restricting the solution to C only. The interviewer does this on the basis that one has to know C before they can master C++. I believe I can mention several ways where this is completely asinine.

lol didn't think of that. This job is awesome at making you feel stupid some times.

Its important to know if programmers can, you know, program. I always ask at least one fizzbuzz question. I like the above due to many easy solutions. If they can't get it, they really can't "program".

Adios, the reason people ask questions like this is that they're straight forward coding questions that anyone you want to hire should be able to do and that require a bare minimum of context to be communicated from interviewer to interviewee.

There's nothing wrong, imo, with starting from how the standard library can be used, but its totally reasonable to then be asked how to do it without that. I suspect it had nothing to do with wanting you to know C before mastering C++ and more that they want to see you tackle a less trivial problem.

First, C++ minus the standard library is not C and reversing a linked list is a basic algorithm question that has nothing whatsoever to do with C vs C++. Second, no one ever asks a basic algorithm question to see if the candidate happens to have memorized how to call the relevant function in the standard library that solves the exact problem.

Wait nevermind this won't work. Too early for me. This will just return the length of the array that contains the non a's.

Well its not about efficiency at this point, just "can you do it". There's been a "push" towards functional programming in JS lately too now that modern browsers support map/filter/reduce.

Did you mean to quote Gullanian's post? I'm pretty sure his works.

Yeah nevermind that's fine I typoed obv..

much slower, but with a slightly better code golf score:

I just tried to reverse a singly linked list just now after reading this thread but it's really inefficient ��.

You can reverse a list efficiently simply by swapping value pairs inwards

How easy was that test though? I'm glad i didnt stress over it

It's not very expensive in an ERP setting compared to the alternative imo. They are pretty much doing standard up front ERP consulting stuff while gaining the domain expertise. Basically while they pick up the expertise they provide value for the customer from the getgo. The business processes have to be analyzed either way, the security profiles have to be created either way etc.
We got very good feedback on this in general especially from customers that had previously worked with big ERP companies that tended to have or claim domain expertise. From a small sample they didn't bother to be in close contact with the customers because "they knew the domain/business/market". In fact this "arrogance" is somewhat commonplace when it comes to big ERP companies (it's slowly changeing). SAP specifically is notorious for telling people "we do stuff in this market thousand times over, use our standard processes...it's better for you". Common practice vs best practice etc.

It's also not likely that you happen to have a central banking or aerospace/satelite systems domain expert as a random ERP company that isn't huge. A pure satelite systems domain expert would certainly have cost more than a good developer for example.
+it creates a huge amount of trus from my experience.

I mean what do you suggest a non-SAP/Oracle/Salesforce sized ERP company should do regarding domain expertise? You can't just pluck experts off the street especially if you'd technically need them before you do the sales pitch to be ethical.

You can get a good anough understanding to get a face to face with some efford. Read a couple of websites, browse a couple of books, call a couple of people in your network, read some papers etc. Granted it takes pretty good and nonlazy sales people. Basically the pitch was "we know a little bit about the market from research, tell us how it works from your POV and we can tell you if we understand it well enough to deliver a great system". Honesty is very powerful, CTOs and the like have pretty elaborate bull**** filters.
It also helps if you are ready to not take on a customer if you feel you can't provide enough value/deliver a good enough result.

This is what I was thinking. But I like split() better.

wow @ macbook with 1 port in total and $80 dongle to get power, hdmi, and usb.

I think this notion while correct is a very commonly misapplied. Once again we worked in very complex and special domains not standardized stuff. I'll use the central bank as an example again. The only real domain experts are the employees of said continental central bank. You could get central bankers from another continent, regular bankers or economists. But the real deep expertise won't be there from 2nd level people.

Programmers tend to be smart and lifelong learners. What really matters is that they are willing to learn domain knowledge which often is not the case especially for "ERP stuff" which can be boring and non-sexy.

It is also very rare that you have to understand the entire domain. You usually need a decent broad understanding of the entire domain and then very deep knowledge of certain processes (that are often cross-domain).

As think as long as the required domain knowledge is "businessy" it's feasible to understand it deep enough to deliver excellence. If it gets more technical it gets harder (I'm thinking of software for an atomic reactor or something). But then again ERP is usually handling the businessy stuff even for technical domains.
If we're talking about writing the control systems for airplanes...hell yeah domain experts are important. If we are talking about optimizing the production of airplanes it's different.

Target a specific industry.

Yea wasn't too bad. I could see myself missing points though for being careless somewhere.


Yea and the price makes the MacBook pro > macbook. Unless you really care about the thinness, retina beats this all day

2 pounds and gold though. I'm interested in what that processor can do.

I guess that's what most proprietary companies do, yeah. Build up domain focused and bowling-pin your way up (Tornado/Hurricane etc). Lots of small ERP companies have a technical founder and a domain expert or two founders from a domain (or disgruntled big-corporation people).

I'll retreat to a position of "it most certainly works very well if you just send developers who are open minded and business interested to live with the customers for a longish time".

Or I guess...employees that love learning and are good at it are awesome no matter what you do :P

RE: Air...I've only browsed it but the design seems odd to me. Thinner, thinner, thinnner. Did I read it right...I can either charge or hook up a beamer? Doesn't matter in practice because battery life of all Apple laptops I've used so far has been excellent but seems rather obnoxious design wise.

I want to get a 15" pro anyway if I go that route (latest I read is there might be a new one in June) but new shiny stuff is always interesting.

Clowntable;

Have you ever seen the company-wide acceptance or backlash from the entire company? I'm not talking about the talking-heads who you meet, I'm talking about the cogs, from the guys at the computer who end up writing 1KLOC macro books to work around limitations to the guy on the floor struggling with the assumptions your scanning technology makes.

This is where I start to question the value of products and software. What is the point of causing a bunch of non-programmers to hack your systems? Have you ever seen the otherwise nice customer service manager say "I can't do it? Oh well, **** it." I mean, one minor wrong assumption causes massive reverberations across the system and affects the end-users 10x. The fact that you didn't have a domain expert means you didn't have a someone who looked at the end-users style (no two companies are the same) and could have prevented all issues by pointing out that you needed to add a single LUT to the database. It is these small nuances I'm talking about.

I will also say that end-users should be willing to grow into a company that can unify with the software as well, but just as software has legacy, the end-users have legacy and change is difficult in both directions.

I think that, notionally, we agree, but I think you and I have a very different perspective on domain expertise. Where I am saying find someone who has worked in the mud and titles be damned, you are looking to C-Levels, which -- sorry to be a jerk -- I feel is a destructive perspective because they really aren't on the line and don't (and shouldn't) know about the day-to-day issues the end-users are facing. I think there is a lot to be said for someone who can talk equally well to the floor guy, the office worker, logistics, and management.

I'm willing to give you a little more benefit of the doubt because you are an open-source company, so the end-user will be able to make modifications, so the things you missed will be fixed in due time for the most part.

I have dealt with SAP and many other popular and not-so-popular competitors, or rather, I've dealt with their sales teams. I'm shocked they get any sales at all because they are terrible at identifying the customer's need. You don't walk into a sub-20mil company and start talking about managing a nationwide fleet of trucks with 3 logistics hubs. You also don't walk in and refuse to discuss money. For small companies, you certainly shouldn't be backing your systems up with Oracle, MS, SAP, etc, effectively adding in a ton of hidden costs. What none of the people who gave online demos ever realized was that, sure, they are talking to one or two people, but there is a grip of 5 to 10 other people in the background watching and taking notes. It is an interesting dynamic. We post the two nicest "oh wow" people on the call, but the real decision makers are totally invisible. It is amusing to see a session took two hours, but the decision makers already decided they were talking to morons, the software was junk, and left within the first 10 minutes.

FWIW, the software that I was talking about at the beginning of all of this is targeted to a specific industry, and no, I don't feel they have any excuse to not have domain experts or prior end-users of their own or competing software.

@dave: I think I'm miscommunicating the process we used greatly. It was essentially: "Give us 2-5 guys that are the stone cold experts at what you do and will use this system until their eyes bleed. They need to teach us how they work, we need to understand what they do every day. They are part of the UI building process from the getgo, they need to show us how data flows through the system is queried and stored" etc.
Our developers were literally sitting at the same desks and spending the day with them for months. It takes a lot of commitment from custmers and a lot of them won't or can't work in this way.

We basically tried to understand business processes and day to day tasks (especially the mundane old paper document flows which tend to tell you a lot about how comapnies are actually working) as well as we possibly could and build the system around them (workflow based base system) not try to fit them into the system. The base system is ultra flexible.

---
If our sutomers didn't know their own business really well we'd be in deep ****. Many ERP companies are also process optimizers. We strictly didn't do that (explicitly). We assumed customers knew their processes pretty well and picked them accordingly. There was a lot of process optimization regardless but it was often more of a rubber duck effect/having new possiblities due to software improvements.

Aside: From my experience you could pretty much run a process optimization consultancy that only let the customers explain their processes over and over and serving as a very expensive rubber duck.

When does this statement stop being funny and starts getting sad?

"My program is _____ LOC and it doesn't do a damn thing."

a) 1000
b) 10,000
c) 50,000
d) 100,000

Yeah, it would take a long time to build up the trust between you and the company as well. I think there is a lot to be said about personality fit here, which is my main central thesis.

Consider the difference:

"Hi, my name is Binary Bob. I'm learning how to do your job. Why don't we try this instead?"

and

"Hi, my name is Programmer Peggy. I used to do your job. Wow, this program you are using is a piece of ****. Oh, neato, look at the size of the Excel equation! Why don't we try this instead?"

Who do you think gets more respect? Which one do you think will hear "Yeah, donkey ****, we already tried that" and get no further explanation why it doesn't work?