Below in the comments, I mention I am very curious to find out if people will take buying the least popular t-shirt as a positive (I'm unique) or negative (Why would I want a trash shirt). You clearly fall in the latter category, which is very reasonable. I am very open to tweaking the game mechanics so it is perceived as a win win by everybody while still a sustainable site.
The shirt and printing style are of high quality. I need to do a better job on the site emphasizing that.
Sorry you did not like this week's designs. Maybe next week (or not based on your comment =p)
The fact that you only reveal the last hourly sales, which really has zero relevance to total sales and whether or not you "win", makes it feel like a game of 3-card monte, as I mentioned in another comment.
Maybe you need to be more transparent and show the total sales or the ranking. This might help show you're not trying to scam anyone. Then, it turns into something more where people can decide "do I want to buy this t-shirt in a 2-for-1 sale" since they get the next shirt free.
Except that the changes you propose would take all of the fun out of the game for those of us who -do- like the idea.
Though in fact, if there was UK shipping I have a feeling I might've bought the Graphic Love T-shirt just because it's clever.
However, it seems to me very much like you really don't find the concept entertaining and thereby end up feeling like it's trying to rip you off rather than entertain you; I don't think the site's owner can solve that without destroying the things that make it potentially interesting to other people.
I think its just a matter of redoing the copy. At first I didnt realize it was a competition between the 5 shirts, I thought it was just an incentive deal to offload some inventory. I would walk through the process first, and bring up the least popular shirt part last.
As a very frequent t-shirt purchaser myself, the reason sites like TeeFury (which I love) do not sell at $25 is because their t-shirt quality, design, and printing style is not anywhere near as nice as Threadless or DesignByHumans. I am hoping Nifty will earn a reputation more like the latter sites than the former.
With that in mind, I will definitely test price points and appreciate the perspective from a fellow t-shirt buyer.
$200 upfront for 12 months of shirts (works out at about $13/m), every third week of the month you generate a random shirt for me from that weeks shirts and if that shirt matches the least popular I also get a bonus shirt (fits with the theme of the main weekly sale) or maybe if I am a subscriber I get double the chance of a bonus shirt (maybe least popular and most popular or least popular and second least popular) or something.
You could even do it like a loss leader type deal, have a yearly subscription for $100 (which would be ridiculously low and pull lots of people in) and then use the marketing from that (people telling their friends about the cool shirt that just arrived, tweeting about it etc. every month).
Although I guess as you're doing t-shirts on demand there's probably not much financial outlay so cash up front might not be worth potentially losing profits.
If your shirt quality is good (I'm going to order a shirt later to find out) then I'd sign up to that sort of deal ($200, or $100) without a second thought because there's nothing better than getting a surprise t-shirt.
The subscription suggestion is great and might be a better fit for Nifty. I'll have to give some thought.
Another direction I am thinking of going is more clearly separating the purchase from the pick. So you pick your shirt to buy and then make a separate pick for the least popular. I worry the additional UI may complicate things, but it is probably worth testing.
No, regardless of UI, I think the dilemma of having to buy yourself the least popular one to get an extra t-shirt is important. And what would happen to your buisness model if everybody liked (and ordered) t-shirt A but nominated t-shirt B? You would have to ship two t-shirts to everybobdy, whereas your current plan guarantees that no more than 20% of customers get a free t-shirt --- which also makes it more challenging to play the game.
Maybe he calculated assuming a free shirt if you randomly get a least-popular? This means 14.4 instead of 12 per year, and truncates to $13 (rounds to $14).
I had this idea rolling around in my head for the last couple of years, and I finally decided to build the damned thing just to get idea relief.
The backend is a typical LAMP stack with the Symfony2 framework backing the P. Varnish sits in front of all the Chef managed Linode boxes. The site will work without Javascript (up until the checkout), and the style degrades really nicely depending on your viewport (try it out by resizing your browser).
I'm open to all comments and critiques, so let me hear them. And if you are into graphic t-shirts, here is a code for a Hacker News 20% discount: 4803-7940-0816-5604!
That's a heck of a cool idea, nice job! I visit a lot of t-shirt sites and my first thought was "Very clever!" which doesn't happen that often. :)
My only problem is that I already have enough of a t-shirt buying habit that spending $25 per shirt isn't going to happen very often, especially when I don't know the quality of the shirts. You might add more detail on the actual shirt quality and fit.
The email collection line on the homepage doesn't make it clear what kinds of emails you'll be sending. If it's a weekly (bi-weekly, whatever) showing of the new shirts I'd say something like 'Sign up for our weekly new shirt email' so it's more specific.
I checked out the new page with the extra information, and a new question formed: why so many brands for the shirts? Typically I'm used to seeing a shirt shop just say "we print on American Apparel".
Good question and obviously not an optimal situation.
Since I'm a small shop going through a third party printer, I am last in line for raw t-shirt supply. Mix in color and size availability, and it gets pretty tricky to rely on one brand. So for now, I am using a few high quality brands to make sure t-shirts get out in a timely manner.
Hey, best of luck with this - I really like the idea and it seems like something you're passionate about. Congrats for shipping it, I'm excited to see what reputation it builds.
That being said, I'm excited for my minimalist bicycle t-shirt!
Nice site, just wanted to say I really like the phrase "style degrades" instead of "responsive design." It's much more accurate and I will be using it from now on, thanks.
The full idiom is "graceful degradation". It's been common on the web since the 90s, but I think it actually came from networking jargon.
It's not the same as responsive design. Graceful degradation implies a sort of hierarchy, where you subtract features on platforms that don't support them. So if you're using an supercool advanced browser feature, like colored text, you don't break the site for older browsers.
The responsive design idea is really more about different use cases than adapting to a more primitive environment.
I'm actually disagreeing with what you are saying: responsive design is such a poor solution to the problem of providing a mobile or tablet site, that it is actually more accurate to refer to it as graceful degradation, rather than as addressing a new use case.
I believe the initial logic was due to legacy browsers such as IE6. These are browsers that aren't what you designed for, so the webpage degrades. Since you take some steps to mitigate this and optimize it when it degrades, it makes it "graceful degradation"
The purple t-shirt has the logo photoshopped on 100% identical for male and female. Destroys the illusion of actual product photography even for very gullible people.
I'm a full-time freelancer with about 10-15 off-hours a week of availability. I'm primarily a backend/web developer with strengths in PHP, Java and C++. My background consists of stints in the video game industry, co-founding a new media advertising startup, and a collection of client work.
I'm primarily a backend/web developer with strengths in PHP, Java and C++. My background consists of stints in the video game industry, co-founding a new media advertising startup, and a collection of client work.
This is not, nor are similar whiteboard questions, a good interviewing problem. Not because the problem is particularly difficult or uninteresting, but because no matter how much the interviewer wants these questions to just be 'signals' of your ability, the candidate's performance at the whiteboard will likely be the determining factor for landing a job. The whiteboard gets too much weight, because it's too hard for an engineer (or likely anybody) to ignore somebody having a bad moment and flailing on something that seems so trivial to the interviewer.
And this is why Google's interviewing process and reliance on these problems is terrible.
You are put in five 1 hour sessions where you are asked Pascal Triangle esque whiteboard problems. Get a bit intimated? Stressed because of the interview? Miss your morning coffee? Start to panic a little bit? And suddenly you stumble on 1 or 2 of the problems and make an embarrassing impression.
At this point, it does not matter how strong your portfolio is, how many recommendations from fellow Googlers you have received, past performances, or your samples of past code (all of which are much stronger signals than a whiteboard problem). You will not be getting the job.
I hear this complaint a lot, but I kind of don't get it. I just don't know any way to make job interviews fair for people who are having a bad day. Can we just stipulate that any interview technique will fail to recognise the potential of some candidates? False negatives of that sort are kind of inevitable. And from the point of view of a hiring company? a few false negatives aren't the end of the world. A false positive is way more costly.
Because a candidate with a mediocre background yet a strong showing on the whiteboard will get the job. The problem isn't not hiring somebody having a bad day. The problem is the over reliance on the whiteboard signal, despite a candidate's history of contradictory evidence (either positive or negative). If you are going to use typical whiteboard problems as a signal, it is really really hard to not heavily weigh the results, especially when sour.
Your argument is that using coding tests under interview conditions is bad because a poor interviewer will overweigh it in their assessment. But the same applies to everything that takes place in an interview. Some interviewers will make up their mind on the candidate's handshake, so it's probably not fair to have handshakes in an interview. Others might place too much weight on the vocabulary and language an interviewee uses in answering questions, so we should probably not let them hear the interviewee speak. And asking candidates to write code risks the interviewer placing too much emphasis on the interviewee's ability to demonstrate their coding skills, so we should prohibit that too.
"Because a candidate with a mediocre background yet a strong showing on the whiteboard will get the job."
Is there evidence that this happens a lot? Does this happen at Google, where whiteboard programming during interviews is common?
"The problem is the over reliance on the whiteboard signal, despite a history of contradictory evidence (either positive or negative). If you are going to use typical whiteboard problems as a signal, it is really really hard to not heavily weigh the results, especially when sour."
What history of contradictory evidence? Do you have any suggestions for other signals that have proven effective in your experience?
I have very, very little experience as an interviewer and no experience dealing with and evaluating the success of new hires in the long term, so I definitely don't claim to have the answers here.
Sorry, the 'history of contradictory evidence' should have read the 'candidate's history of contradictory evidence' (e.g. having a really strong portfolio and work history to contradict a poor showing on the whiteboard).
I try to interview a candidate like he is a friend I haven't caught up with in many years. I want to have as honest and interesting of a conversation as possible, hear all his opinions, and learn all about what he has done and can do. If I feel the conversation was honest, the personalities were compatible, and there is evidence of good work and reliability in the past, I will likely consider the candidate a hire.
The problem with this method can be
1) It relies on the candidate having some sort of tangible history (referrals, solid portfolio or resume, open source projects, etc...), so new grads are tougher for example.
2) Having an 'on the level' conversation with somebody who knows they are being interviewed is not always possible. Nor are all interviewers capable of extracting useful information this way.
We hire based on personality. Before we bring an interviewee in we have looked at their bitbucket, github, portfolio, etc.. By time they get to the interview we know they are good enough to work for us, so we just talk technology with them and gauge based on that.
If the person is inexperienced or does not have a very public profile (no opensource projects), then we will drop back and throw them some random problems to solve but never a puzzle, since most people just memorize the solutions to puzzles or learn the solutions after doing enough interviews.
We prefer giving them problems like writing a text based guess the number game or tic tac toe. Mindless easy to solve project. They could spit it out in the shortest number of lines, which is what the bad puzzle questions encourage, but we are looking for how well the design/architect code. So the person who creates a good class structure and writes tests for his/her game is the one who gets hired, not the person who prefers shortest lines of code.
Well that is unfair. I got did not get an interview at a financial company for this reason. Unless stated explicitly, I'm not going to gold-plate interview code, because my assumption is that you are weeding out people who cannot code.
If you tell me to write it as OO as possible, then I'll do that. But if I can write it in a shorter, more efficient way using only arrays, I'll do that.
We tell them "Write this how you would write a real world application". We don't care if it is OO or functional or whatever... We just care if it is well designed. We don't tell them to write tests but if they don't then that means they don't write tests in the real world either.
There's just too much context missing from what this "real world application" is supposed to be or where its supposed to serve to make the concept meaningful.
What size inputs am I expected to handle? What platforms must this run on? What environment can I suppose is available? What performance is available? What kind of tests does your company use?
I think you're making too much implicit assumptions that everyone is programming in an environment similar to yours if you state it that way.
"We prefer giving them problems like writing a text based guess the number game or tic tac toe. Mindless easy to solve project."
Language, Environment, etc doesn't matter. If you are interviewing people on that stuff then you aren't finding the best candidates.
They get to choose everything outside of the problem to solve and it is an extremely dumbed down project like I said in the original comment. The "real world" part is in the implementation... How well is the code architected? Did they write tests? Are there performance issues? Bugs?
We don't expect people to be perfect either, we learn more from the discussion afterwards, since its not a puzzling problem we get to focus on software design and not the problem itself, which we feel is more important.
Why would I write tests for Tic-Tac-Toe? It's insanely easy to exhaustively hand-test, or just look at the code to see its validity. If you expect tests on something that simple, then you're expecting people to waste 1/3 of their time testing code that is sure to work.
Our interviews are never in the office. They are at a restaurant or bar. We just have drinks and food with them and chat. Talk about technology, them, us, etc... If we can have lunch and drinks with someone and they are talented then they are a good fit for the team.
The lunch/bar setting also loosens the interviewee up and they are always less nervous than if we had brought them into the conference room.
We don't care how talented you are if we can't stand being around you. If we had to choose between a mediocre programmer who has a lot of passion and fun to be around or a brilliant programmer who is arrogant, we'll take the mediocre guy and just train him up into being a brilliant programmer.
You're selecting for extroverts at the expense of introverts. Which may be desirable for your company, but I would (somewhat selfishly) not want that to be the common case.
we'll take the mediocre guy and just train him up into being a brilliant programmer
If you actually have a successful process for doing that, you could be owning many islands.
Its not about introvert vs extrovert, its about passion. I don't think any of the people on my team would do well socially at a bar but you ask us something about Linux, Python, etc and we could talk for hours.
"If you actually have a successful process for doing that, you could be owning many islands."
Don't pull a fox news on me, you can't rip out the most important part of that sentence ;)
I'm a backend developer with strengths in PHP, Java and C++. My background consists of stints in the video game industry, co-founding a new media advertising startup, and a collection of client work.
Better seems very subjective. I spent more time trying to figure out how to read a re.vu candidate's charts and visualizations than quickly digesting useful information about the candidate.
I am a fan of exploring portfolios. I am not a fan of exploring resumes. Especially when I would like to flip through a few hundred quickly.
The shirt and printing style are of high quality. I need to do a better job on the site emphasizing that.
Sorry you did not like this week's designs. Maybe next week (or not based on your comment =p)