Skip to main content

Career Resources — Technology

Finding & Applying

Technology can be thought of as a sector rather than its own industry, as it is a subset of virtually all industries. Attending information sessions and career fairs will allow to you have discussions with recruiting staff to see what technology opportunities exist with your top companies. Many of these opportunities can be found on Go IRISH, but it is helpful to connect with alumni in the field to learn more about the specific opportunities. 

Hiring Timeline

Tech recruiting for both full-time and internships kicks off in early fall.  A large portion of the tech recruiting will be done by Thanksgiving, but there will be more “just – in – time” opportunities that occur in the spring semester.  The internship between Junior and Senior year is a critical component to the full – time search.  Many larger corporations will hire for their full-time positions from their intern class

Job Boards

While Go IRISH is an excellent resource for jobs in technology, there are also specific tech job boards that will have additional opportunities outside of Go IRISH.  Many companies will also utilize social media as a major recruiting tool and may conduct all interviews virtually vs. recruiting on campus. 

Additional Job Boards

Interview Preparation

Preparing for a tech interview depends greatly on the industry which it is nested in and the nature of the position itself. Coders may be asked about C++, Java, or Unix. Software implementers may be asked about prior project management skills. The best way to prepare is to have a discussion with your campus recruiting contact and then following up with the “ND Student Interview Feedback” document on the homepage of Go IRISH.  Here are tips for a variety of technical Interviews:

Preparing for a Technical Interview

Data structures and algorithms and operating systems

Data structures - Stick to basics if you have not taken the class yet

  1. Linked list, binary tree, stack, queue, hashtable
  2. Trees especially have lots of types and specific knowledge
    • Breadth first vs depth first search
    • Traversal (post order, pre order, in order)
  3. Be familiar with run time of access, insert, delete, traversal
    • This is what determines what they’re best used for
  4. Wikipedia is a great resource once you’re curious about a specific structure


  1. Sorts and searches
    • Again, know the basics, their run times, when it’s good to use which
    • Ideally, be able to code them
  2. Lots of classic / repeating problems in CS


  1. Overview of topics to study (very comprehensive) 
  2. Basic data structures overview 
  3. Cracking the Coding Interview:  Google it for a free PDF - yes it’s a book but SO valuable

Conceptual Interviews

Personal Technical Knowledge Brush up on specific technologies you’ve used and related technical jargon

Technology specific questions

  1. Utilize frameworks - particular aspects of a technology or language - examples:
    • What is the difference between a POST and PUT request?
    • Stuff about databases / database design
    • Memory management in Objective C

General CS concepts / problem solving / design questions

  1. More general/fundamental topics
    • Example: Explain a design pattern (usually of your choice) (Singleton, Factory, MVC, lazy instantiation, observing)
  2. “How you would approach this problem” - questions where the answer is talking through the code you’d write or how you’d design the solution
    • Examples:
      1.  Questions about object oriented programming (design a class structure for a parking garage)
      2. What data structure would be best for X? / What are the pros/cons of using some data structure for X?

Coding Interviews

Note: These tips are heavily influenced by a workshop at Google, advice from Google interviewers, and experience interviewing with Google specifically. Many apply generally, but some are more true at Google.

Explain your thought process at all times

  • Even if you are unsure about your answer, sharing your thought process is better than remaining silent
  • Start simple (brute force/”dumb” solution) and optimize later
  • Think out loud and say whatever idea you have out loud
  • Talk about why you’re exploring a specific solution
  • Reaching ANY conclusion is better than not, even if it isn’t the best one
    • Talk about tradeoffs, decisions

How to break down and work through a problem

  1. When first asked a question:
    • Paraphrase it to make sure you understood them
    • Jot important parts down
    • Ask clarifying questions - they often don’t give you all the detail right away
  2. Should I optimize for something? Speed? Memory? Are there any additional constraints? (usually the answer at first is no, then these twists get added in once you have something basic working)
  3. Structure the problem before beginning to code
    • List assumptions that you’re making (even write them down)
    • Talk about its downsides or directions to take from there
  4. It will help you think of better solutions by getting ideas flowing
  5. Develop a general flow of how you’re going to solve the problem
    • Use diagrams, flowcharts, text, pictures if it helps you to illustrate thought process / approach
    • Be talking through it, explaining it clearly
    • Don’t jump straight into coding, but also don’t spend so long looking for a solution that you hardly leave enough time to code = keep a good pace
    • Once you have a decent idea of how to proceed, start coding

Coding tips

  1. The interviewers will want syntactically correct code, BUT don’t waste precious time writing basic things they know you can do that aren’t essential to solving the problem. Example: initializing something with a for loop
  2. Ask if they want you to code it or if you can just put a comment noting that’s what you would do
  3. Utilize the language you’re most comfortable with and know the best
    • You will be coding in a text editor or on a whiteboard (i.e. no error checking, auto fill, etc.)
  4. It isn’t worth showing off - you’ll end up looking worse because it’ll be clear you don’t know totally what you’re doing
  5. Don’t utilize features of the language you aren’t 100% sure how to use – It is better to use a more simple method than get mixed up trying to use something fancy
    • They are more interested in your thought process
  6. If running low on time, start putting in comments/names of methods as placeholders so you can get the basic flow written (you may want ask if this is okay first)
  7. Make sure you clearly explain what the method would do and any side effects it would have
  8. Go back and implement it if you have time - It’s better to get the skeleton written and have shown your whole thought process than to not because you got hung up perfecting one aspect of it - Also do this if you don’t know how you’d deal with something and know you’ll lose a lot of time trying to figure out
  9. The interviewer may stop you if they want you to actually implement it / you can ask if it’s okay to “skip for now”
  10. If you finish, go back and debug and test
    • Test by talking through edge cases and how your code would handle them
    • Especially test for boundary conditions (ex: out of the ordinary, very large, or very small input)
    • Point out and correct any bugs you find - If you don’t, they will. You want to be the one to find it.
  11. If you’re stuck, don’t freak out - Ask for a hint/guidance
    • For example:  “Do you think this is a good direction to take?”, “I’m not sure where to go from here…”
    • Acknowledge you don’t know how to do something, but offer what you do know
    • Try to avoid doing this if possible - Only if you really, really don’t know how to do it and there’s NO other way
  12. Backtrack and try another idea if you realize your first approach won’t work
    1. Just make sure to explain why it won’t work and why you’re choosing the new one

Interaction with the interviewer tips

  1. Be patient and polite if they interrupt you, correct you, or don’t follow your logic
  2. They’re most interested in your technical ability but still want a great human too
  3. All normal interview tips apply - look clean/presentable, have good manners, don’t be arrogant, show passion for company and position

If you get flown out and are whiteboard coding

  • Make eye contact with the interviewer
  • Try not to turn your back to them too much when writing code on the board