I am currently an embedded C programmer. I''ve been doing real-time embedded C for the past year. One gripe about my current job is it also involves testing a lot of my own applications as well as legacy applications. Although I find embedded applications fairly unrewarding, fortunately DBs have nothing to do with my job. A year ago I was a Windows PC programmer using MSVC++ to debug and develop an application. No formal DBs were used. I did that for one year (why did I leave?) and I came into it straight out of school. In my only two jobs so far I haven''t had to mess with DBs. This is great in my opinion because I find them generally uninteresting. However, is it pointless to attempt to avoid them forever? I am realizing that DBs make up a huge segment of the software industry. I have a job offer that entails working with Oracle and SQL to some extent. Otherwise, it deals with much cooler technologies and also has a better work environment than my current job. Should I take this offer, or wait for a more ideal offer? Note: they might be developing a lot of Java apps in the near future and writing an OLE DB wrapper around Oracle''s OCI so you can get low level DB access with VB might be cool. They hate Delphi btw. I suppose most software deals with files, and usually those files are pretty big and therefore are DBs. It might even be bad for my career and skill-set to ignore them even if I don''t care to work with them. However, I don''t think many professional game programmers deal with DBs. Perhaps the exceptions are the Blizzard programmers working on Battle.net for D2, which have my utmost respect! PS I''m extremely proficient with mainframe COBOL and JCL, which I haven''t used outside of school and don''t care to.