jconley

I'm pretty sure I could never get an engineering job at companies that interview like this. I've shipped tons of real world products over the last 20 years, founded companies, and just reading about what it is like to interview scares the shit out of me. I'm a firm believer in proving real world skills, not silly/irrelevant high pressure short time domain stuff.

Safe to say, we don't interview with whiteboard hazing. We do a phone screen mainly for personality and to see if the candidate deeply knows about a project they recently worked on. We dig in a bit there and look for the spark of passion. Then, if we are moving forward, we give a take-home project in a private git repo that is relevant to the role and tell them to spend 4-8 hours on it depending on their availability and ask them to time it and be honest. They choose the scope of work they want to accomplish. If the code looks reasonable we have a video conference where we do a code review and dive deep and ask "why" a lot.

We have been really surprised at the difference in quality of these take home projects. Some people can barely get started and struggle to produce anything. Others build full on, useful, applications.

Obviously we are screening for people that are self-starters, so being able to choose scope and regulate and make larger decisions is important to us.

An example project for a full stack c# developer:

Feel free to search around and work on the challenges as if you were on the job. Let me know when you think you can have this stuff done by. Please do this on your own time, with your own equipment and tools, and not your employer's. We don't want any lawsuits or IP ownership questions. Also, for the code, you can retain copyright if it's something you'd like to publish on GitHub, etc.

Clever Code Can you send me a code snippet in the language of your choice of something you have done that solves a hard problem in an elegant way?

For instance, here's one of my snippets from a few years back. It solves the complex problem of transactional optimistic concurrency control using ~30 lines of code. The usage of lambda expressions in C# and generics makes it succinct and expressive.

http://blog.jdconley.com/2009/01/functional-optimistic-concu...

Production Backend Question Let's say I have a very popular consumer facing service with 10 load balanced front end web servers running the latest asp.net mvc and averaging 100 simultaneous requests each, appropriately sized ms-sql servers, and a heavily used memcached cluster of 4. Everything is running great until we do some capacity planning and double the number of web servers to 20 and experience a 25% increase in simultaneous requests. Suddenly load shoots up on the ms-sql tier with far more transactions per web request than typical, overwhelming a ms-sql cluster that should have handled twice as much web traffic. Web server requests start timing out and throwing 500 errors to the clients, and the system practically comes to a halt. There were no code changes. Describe how you would troubleshoot this and what you think might be a few likely causes.

Failure Tell me about a project you have worked on that failed. What was your role? Why did it fail?

The Challenge This is meant to be a practical exercise, and is representative of the types of challenges we face. We want to see if you can make reasonable product choices under time pressure as well as write code. You get a lot of ownership here. Please use any frameworks/services/etc you want. We suggest using something you know very well. Feel free to search Google, go to the library, call a friend, or whatever you need for research. Please write all the code/copy/etc yourself. The output can run on whatever OS or PaaS/SaaS provider(s) you want, but it should be something we can also easily run. Please try to limit this to 4-8 hours of your time.

If you want to keep the repo private, please share it with me: https://github.com/jdconley

Create a web site with the following characteristics: Make the hackathon/minimal/proof-of-concept version of some popular consumer web app that you think could use some love. Craigslist, eBay, reddit, whatever...? Site must be responsive, gracefully scaling down to smartphone resolutions and up to full screen desktop displays. It does not need to be beautiful. Supports all the way down to IE8, with appropriate feature degradation as needed. Lean toward implementing things in-browser rather than in back end code. Bonus points if you do a Show HN and your implementation makes it to page 1 on hacker news.

Looks like this uses a Ruby version of redlock under the hood: http://redis.io/topics/distlock

Seems to be just a little abstraction so you don't manage the locks yourself.

So this is for read through caching with distributed locking. There are a couple scenarios where this is interesting.

1) If calculating the item in the cache is so expensive to some system, and might happen so many times concurrently, that you'd rather block than duplicate work. 2) There is something not-idempotent about the operation you are blocking on.

But, coming from experience, be very very very very careful with distributed locking and put lots of logging/monitoring/timeouts around it if you have to do it. Avoid it if possible. Try hard to use a different persistent data structure, store, or algorithm that makes the locking irrelevant.

