Florian has taken the time to look at my work on MooseX::Method::Signatures and committed method trait changes to his master. I am very excited about this for two reasons.
One, it really is much simpler than my implementation. No need to parse Perl with PPI via Parse::Constructor::Arguments. I am not sure why I didn't consider his approach in the first place, honestly. It makes much more sense. I am going to blame Cory because I picked up where he left off, heh. No, really, I should have taken a step back and realized I could do what I wanted to do without invoking PPI.
Parse::Constructor::Arguments is going to stick around even if its use has been superceeded by simpler code. Someone else might find it useful. I still need to test it against the latest PPI to make sure it doesn't break though.
And two, once integration into MooseX::Declare happens, I can finally release all of my modules I wrote for YAPC::NA. I've sort of stopped work on Voltron and on POEx::ProxySession largely because I am waiting for Florian to catch up. I am excited to start back up again and finish fleshing out the automagical reconnect logic in ProxySession. From there, Voltron is going to get proper signature matching support via Parse::Method::Signatures.
In other news, I think I've nailed down my learning language syntax and semantics. I've covered a core language and then an object oriented extension. Next up is manipulating flex to get it to lex it.
And finally, yes, I did get the job. I start this coming Monday. Still keeping my name in the hat though for some other things. This job is only a contract gig for six months. It might extend, but then again, it might not, so I might as well keep my ear to the ground.
Tuesday, July 28, 2009
Tuesday, July 21, 2009
Preparing for a Perl Interview
So I have an interview tomorrow with a prospective employer. The job is supposedly a Perl Software Engineer position, but the skill set they want is all over the place. So we will see, really, what they want.
But I like to prepare as much as possible for interviews. And it depends on the interviewer what kind of questions they will ask, but I like to cover my bases by reading over the existing core documentation. That includes all of the obscure things inside perlvar, and even the deltas to know just when I can't use some modern feature. It seems like every interviewer has their "gotcha" question: the one question they weigh the heaviest in their assessment of your skills. Even I have them.
The Perl knowledge space is rather large when you consider what is packed into the core language. Everything from complex data structures, special global variables, an entire compact, and somewhat hard to parse-by-person, sub language (regular expressions), context depending expressions, and so much more is all crammed into Perl. There are bits that I am very much not intimate with: perlguts or XS in general, formats, pack/unpack, and I am sure there are others. Generally when I need to venture into those parts of the language, I will grok the concepts for the duration of my need and then it is back into the ether with those. But sometimes, those hard parts end up as someone's pet interview question. "Write me a format that produces this output." "Here is a specification for a message encoded as binary, write me a pack/unpack string that produces/consumes it." "We have a simple C library that we want to use in Perl, write some XS that encapsulates this functions usage."
And then sometimes, I am handed a dry erase marker and told to start writing code. That is very hard. Not that I consider a proper text editor with syntax highlighting and brace matching a crutch, but it is a rather limiting experience to write on a whiteboard. In front of people. People that are critical.
And even though I am critical of the tests that are sometimes given, I prefer them over a live whiteboard session. I guess part of my insecurity is that I have not done a lot of pair programming so I am not used to idea of someone looking over my shoulder constantly with a critical eye toward what I am doing.
How tomorrow is going to go, I am not sure. I am nervous. I am brushing up on the esoterics just in case. I just hope these guys have taken the time to go over my public work and save themselves some effort when it comes to asking the silly questions such as "What keyword would I use to sort an array?"
But I like to prepare as much as possible for interviews. And it depends on the interviewer what kind of questions they will ask, but I like to cover my bases by reading over the existing core documentation. That includes all of the obscure things inside perlvar, and even the deltas to know just when I can't use some modern feature. It seems like every interviewer has their "gotcha" question: the one question they weigh the heaviest in their assessment of your skills. Even I have them.
The Perl knowledge space is rather large when you consider what is packed into the core language. Everything from complex data structures, special global variables, an entire compact, and somewhat hard to parse-by-person, sub language (regular expressions), context depending expressions, and so much more is all crammed into Perl. There are bits that I am very much not intimate with: perlguts or XS in general, formats, pack/unpack, and I am sure there are others. Generally when I need to venture into those parts of the language, I will grok the concepts for the duration of my need and then it is back into the ether with those. But sometimes, those hard parts end up as someone's pet interview question. "Write me a format that produces this output." "Here is a specification for a message encoded as binary, write me a pack/unpack string that produces/consumes it." "We have a simple C library that we want to use in Perl, write some XS that encapsulates this functions usage."
And then sometimes, I am handed a dry erase marker and told to start writing code. That is very hard. Not that I consider a proper text editor with syntax highlighting and brace matching a crutch, but it is a rather limiting experience to write on a whiteboard. In front of people. People that are critical.
And even though I am critical of the tests that are sometimes given, I prefer them over a live whiteboard session. I guess part of my insecurity is that I have not done a lot of pair programming so I am not used to idea of someone looking over my shoulder constantly with a critical eye toward what I am doing.
How tomorrow is going to go, I am not sure. I am nervous. I am brushing up on the esoterics just in case. I just hope these guys have taken the time to go over my public work and save themselves some effort when it comes to asking the silly questions such as "What keyword would I use to sort an array?"
Monday, July 13, 2009
Foreign Country Hacking
So I've been in Mexico for the past week visiting family, and I haven't had the luxury of time to sit down and continue to work on any of my hacking projects. I did bring some materials including the docs for flex and bison to work a bit on my toy language, but haven't touch them.
When I get back there are a number of things I need to look into (besides trying to find a job) in no particular order:
1. Get the lexer grammar written for NULL (Nick's Useless Learning Language)
2. Rewrite the INSTALL doc for perl core (make it exhaustive of all the options and then list better examples on types of installs).
3a. Bug Florian to merge my code
3b. Release all of my modules from YAPC
4. Put my recent work on the POE wiki and work toward more POE+Moose interaction
I am heartened to see that RGS cherry-picked my patch and committed. It makes me want to do more work in that area until I get my feet wet enough to contribute meaningfully with code.
Light post this week. I have been too inundated with international travel to do much more than eat, sleep, and fiesta :)
When I get back there are a number of things I need to look into (besides trying to find a job) in no particular order:
1. Get the lexer grammar written for NULL (Nick's Useless Learning Language)
2. Rewrite the INSTALL doc for perl core (make it exhaustive of all the options and then list better examples on types of installs).
3a. Bug Florian to merge my code
3b. Release all of my modules from YAPC
4. Put my recent work on the POE wiki and work toward more POE+Moose interaction
I am heartened to see that RGS cherry-picked my patch and committed. It makes me want to do more work in that area until I get my feet wet enough to contribute meaningfully with code.
Light post this week. I have been too inundated with international travel to do much more than eat, sleep, and fiesta :)
Wednesday, July 8, 2009
Programming tests with Perl
I figured since my last post was so provocative, I've decided to write about something completely uninteresting and uncontroversial. Who here has had to take a programming test as a step in the interview processes? I know I have a few times.
Java tests. C# tests. Etc. Usually they want you to write from scratch some solution to a very contrived problem. And that is fine. They want to see a sample of your work and how to approach your problems. Sure as hell beats standing in front of a group of critical people with a dry erase marker in your hand and a massive expanse of whiteboard behind you.
Typically when taking a test for another language, writing stuff from scratch is mostly the norm. Oh sure there are open source libs out there for various languages, but when it comes to Perl and the massive CPAN, those other libs are dwarfed by comparison. So when I come across a Perl test that wants you to write something from scratch when a myriad of distributions on CPAN solve that exact problem, I get a little worried. Does this corp environment discourage use of CPAN to avoid reinventing the wheel? Does NIH permeate their corporate culture to the point of detriment?
In the past, I simply fired up cpan, changed a few config options and made sure things were installed into a local directory. The proctors of the test were a little intrigued, but mostly they were against the idea. They wanted to see me waste my time writing the wheel again. Ultimately, in that particular instance, I didn't get the job. And probably a good thing, too.
Of all the tests I've taken in the past though, they given me a machine, most of the tools I would expected to use, and a fast enough internet connection to use for searching for hints. And this makes sense. You wouldn't ask a graphic designer to create a design without some graphics program like Illustrator or Photoshop or tell an architech to draw up some blue prints without advanced CAD software. So why would a software programmer be any different?
Recently, I took another Perl test from a recently well known municipal auction provider, but this time I wasn't supposed to use a proper editor with syntax highlighting, I wasn't supposed to attempt to compile my answers, nor was I supposed to use any internet based resources. My face wrinkled up into the weirdest frown. They wanted to duplicate a "written" test environment. How does that have any bearing on the job they are potentially asking me to do? Not that they could enforce that since it was just a dumb form on a page without any javascript (I certainly didn't turn it on to see).
So I used the tools at my disposal to solve their contrived problems to the best of my ability using the tools that I use to develop software: vim, perl5.10.0, etc. I also made sure that my solutions were wrapped up into proper classes (via MooseX::Declare), reusable, and took advantage of modern Perl idioms. Save for some hairy multiple sorting that was giving me an issue, all of my answers compiled the first time without syntax problems and all ran as designated in the problem without issue. I tried to be as thorough as possible without going overboard. MooseX::Method::Signatures via MooseX::Declare saved me a lot of time from validating inputs, etc by hand, so that was a big win. If I had had to do that myself, I wouldn't have finished the test.
For some reason, I didn't get this job either. I asked for a little more feedback but I don't believe it will be forthcoming, which is their prerogative. It would be nice to know how I did on their test.
But considering my short chat with one of their developers at YAPC a couple of weeks ago revolved around "Why would you use POE when we could just spin up another persistent mod_perl instance?" perhaps it is good that place decided to look elsewhere.
So just for the record, if any of you future employers out there want to give me a test, please remember that I am going to use all of the tools at my disposal and give you an honest effort at solving your problems. If you tie my hands behind my back and then are disappointed with the result of my painting a bikeshed with my feet, that's your problem and not mine.
Java tests. C# tests. Etc. Usually they want you to write from scratch some solution to a very contrived problem. And that is fine. They want to see a sample of your work and how to approach your problems. Sure as hell beats standing in front of a group of critical people with a dry erase marker in your hand and a massive expanse of whiteboard behind you.
Typically when taking a test for another language, writing stuff from scratch is mostly the norm. Oh sure there are open source libs out there for various languages, but when it comes to Perl and the massive CPAN, those other libs are dwarfed by comparison. So when I come across a Perl test that wants you to write something from scratch when a myriad of distributions on CPAN solve that exact problem, I get a little worried. Does this corp environment discourage use of CPAN to avoid reinventing the wheel? Does NIH permeate their corporate culture to the point of detriment?
In the past, I simply fired up cpan, changed a few config options and made sure things were installed into a local directory. The proctors of the test were a little intrigued, but mostly they were against the idea. They wanted to see me waste my time writing the wheel again. Ultimately, in that particular instance, I didn't get the job. And probably a good thing, too.
Of all the tests I've taken in the past though, they given me a machine, most of the tools I would expected to use, and a fast enough internet connection to use for searching for hints. And this makes sense. You wouldn't ask a graphic designer to create a design without some graphics program like Illustrator or Photoshop or tell an architech to draw up some blue prints without advanced CAD software. So why would a software programmer be any different?
Recently, I took another Perl test from a recently well known municipal auction provider, but this time I wasn't supposed to use a proper editor with syntax highlighting, I wasn't supposed to attempt to compile my answers, nor was I supposed to use any internet based resources. My face wrinkled up into the weirdest frown. They wanted to duplicate a "written" test environment. How does that have any bearing on the job they are potentially asking me to do? Not that they could enforce that since it was just a dumb form on a page without any javascript (I certainly didn't turn it on to see).
So I used the tools at my disposal to solve their contrived problems to the best of my ability using the tools that I use to develop software: vim, perl5.10.0, etc. I also made sure that my solutions were wrapped up into proper classes (via MooseX::Declare), reusable, and took advantage of modern Perl idioms. Save for some hairy multiple sorting that was giving me an issue, all of my answers compiled the first time without syntax problems and all ran as designated in the problem without issue. I tried to be as thorough as possible without going overboard. MooseX::Method::Signatures via MooseX::Declare saved me a lot of time from validating inputs, etc by hand, so that was a big win. If I had had to do that myself, I wouldn't have finished the test.
For some reason, I didn't get this job either. I asked for a little more feedback but I don't believe it will be forthcoming, which is their prerogative. It would be nice to know how I did on their test.
But considering my short chat with one of their developers at YAPC a couple of weeks ago revolved around "Why would you use POE when we could just spin up another persistent mod_perl instance?" perhaps it is good that place decided to look elsewhere.
So just for the record, if any of you future employers out there want to give me a test, please remember that I am going to use all of the tools at my disposal and give you an honest effort at solving your problems. If you tie my hands behind my back and then are disappointed with the result of my painting a bikeshed with my feet, that's your problem and not mine.
Subscribe to:
Posts (Atom)