zlacker

Early on in Ello's life, possibly year 1, I interviewed for a job with them - back when their office was basically one floor of a residence, and all the engineers pretty much worked at a single dinner table packed with monitors. I probably scored the interview because of my previous experience as CTO of a startup social network for people who wanted social change (which we sold to Gaiam, and that's how it eventually died a few years later, but at least I ended up in the Denver/Boulder area).

Anyway, the code test part of the interview involved pairing with another engineer on a small portion of the ello User model (their application was built with Ruby on Rails at the time), and I remember being rather underwhelmed by what they asked me to do, at least in terms of whether it provided a decent test of my abilities. I ended up sending a follow-up email expressing that, along with numerous polished samples of other project work.

They ended up passing on me, but I stayed a member of ello for a while longer because I thought the idea might have promise. Maybe I left too early, but I eventually ditched it because... there was no "there", there.

I liked their general idea, but... they could have done so much more with it, even with a small team. As it was, I left before ello ever got out of its "tumblr clone with way too much empty space" phase - if it ever did.

RIP

>>wideop+(OP)
>They ended up passing on me

Sounds like a win for you.

>>wideop+(OP)
> I remember being rather underwhelmed by what they asked me to do

funny how people that say this are often the ones bombing the interview.

usually the ones who score well, are the ones that see how the simplicity of the given problem gives them room to show how well they understand the domain, and they appreciate it.

>>leoff+oo3
Most software like this is simple; the danger is that some developers will overcomplicate a solution, or think there's more to it than there really is. A trick question if you will.

Don't judge a company by its tests, if they're easy for you to do it's not a slight on the company or the skills required.

>>Cthulh+nC3
Oh, I totally agree. That wasn't intended as a slight toward the company; rather, the solution to the problem was (if I remember correctly) only a few lines of code, but I think the test was tailored to more junior candidates, who might have needed to talk through it more (and as a result, have provided more insight into their thought process).

At the time, I didn't realize _that_ was likely what they were evaluating, but in my experience interviewing engineers since then helped me realize what I'd overlooked.

I mentioned they passed on me mostly for transparency given the rest of my comment, but I can understand how it might have sounded otherwise. I liked their concept and stayed connected for a while after, not something I normally tend to do if there's bad blood.

>>leoff+oo3
I mentioned this in another comment, but yeah, I bombed the interview precisely because I understood the problem and its domain but failed to walk through my initial thinking process with the interviewer who was pairing with me. I was approaching it as a technical problem, not an evaluation of my ability to pair with peers - which was why I was underwhelmed.

Having said that - over the years, I now much prefer conducting interviews where interviewer and candidate walk through a problem, figuring out a solution together; they provide much more insight into a candidate compared to rote memorization/whiteboard tasks like "Implement a linked list". So, in the end, I've learned to appreciate their approach.