Archive for the ‘the industry’ Category
Twitter in the microblogging world now has the pull of Google in the search world – if you’re not ‘on Twitter’ you’re nowhere inn terms of being able to connect, share and promote via microblogging (surmising that Twitter now gets 80 – 90% of microblogging traffic / use.)
This effectively locks the market into one monopoly platform – Twitter.
Imagine this applied to blogging or web publishing. Say there were many publishing services, you could only use one publishing service at a time and publishing service A had 90% of the total traffic and users.
If you weren’t using publishing service A, regardless of the quality of your content, you’d miss out on 90% of the traffic, connection or exposure just by being on a less popular service. Not a nice thought.
Would an open messaging platform – essentially a server application which allows you to create a master account and associate ‘child’ accounts to it for other microblogging services (Twitter, Jaiku et al) make any difference in leveling the microblogging playing field?
The idea is that the platform would broadcast your posts or ‘tweets’ to all your subscribed services, but would also aggregate posts from the users you’re following and stream them back to your ‘open messaging’ client.
Rather than ‘a twitter client’, you could have a general micro blogging client offering not only the power to broadcast your posts to multiple services, but to also aggregate the incoming messages regardless of what service they came from.
It wouldn’t matter what service someone you follow was using (surmising that you also had an account on that service), because in your microblogging client, you’d see one unified stream of updates regardless of the API they were built on.
Microblogging would become a standardised platform in its own right. Rather than having disparate API’s, an open messaging platform could seek and serve to unify microblogging API’s and REST-based services, or at least provide a simple bridging framework between them.
6 Tips for Getting a (Web) Job
Posted on: August 29, 2008
Seeing as we’re looking for a web coder, I’ve been charged with trawling through CV’s (resumés for you northern hemisphere folk) and checking out the candidate’s coding strength.
After suffering through two rounds of applications, I feel compelled to pen some handy tips for current or potential web job hunters.
1. Read the Role Requirements
Do you fit the role? You may want the job, but it’s highly likely the people advertising want someone who can ‘hit the ground running’.
It’s a given that the requirements list for a role is usually a wish-list for the people advertising, but it you don’t hit at least half of the requirements, don’t apply. You’re wasting your time.
2. Give ‘Em What They Want
Pause for a minute here.
Before you send your bog-standard CV in, open it up and take a look at it. Does it reflect the requirements of the role? Is there extra stuff in there that the employer just won’t be interested in? If you’re serious about the role, take a few minutes and edit your CV to more closely fit the role. This will help your employer clearly see the fit between you and the job.
I know the web makes it really easy to apply for a lot of jobs quickly, but this “shotgun” approach is very obvious when someone reads your CV. It will soon be dumped into the “No” pile if you haven’t related clearly just why you should be considered for the role.
3. URLs count
Seriously. Your referenced URLs are among the most important part of your application. Companies should check if your code validates. They should also check the tools you use and how you use them. Public source code tells me a lot about you as a coder. Put your best foot forward and make sure your URLs and the associated code make you look good.
Been involved in a lot of sites? Put in your best 6 – 10. And make sure they’re still live. (Dead URLs are not a good look.)
4. Less is More
Your potential employer doesn’t need to know what high school you attended, or what other qualifications you hold if they aren’t relevant to the role. If your skills are ready to pay the bills, you’ll get an interview. In the interview your potential employer will have lots of time to get to know you better. Save the extra fluff for the interview.
Take your CV and multiply it by 20 or 50 – that’s what someone will have to read through in order to get a good shortlist for the job. If you have a clear, concise CV you’ll stand out. I promise.
5. Check, check and check again
Spell check and grammar check all correspondence. By all, I mean all. Emails, CV’s, cover letters, application forms. Bad grammar makes you sound stupid. Incorrect spelling makes you look sloppy.
Where possible, once you’ve checked your writing, get someone else (preferably someone who can read and write well) to check your work.
6. Ditch the Cover Letter
Unless it’s a requirement for the correspondence (more than likely just to save a recruiter some time), don’t write a cover letter. If you must, keep it short (half a page at most) and directly address how you fit the role.
For technical roles, most of your cover letters won’t be read.
(If you do write one, at least make sure you get the name of the organisation right.)
Summary
Let’s recap:
When you apply for a job, you’ll know that you’re a close match because you’ve read the requirements. You’ll have edited your CV to fit what the company is looking for and you’ve out in your best URLs.
You’ll have a CV that gets straight to the point and has no unnecessary fluff. Your communications with the company will have correct spelling and good grammar, and you won’t include a cover letter unless you absolutely need one.
All done? Your employer will love you 🙂
————-
Looking for help improving your CV / resumè?
You may want to read: The Elements of Resume Style: Essential Rules and Eye-Opening Advice for Writing Resumes and Cover Letters that Work
paul bennett 
recent comments