The conclusion makes perfect sense; software engineers should be paid much less than quants. After all, we know that software is really easy to build, that's why there are so many cheap programmers out there. Once it's built, there will be no maintenance problems, we won't need to add new features, port it to use some other backends, nothing which requires a really thought-out and flexible design and of course, who cares about security? When it gets big, we'll just rewrite it, hire ten more people to do it in three years and realize that we're so buried in technical debt that we'd be better of selling this to a big company and just doing another startup.
I think they were. They're being sarcastic, and commenting on how the end of the article puts the coder into a junior position and puts the math expert into a senior position.
How useful is the guy who thinks about algorithmic complexity but doesn't code?
At the end of the day, someone's got to write the code that runs on your servers. It doesn't magically transfer from that paper covered in pencil markings.
The actual conclusion of the piece made sense to me- all 3 were worthy of offers, for different reasons. Not hiring all three has less to do with how good the economy is (that was a non-sequitor) and more to do with the needs of the particular company at this particular moment. Right now they need people to design algorithms and to code.
They need both, and their company doesn't advance if they only have one and not the other.
depends on what they work on, business applications in large organizations we tend to direct programmers through reams of project documentation, from top level to familiarize them with what the overall direction is to technical documents which specify exactly the formulas to be used at all levels of calculation. These formula and related specification does include the number of decimals to use within calculation, rounding, and resulting decimal precision.
yeah its nice if they understand it all but programming isn't all shoot from the hip, many work in very structured environments which is more true when projects can have more than a dozen programmers on just one machine. Throw in three or more touch points and I am more concerned you follow the technical than branch out with your own ideas
It's hard for me to believe that Tom hasn't ever come across the knapsack problem and a discussion of space and time complexity before, but it's clear to me that he will be productive for a bunch of things immediately, and he probably learns fast.
And Harry is undoubtedly a resource of incredible value on things that the grocery startup hasn't even considered yet; exactly the sort of senior person they're going to need.
Hiring both of them is the right thing.
I'm not sure how Dick got past the phone interview, though.
Its amazing to see people actually taking the time to read ginormous walls of text and giving feedback, so thank you!
afaik Knapsack as originally stated is integer programming ie. it operates over discrete n, and NP-hard, so for large n the compute times are prohibitive. Simplex algorithms operate over continuous n[1], so you have amortized poly or worst-case exponential big O.
In other words, if you were in a fruit market with 1000 different kinds of fruit & you were not allowed to chop a fruit ( generally the case, you can't walk into Safeway, chop up an apple & walk out with one-eighth of an apple or half a grape or quarter blackberry ), then you'd have Knapsack, & there'd be no easy way to solve it for n=1000. But here you can buy 0.47 pounds of ham & 0.26 pounds of cheese & so forth ie. anything above 0.25 pounds is fair game, so the problem lends itself to a solution in reasonable time even for very large n.
There is a variant of Knapsack called Continuous Knapsack[2], which is solvable in polynomial time, in-fact O(n) if you reformulate a bit. But that isn't the simplex algorithm either.
I guess what I'm saying is - knowing Knapsack & dynamic programming won't help you in this case. I actually solved a very similar problem for BofA a few years ago. We used the commercial version of CPLEX to optimally allocate a couple hundred million dollars to a few million home loan portfolios across the US.
I was actually hoping someone would post a solution using criss-cross[3].
I thought that was an anecdote on how NOT to hire.
If you ask me a question and algorithm X is the "correct" answer AND algorithm X is obscure, that's a gotcha interview question. Why not just ask me directly about algorithm X? I could certainly look up linear programming and implement it, but I don't know enough to go through it on an interview.
Yes, being able to look up and implement an algorithm once you've been told its name is a useful skill.
However, being able to look at a problem and recognise that it is a specific instance of a well-studied problem with libraries already written to solve it is a different skill. Ultimately, someone on the team has to realise that the problem they're trying to solve is linear programming.
One day, a mechanic is approached by a company. One of the machines on their factory line isn't operating correctly, and they are in dire trouble. So, he goes, examines the machine over about ten minutes, pulls out a hammer and hits the machine. It begins working flawlessly. He tells the company the repair will be $50,000. They are aghast, and demand an invoice. So, the mechanic grabs a piece of paper and writes:
Labor, 10 minutes exam and hammer hit: $100
Knowing where to hit the machine: $49,900
Moral of the story: Looking things up is fine if all you need is a walk through the algorithm to implement. Knowing WHAT algorithm to look up and implement is the part you'll get paid for.
I'm interested in what you'd pay the sort of people who could pass these interview questions flawlessly. Even the recipient of the 'generous offer' admitted to not coding, which is what you were looking for.
Everyone in this line of work (probably in every line of work) tends to compare their own abilities with others'. Frankly, I have no idea how I'd solve any of this unless you said 'Knapsack problem, figure out how to implement it' -- even then I'd have to go google stuff. Is this kind of stuff standard for higher level work?
The first one asked me to implement a Naive-Bayes Classifier on Map Reduce from scratch (ie. no Naive-Bayes libraries), gave me real customer data & I was supposed to run the classifier & pick out the list of customers who should be sent emails based on the classifier's results. All in the course of 1 hour!
The second startup gave me a time-series signal and I was asked to figure out whenever the washing machine was running. When you have electric signals, you can decompose them into fourier harmonics, & running the washing machine leaves a distinct signature - you'd get extra harmonics if you ran the washer.
The third one asked me to flag a bunch of potential delinquent borrowers from a 30-year home loan repayment schedule. Risk prediction
What kind of positions were you interviewing for? Did you get any offers? Frankly, as a webapp developer, those sound like some tough interview questions!
imho there's a lot of froth in the market. this has created a bunch of 1-st gen AI companies in SF with speculative business models who want data-scientists to essentially work miracles & find needles in haystack.
If someone had told me you could datamine electrical consumption from smart meters, figure out when the customer is running his washer-dryer, and ask the customer to reschedule his laundry routine for a slightly smaller bill so the utility company gets a smoother duty cycle throughout the day, and there was a business model in that, I'd be flabbergasted. And yet, it exists!
This grocery startup that employs essentially portfolio management theory to optimize cost given calorie consumption is not entirely fiction either.
There's a company that datamines historical MLS data joined with facebook data & predicts which customers are potential home buyers because they are having a "life-event" ( usually birth of kid, so need extra room ) & realtors cold-call these potential home buyers.
There's an airline that datamines flight paths of every pilot on its payroll ( essentially (x,y,z,t) coordinates at time t) and flags the dangerous/risky pilots ie. the pilot who is prone to choose those flight paths that bring him very close to another airline, thus creating potential collisions between the airplanes.
I've seen demos of all of the above & more. We live in very, very interesting times!
