karterk

It depends on what you are trying to achieve. There are many, for e.g. see: http://cs231n.github.io/neural-networks-2/#losses

Practically speaking, someone looking for a job change does not have 10 hours to spend on every company's coding challenge. So, you will have only a few people who would go out-of-the-way to do something like that.

And, that's not very different from someone spending more than the expected 40 hours at work. One can't do much about that if that person genuinely loves coding all day and does not mind working 60 hours a week.

Finally, in the follow-up call, I do ask the candidate how long the assignment took and how she spent her time across multiple tasks. Obviously if someone spent 10x the expected time, then that's another data-point to the final decision.

This has been an area of interest for me as well. I have spoken to a lot of engineers and hiring managers on this subject, and my takeaway is that no two engineers seem to agree on what's the best way to hire people.

Some think that code-while-on-the-phone interviews are bad (too much pressure for some candidates), while others think that take-home interviews bring all kinds of issues (e.g. candidates copy pasting code from Stackoverflow).

Some think that white-boarding is important (insights into the thinking process versus syntactic correctness), while others think that it's not a true evaluation of what the candidate will actually be doing at work.

Some think that asking pure algorithmic questions are bad (does anybody even implement their own hashmaps at work?) while others think that it's a reflection of how much a candidate explores the depth of a subject.

Some swear by HackerRank/Codility based automated tests to "filter" unqualified candidates, while others think that looking at Github for their code samples would be a better evaluation.

Some want generalists, while others want specialists.

Some people reject candidates on arbitrary "culture-fit" reasons.

Personally, here's my ideal interview process based on all these conversations and my own 100+ interviews in various places I have worked:

* Minimum reliance on resume - some people are just bad at writing about their achievements

* Have an initial 30-min call to learn about the projects that the candidate has worked on (especially if you are hiring a specialist). This should not be a filtering round unless you see something totally off target.

* Send the candidate a take-at-home coding assignment. This should ideally take only 2-3 hours and should be directly related to the kind of work she will be doing at work.

* Have another 30-60 min follow-up call to ask the candidate about the approach taken, alternate options, and possible extensions. This will help one ensure that the candidate had not merely copy pasted the code from the Internet.

* If everything looks good, bring the candidate onsite for face-to-face interviews.

* I prefer 2 rounds of face-to-face - the first round asking questions around the candidate's areas of strengths, and projects previously worked on by her. On the second round, I prefer asking questions that are from the domain I am working on. This will allow me to find out how the person attempts to understand a new domain, and whether the person listens/asks questions etc.

At the end of the day, interviews are subjective, and I have made peace with the fact that you're always going to miss out on people who might have just had a bad day.

This also explains why VCs look to fund billion dollar opportunities even if they look a little risky. VCs are in the game for big exits and that's how the math works out.

Something to keep in mind when you're planning to raise money.

Being on AWS does not necessarily mean that you don't need a devops person - especially at the scale where not being on AWS actually makes a difference to your margins.

I have seen quite a few people move off AWS successfully onto bare-metal leased hardware. S3 is just about the only service that's difficult to find an alternative for. Personally, I find using something like DynamoDB no different than using an Oracle DB - it's a vendor lock-in. Unless you had enterprise-level support on AWS (which costs a lot) - if you run into issues with Amazon's proprietary services, then good luck to you.

AWS is great to get started, but once you know that you're going to need scale (and lots of infra), it's best to move.

I say all of this as someone who has extensive operating experience on AWS. YMMV.

Flywheels sound exciting but their energy density is about the same as Li Ion batteries (even when carbon composites are used). There are very few large scale deployments of flywheel energy storage systems in the world despite lots of active interest in them. Safety is also a huge concern since if there is a mechanical failure, a huge amount of kinetic energy will have to be safely disposed or you are going to have shrapnels flying everywhere.

>They got me a great interview at a large, well known company- who didn't end up making an offer, but had a great hiring process.

Unfortunately I thought that this was exactly the problem starfighters was supposed to solve. I.e. qualified engineers getting dropped mysteriously due to various biases of a company's interview process.

Semantic word embedding:

https://code.google.com/archive/p/word2vec/

Recurrent neural networks:

http://karpathy.github.io/2015/05/21/rnn-effectiveness/

This is literally one of the most exciting papers I have read recently that will have quite some impact on deep learning models. The major drawback of deep architectures today is training time and any.improvement to that will have a drastic effect on my productivity.

Right now I basically run N architectures on N GPUs at the same time to speed things up. And that's a luxury.

What would your ideal interview process be like? I often hear about horrible interview processes on HN, but it would be interesting to hear how it can be improved.

For a very long time, I did not want to use ad blockers. I have used ads in the past to monetize some of my own projects, and I really did not want to stab the creators of quality content.

However, last week I finally reversed my decision and started using ad blockers. Why? Frankly, many sites are just greedy. Banners were ugly enough (and I tolerated them) but many sites these days show ads that cover the content, and going as far as to hide the [x] button for a few seconds. And, I am not even talking about privacy and security issues.

