Document Actions
Ken's Blog
Ken's Blog
Year End Thoughts ...
The year draws to a close and it is time for the yearly retrospective again. Time really does pass quickly:
- 2007 Resolutions
- 2007 Lessons
- 2008 Resolutions
Getting promoted to the level you are performing at ...
Some of the stuff I write about aren't my own thoughts but thoughts from fellow front-line managers. In particular, today's thought comes from Cindy:
You do not get promoted because you are doing your job well. You get promoted because you have been performing at the next level long enough for people to notice and reward you.
This came out of a discussion about how some people (fortunately not from Exoweb) were thinking that just because they had just started doing well at their jobs, they were due a promotion/raise. Coming from the other side of the trenches, this doesn't seem really realistic to me.
First - you never promote lightly. For the most part, you cannot demote someone. You end up having to terminate that person if you make a mistake. So until you are absolutely sure this person can perform at the higher level, you take your time with the promotion.
Second - humans have highly variable performance. Someone who is highly motivated today may be very demotivated tomorrow for no apparent reason. If what you are seeing is one of those peaks, promoting the person would be a mistake. One week later, the person could very be performing at a much lower level again. You need proven, sustained performance above the minimum level for the position to be promoted to.
Finally, a person doing well for the current position does not merit a promotion. Not unless you want the Peter Principle throughout the organization (people getting promoted to their level of incompetence.) A person doing well in their current position may get raises and bonuses, but never a promotion. Proof that one does well at the current position is rarely proof that the person would do better at a higher level. The skills are often different. The skills required for a software developer are different from that of an architect, project manager, etc.
Language learning on FOSS vs OSX
My primary desktop is OSX and for the most part, it suits my purpose well. 99% of the time, everything just works, there are few hassles and things behave the way you expect them to. The Ubuntu releases are close but not quite there yet for me.
As great a desktop as OSX is though, it only shines in the most commonly used functions. In many niche areas, FOSS can provide superior solutions by virtue of the huge variety of applications, developers and freedom to develop on it. One such area that comes to mind these days is language learning.
I'm barely able to read in Chinese and trying to work my way through a website or document is pretty much impossible without a dictionary. I particularly need a dictionary that can immediately translate words I highlight on screen. On OSX, the options are pretty limited. Most solutions are shareware or paid software. Right now I'm using TranslateIt! which works fairly well. I highlight the word(s) I want translated, hit a keyboard combination and TranslateIt! pops up, hopefully with the translations. It is one extra step though. The paid version for TranslateIt! includes the functionality to get immediate translation after I highlight it.
My colleagues on FOSS desktops don't need to pay for this. StarDict comes with most distributions and does the highlight/translate thing right out of the box. It's invaluable in a mixed Chinese/English environment like Exoweb. Besides the software, the power of FOSS shows up in StarDict's dictionaries, which are varied and extremely useful. So much so that TranslateIt! actually uses StarDict dictionaries and all the translations I am using are StarDict's. Without StarDict, TranslateIt! would actually be useless to me.
My favorite StarDict dictionaries include (all zh_CN -> en):
- cedict-gb dictionary (has pinyin and tone marks. Must have)
- langdao-ce-gb (a much larger vocabulary but translations sometimes not precise. No pinyin)
- Chinese idiom dictionary (a dictionary translating chinese idioms. Unfortunately the translations are chinese->chinese and some colleagues have said its translations are suspect)
Two are under the GPL while the cedict library is under its own license similar to cc-by-nc.
While I'm sticking to TranslateIt! until such time StarDict works natively under OSX, I would simply be unable to read anything at all in Chinese without StarDict's dictionaries.
We Make It Up As We Go
Every now and then I find myself repeating the same thing in weekly chats, so I try to note them down in a blog post so the Exowebers that actually read the Exoweb Planet have a chance to see it. This particular one has to do with how we developed our work processes and best practices. There is no mystical method, no profound MBA insights or deep pondering. Quite simply, we make it up as we go.
That's not to say all our current processes are arbitrary. Every process or practice we have, we evolved to overcome a perceived problem. We experiment with different processes and those that work, we kept. Those that failed we learned from and moved on. The entire organization is a work in process, continuously trying to improve itself.
There are a few core values we do have, which very much reflect those of agile methodology: People over process, working code over documentation, etc. We also believe very much in making this a great place to work. Since you spend a huge portion of your waking hours at work, why wouldn't you want to make it as pleasant, as fun, as challenging a place as possible?
From these core values we simply figure things out as we go. For example, our current process of code reviews was triggered by the realization that our code quality wasn't good enough, that too much bad code and bugs were leaking into production systems. We tried the NASA style group code reviews but found that much too heavy. We then tried having a couple of core code reviewers doing all the work, but found that it did not scale and that the benefits of code review actually were disproportionately accumulating with the core reviewers. Our current method is a lightweight team review process that seems to combine the benefits of code review while reducing the cost. We are likely to make more tweaks and changes in the future, depending on future needs and ideas.
What does this mean for Exowebers? Most important of all, it means that it is the past ideas of all of us that have created the great environment we have. It means it is your future ideas that will make us an even better place to work. You need to pay attention to your environment, be willing to question our processes and methodologies, and contribute new ideas when they come to mind. No process is sacred. Given good enough reason, visible enough benefits, anything can be changed.
You can contribute ideas openly, by floating RFCs by email, or you can quietly suggest them to your team leaders in weekly chats. Whatever method you choose, it is important that the ideas are communicated and considered. Only then can we as a company improve. Only then can we make this place an even better place to work.
Yes, this includes higher salaries too. If you have ideas on how to make us more profitable, we can all share in the profits in the form of higher salaries :)
What Happens When You Turn Fsync Off On Postgres
We use the PostgreSQL database extensively to handle a fairly large amount of data. Our largest single database is over 25G in size, with a fair amount of transactions going through it daily. As such, we've had to do a lot of optimization over time. One of our experiments was turning fsync off on one of our non-critical databases. In retrospect, this probably was not that great an idea ...
This database was a non-critical but fairly write intensive database. It logged a lot of information, largely in the form of inserts. Inserts in postgres can be a bit slow sometimes since a insertions tends to lock the same section of the index until the insert is complete, forcing all inserts to go in sequence. Updates are usually a lot faster if you're updating different rows since they don't all rely on the same section of the index and can often be done simultaneously.
The fsync option slows this down even further, since postgres then waits for the data to be flushed to disk successfully before continuing on with the next operation. Not a problem for low traffic databases but if you attempt to insert hundreds of transactions a second, the milliseconds spent waiting for the disk to write the data completely really hurts. fsync ensures data integrity but at the price of speed, especially in the case of unexpected power failure.
Since this was a non-critical database and losing data wasn't really a problem (we could either recreate it or live without it), we turned fsync off on this database. All went well for months, until we actually did suffer a power failure. During the busiest period possible. Good old Murphy.
At any rate, once we brought everything back up, things seemed to work as usual ... for about 30 minutes. Then we realized our servers were frequently losing connection to this particular database. Investigations revealed that the postgres processes were terminating themselves with messages like "Error: out of memory" or complaints about data inconsistency. Yep, we got our first corrupted Postgres database. The first one I've encountered in over 7 years of using this database.
I have to admit, I had very little clue on how to recover a corrupted database and each database was corrupted slightly differently. Initially it appeared only the indexes were damaged and a reindex removed most of the problems. Later we found that there was some damage to the tables themselves (took a long time to find that) and we attempted to restore through a backup. The Write Ahead Log (WAL) backup proved to be useless. Those were corrupted or inconsistent. Strangely enough, the database could still do a pg_dump, so we just dumped out all the data and reloaded it back in the database. This ultimately fixed everything.
Morale of story - don't turn fsync off unless you really know what you're doing, including how to detect database corruption and fix it. Our biggest problem was that postgres, unlike MySQL, does not scream "Table/database corruption!" immediately. It took us a while to determine what the problem was. Then again, unless you turn off fsync, it is probably something that almost never happens on postgres. I've had tons of corrupted MySQL databases. This is my first corrupted postgres database.
Things I Would Like to See More In My Teams
Overall, I'm working with a great bunch of people, so don't let the topic mislead you - I'm really happy with the people I work with. However, nothing's ever perfect and there's always room for improvement. The following are things that have recently made me stop and think, "I wish I saw more of that ..."
- Curiosity
- Sharing of information
- Dissatisfaction
3 Questions ...
This is the English version of Cindy's "3 Questions" blog post, written from a different viewpoint. As a bit of background, Cindy and I are both managers in Exoweb and one of our responsibilities is to carry out weekly chats with the people in our teams. Both of us have been asked these questions before and we figured it would be of interest to Exoweb people in general. I'm writing this without having actually read her post, so it should be interesting to see how our viewpoints differ.
The questions are:
- Does Exoweb give team members a chance to switch career paths?
- Are personnel evaluations transparent?
- If an employee makes a mistake, how will the company handle things?
Spammers And Gated Communities On The Web
YAR - Yet Another Rant ...
From my experiences living in various locations around the world, I have always loved the locations where there are very few gated communities. You can enter the different areas very freely - there are few security checkpoints, very few guards and movement is very unrestricted. These are usually the very safe areas and there's a lot of interaction between people in the different areas. These are usually friendlier, livelier and richer communities, especially with inter-community mingling.
On the other hand, the areas with lots of tightly gated communities bother me. This usually implies that the area is not very safe and you need a variety of fences and security personnel to keep out undesirable and potentially dangerous elements. These communities live in fear and are very closed. While it is peaceful inside these communities, it is still a prison of sorts.
Lately, I have begun feeling that the web is turning more and more into a group of gated communities. Mind you, it's not just linked-chain fences and rent-a-cops. It feels like many areas are starting to turn into fortresses - high walls, constant patrolling of the boundaries by guards with very deadly weapons and constant challenges while you wander through. The problem - spammers.
More ...
The Three Aspects of Management
Found myself explaining for the third time in a day yesterday about the three different aspects of management that I deal with in my work in Exoweb. Thought it best to blog about them, to put down in writing what I have had to repeat multiple times last week.
These are my personal opinions/divisions of course and have no grounding in scientific research. They are merely based on personal experience. However, all managers in Exoweb perform at least one aspect and some can do all three.
In my daily work, the three aspects I end up spending my management time on are:
- Tech Management
- Project Management
- Human Resource Management
VMWare vs Parallels: Marketing Spam comparison
Just an annoyed rant - VMWare has really managed to annoy me lately. A long time ago, I downloaded one of their server versions for evaluation purposes. Since then, I have been receiving marketing emails from them, despite marking "no marketing emails" when I registered with them (I always do this on all sites). Lately, because my registered address is in China, they've started using a third party marketing company to send me chinese marketing emails. Thanks. They go straight to the dustbin unread, since I read chinese about 5-10x slower than English.
I finally got annoyed enough to go through the trouble of unsubscribing from their marketing list. This shouldn't have been necessary in the first place - I never agreed to let them send me these emails. Unsubscribing turned out to be multiple steps - you actually have to confirm that you want to opt out. After clicking on the unsubscribe url, they send me an email to confirm that I'm the guy who really wants to unsubscribe, then I have to click on that url again. I've done that, about 5 minutes of my life wasted (slow network speeds here). Bah. Let's see if I continue to receive spam from them.
On the other hand, another nice virtualization provider, Parallels has never spammed me, even though I've actually bought products from them. The only emails I've ever received from them were the purchase confirmation emails and directions on where to download their products.
Email marketing is cheap and sometimes powerful, but you really have to be careful to avoid annoying your potential customers. I wish people would pay more attention to this.
Tallinn Thoughts
Yet another quickie post with some random thoughts about Tallinn, Estonia. Hopefully useful for my colleagues coming over shortly and anyone else who might be visiting soon. I won't touch anything that should be easily accessible from a tourism website.
First, a couple of thoughts about traveling here - the no-liquids rule and small planes on the final hop here really make it much easier to check in luggage rather than relying on carry-on. Now that flying in EU has the same restrictions on carrying liquids as flying in the US, you pretty much cannot carry any creams, gels or even toothpaste. If you try to stick to carry-on luggage to avoid baggage claim the way I do, you will have to buy everything again when you hit Tallinn. Also, every time I have flown to Tallinn (three times on two different airlines) the final hop uses a very small turbo-propeller driven plane of Russian construction. The problem with these planes is that the overhead compartment is tiny and cannot hold much more than a backpack or a standard briefcase. None of those large carry-ons.
Flying FinAir from China stops in Helsinki but you can stay in the international section of the airport. No EU (Schengen) visa required. Flying Air China requires changing planes/airlines so you will need an EU visa. Much more convenient to fly FinAir even if the EU visa isn't a hassle.
Tallinn appears to be pretty safe. There are people walking alone late at night, so violent crime doesn't appear to be a problem for most folk. The city is small enough that you can walk to most places. Bring a comfortable pair of shoes. It also has a lot of beautiful old europe architecture so bring a camera if you are into snapping pictures.
Lots of decent western food places here, but other than Indian and Japanese, not a lot of Asian food. Prices are about double the price for western food in both Malaysia or Beijing and many times the price of a standard meal in either country. Still quite cheap for an european country though.
A very nice place overall. I could be convinced to come here a lot more often ...
The Writing On The Wall ...
Just a quickie on a thought that struck me while responding to a friend's email - too many students are not aware of the quiet FOSS wave that is happening under the surface, particularly here in China. They are still focusing their learning efforts on Java, C# and Windows without a thought to picking up basic FOSS skills.
Yet if you pay attention, you can see the trend. From today's news, HP made $25 million in sales directly related to Debian GNU/Linux. This is just one Linux distribution mind you, and one with no commercial company or advertising budget behind it. Exoweb is slightly responsible for that as we (and our clients) bought more than $15k of servers from them last year. :)
In our daily work integrating with third party providers, we are seeing more and more FOSS based products. Not all are fully FOSS based - many are WIMP (Windows, IIS, MySQL and PHP). This FOSS trend is especially noticeable from startup companies or companies with limited legacy infrastructure. We love this of course, since they are typically easier for us to integrate, host and maintain. Yes, we (or our clients) do pay a fair amount for these products so they are making a lot of money while being FOSS based.
My point? For anyone who really wants to be in the tech industry, FOSS skills, no matter how basic, will give you a valuable advantage. Otherwise you will be locking yourself out of a rapidly growing portion of the industry. Besides, as a craftsman, wouldn't you want to know every tool available? Otherwise how can you use the right tool for the job?
2006 Year End Thoughts
Can't believe another year has come and gone. It seems like only yesterday that I wrote the 2005 Year End Thoughts, and only a few days ago that I came back to China and started my career in Exoweb. Time really does fly when you are having fun, and I certainly have been having a great deal of fun in the last few years. Sometimes stressful and sleepless fun, but fun all the same :)
General summary of thoughts:
Things that I am happy about:
- Exoweb
- Teams improving, growing
- Culture
- Personal
- Facing the different challenges over the last year
- Learning to delegate
Things that need to be improved:
- Exoweb
- Giving back to FOSS
- Creating a continuous learning culture
- Personal
- Working with people
Goals for 2007:
- Make self (almost) redundant
- Teach, not do
Time To Turn In My Geek License
Apparently, I'm spending too much time doing management and turning into a PHB. No one seems to think I'm technically competent anymore. Some recent conversations:
While training a junior project manager:
Me: "So remember, with new tickets, ask a technical senior to help you estimate how many hours are required to complete the task ..."
A few days later, during the usual morning meeting discussing what tickets to create, prioritize, etc:
Me: "... so I think we should put this task in Milestone x, priority critical, estimated time 8 hours"
Jr: "Ok, sounds good. I'll go get an estimate from senior x and take care of it."
Me: "Wha ... didn't I just give you an estimate?"
Jr: "Yes, but you said I needed an estimate from a senior ..."
While showing a relatively new developer the rankings of everyone in Exoweb:
Me: "... and here we have the mid-levels devs, split in 3 sub levels. Finally, these are the seniors ..."
Dev: "Wait, you're considered a senior?"
After relating the above two incidents to yet another developer:
Me: "... so apparently they don't think I'm a senior anymore ..."
Dev: "Well, if you don't tell them, it's not obvious ..."
If anyone wants me, I'll be out getting a haircut, buying some suits and gaining a lot of weight ...
KISS (or why MS CS students have a bad time in interviews ...)
It's that time of the year when Master's students are hunting for jobs in China and we are flooded with resumes from students with Masters of Science in Computer Science (MScCS). We've spent the last couple of weekends interviewing the candidates that passed the front interviews and it has not been pretty. In fact, it has been pretty sad.
The biggest problem we encounter with MScCS grads is made very apparent in how they approach one of the our typical programming problems. This particular problem is fairly simple and with a little bit of thought, can be made into a linear (computer performs x more calculations for every element added to n, where x is a constant number) or O(n) type of equation. Most competent people will come up with a O(n^2) algorithm (computer performs n operations for every additional element added to n, resulting in rapidly increasing number of calculations per element added) to it at first, then after a little thought, realize that there are a lot of duplicated operations, refactor that out and come up with the linear solution.
MScCS are a little different - almost all the ones we have interviewed to date encountered this problem, probably came up with the O(n^2) equation ... then went off the deep end. They would inevitably come up with complex, fancy algorithms that utterly failed to solve the problem. These fancy algorithms would often handle the common case but fail on the boundary cases. They were fragile, easily tricked or prone to failure. When these flaws were pointed out, these candidates would come up with even more complex algorithms or add a lot more if/else checks ... resulting in even more brittle and unreliable code. None of them, if unaided, could come up with the ideal solution.
Well, that's not really true. One particular candidate, after coming up with 4 complex, unworkable algorithms, finally said, "well, since you have given me such a tight time limit, I have no choice but to brute force it." He then proceeded to give the ideal solution. Linear time, handles all boundary cases. But he would rather give 4 non-working solutions rather than the working, "inelegant" solution.
What I find strange and rather disturbing about these interviews is that it is somehow related to the mindset of those who are doing their MScCS. Bachelor level grads or people with several years of working experience rarely make this mistake. They either do it right or not at all. Yet for some strange reason, the MScCS students seem to value fancy algorithms over _working_ algorithms.
Maybe it's the MScCS curriculum here in China which tries to focus on fancy algorithms. Maybe it's just that the MScCS feel the need to prove that their abilities are above the norm for CS graduates. Maybe we just have incredibly bad luck with our candidates. Whatever the reason, extremely few MScCS fresh grads have passed our interviews. As you can imagine, in a production environment, we highly value working code and eschew the fancy algorithms, especially algorithms that needlessly complex. Simplicity and correctness is far more important in our craft.
The famous quote attributed to Brian Kernigham comes to mind:
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
When writing algorithms, another quote from Agile development comes to mind - "do the simplest thing that can possibly work." Keep It Simple ... er, let's call it Keep It Stupidly Simple (KISS) and avoid insulting anyone :)
Need your MacBook repaired? Wait a while ...
So after all the fun I had with the MacBook, I eventually found that my MacBook fell victim to the usual MacBook discoloration and random shutdown problems. So did the other MacBook in Exoweb that was purchased at the same time. Last week, we sent the first of them in for repairs with Apple. Guess what the company sysadmin got back as a response from Apple?
"Apple said there's no hardware in the entire world to fix your laptop---they have to manufacture it first. "
So if you're like me and need all these issues fixed, I guess you're going to have to wait a while for the spare parts. At least for me, the random shutdown is limited to once per day, when I work the computer too hard after it has been idle for too long (either in suspend mode or just sitting there unused for several hours.) Once it has shut down once, pressing and holding down the power button for 5 seconds restarts the computer just fine and as long as I keep it busy the rest of the day, the random restarts go away.
MacBook Day 3
8 am saturday morning and I am up, messing around with development, writing code and tests. Big deadline coming up? No. Urgent bugfixes? No. Just testing out the MacBook as a development environment. So far, I must say I'm quite happy.
Since my projects all run on debian stable in production, my development needs are quite simple - a Unix-like environment and the usual array of FOSS tools. With a little bit of effort (about 4 hours, most spent just waiting for things to download), I managed to duplicate my production environment via darwin ports on OSX. The only thing that didn't match was the operating system - OSX does work a little differently from Debian linux.
This worked out decently. Writing code, especially when you're used to using emacs in a terminal, is the same everywhere. Running tests is usually the biggest problem. The problem I had with the old powerbook was that it took 90 minutes to 2 hours to run the full suite of the tests at the time, a bit too long for the write-test-commit cycle. On our server class machines (3 Ghz Xeons), these tests take 20 minute to run. Still too long (refactoring coming up shortly) but acceptable.
With the MacBook, tests take 30 minutes to run natively. Not quite a match for server class machines, but comparable to and in some cases, faster than our development desktops. If we refactored the tests to run more in parallel, results would be better as current tests only use one of the two cpus in the MacBook.
However, there is one problem with running all this on OSX - it's not exactly our production environment and we have been bitten before with slight differences between behaviour on different systems. What works fine on Gentoo crashes and burns on Debian ... etc.
In comes the Parallels virtualization product, a virtual machine solution targeted for OSX on Intel. A quick download of the software, a few clicks and 30 minutes later, I had a minimal Debian stable install running. Another 30 minutes later, I had a full development environment installed and running inside the virtual machine. The virtual machine was fast, responsive and fully functional. The full suite of tests took 45 minutes to run - not zippy, but still far better than the powerbook and usable until the great test refactoring happens.
I'm really pleased with this laptop. All my needs are more than adequately met by this system for the forseeable future. I just might need to upgrade the hard drive in a few months, as the 60G I'm starting with is a bit small. All these virtual machine images will eventually add up.
MacBook Day 1
I read PlanetPython a lot, and one of the interesting things I've noticed is the number of Mac posts I've seen there over time. Various Python personalities keep getting their latest MacBook (Pro) and talking about their great experiences with them.
Well, I gave in (really did not take much convincing) and joined the crowd. Got myself the lowest end MacBook, the 1.83 GHz model, with the lowest end specs. Then immediately maxed out the RAM to 2G. I figured I could live with the 60G hard drive (I don't actually pack very much) but I might one day need to run the parallels virtualization software and more memory never hurts when you're trying to run multiple OSes at the same time.
Day one has been pretty good. It really didn't take all that long to get up and fully functional on the new system. All OSX systems include a nice utility to migrate your data over, but I lacked a firewire cable so I had to manually scp my home directory from my Powerbook over to the MacBook. After installing all the other apps I used regularly (Colloquy, Adium, Firefox, OpenOffice.org, darwin ports), everything else just worked like the old Powerbook, just a lot faster. It's nice how OSX puts almost all your user settings into your home directory, making moving everything really easy.
It's funny how the lowest end MacBook beats the crap out of an 8 month old Powerbook, but I guess that's just the power of the new Intel chips. Things are responding much faster now and I believe I can actually use this new system for serious development, rather than ssh'ing to servers to run CPU/IO intensive tasks. We'll see though. Ports is still building the dependencies needed to run my main project applications.
I suppose lots of other people have given their impressions on the MacBook, but my own impressions have all been really positive so far. The screen is much brighter and crisper than the old PB. I like the much larger trackpad and the new keyboard is decent, though it requires a little more force than the old PB. My fingers must have gotten weak.
Heat really doesn't appear to be that much of a problem. I tried running both CPUs at 100% for about 15 minutes and while it got warm, it was usable. In regular usage (darwin ports compiling stuff in one window, me writing in another), it gets a little warmer than the PB, but still usable on bare skin lap. Would be a lot nicer in winter than summer though.
I plan to use the system extensively for development, especially while traveling around Europe later this month. This laptop is going to get a much more intensive workout than the PB. After I found that the PB took up to 3 times longer than my regular desktop to run a full suite of tests on one of my projects, I stopped using it for actual development (was great as an emailing/document generating machine). We'll see how things turn out after darwin ports finishes compiling all the dependencies and I run the full suite of tests for the first time.
Full Emacs Keybindings in OSX
One fun thing about reading blogs - you learn little gems that you wouldn't encounter otherwise, sometimes even when you search for it. When I got my Mac in August last year, I was thrilled to find that it supported emacs style key bindings in most Cocoa applications. However, it wasn't complete support - while all the control key bindings worked (^f, ^b, ^p, ^n, etc), the ALT/option button bindings did not. So I missed useful keys like page up (Alt-v) or forward one word (Alt-f).
I did spend a couple of hours searching on this, particularly in the help documents and knowledge base contained in the Mac and on google. No luck. I eventually resigned myself to working without the Alt keys and chugged along mostly happy. That is, until today, when I read Erica Sadun's blog on the Mac DevCenter RSS feed.
Turns out that all I really needed was this Apple Developer article on Key Bindings in OSX, including Emacs examples. It was as simple as adding my own custom definitions in ~/Library/KeyBindings/DefaultKeyBinding.dict.
The OSX key binding capability is actually quite impressive. You can even do multi-keystroke bindings, such as ^x^f (if you really miss Emacs that much).
Another day, another great functionality to rave about in OSX :)
Interview Programming Problems
Another Saturday done, another interviewing round finished. Thought I would put down into words what I look for when reviewing the programming problems done by candidates. I don't really care if candidates know what I look for - if they can do it in an interview, they can do it in their daily work. Especially so when code reviewers are likely to be at least as watchful as I am in an interview.
As an illustration, I'm using a problem we previously used in our written tests. We replaced it recently because everyone answered it in almost the same way, making it useless as a differentiator between candidates. The problem is as follows:
Implement a function "intersection". The function takes two ASCII strings and returns an ASCII string containing only those characters, that are simultaneously present in both arguments. The result should be as short as possible. For example:intersection("abde", "bexy") may return "be" or "eb"
intersection("exoweb", "candidate") should return "e"
Almost all solutions (that work) are variants of the same form. Below was the minimum acceptable code to pass first round screening in Exoweb, in a prettied up python format:
def intersection(a, b):
intersections = ""
for char1 in a:
for char2 in b:
if char1 == char2:
intersections = intersections + char1
return intersections
(trivia - usage of the "in" keyword is up to 3 times faster than a str.find() call on my laptop)
(trivia #2 - something like 50% of candidates who make it to the written test are unable to write even the above snippet. After this test, 90% of all candidates who have submitted their resume have been eliminated)
Read more on the problems with the above code snippet ...
