This is Flwyd's Typepad Profile.
Join Typepad and start following Flwyd's activity
Join Now!
Already a member? Sign In
Flwyd
Recent Activity
The form factor of a knife in a smart phone might be problematic, but why not replace your keys with your smart phone? It wouldn't be hard to build a door handle with bluetooth and an OTP generator. Hold your phone up to the door and it lets you in. If the idea catches on, car manufacturers could add an OTP module to the steering column.
Toggle Commented Aug 21, 2010 on What's On Your Utility Belt? at Coding Horror
For a laptop or desktop, I'm with you: typing and mousing is a lot more effective than speaking. But on a mobile phone with a screen that fits in your hand and a tiny software keyboard, typing is a royal pain in the ass. The device is designed to pick up the human voice, so it'd be nice if it could do more than just copy that voice to somewhere else on the planet. Unfortunately, the most frequent and annoying thing I type on my phone is my password, which is optimized for having lots of numbers and punctuation, not being easy to type on a simplified keyboard. And I don't want to speak that into the phone, even if I could. For universal speech recognition, we need to do a lot better job with semantics. The human perceptual system has an impressive amount of interaction between high-level and low-level language processing for disambiguation, filtering, prediction, etc. If you proposed the human speech system to a software architect, the high coupling, lack of clean interfaces, and legacy spaghetti code would drive him nuts.
To folks commenting about the relative merits of algorithmic questions versus solving business programs: Your interview should test the skills you need at your company. If you're applying for a job at my company, you need to know how to work out a solution to a novel problem, so an algorithmic question is great. If your company needs people that can create Visual Basic forms to call COM objects, create a simple one and have interviewees pop up a dialog with the result of a method call. I'd probably struggle in the latter interview, which is good for both of us: I don't want to work with VB and you wouldn't like the way I'd try to solve problems. The principle in both cases is the same: quickly reject anyone who can't do the work that, in your company, is really basic. Of course, you need to decide how much of a learning curve you can handle. When I created a "take home" programming interview problem, I let candidates do it in whatever language they wanted because it's easier to teach a good programmer a new language than teach someone who knows a language how to program. But if you want someone who can complete the VB project in three months for a big client, you may not be happy with someone who's spent his time writing UNIX device drivers.
Toggle Commented Feb 24, 2010 on The Non-Programming Programmer at Coding Horror
"I was asked in a phone interview the difference between a linked list and an array. The company does not do low level programming or code for mobile devices which would make the performance between the objects perceptible." Unless they only ever work with small amounts of data in a high-level language, all programmers should understand the difference between an array and a linked list. It's almost akin to a carpenter knowing the advantages and disadvantages of nails versus screws. There are plenty of software creation activities where understanding how to use a hash table aren't important, but they shouldn't have Programmer or Software Engineer in the job title. A surprising number of recent CS graduates have trouble writing a program. There's a tendency for CS classes to focus on theory more than practice. Algorithms classes, for instance, will often provide skeleton code so the student just needs to fill in the algorithm's implementation, because that's the important piece for that class. And at a first pass that's good: more of my software engineering worth comes from learning about computability and context-free grammars than comes from chasing leaky pointers in my freshman year. But I'm very glad that my program requires all students to participate in an actual software development project (sponsored by and in communication with local companies). In case any CS students are reading this comment, here are my key tips: * Know one language well. Use it to do math, manipulate strings, handle collections of data, read and write input (from standard in and standard out, if possible). * Write simple but real programs. If you've got a repetitive task, write a small program to do it. You'll quickly learn the quirks and bookkeeping that aren't theoretically interesting but are critical for getting things to work. * Learn a few tricks about your development environment, from IDE shortcuts to text-processing functions in vim/emacs. If you're interested in professional software development, these instincts will pay dividends. * Learn why things work the way they do. When you use a utility function, think about how you might implement it. Then look at the source code to see how the library designers decided to do it. (They're usually pretty good.) Don't get worried if you don't understand something yet; there's a lot of "It just works that way" until you learn more. * Program outside of school. Internships, ACM programming challenges, fun projects with friends, whatever. Just like students in music school should play their instrument beyond what's required for class, computer science students should program for fun and profit.* If you can't seem to get the hang of programming, assess your interests. There are lots of ways to be involved in software development without writing code. Quality assurance, user interface design, project management, system administration...
Toggle Commented Feb 24, 2010 on The Non-Programming Programmer at Coding Horror
Flwyd is now following The Typepad Team
Feb 23, 2010