I went from startup to corporate and back to startup. You can't resist the desire for instant gratification and feeling of accomplishments that you get at a startup. You become this "T-shaped person", and your knowledge bar on the _T_ keeps expanding because you get the chance to wear many hats, while still being able to expand the vertical bar of your expertise/develop new specialties.
Right on! This freedom to wear many hats is what makes working at startups such a lively place. Startup is chaos and finding ways to contribute to the overall business eliminating the chaos is what makes your worth.
Hiya! Author here. I can't comment on why you felt this was clickbaity. The intention was to give a third-person perspective of the life of an engineer as a webdev at a startup, emphasis on _startup_.
The post is largely targeted at beginners. I think giving this perspective to fresh grads can help them take a decision to atleast clear up the dilemma when they have to choose to work at a startup/corporate during internships or right after college.
The reason I wrote it was because during my four years at college, we had this perception that webdev was boring and nobody used to opt to interview for companies which were into it. And the joke was, "All you do is change the colors every 6 months". I had the chance to intern at a SaaS startup and then worked there for more than 2 years and then figured students back at college needs to know more about this experience.
To debug the process, you can start with searching Google for your own site. The syntax is: "$searchQuery site:wisaw.com", for eg: "wisaw site:wisaw.com"
I got only 4 results with that search. So those 4 pages are definitely indexed. You can check with different search queries for the rest of the pages.
I observe that it's a photo only website. It's hard to get them ranked better than sites with content. Search engines are smarter now, so adding title, description, keywords, etc does not ensure it ranks better for those keywords. It used to work, but not anymore. Search crawler check for actual content and relevance.
Since its "an anonymous photo" app, you'll have to rely high on word of mouth/social/referral traffic instead of organic sources.
I can relate to this. Not a product, but a blog I run gets just ~20 (out of ~200 page views/day) of traffic from HN, Reddit, Facebook, Twitter combined. Rest is organic and most of it is via Google searches.
I read this again now, and I see way too many typos, can't edit it anymore though. Please excuse the messed up grammar and totally unrelated words in between.
A bit of a cliche answer, but I'll still go with this: depends on the target audience. Find out who can most benefit our of your product? Developers? Sales? Marketing? General netizen?
Next, figure out where they spend their time on. For eg: to target devs, post on communities like HN (as Show HN). Reach out to community driven blogs and be an author subtly marketing the product. In fact, an interesting story on what you went through during the product building phase, that challenges you solved is exciting enough to intrigue a developer.
General netizen? Share on platforms like reddit (specific subreddit), twitter (would be good if one of your users which high reach can volunteer for this).
Is it a B2B product? Offer the product at a discounted rate to initial users and in return, you can ask for promotion through their site/social media (a bit like testimonials). For eg: I got to know about mixpanel by seeing the badge on the footer of certain website I used.
I think it's meant to be a subtle addition to overall feel when user lands on the page. I've not seen this happen in SaaS products, however, most product marketing/landing pages have a certain "uniqueness" to create a brand/product perception by employing such effects. One of the examples I can think of is Stripe, all the mix of graphics and animations on their product landing pages adds a bit to the overall feel. One other community platform that stands out from design point of view is IndieHackers. Ofcourse, HN has its own charm.
Quite common in early-stage startups, 2-5 people including founders. As soon as the MVP is ready (first 3-6 months usually), they start around organizing things and prioritize stability, robustness over speed of delivery.
If the early engineers were experienced guys, a basic test suite and deployment pipeline would have been the first priority at the onset. It makes releasing frequent commits a breeze. Or else, they learn from subsequent hires to organize code, write tests and add extra processes. If they fail to hire such talent, they learn the hard way, frequent downtimes leading to user frustration and failing to retain them. It's crucial they realize this early on though, otherwise, this could lead to things blowing up pretty quickly leading to the death of the product.
Although I'd say, it sounds unusual for an investment bank. Doesn't sound like a company anyone would stick around for long. Sounds like inexperienced engineering leadership. If you're early in your career, I'd suggest looking for better companies.
I just tried it, although it asks to upgrade to a premium version to post comments. I think I'll just keep the authenticated browser tab open to post comments for now. :)
Well executed! There's already a comment requesting this, I'll just add to it. Ability to login and take CUD (I mean, we already checked off R from CRUD) actions would complete the circle.
Am I getting this wrong, or did everyone else in thread got it wrong? Is the question more from candidate point of view, whether to join a company if you enjoy working for the trial period?
If my assumption is correct, the candidate will fall in this situation if they didn't already clear up the expectations, roles and responsibility before/during the interview. A friend of mine recently found himself in a situation where they decided to quit after working for less than 2 weeks at an early stage startup. He ended up quitting by the end of the month.
I believe it's a shared responsibility to clear up such things before making an offer (from company's POV) or accepting an offer (from candidate's POV). This situation doesn't help either party.