Jython Phone Interview Advice

[George Jempty]

I'm undergoing a phone interview for a Jython job today. Anybody have
practical advice for me? I haven't worked with Python in years, but I
have been working with Java in the meantime (resume at
http://scriptify.com/george_jempty_resume.pdf). I've been reading up:
my old "Quick Python" (Harris/McDonald) book, a somewhat more current
"Visual Quickstart Guide" (Fehily), as well as "Jython for Java
Programmers" (Bill) via safari.oreilly.com.

My interviewer today will be a somewhat technical manager. A key thing
I plan to ask is will this be primarily maintenance or new development.
I don't think I'm cut out for new development considering my
inexperience.

Some things I'm noticing upon (re)reading my books. Triple quoted
strings: those provide functionality similar to Perl's "here"
documents.

Also, considering Javascript will be a substantial component of my job,
I'm noticing that Javascript's array/"hash" literal syntax is EXACTLY
the same as that for Python lists/dictionaries. This could lead to
easily sharing data between the client and server side, though I think
I should probably keep this one under my hat, at least with a manager.
Though if things go well I will probably subsequently interview with
more technical folks.

Otherwise, the only thing I can think to tell a manager in a phone
screen is that I'm willing to undergo brainbench.com's Python
certification.

Any advice would be much appreciated. Thanks in advance

 

[Harlin Seritt]

George,

Know what they will be wanting you to do with Jython. This has bitten
me in @ss a couple of times. I guess it was lack of attention to
detail.

Good Luck!

Harlin Seritt

 

[Paul Watson]

I'm undergoing a phone interview for a Jython job today. Anybody have
practical advice for me? I haven't worked with Python in years, but I
have been working with Java in the meantime (resume at
http://scriptify.com/george_jempty_resume.pdf). I've been reading up:
my old "Quick Python" (Harris/McDonald) book, a somewhat more current
"Visual Quickstart Guide" (Fehily), as well as "Jython for Java
Programmers" (Bill) via safari.oreilly.com.

My interviewer today will be a somewhat technical manager. A key thing
I plan to ask is will this be primarily maintenance or new development.
I don't think I'm cut out for new development considering my
inexperience.

Some things I'm noticing upon (re)reading my books. Triple quoted
strings: those provide functionality similar to Perl's "here"
documents.

Also, considering Javascript will be a substantial component of my job,
I'm noticing that Javascript's array/"hash" literal syntax is EXACTLY
the same as that for Python lists/dictionaries. This could lead to
easily sharing data between the client and server side, though I think
I should probably keep this one under my hat, at least with a manager.
Though if things go well I will probably subsequently interview with
more technical folks.

Otherwise, the only thing I can think to tell a manager in a phone
screen is that I'm willing to undergo brainbench.com's Python
certification.

Any advice would be much appreciated. Thanks in advance

Gee, George. I wonder if the interviewing manager or anyone in their
company has access to newsgroups?

 

[George Jempty]

Gee, George. I wonder if the interviewing manager or anyone in their

company has access to newsgroups?

Then I hope they would see that I was trying to properly prepare for
the interview. I've given it to them straight so far: I'm no
Python/Jython guru. And I'll give it to them straight if they say this
is primarily new development: that I don't think I'm their man.

If they somehow construe my reliance on this newsgroup negatively, I
would never want to work for them.

 

[D H]

Also, considering Javascript will be a substantial component of my job,
I'm noticing that Javascript's array/"hash" literal syntax is EXACTLY
the same as that for Python lists/dictionaries. This could lead to
easily sharing data between the client and server side, though I think

Look up JSON, XML-RPC, XMLHttpRequest and Java (you can use Jython in
place of Java of course):
http://oss.metaparadigm.com/jsonrpc/
http://developers.slashdot.org/article.pl?sid=05/01/24/125236
http://www.webpasties.com/xmlHttpRequest/

Otherwise, the only thing I can think to tell a manager in a phone
screen is that I'm willing to undergo brainbench.com's Python
certification.

Way out of date.

 

[George Jempty]

think

Look up JSON, XML-RPC, XMLHttpRequest and Java (you can use Jython in

place of Java of course):
http://oss.metaparadigm.com/jsonrpc/
http://developers.slashdot.org/article.pl?sid=05/01/24/125236
http://www.webpasties.com/xmlHttpRequest/

I like that last URL in particular. I actually already knew of JSON.
I figure I can eventually leverage this similarity, though again I
think that is a more appropriate discussion to have with technical
leads rather than management.

Thanks for the awesome link(s) though

 

[c d saunter]

George Jempty ([email protected]) wrote:
: I'm undergoing a phone interview for a Jython job today. Anybody have
: practical advice for me? I haven't worked with Python in years, but I
: have been working with Java in the meantime (resume at
: http://scriptify.com/george_jempty_resume.pdf). I've been reading up:
: my old "Quick Python" (Harris/McDonald) book, a somewhat more current
: "Visual Quickstart Guide" (Fehily), as well as "Jython for Java
: Programmers" (Bill) via safari.oreilly.com.

: My interviewer today will be a somewhat technical manager. A key thing
: I plan to ask is will this be primarily maintenance or new development.
: I don't think I'm cut out for new development considering my
: inexperience.

Not that I'm likely to be interviewing people for a long time (lowly PhD
student but if I were I'd be less concerned about a persons detailed
knowledge of a language (esp. one like Python with relativly few gotchas
and quirks) then their general competency at writing and managing code and
working as part of a product group. A good programer shouldn't have any
serious problems adapting to a new language, so be ready to fo over some
examples of your ability to switch / learn new languages.

Also, never be afraid to ask for clarification etc. Worst thing ever in
interviews can be getting the wrong end of the stick and following it,
esp. if the people on the other end don't realise you're on the wrong
track.

Take all the above with a (large) pinch of salt!

Cheers,
Chris


: Some things I'm noticing upon (re)reading my books. Triple quoted
: strings: those provide functionality similar to Perl's "here"
: documents.

: Also, considering Javascript will be a substantial component of my job,
: I'm noticing that Javascript's array/"hash" literal syntax is EXACTLY
: the same as that for Python lists/dictionaries. This could lead to
: easily sharing data between the client and server side, though I think
: I should probably keep this one under my hat, at least with a manager.
: Though if things go well I will probably subsequently interview with
: more technical folks.

: Otherwise, the only thing I can think to tell a manager in a phone
: screen is that I'm willing to undergo brainbench.com's Python
: certification.

: Any advice would be much appreciated. Thanks in advance

 

[Jeremy Bowers]

I'm noticing that Javascript's array/"hash" literal syntax is EXACTLY the
same as that for Python lists/dictionaries.

No it isn't, quite.

Two differences of note, one literally syntax and one technically not but
you probably still want to know about it.

First, Javascript objects can only use strings for keys, anything used as
a key will be converted to a string. Try this in your browser and you'll
see what I mean... the "instance" of the "class" I define (let's not get
into prototyping issues here ) has its string value used as the key,
not the object:

javascript:function a(){}; a.prototype.toString = function () {return
'q';}; b = new a(); c = {}; c = 1; alert(c['q'])

(All one line, if your browser objects to the newline.)

The other is the syntax point: The strings you use in {} expressions to
denote keys are used literally, they are not resolved. Thus, in the above
I *had* to write

c = {};
c = 1;

Because had I written

c = {b: 1}

I would have ended up with an object where c['b'] == 1; Javascript does
not resolve the "expression", 'cause it isn't one.

(That said, certain reserved words like "class" and such do have to be
quoted, which means the safe bet is to quote them all, which leads to
Javascript objects that look identical to Python dicts. But

{1+2: "moo"}

will end up different in each language.}

<steve_irwin>Danger danger danger!</steve_irwin>

 

[George Jempty]

No it isn't, quite.

Two differences of note, one literally syntax and one technically not but
you probably still want to know about it.

First, Javascript objects can only use strings for keys, anything used as
a key will be converted to a string. Try this in your browser and you'll
see what I mean... the "instance" of the "class" I define (let's not get
into prototyping issues here ) has its string value used as the key,
not the object:

Perhaps the above assertion applies to native Javascript objects only?!
Because I've been successful in using host(browser) objects as keys to
associative arrays, namely forms. This is handy when the form's id
and/or name attribute have not been set. I was concerned that
identical forms would be equal, but then I proved that was not the case
with the following test:

<form></form><form></form>
<form>
<input type="submit" onclick="alert(document.forms[0] ==
document.forms[1])">
</form>

This results in false. Am cross-posting the rest of this message in
it's entirety to comp.lang.javascript.

javascript:function a(){}; a.prototype.toString = function () {return
'q';}; b = new a(); c = {}; c = 1; alert(c['q'])

(All one line, if your browser objects to the newline.)

The other is the syntax point: The strings you use in {} expressions to
denote keys are used literally, they are not resolved. Thus, in the above
I *had* to write

c = {};
c = 1;

Because had I written

c = {b: 1}

I would have ended up with an object where c['b'] == 1; Javascript does
not resolve the "expression", 'cause it isn't one.

(That said, certain reserved words like "class" and such do have to be
quoted, which means the safe bet is to quote them all, which leads to
Javascript objects that look identical to Python dicts. But

{1+2: "moo"}

will end up different in each language.}