One of the C# oddities I noted in my recent article was that I find it odd that creating a numeric type with less-than, greater-than, and similar operators requires implementing a lot of redundant methods, methods whose values could be deduced by simply implementing a comparator. For an example of such, see my previous series of articles on implementing math from scratch.
A number of people commented that my scheme does not work in a world with nullable arithmetic (or, similarly, NaN semantics, which are similar enough that I’m not going to call out the subtle differences here.) That reminded me that I’d been intending for some time to point out that when it comes to comparison operators, nullable arithmetic is deeply weird. Check out this little program: Continue reading
I got a lot of great responses to my recent piece on features of C# I somewhat regret; thanks all for those.
As promised, today on fun-for-Friday-FAIC I’ve posted some fabulous adventures in nature photography from my recent trip to Lake Huron. Click on any image for a larger version. These were either taken by me or my friend Amber, who graciously loaned me her Canon DSLR, and taken with either the Canon or my GoPro.
Hey everyone, I am finally back from my many travels this summer and looking forward to doing some blogging this autumn. I’ll post some vacation photos when I have them sorted out. Until then, here’s an article that the nice people at InformIT asked me to write: what are my ten least favourite C# features?
I’m sure I missed some of your least favourites; I’d love to know what your pet peeves are in the comments here or on the article itself.
I have begun my travels but I have one more from the road. Literally!
The nice people at radar asked me to write them a short article on static analysis for beginners; I was happy to oblige. (There seem to be some problems with some of the spacing and HTML tags; I’ll try to get those sorted out.)
A quick note: I’m going to be traveling for much of the rest of June and I haven’t got articles queued up, so the blog will go dark for a bit; see you in July!
In the last two episodes I did reruns of earlier articles on the technical interview process. I thought I might go into a little more detail about how I structure interviews and what I’m looking to get out of them.
I have some primary goals:
- Prevent bad hires
- Make good hires
- Leave the candidate with a positive impression of the company
Of course preventing bad hires is of far higher priority than getting good hires. If we fail to get a good hire, that’s too bad, but if we make a bad hire, that can drag down the productivity of a team for years.
That last point is also key; if we want to hire the candidate then obviously they need to have a positive impression. But I want all the no-hire candidates to have a good impression as well. They have friends who might want to interview. They may be in a position to make purchasing decisions or product recommendations now or someday. An interview is a very expensive “high touch” business process; if we don’t get a hire out of it, at least maybe we can get a customer, or if not that, at least some good will.
The actual interview goes like this.
Last time on FAIC I reran my 2004 article on tips for coding on whiteboards for interviews. This time, a rerun from 2009 article on a similar topic. Next time, some more thoughts on this subject.
Interviewing job-seeking candidates is probably the most impactful thing that I do at Microsoft as far as our business is concerned. Sure, the day-to-day work of implementing the compiler is of course what I am specifically there to do. But ultimately nothing impacts the bottom line of our division more than preventing bad hires and encouraging good hires. The dozens of people that I’ve interviewed who got hired will collectively deliver much more value (or do much more damage!) than I can alone. So I think about it a lot.
I got an email from a reader in India recently asking me to talk a bit about thoughts on technical interviews. Here’s a rerun of my 2004 article on that subject. (Note that this was before I was on the C# team, so this has a very C++ flavor to it.)
Next time on FAIC I’ll post another rerun on the same topic.
I occasionally interview candidates for development positions on my team and other Visual Studio teams. Plenty of people have written plenty of web pages on interviewing at Microsoft, so I won’t rehash the whole story here. What I wanted to mention today was some words of advice for candidates for development positions. This is by no means complete — I want to concentrate on one important aspect of the interview.