I run a company that among other things, works with mid to early stage startups (as in, some folks with an idea). We help them build the product (design, development), launch it and do marketing. My email is in my profile if you have any questions, etc.
I recommend nailing down exactly what you think an MVP should look like and iterating on early customer feedback.
It's important to stress that we are there to help startups augment their teams at later stages, but by no means can we replace the culture and passion of a dedicated team working night and day to make your dreams come true.
We can build you something fantastic, help you grow a user base, but at the end of the day the road to most effective profitability and vision is in the hands of the founder.
I really agree with the sentiment of audition projects. The interviews I have enjoyed the most all involved some sort of take-home project, although I have never been paid for one. On that note, how expensive does it become for a startup to dole out many interview projects across a wide range of candidates? I think a better strategy would be to conduct preliminary interviews and then based on some granularity, assign projects. One more issue I have with take home projects is that it is not always possible to tell who did the work. When it comes to interviews at startups I doubt that there would be much cheating, but for large companies where candidates are more easily able to slip through the cracks, I image this may present an issue. Can anyone speak to this experience?
Here's a problem with audition projects: I would never be able to take part in one, since my current job contract has a clause forbidding me from simultaneously working for any competitor in the same field. (This is a German job contract; I don't know if such clauses are common in the US or elsewhere, too.)
So in order to work on an audition project, I'd have to be unemployed already.
Those clauses are really hard to enforce generally. They're effectively restraint of trade. Your time not working for your employer is your time. Your employer is on dodgy ground specifying what you can do in it. At least that's the interpretation most places I've worked (UK and Australia). Germany may be different.
But specifically if you were taking an interview rather than working a side job you could make the argument that the clause didn't apply in any case.
It all comes down to how much you pissed off your ex-employer by leaving, and how much they want revenge. No-one is going to gain anything from suing you after you've moved jobs.
Talk with your solicitor. A lot of companies like to include such clauses in contracts even if they're not legally enforceable, particularly in the case of US companies operating in a country with relatively strong workers' rights like Germany.
I agree with other posters that same-field is usually going to be blocked anyway. I've had non-competes at 2 of my 3 jobs which would prevent me from working at any competitor in the industry for X years after quitting anway.
But my current work contract has an anti-moonlighting clause that could also be a problem. It states that I can't have other demands on my time that would interfere with my day job. Now, I interpret that as meaning I can do side projects that have no deadline and just be luxuriously slow and lazy at making progress on them. But for an audition project I probably wouldn't be able to take it that slow.
Generally, I've come to believe that the 'field' that a company specifies they're in is intentionally left vague. I would assume that most people looking for a new job would more likely than not look for something in a similar industry, and be, in fact, infringing on such clauses if they did audition project work for other employers in said industry.
It depends on whether they can show me some of their previous work, usually in the form of pictures from past projects. Serious vendors even invite prospective clients to their stores where they will have a "demo room" showcasing their work.
If they have neither, then it's absolutely fair to ask them to do a small audition project first. Otherwise how can you be sure they're competent?
Keep in mind this idea doesn't exist just in recruitment. It's basically recruitment's version of what's called a "proof of concept", which is proof that the party that is pitching/asserting something (i.e. their skill) can actually deliver.
In my past of applying for jobs as a designer, I had companies that would ask for take home tests. I always refused and of course didn't get the job. Conversely, other companies I worked for offered freelance positions (probation) before settling onto full time which I thought was far more effective and fair method at evaluating me as a long term candidate.
While it is indeed possible to cheat on the project itself to have any value that project gets followed up with an interview in which its discussed, and I think most people would trip up quite quickly if asked to explain in detail the process of developing some software they didn't in fact write.
Exactly. Asking the candidate to outline the solution, the issues encountered, and the rationale behind the design should quickly illuminate any funny business. Depending on the scope of the project, you could even have them push code to a company repo real-time as they make progress. Obviously VCS histories can be rewritten in some circumstances, but I think it would help give a little more granularity as to how the work was done.
I got asked to do an audition project as part of an interview last year. After completing the phone interview and receiving the project, I determined that this was something that they were having trouble getting ideas for, and were simply using the interview process to jump start it. I declined to participate and told them I would look for work elsewhere.
If the project is a couple hours, then sure, I have no problem with it. When it's an entire real project for the company, you're just donating a week's work to someone in the hope of getting an offer letter.
Audition project just substitute one bias for another. They also presuppose that those who will actually work with the candidate are somehow more enlightened and above bias than the standard interviewers.
That seems more like a question on how the candidate's work is measured.
While there's always some bias, I think it shifts quite a bit once you move from an artificial "interview environment" to a work environment.
Plus as has been said, since they candidates are working with the people they would be working if hired and that relationship doesn't work out, then maybe it's better to keep looking for someone else.
In my experience, those who must work with people 'on trial' hate doing so. They treat the entire experience as a chore, well aware that 90% of these people won't be around next month. That lack of commitment by the organization means those in control are only more free to express bias because they know the person at issue is already disenfranchised and weak.
What do you think about consistency between a mobile app and a website? Logos and other such assets aside, is it valuable to keep the colour scheme the same, and keep UI elements such as buttons the same?
Hi! I’m Vicky from the Codelitt team and author of the blog post, thanks for your question! Consistency is a very important factor when trying to communicate your brand values and setting a clear message for your product, and color schemes shouldn’t be treated differently. Brands have core color palettes that help communicate and keeping those consistent throughout platforms will only strengthen the relationship between the user and the product. However, keeping everything in the UI the same is a bit tricky: there are limitations to how much desktop and mobile platforms should share in terms of UI, as each of them have a set of rules individual to them. While working within those rules, you should try to keep as many constants as you can. For example, if you’ve decided to make any major CTA red with a white font, you should keep that constant for every platform you develop. Consistency in such elements will help ease of use when your users jump from one platform to the next (think of picking up where you left off when switching from desktop to your phone). Menus and navigability, on the other hand, might differ from one platform to the next.
To me it sounds like you don't like the work you do, and going to university to do an undergrad won't get you a better job (assuming you still want to work in tech?). The best way to get a job you might like more is to learn some new skills and pivot your career.
I'd also like to mention that going to a prestigious university has generally no bearing on the jobs you get, it's the people. As a result hiring companies (in the tech sector) don't really care where you came from as long as you can prove your value.
Things Composer.js provides that are not in Backbone: Generic class system, filtered collections, controller-collection tracking, granular silencing of events, router-provided auto link binding, controller event inheritance.
The reasoning was that at the time of building, Backbone was tied to jQuery, and I really don't like jQuery. So Composer was built on top of Moo (and used a lot of the built-ins, such as the class system) but the API stayed very close to Backbone.
As of v1.0, everything Moo-specific was ripped out, the class system was redone from scratch, and everything was modularized so different pieces of Composer could be used in different places, independent from each other.
For instance it's common practice for me to take just the class system or eventing objects from Composer into projects without importing all the other stuff.
i'm confused by this. the reason for creating an entire framework is you didn't like the jQuery dependency?
replacing jQuery with MooTools in Backbone seems trivial, especially with respect to creating a whole new framework. you'd just need to override a small handful of methods.
all the other problems Composer solves that Backbone excludes (like filtered collections) are supplemented by other third party libraries. i'm not one of those "another framework?" guys- but it seems like you had a great opportunity to make the landscape more robust, instead of further segregating it.
From what I remember at the time (keep in mind, this is ~3.5 years ago), backbone had a few issues (and bugs) that were making it difficult for us to use on an app we were building.
We could have spent a good amount of time forking, fixing them, hopefully getting a PR merged (if the changes were even in-line with the project), and on top of that creating an adapter to replace any sort of DOM manipulation with Moo, which I think back then was more then just overriding a handful of methods.
So, composer was born not just out of "jquery sucks, we're redoing this" but more "well, we could fix all the stuff that we don't like in backbone, or build something that suits our needs directly."
I admittedly haven't taken an in-depth look over the framework, but what specifically did you feel was missing from Backbone? Anything we can improve?
I don't find this list [0] to be particularly helpful. It looks like the main addition is filtered collections and relations, which there are many ways of doing [1] or pretty easily added via a plugin.
(And as an aside, Backbone absolutely does support IE6, and goes out of its way to maintain bc, particularly in History).
gotchya. i don't mean to sound accusatory- i am just being selfish. there are bits and pieces of Composer that i'd like to see in Backbone proper. but, the thought of leaving Backbone for something a lot like Backbone is scary.
You did not come off as accusatory, and these are good questions to ask. I also understand the hesitation in trying it out. Do keep it in mind though if you ever have a toy project and a few hours...you might like it!
Disclosure: I work on Backbone from time to time. In the next version of Backbone we're removing the jQuery dependency from Backbone.History and making it easier to separate out from Backbone.View.
Adding support for MooTools should be as simple as overriding Backbone.ajax and a few methods from Backbone.View. There exist at least one or two projects that do this already that I know of, though I've never had a use for them myself.
Thanks for the update! The things that Composer needs jquery/moo for are all compartmentalized into one place (called the adapter)...sounds like you guys are moving in the same direction.
I wish backbone hadn't tied itself so closely to jquery early on because I really like the project and could have seen myself building a lot on top of it (like composer's filtercollections or listcontroller), and now it seems both projects are occupying closer and closer to the same space. Who knows, this may be good though.
To be sure, Backbone has had "adapters" for a pretty long time. You just replace Backbone.$ and be on your way (there's a few for mootools, etc if you look hard enough). The latest changes just make this a bit easier so you can use native DOM / xhr methods if that's your particular bag of awesome.
