Many people have discovered the joys and advantages of pursuing a career as a software engineer. It is a good thing people are pursuing it because the Bureau of Labor Statistics reports that software developers can expect 24 percent growth around the country over the next decade. However, with so many people pursuing degrees in software engineering, there is a lot of competition. Even after you get a degree, you still need to land your first job, and here are some tips to keep in mind during the job hunt.

1. Write a Stellar Resume and Cover Letter

In general, you do not want to send the exact same resume to every job you apply for. The reason is that different hiring managers will want different things out of applicants even if both jobs are for software engineers. Therefore, you need to customize your resume and cover letter to exactly what the employer wants. You can get a good sense of what the hiring manager is looking for by reviewing the job listing at length. You should also review your application multiple times to ensure it is free of spelling or grammatical errors.

2. Network With Professionals in the Field

There are many online job boards where you can find open positions, but you can also learn about new opportunities through networking. Many people are hesitant to attend networking events, especially if they are introverted. It is important to remember never to feel intimidated because a lot of other people are probably just as nervous as you. Set a goal to meet three or four people and even if you do not get any leads for software engineer jobs in Seattle, you improve upon your social interaction skills.

3. Prepare for a Technical Interview

You should prepare for a standard interview where the hiring manager asks you questions such as “What is your biggest weakness?” However, you should also prepare for the more technical aspects of the interview. The employer may ask you to write out some code on the whiteboard, and you do not want this to take you by surprise.

4. Create a Portfolio

In addition to a resume and cover letter, you also want to make a portfolio displaying some of the projects you have worked on in the past. Ideally, the projects will be similar to the ones you will have to do at this company if you get the job. For instance, if you apply to be a software developer for apps, then it would be advantageous to have at least one app to show.

5. Do Not Worry

When on the job hunt, it is easy to feel stressed. However, as long as you put in your due diligence, you really have nothing to fear. There is a high demand for software engineers at the moment, so you are bound to find a great company eventually that wants to hire you. Additionally, once you get your foot in the door at one business, it will become much easier to get other jobs in the future.

Originally posted on October 9, 2018 @ 10:08 am

Here’s the conclusion that all the web gurus seem to have drawn over the past months: HTML5 is the future, and that future is slowly creeping into our midst. This article by Dave Shea is the latest proof of that. Then there are inspiration galleries and blogs dedicated to the use of HTML5 for markup, plus hardly any mention of XHTML2 anywhere else.

rel and more meaningful links

But I’m not going to get into the war between the two here; I’ll just focus on a specific development in the arena: link relations. There’s more to it than rel=stylesheet and rel=alternate. About a dozen more.

For example, the Google-imposed rel=nofollow will be officially added in HTML5, but the seemingly convenient rel=feed may be dropped due to browser implementation. Other interesting link relations mentioned are rel=search, which obviously points to a search page, and rel=sidebar, which refers to a document “shown in a secondary browsing context (if possible), instead of in the current browsing context.” More are being proposed here, including rel=accessiblity.

rel seems to be what plugins are to web browsers, so it’s interesting to see how they can make a markup language as extensible as possible.

rev and a less rotten web

Still related to link relations is the rev attribute, which stands for a “reverse link”. It hasn’t been as popular as its cousin rel up until microblogging boomed, and consequently, URL shorteners and the threat of link rot.

Considering just how popular Twitter is these days, particularly as a social media marketing and SEO tool where links are the mode of currency, using rev=canonical to indicate one URL is a shortened version of the other:

Google introduced rel="canonical" recently. It’s a way of pointing from an alternate URL back to the canonical URL of the current document: the relationship of the linked document to the current document is “canonical”.

If you’re linking from the canonical URL to an alternate URL (like, say, a shortened URL), you could use rev=”canonical”: the relationship of the current document to the linked document is “canonical”.

People are also advised to check long URLs at this RevCanonical app to determine whether they already contain shortened ones.

Originally posted on June 2, 2011 @ 9:22 am

Although we’re now in this transitional stage of shedding off old browsers and web technologies that have been stumbling blocks to creating innovative new websites, there’s still confusion and fear that needs to be quelled. (Some people just can’t get excited that easily.)

Jeremy Keith’s article, Misunderstanding markup, seems like the ideal anchor at this point. First, it points out the differences between XHTML 1.0, XHTML 1.1, and XHTML 2:

1. XHTML 1.0 = HTML4 with XHTML syntax
2. XHTML 1.1 = XHTML 1.0 with the requirement that documents should be served with the XML MIME type
3. XHTML 2 = a whole new specification that has little in common with XHTML 1.0/1.1/HTML 4
4. XHTML has two types: pages that are actually served using the application/xhtml+xml MIME type; and pages that are actually served using the text/html MIME type but follow XHTML syntax.

Confusion? Fixed.

Second and more importantly, it emphasizes what the triumph of HTML5 means for XHTML:

1. You can still use XHTML syntax on HTML5 documents; it’s flexible enough and backwards-compatible (unlike XHTML2) that way. You can also go back to old coding conventions like uppercase tag names, optional quoting of attributes, and the absence of trailing slashes, and that’s okay too.
2. In fact, you can serve HTML5 documents as application/xhtml+xml and you get an XHTML document, affectionately called XHTML5. At this point, only XHTML2 is dead.
3. Still scared about taking the plunge to HTML5? It’s as easy as replacing that long-winded strict, transitional, or (gasp) frameset DOCTYPE declaration to <!DOCTYPE html>.

Once you learn items 1 and 2, the third item is all you’ll need to focus on from now on. It’s a comforting message that if you think catching up to HTML5 will be difficult, rest assured that it’s not as scary as it looks.

Fear? Fixed.

Let’s move on, shall we?

Originally posted on May 11, 2011 @ 1:53 am

Right now, so many major players in the web browsing space have turned to the WebKit project for its rendering needs—

• Apple: Safari
• Google: Chrome
• Nokia: Symbian web browser for S60
• Google: Android web browser
• Research In Motion: BlackBerry web browser
• and more

—that one has to wonder if web browsers should just stop running on their own and agree to just merge, possibly under WebKit, since it seems to be so popular across the board. To be clear, if Mozilla’s Gecko renderer had the same track record, I’d say the same thing.

It’s less a matter of killing healthy competition and innovation among vendors, more about eliminating the headache of rendering differences. People can probably file away all the browser bugs and inconsistencies across browsers and their various versions in a full encyclopedia set. (IE6 would take up at least a couple of volumes.) This tedious aspect of front-end development could be greatly reduced if all these browsers adopted the same rendering kit. Then the vendors can focus on improving and innovating in other aspects, like what Google did with its JavaScript V8 engine.

Mozilla can enjoy more time expanding its already large and loyal userbase, working on Labs products like Bespin and Weave, pushing for the WOFF web font format, and so on.

One can argue that if we should be able to choose browsers, then the same can be said for underlying rendering engines, and accept the differences as a a consequence of the freedom to choose. But does a consumer of the Web need to choose which rendering engine he prefers? Or are the differences something we can finally do without?

I, for one, would be thrilled if we didn’t have to worry whether websites looked the same in every browser, and just focus on making websites look and behave the best they can. And I’m pretty sure ordinary users don’t even think about rendering differences.

Originally posted on May 11, 2010 @ 9:16 pm