Hi Brian, The trick there is to put your "cool technical things" in the right business or user context, for example:
- cut system response times - make whatever system you're working on easier to understand - give them more control - lower cost - better uptime - reduced risk - deliver features faster - etc. This will *all depend* on who you're talking to (eg. CEO vs. direct manager vs. HR vs. "internal customer" vs. ...). And if the cool technical things don't have any impact along those lines, generally you shouldn't be doing them :) Usually in an interview (esp. at the more senior levels), you're looking for a 'fit' - ie. here's cool stuff that I can do which will help your organisation. Focus on that, rather than trying to fill out their interview checkboxes, and you'll find a lot of the other stuff that you're 'supposed' to do, such as - having clear technical skills - asking focused, directed Qs - researching the org - generally being personable and easy to get along with - etc will come along with it. eg. if you don't know what the company does, you have no idea where you fit in, other than "I am a Python dude" and start talking about technical Python things -- in which case *you lose*, because if they're non-technical they have no way to evaluate that. My 2c worth, Anthony *ps.* As an example of this, I interviewed at a relatively large company where Agile/Scrum was a big component of what they were looking for. I didn't (and still don't) have any formal qualifications or much experience in that direction, which they were keen on, but I was broadly familiar with the terms, how you apply them, could talk about it and so on. This would normally be a bust or a 'meh', but we actually instead ended up spending most of the interview with me (nicely) giving them shit about their unit tests / testing and telling them what I would do to get it back on track. I ended up landing that one, because it was obvious that I would add value. (That, in turn, was from a "sneaky" question that I normally ask in interviews - "What was the last unit test you wrote, and what did it cover?", which I've found is a much more effective way of figuring out whether they're doing tests than asking "Do you do unit tests?" - the answer to that is usually "yes", regardless :) ) On 7 February 2016 at 12:02, Brian May <[email protected]> wrote: > Sunny <[email protected]> writes: > > > Just want to add another perspective to the above code... that would have > > applied too for anyone trying to get their first job, not just > specifically > > Agile methodology in the field of programming in python. How did you get > > your first job? Are there many python work in Melbourne? > > The jobs I have got in the past are from meeting people at conferences > and user group meetups and knowing people from conferences and user > group meetups. > > Which is possibly an indication that I am not really good at selling > myself at interviews. Especially when the interviewer is a non-technical > type person and doesn't understand the cool technical things that I do > in my time. In this case, do you keep giving lots of technical details > and overwhelm the interviewer, and do you simplify your responses and > risk underwhelming the interviewer? > > I think the solution to this is that you need to know what the > interviewer is looking for by asking the question, and for a > non-technical interviewer it is unlikely that they want to know the full > technical details. Which is unfortunate as it is the technical details > which I know and can describe the best. > -- > Brian May <[email protected]> > https://linuxpenguins.xyz/brian/ > _______________________________________________ > melbourne-pug mailing list > [email protected] > https://mail.python.org/mailman/listinfo/melbourne-pug >
_______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