I've been a user of this client for quite some time, and I've always had to use it with a light touch. Click one thing, wait until done, click another thing. Basically serializing things myself, because even though the UI allowed the input, the state of things would get really screwed up if you did things concurrently.

If concurrency control in a multi-threaded, multi-process, app is a premature optimization, well, wow.

At the end of the article the author states: "Before these changes, GitHub Desktop suffered from race conditions as units of work would become interleaved in error.

Since implementing the concurrent/exclusive locks we have seen an improvement in stability and performance. "

Sounds like they used to just let the client spin up multiple concurrent operations fairly willy-nilly.

Perhaps I'm just feeling like a Grump Old Guy today itching for some down votes, but, why was concurrency control like this not in the client in the first place? Seems like a pretty core thing to an application designed to do destructive things to large swaths of files.

I bet the devs could code algorithms on a whiteboard like nobody's business though! /s

On a less-grumpy note, we really need a way in this industry to disseminate knowledge through the generations. I can't believe how many posts like this I read every day where someone rediscovers the same truths over and over again, that those of us with more experience also "discovered", and those before us, and so on.

Stored procedures, functions, triggers, etc, are very useful tools. They are used regularly in Microsoft SQL Server and Oracle systems.

But, one has to be very careful to use them when warranted. The out-of-the-box tooling for debugging, maintaining, versioning, and testing code that lives in your database is not nearly as robust as what you have for most other development environments.

The key here is to use the tool when it is most useful.

SPROC's are good when:

1. You need extreme data security and you are able to pass authentication tokens from application to database. You can apply authorization rules when you read/write the data, rather than transporting more than you need over the network. This eliminates a number of potential attack vectors. I have worked on HIPAA compliant systems for government agencies that held sensitive data that required all data access to be through stored procedures with proper access permissions, in addition to an authorization tier in the application logic. Very common use case.

2. You need to churn through a bunch of data and need very close data locality to pull that off and meet your performance requirements.

2a. Your database nodes are network IO bound and this is due to applications requesting more data than it needs, and that logic can be performed in the database.

3. You have a very strong DBA/Developer that can manage your data access layer that your application uses as well as code the database. This can abstract the "how" of data storage from the application developer, which can be very useful in a data-centric large application.

However, SPROCs are bad if:

1. You have to switch DB providers due to scalability, or cost issues, etc. The switching cost can be huge if there is a ton of logic buried in your database.

2. Your database nodes are CPU bound. In this case you'd want to do as little logic as possible in your DB. This is more rare nowadays, but used to happen.

3. SQL (or whatever-sproc-language) is not a core language you want your team to have to become experts in.

4. You don't like adding more code. You'll end up generating and writing yet another layer of code, this time for stuff that lives inside your database. This code has to be maintained, versioned, etc.

Modern CPU's are so complex I'm not convinced that one can reason about the performance implications of micro optimizations such as the div trick. Perhaps the 0.001% of developers that specialize in, and understand how said CPU's work might be able to, but for the rest of us, we have profilers.

There are so many layers of abstraction and so much to understand in modern computing that it is a Bad Idea(tm) to tell engineers to not profile.

Irrigation methods can significantly reduce water usage for some crops. Others require gobs of water. I don't know the numbers for each crop, though.

The Almond Board of California has some info on this for Almonds. Obviously, take this as you will, given the source: http://www.almonds.com/pdfs/waterfactsheet315.pdf

Yes, California's historical (lack of) ground water regulation and tracking was/is disturbing. Nobody has any idea how much is there or how much we are actually using.

There are limits on extraction going into effect [0], but it may be too late by the time they are supposed to happen.

[0] https://www.hcn.org/issues/46.19/californias-sweeping-new-gr...

% of GDP is one lens to look through when thinking about water rights. Having access to affordable/local/healthy food is another.

I think incentives would help, yes. There is also a "use it or lose it" system builtin to many of the water rights contracts that are toxic. Much like big corporate budgets, farmers find a way to use the water just in case they need it the next year.

The reality is it is very expensive to change irrigation systems in established orchards. Incentives to do that would certainly be well received by the tree farmers I know.

I know this is all straw man, but interesting stuff...

