interview questions

Can anybody explain me these interview questions?

2.Difference b/w 7.33 and 8.11 FUNCTIONAL wise aswell as upgradation wise.

5.Want to retrive data from 10 tables.How?

7.Any info abt cache memory?

8.what is unicode ?

Probably these are not answers to your questions. Still I guess my reply helps u

[ QUOTE ]
2.Difference b/w 7.33 and 8.11 FUNCTIONAL wise aswell as upgradation wise.

[/ QUOTE ]

Search Oracle.com/ Jdelist.com. You will get more data



[ QUOTE ]
5.Want to retrive data from 10 tables.How?

[/ QUOTE ]

Table I/O simple answer

[ QUOTE ]
7.Any info abt cache memory?

[/ QUOTE ]

Have a look at http://en.wikipedia.org/wiki/CPU_cache

[ QUOTE ]
8.what is unicode ?

[/ QUOTE ]

Have a look at http://en.wikipedia.org/wiki/Unicode

[ QUOTE ]
5.Want to retrive data from 10 tables.How?

[/ QUOTE ]

If I wanted to retrieve data from 10 different tables, I'll tell you one thing; I wouldn't use OneWorld. It's kind of clumsy at that sort of thing.

"Thank You uh Adam, and that will conclude our interview.......If we have any more questions....nevermind.....good bye." And that concludes another ?successful? interview.

just kidding.
Ben again

Are you kidding? I'd make the guy Vice President for a response like that (assuming I were CTO). In fact, when I'm interviewing I want the prospect to tell me how to do things outside the tool. Trapping your head in the jde guide is a career killer in my book.

If there is one thing I learned from the WP (and there are many...) , it is this. Do NOT limit yourself to the tool. Whether it is OW, or any other... get the job done. The concept of what needs to be done is what matters. Not how it fits into the confines of your tool set.

I'm still working on that... but I always keep that in mind.

Forgive me as I did make some assumptions.

One, someone interviewing for a Vice President's position would never get the question in the first place.

Second, someone being interviewed for a OneWorld Developer that always recommended ways to not use the software would never get hired - oh except for by you - but then you aren't really a company that owns the software.

Three, if I was interviewing someone and they expressed as much disdain for the product as you seem to be expressing, I would stop the interview immediately.

Four, some of us LIKE the career that OneWorld has given us for the last 13 years, and working around capabilities that OneWorld lacks is just fine, but coming up with work-arounds just to "do things outside the tool" is not especially constructive.

Ben again,

Thank you Reddy

Hey Darrin, I'll consider that high praise.

And if anybody out there is interviewing some random fellow and gets that answer (hopefully word for word) or gets referred to a wikipedia article on CPU caching, I think we all have a right to hear the story.

I think I'm more in agreement with WhippingBoy. Knowing the limitations of the toolset is critical, and in most cases, essential if you want to advance.

Ouch, Ben.

I don't 'always' recommend using things outside the tool. I certainly don't disdain the tools (ok, maybe TC - that thing still needs some work!). The tools have come a very long way from 1995. I like them, and they make life easy in lots of ways. However, they are just what the name implies; tools. They aren't solutions, they're tools. In most cases they are the means to the solution, but in some they just can't be used.

My response was mostly towards the 10 table question. In my opinion the answer is not Table I/O. I believe it's a trick question and it's regarding joins. How do you read from 10 tables at once? Answer: you can't . . . . unless you go outside the tool: table views(database-not Business Views), stored procedures, custom query code, etc. The question was probably for ferreting out the programmers with no experience. The tool stops you at 5 simple joins. But maybe it was also to see who can offer 'solutions', too.

I've written about this stuff before, so there's no need to do it again. The short version is: in my experience employers want people who will offer 'solutions', not just 'the tools allow for x,y,z.' 'Thinkers' who are knowledgeable about the options make better programmers. That's what I meant about 'career killer.' The tools won't live forever, so don't put all your eggs in one basket. Conversely, it's good to consider hiring people who own more than one basket.

Lastly, I LOVE my job in E1. I have worked on immensely challenging projects and it's been a joy to be able to write all sorts of solutions with and without the JDE tools: Advanced Pricing, Integrating Logility, Integrating Sterling Commerce, UPS/USPS/FedEx Integration, Java, XML, JDOM, C++ (not bsfns), MFC for ODBC dlls, Digital Signature Capture, embedded JavaScript, and on and on. Most of the time I use the 'tools', but there are times when they aren't the right solution.

You get my vote! ;-)

Perhaps I owe the forum an apology. I say perhaps because I am still mulling it over. At least I can provide an explanation. I have been developing in JDE OneWorld for 13 plus years and find myself in a new situation. I have been on the bench for four weeks now. With the stock market tanking and me quickly approaching my 49th birthday, I am finding myself worrying about what is next.

I'm not telling you all this so you start feeling sorry for me. But when I see clients overcustomizing and blaming the software when it runs slow, or rookie programmers trying to make a Fix Inspect have a Find Button, then I get yelled at because I say that it will take longer than expected trying to add a field (because it is not in a table)- I get tired of defending a decent software package. The best analogy I can think of would be the rest stops on american highways. Rest stops are really a nice uhm service, except when you have to follow a few hundred people that have no sense of hygiene.

Anyway, I am just venting right now so ignore me.

In anycase, I am for finding a solution withing JDE first, then finding a solution outside of JDE. If data retrieval needs to be faster, I am going to look into indexes on tables before trying to create C functions specially tailored to retrieve data. In answering the interview questions, I would probably talk about the limit of business view joins and the bulkyness of ten table I/Os but I would mention them first before bring up Database views. If I had been the interviewer and the interviewee went straight to Crystal Reports without mentioning the other limited options, I would have to dig much deeper, because my primary purpose to the interview is to find what the interviewee knows about the software that we are using, not ways of getting around it. In fact, I have seen so many developers recommending Visual Basic solutions instead of JDE Development that it would make your head spin.

Now as far as 'solutions' versus 'tools'. I HAVE come across clients that want the answer to both. Many clients have chosen capabilities that were available within JDE over those solutions that were available outside JDE even though it meant they had to adjust their expectations. Because of this, I have gotten in the habit of providing both what is available withing JDE and what is available outside JDE and what the consequences are with each options in regards to support/upgrades/maintenance.

Ok, WhippingBoy, maybe I was a little oversensitive, please accept my apology.

Ben again,

Yes, this is a very agreeable approach, you get my vote too! ;-)