Talk more about the product you built (What worked, what customers said, how was it improved overtime, what did you learn from customers using the product and talking to them), rather than going in detail about the technical requirements of the product (Used technology, improved loading time by n%, rewrote using a different framework).
And the reason why it's important is because startups fail because of bad value propositions, not lack of technical expertise.
As someone who describes themselves as such and has had good success - demonstrate that you care more deeply about the success of the product than "technology" itself. Code is a tool to solve those problems - focus on what has worked and not worked in coding, rather than what is cool and exciting. Its more of a mindset thing than anything - spend enough time actually being interested in business problems rather than CS problems.
If you want a product focused career path, start getting "product" in your job titles. Every employer knows I'm a product engineer because "Product Engineer" is on my resume.
Like others have said, the rest is mostly about the way you talk about what drives you. Solving hard problems is nice, but demonstrating that you can think well about building something people want is what you should aim for.
Maybe not! Entirely possible. How could I possibly know, though? I just try to focus on being kind and empathetic to people, supportive to my coworkers and employees, be mindful of how my actions affect others, and when I screw up, try to do better the next time. I don't think there's much more than that most people can do.
I don't understand how verifying a TSP is any different to solving it - I.e. don't I have to do just as much work to verify that a particular solution is correct as if I was solving it from scratch? I.e. brute force?
There are a few ways to ask the TSP question. One question is "give me the shortest route geometry", this problem is NP-hard and can't be verified easily, this is what you're thinking of. However, the decision version of the problem is usually phrased "Is there a tour of less than length L", and this is NP-Complete - takes a while to find the tour, but it's trivial to check if it's less than length L.
That works for one way (where the tour exists), however, if the true answer to the particular decision problem is "no! it can't be done in L steps!" - then the only way to verify is to repeat the whole process, no?
Having an easily verifiable tour that does it in L+1 doesn't really help in verification that some other combination could or could not do it in L steps.
NP only requires that you can verify a positive answer in polynomial time. Problems with polynomial time proofs for negative answers form the class Co-NP.
Besides that, if you can solve the decision problem and the distances are well-behaved, for example integers, you can solve the other variants, you can perform a binary search for the minimal tour length and you can find the actual tour by probing all edges, i.e. removing one by one and checking whether that increases the minimal tour length.
You can just choose an arbitrary starting L, and if the answer is No, keep doubling your guess until the answer is Yes, then just binary search from there. Or if you want to start with the maximum possible L, just start with the sum of all the edge weights in the graph.
TSP is NP-hard -- we don't know if it's in NP (that is, we don't even know if there's a polynomial time algorithm to verify whether a proposed solution is optimal). The decision problem of TSP is NP-complete:
> The problem has been shown to be NP-hard (more precisely, it is complete for the complexity class FPNP; see function problem), and the decision problem version ("given the costs and a number x, decide whether there is a round-trip route cheaper than x") is NP-complete.
( https://en.wikipedia.org/wiki/Travelling_salesman_problem#Co... )
The author got this wrong in the article -- just because you can check that each house has been visited in polynomial time proves nothing.
(other people have answered you already, and their answers seem quite knowledgeable, but I sense their answers are actually off the point of your question, i.e. I think there is a better answer than you have been given. However, I learned this material long time ago and the precise answer is not fresh in my mind, so hopefully I can give you the gist, we'll see, but apologies in advance for all my hand waving)
it's like this: if I give you a large number and say "factor this", you will work hard figuring out the answer, but if I give you a set of factors and say multiply them together and see if they equal the big number, you can do that fairly quickly. i.e. you can check the answer a lot easier than you can find the answer.
An NP complete optimal routing problem is the same way, it's hard to find an answer, but if somebody gives you the optimal solution, it is easy to check that it is optimal by substituting segments from the solution set for segments that are not in the solution set, and trying to incrementally improve on it: if you have a solution, none of your substitutions will piece-wise be an improvement, furthermore, you can do it in an orderly way that "proves" your route is best precisely without duplicating all your work. This is the part I don't remember but it's something like "find the longest segment on your route, is there some shorter way to accomplish what that accomplishes? no there isn't. or look at the shortest segments, are they penny-wise but pound-foolish, no they aren't." i.e. the part I do remember is that it is polynomial time to confirm the answer, and it is not polynomial time to find the answer. This is what is in fact meant by "non-deterministic polynomial", it's polynomial only if you magically know the answer in a non-deterministic way. Polynomial to check, but in a deterministic way it is not polynomial to determine.
Again, sorry for all the handwaving, but I'm pretty certain that's right.
Oh, and while I'm here, what was the most irritating thing about this article is that P vs NP is not a huge "assumption". Call it a conjecture, call it a hypothesis, call it a problem to solve, but it's not an assumption, it's been tested long and hard by a lot of really smart people and it's the fringes of our knowledge. That's not what is typically meant by the word "assumption".
The actual decision problem statement for TSP is "Does there exist a tour of less than length L".
It is easy to prove if such a tour exists: simply give me tour. I can sum up the lengths and check that the sum < L. Finding such a tour is the computationally hard part in the worst of cases.
The Traveling Salesman Decision Problem, the one that's NP-complete and not just NP-hard, does not ask for the lowest cost route. It asks whether there is a route cheaper than k. Verifying that is trivial, you just follow the route and compare to k.
Check if your brokerage is offering them. Usually there will be a way you can sign up for "new issues".
In this arrangement, you would enter into an "expression of interest" to purchase shares at the IPO price, if your broker was allotted any shares by the underwriters. Once you have entered into this, you must be ready to buy the number of shares you indicated at the IPO price, but if there is a lot of interest, you may not get fully filled and may not even get filled at all.
I love this part of the article, it's incredibly important to remember this:
"The web is the greatest entrepreneurial platform ever invented. Lowest barriers of entry, greatest human reach ever. I love the web. Permission-less, grand reach, diversity of implementation. Don’t believe this imaginary wall of access of money. It isn’t there."
I believe that the next evolution in startups is full recognition of this fact. Costs are practically zero for building viable SaaS products. Great developers are everywhere. This isn't just over optimism, it's largely true. What will that mean for startups and capital? My prediction is we will see new models, more "startup factories," etc. Interesting times.
Which does not diminish the original point. Everybody says they will only hire genius top-1% programmers and that's usually ridiculous. For the vast majority of products, you don't need 20 great developers to build it and make it great. You can do it with 20 mediocre developers and one or two great leads who can mentor and help them perform at their best.
If that's true, then it should be easy to name some startups that fell into technical mediocrity and recovered. Are there any?
I saw the opposite happen firsthand: a company that was about to get steamrolled by a competitor, and they knew it. There was nothing they could do, even though they had over two years to prepare. The reason they couldn't do anything was because their team was mediocre. Last I checked, that company no longer had any job listings.
How many people here have similar stories? It's tempting to believe that mediocre programmers can be mentored, but it doesn't seem that simple.
I would say your statement is predominately false. Great developers can be found in most places, and even more if you don't require that everyone be together.
This is probably it, there's even movies about it (Legally Blonde, etc). What's different there is customer-facing vs non-customer-facing roles, a lawyer who shows up in court in non-professional attire is going to get flak, and I don't know what the immediate female-heavy analogue for a back-of-office, not-customer-facing male-dominated engineer department. The usual examples of female-dominated professions like nursing and teaching don't fit that comparison.
But it's very disingenuous to call engineering low social status these days. Wearing Star Wars t-shirts or talking about computer parts and technology 24/7, yes, that will still receive at least some ribbing, if not more, but that's not the same as being an engineer by day. In my recent social experience, reaction after someone asks "what do you do?" is pretty uniformly somewhere on the positively-neutral-to-impressed spectrum.
A little off-topic, but has anyone else found that a lot of Haskellers fit into that "pet technologists" category? I've worked with a number of them, and seen them sneak Haskell in, despite it not being the best choice for the project.
The really weird thing is that the couple of people I've encountered this problem with weren't very good at Haskell. A big ol' mess of code mostly in IO, scattered willy-nilly with a lot of code duplication (in Haskell of all languages!). No pipes, no lenses, unnecessarily partial functions, manual implementation of things the type system is supposed to do, just bad in every way. (Not saying you "have" to use pipes or lenses, but you ought to know what they are and choose not to use them, not have your choice forced by ignorance.)
And, uh, quite tetchy if I even hinted at the possibility there were better ways to write that stuff. These people also expect to be the only ones who know Haskell in the area and are, ahh, unprepared to be wrong.
For what it's worth, don't judge Haskell by these people anymore than you'd judge any other language by its worst adherents. It may not be The Answer To Everything (TM) but it is worth some study at some point by any developer interested in progressing their skills.
I asked myself the same question. What is the best choice depends on both stated goals, assumptions, and predictions, which means others might differ in their assessment of the right tool for the job. In this case, why was Haskell not the best choice for the project and do you think those that tried to introduce it would have agreed?
Actually, this exact thing happened to me. I was asked to come in for a couple of hours to meet the team and see the office. When I arrived I was taken to a room where I was interviewed for 3 hours, by 3 different interview teams. Two of them were whiteboard interviews, then an interview with management.
Needless to say I rejected the offer, I was so unimpressed with the hiring process. Disgusted actually.
Did the disgust manifest after, or during, the 3 hour process? Curious to know whether there were other factors in play (perhaps curiosity?) that made you stay throughout the ordeal.
I recently did some interviews which were described as "can you come meet with our engineering team in more depth". Which I read (correctly) as "technical interviews", but the description was certainly a bit coy.
I think people tend to use euphemistic language to try to preserve a "we're all buddies here" atmosphere, and out of sense of discomfort with the idea of interviewing.
(Though it's not such a huge deal, to me -- any time I'm talking to someone, if we're considering working together, it's fair game to get into technical questions, IMO.)
Is it the particular things they have worked on at other jobs, i.e. their experience, or is it the way they talk about what they want to build?
I'd be really interested to hear how I can make myself sound like more of a product programmer.