Many crops use much more water than Almonds [0], I guess they're just fun to pick on. It'd be interesting to see a calorie/water comparison of many foods.

Also, my family's farm spends more money on well water than the government supplied water due to the high cost of electricity for pumping.

I do agree that a real market for water might help. The root of the problem really is that we are farming in a desert and relying on water from other locations. However, the desert does otherwise provide a great climate for efficiently/consistently producing many crops.

[0] http://www.latimes.com/opinion/op-ed/la-oe-gleason-almond-fa...

It's much more convoluted than that, unfortunately. There are many layers of rights to water. Farmers will get anywhere from 100% to 0% of water from government sources. For instance, my family's farm is getting 0, so they are forced to rely on well water.

Many farmers are getting no [0] water this year and are relying on ground water to keep trees alive or not planting seasonal crops. Others get a very small fraction of their typical allotment [1]. California water rights are complicated...

[0] http://www.sacbee.com/news/local/environment/article11355200...

[1] http://hanfordsentinel.com/news/in_focus/california_drought/...

The challenge of the more accurate method you describe is balancing how much CPU is used to find the point in game time where a collision occurs because it is almost certainly at some point between your tick times. You have to perform the calculation at many units of time across the tick delta with the significance level you care about, with more calculations necessary as velocities of bodies increases.

Of course, this is what physics engines do, and why you should probably use one instead of reinventing the wheel.

In terms of showing how a game loop and really basic game physics works, however, this is a pretty clean and understandable example.

The alleged red-handed part is that Verizon used Title II to build out fiber lines under the guise it was improving its telephone service, but was actually using the fiber for broadband services which it does not want regulated under Title II. Sounds like the proverbial "having your cake and eating it too".

RealCrowd (YC S13) - Palo Alto, CA - Full Time

RealCrowd is a seed funded, profitable, commercial real estate investment marketplace. Investors purchase shares of commercial real estate properties, funds and debt, and participate in their share of the returns on those investments. What were once investments reserved for large funds and country club networks are being opened up to the individual investor.

We are taking a fundamentally different approach than others in the "Real Estate Crowdfunding" market and it is working. Investments are growing at a rate of 25% per month and our investors make on average three investments per year at over $50,000 average investment size. We've participated in over $500 Million of real estate transactions with top real estate firms, investors using our site having contributed nearly $17 Million of capital. We listed the first investment about one year ago just before demo day on August 20.

We're looking for junior engineers that have a passion for the responsive web, an unusual ability to ship code quickly, and a desire to learn from industry veterans.

The RealCrowd site is 100% responsive with about 20% of our sessions originating from mobile and tablet devices.

Our front end is developed primarily with a custom Bootstrap theme, AngularJS and CoffeeScript.

We are an API-first development organization, so there are a myriad of APIs available to the front end.

We have designers on staff to help ship best in class UX and visual design.

We're looking for junior engineers for entry level positions to work on a team with 5 senior engineers with an average of over 10 years of software development experience. We are growing and there should be much room for internal advancement in the future for motivated employees.

You should be able to: - Build web sites using html, css, and javascript - Learn new concepts quickly - Try, fail, and try again - Be familiar with server side development in a fairly modern environment such as MEAN, RoR, ASP.Net MVC, etc - Have a passion for building great user experiences - Accept critical feedback and improve your craft - Be passionate about being the best software developer you can be - Get shit done

You will do a small project (where you will maintain copyright) and take a little test rather than have any BS technical puzzle interviews or whiteboard coding.

We have 100% paid health insurance, great food, a relaxed yet high output work environment, and commuter benefits available. This role is on-site in Palo Alto.

Check us out: https://www.realcrowd.com A bit about culture: https://www.realcrowd.com/blog/2014/08/realcrowds-team-cultu... Tech blog: http://code.realcrowd.com

Email jobs@realcrowd.com. Include samples of your work, if no samples are available email us and we can send you our coding challenge project.

Well, you are talking about over a million people in that area. I'd say that's a reasonable sample size. Also, not sure we know who their clientele are. We use doordash for the office, but I also use it at home. Because of their level of service it has also become a destination site, where I go to see what they offer first rather than choosing the restaurant I want first. I imagine I am not alone.