Businesses have to come up with better monetization strategies. Shoving ads on my face and making me accidentally click them is a net loss for everyone.

> You don’t get to use to your own IDE, you have an absurdly limited amount of time and you’re in an incredibly high-pressure environment.

Ironically, HackerRank itself is a part of this problem. All of those are true for HackerRank coding challenges.

As another commenter has pointed out here, HackerRank (and other coding test platforms) want to commoditize the hiring process, but in a way that ensures that candidates are the ones who are doing the all the work. The companies just don't want to spend any time in the interviewing process. It's no wonder that so many companies are struggling to hire good engineers.

If you as a company throw me an online coding challenge as the first interaction, you can be rest assured that you won't be hiring from me again (and many others).

All of the concepts are still valid since he covers the fundamentals.

Interesting. What does your typical day look like? Does it involve a fair bit of ML/algorithms and making them scale horizontally?

This might be an unpopular opinion on HN, but another example of this problem manifests in the sheer volume of companies that require a HackerRank screening test these days. Apart from the clumsy web editor, recording someone under a time constraint means nothing in the larger context of how a programmer's actual work happens. Sigh.

By using such automated tests, companies want to identify top talent by taking a shortcut and not investing any time on their side.

I want to give you an alternate perspective. Sometimes it's far more liberating to accept and move on. There is this book called "Dip" by Seth Godin. I recommend that you read it (it's just 70 odd pages). In that book, Seth talks about how, when you are in a dip, it's important to realize whether to persist and succeed, or to quit. When things just drag on there is an opportunity cost associated with that. Unfortunately, only you are the best person to decide whether you should ride through this trough or to move on.

My first 3-4 side projects were abject, miserable failures. It took me 5+ years of waking up to failures before I had something going that really gained traction. If I had just stuck with my first project, I am sure I would have gotten nowhere. So, have the guts to pull the plug on the project if you think it's the end of the road. It's okay - take a break, and you will bounce back even stronger.

I'm saddened to read such dismissive comments on HN. I think it takes someone to have been in a similar position to understand the plight of the OP. The CEO had a chance to fix this and do the right thing, but firing her was the easy thing to do.

> Seriously, I would never ever hire someone who wrote something like this.

The fact that nobody writes about these issues is the reason why some companies take their non-tech employees for granted.

But when you do need generics and use templates, you are forced to write lots of code in .h files. There is very little you can do in that case to speed up build times, without resorting to devious things like PIMPL.

While I don't know the details of this offer, I would strongly advise you to give it a pass. Such a paycut will rarely compensate you fairly even if your start-up ends up being a moderate success (~200 M exit). Unless this company already has a terrific traction and you get a significant chunk of the options, there is no point in a 50% pay cut.

There are also several gotchas around start-up options. You should read this: http://blog.samaltman.com/employee-equity

I agree, but unfortunately that's not how it works. All founders believe that they can succeed. Every VC believes that their investment is going to become the next billion dollar company, etc. Ideally, options are the icing on cake, but the reality is that most companies use options as a way to reduce their immediate expenses - for start-ups, cash is like oxygen. Most start-ups die not because of their competition, but they run out of money.

You have to look at the 0.2% in relation to the salary that they offer. And, many companies do allow you to negotiate the salary vs options trade-off.

The period (typically just 30-90 days) for exercising the options is the most unfair of the lot. Most of my friends who left, say, after 3-years, simply were not in a place to exercise their options because of the financial implications. People leave for various reasons, and it's extremely unfair for someone to be in this position after 2-3 years. I wish more companies would adopt the 10-year exercising period.

Awesome :) Thanks, I learned a new trick today.

How did you find your first 10 customers? How about the first 100? That's always the hardest part when you start something.

Implementing all-pairs similarity search on a few hundred million records. Naively approached, the complexity of this is O(N^2), so had to come up with novel ways to make it finish in a reasonable amount of time and with limited resources.

Then, why Golang? Are there other things that make this duplication worth?

You would never know unless you started exploring. Stars have nothing to do with revenue - it's purely a function of how much value you can add to the enterprise. Basically, you have to demonstrate quantitatively that you can charge $X to help them save $Y where Y >> X.

Here's what I would suggest. Reach out to a few people from these organizations and ask them for their general views on your project and what their major pain points are. I'm sure they will be more than happy to talk to you about it if they're indeed already deriving great value from it. Once you have established a good rapport (i.e. warming up the lead), set-up a call with them to pitch your vision for the paid product. A call is crucial because email and text can only communicate so much - you can get a far better idea of their domain and problems through a quick 45 min call. Scheduling this should not be a major problem once you have established a good email channel previously.

If you can get about 8-10 people interested in exploring your paid offering you have something that's promising. After that you can think about scaling the business with self-service etc.

Interesting - what candidates do you recruit using Craigslist?

I don't follow you - can you elaborate?

In another thread, you had mentioned that "I don't think we'd use this design again". Curious to hear how you would design such a system differently, without using a LSM tree approach that's popular these days?