I am also new to the forum, so Hello.

I recently had an interview and was wondering, there were two people conducting the interview, to whom do I send the card, email, and direct the phone call too? The person who called to set up the interview with me, or both people, or all three in regard to another interview?

I often get asked, what is it that you would like to do in IT. I am a recent graduate who's 40 years old and I've been retrained due to accident on the job where I was a tradesman. I know construction very well, IT has a gazillion different factions and off shoots, going every which way. How is it possible for any student to really answer this question truthfully when really what a student knows is how to prepare for a final and how to complete a lab given a predefined list of what it is they should reproduce?

After it's been determined that the hiring company has found another candidate for the position, is it appropriate to ask the interviewer for feedback about the interview process at all?

Thanks in advance for any answers I may get to these questions.

jhack's picture

Welcome, sickle!

Send a card to each person who interviewed you. Follow up with the hiring manager weekly.

IT is definitely a kaleidoscope of roles. Here are a few ways to think about possible roles. Please accept my oversimplifications in the service of providing a framework.

First, what kind of company? You can work for a software or hardware company ("vendor"), you can work in corporate IT ("customer") or you can work for a consulting firm providing advice and/or services to customers.

Second are roles: you can create software, you can set up and configure hardware and networks, you can implement software onto that infrastructure, or you can provide service and support for those systems.

A third way to think about it is whether you interact directly with users or if you are more of an "engine room" type.

So you can choose a company type, a role, and level of customer interaction that would give you a sense of what might be best.

If you post some thoughts on this, you might find that folks on the forum could provide more detail on what that job title might be or help you refine it further (for example, "software creation" has many different specialties within it).

And congratulations on making the transition!


tomas's picture


In relation to the question of "What do you want do in IT?" you ideally should have had an answer to that question before commencing the study, and definately before looking for a job. Your lack of focus will come across in an interview as a lack of passion, enthusiasm or even knowledge of the industry. An interview is not the place to be trying to figure out an answer..

In answering the question, you should look at your strengths and try to focus on area of IT where you can use those strengths. It might be doing IT for a construction company, supporting software for the construction industry, or something where you can use construction skills such as cabling (if your physical condition allows). At least pick something that you enjoyed from your course and were reasonably good at. If you didn't enjoy any of it, then you might have a problem.

Good luck with it. Retraining into an entirely different field can't be easy.

sickle44's picture

thank you gentleman for your help with those questions, although I might have to not say thanks to tomas for calling me a sickie? LOL Don't worry though tomas, I wouldn't be silly enough to go into an interview not confident of the position I was applying for. I know what it is that I like doing, really I just don't know what the position is called, if that makes any sense as tech support can mean several different things as I'm sure you're aware?

Perhaps if I can let you know my strengths, likes and dislikes, then maybe perhaps some folks can tell me the names of those positions?

A few years before school, I learned that I am an exceptional salesman and really good with people. I really enjoy the challenging parts of programming and DB's, well, finally getting the query, or debugging the bug I guess would be more specific of a statement. The thought of being code monkey in the back corner with a box of snickers does not really appeal. These statements would tell that my schooling was primarily software based although we did have a little bit of networking thrown at us also. I'll do hardware for my self, mom and dad but wouldn't want to get paid to do hardware really.

Technologies my school taught us were primarily .NET based, we also did some Java stuff. 60% of all the work was web-based using N-Tier tech. They did a very poor job of UML, UP, or SDLC which ever you'd like to call it and I really didn't like that stuff much anyways. Always using MS SQL for the back end which most of the times we built ourselves unless the DB was really big in which case you had to fill it with test data at least.

Please feel free to ask if I haven't been clear enough. Thanks again.

tomas's picture

My sincere apologies for getting your name wrong. My brain some mental gymnastics and made entirely the wrong connection.

Position descriptions can really be a problem in IT. People use different terms for the same position, and the one term for very different positions. Tech support usually means general IT support. Application support or helpdesk might be application specific.

It sounds like your training is really focused on .Net programming. If you want to pursue sales then you could look at technical pre-sales support roles, which basically means that you can handle technical questions are part of the sales process. If you are good with people you could look at areas like training. A business analyst needs to be good with people, but might be a bit hard to get into without some experience.

If you like databases you look at being a Database Administrator (DBA) but that is more of a backroom position.

Not sure if that helps, but please feel free to bounce any ideas around.

jhack's picture

Couple thoughts:

Do a Google search on "IT Job Descriptions" (use the quotes). All kinds of interesting links will appear (ignore the first one).

"Database application developer" would fit what you described above.

Don't pigeon-hole yourself. Think about the kind of work you're good at rather than the title. For example, T-SQL and ANSI-SQL are a little different, but if you're good with MS SQL Server, you should be good with Oracle in short order.


stephenbooth_uk's picture

The following is based on my own experience and observing those around me.

Recent graduate jobs in IT tend to be either development or desktop. Starting out in development often means programming. Entry desktop support jobs can often be in call centres and may be for third parties.

Development does tend to be a youngsters game, people over 30 in that area tend to be in more design/analysis type of roles. Knowledge of programming languages can be important in development roles. Flexibility and the ability to take what you learned in one language and apply it in another are really valuable. Demonstrating that you can maintain other people's code is often useful. Contributing to an open source project could be one way to demonstrate that you can bug fix and add functionality to existing code.

Desktop support tends to have a very high turn over. People tend to use it as a stepping stone to other IT roles. In larger organisations desktop support tends to be very much automated. You follow a script to get the details of the incident then follow another script to resolve it or route it to 2nd line support. In smaller organisations the role tends to be much looser. You find yourself dealing with the desktops, the network and the servers. It's also not unusual to find yourself getting exposure to a breadth of things that you'll not have the opportunity to see in a larger organisation unless you're really lucky.

My first IT job was in a 70 person software house. I was supporting about 100 PCs running various flavours of Windows (3.11 to NT4.0) and AIX, Digital UNIX, VMS and Netware in the server room. I also supported Oracle databases (versions 5 to 8i), the network and most of the hardware. After a year I landed up doing systems testing, first debugging then later developing the installation documentation for our product. Eventually designing systems and doing pre-sales support. It was the best possible training for my subsequent career. Flexibility is the key in IT. You’re constantly moving and always have to be ready for the next version of whatever it is you're working on or for the next new disruptive technology to come along and change or replace whatever it is you're working on. Fifteen years ago the Internet was irrelevant to most businesses, now it is many businesses

A DBA role, mentioned by Tomas, depends on what sort of DBA you become Broadly speaking DBAs come in three flavours:
Applications DBAs tend to be applications support people who mostly work in the database. You spend a lot of time tuning SQL.
Development DBAs tend to be developers who mostly work in the database. You spend a lot of time writing and debugging SQL.
Infrastructure DBAs tend to be the ones who keep it all up and running. You don't do that much with SQL except what you need for diagnosing issues and changing settings but you do tend to need to know the whole technology stack from the front end the user sits at down to the storage hardware the data sits on to some degree.

You might combine two or all three of those roles (especially in smaller organisations) but they also exist as distinct roles. Obviously if SQL is your thing then a pure Infrastructure DBA role is unlikely to satisfy. If you like to deal with the full technology stack then you'll love it.

You might want to consider something not strictly IT in nature, Business Analysis might suit you. As a Business Analyst you're the interface between IT and 'The Business'.

sickle44's picture

gentlemen, thanks very much for the all the help, it's great really!!

tomas, hey, Forget about it!! I was really only just poking fun, not offended at all.

Thanks again guys!!!