We're a YC startup in California (Palo Alto) using .NET. We also use other more hip things, but .NET is the majority of our server side stack. We wanted something mature and solid that banks would use for a transaction system. Something that would let us hire great talent and not compete with all our startup buddies over RoR and node.js rockstars. Something that supported a nice mix of functional and imperative programming techniques. C#/.NET fits the bill pretty nicely.

Regulations are currently prohibitive in this area. Look for that to change soon as the JOBS Act implementation gets finalized.

"Augmenting their funding" through the site also allows operators to build relationships with new investors and expand their network. It's lead gen for them for future deals.

Thanks for the feedback! We do have two eBooks (you get them upon signup), with another in development. We are also working to create a dedicated educational section and will definitely include more inline help in the future. Feel free to contact us with any questions.

1.) We charge operators listing fees and use typical recurring SaaS pricing for the investor/asset management features. We're (of course) working on a home page redesign that communicates this clearly. RealCrowd pricing is not unlike an MLS or other marketing platform.

2.) $235MM+ is the total value of the assets that have received equity funding through RealCrowd. Kind of like PG saying YC portfolio companies have a total value of $XXB. Though in our case that number is based on the value of real property at the time of acquisition.

Thanks!

EDIT: Grammar

RealCrowd co-founder here...

The investments are direct with the real estate operating companies, avoiding layers of fees imposed by the REIT structure.

These sponsors do get traditional funding. The operators we select to be able to post on RealCrowd do not need capital from the internet at large. Instead they augment their fundraising or recapitalize an existing property so they have more free capital, allowing them to do more deals. Since we do not charge any carry or other fees to investors, sponsors also bring their traditional investors onto the site to make the fundraising process easier.

More info on our operator-focused page: https://operators.realcrowd.com

There were plenty of seasoned folks [1] in our YC batch, our group included. 3 of 4 of our founders had families and real responsibilities. One major advantage to YC is it opens doors and connections. Many (most?) YC companies have more funding within 4 months than the ~$100k they get at the beginning.

[1] http://www.forbes.com/sites/parmyolson/2013/08/20/latest-bat...

I've definitely done the separate channel thing in the past for update notifications and it does perform very well.

Our setup is a pub/sub system, where the "sub" happens implicitly with the request for a resource via the GRIP proxy and protocol and the "pub" happens when we update our models as well. The proxy acts a lot like node.js and Socket.IO would, but simply speaks pure HTTP on our RESTful resources instead of the Socket.IO protocol over their transports.

In this approach we aren't re-establishing connections every time since the server side supports keep-alive and the clients are web browsers, which also support keep-alive.

We also hit the API once to push out changes to the subscribed clients through the connection proxy. And the next poll has relatively minimal overhead (obviously not as small as 0) to be queued back up.

In the end, though, this obviously isn't an implementation aimed at extreme efficiency. If that were the goal we'd take a much different approach.

It is about simplicity and semantic elegance.

Yes you can certainly stream and do message passing within HTTP (for some browsers) but you can't, for instance, return headers more than once without your own application protocol.

The most interesting bit about this architecture for me is the 1:1 mapping with a pure HTTP resource. It's a bit like an implicit subscription to a pub-sub enabled resource. In this implementation we are simply calling our API like we normally would (except on the stream domain) and waiting for an update.

Processing the poll request certainly has a bit of a CPU/memory/network overhead. Though any sort of keep-alive would require something similar. I'm sure we'll get fancier with WebSockets when we have to rent too many new servers because of this stuff. The simplicity and elegance of overloading the RESTful HTTP system was the most appealing bit for me with this architectural experiment.

Yes, it's definitely still polling. It is polling about once per minute. However, at least it's only polling at the application protocol level, not the connection level. Browsers and the GRIP proxy support keep-alive so the same TCP connection is very likely to be re-used for quite a while.

HTTP by nature is request/response. To speak pure HTTP, there isn't a way around polling that I know of. Avoiding polling means implementing your own protocol over HTTP, or using WebSockets (see Comet or implementations in Socket.IO, Firebase, SignalR, etc).

We didn't see much of a need to expand beyond long polling, if for nothing more than simplicity's sake. Realtime is a small feature in small parts of the application right now. Keeping it very simple and coupled with our RESTful API let us roll it out quickly.